spf13
Should I use the Apache license
Hey Steve(@spf13),
I've been using and loving this wonderful tool for quite a while. And it's been a great helper in my Go CLI forays!!
Alas, some things have bothered me:
- We can not opt out of any licensing related things( #115 ).
- The tool overwrites without asking( #112 ).
- A small gripe with the fact that if we
initwith a path, we then have to change to said path in order to add commands. - There's been no activity for the past two years, as of July 2025.
Being a programmer myself, I have the means/tools to scratch this itch.
And so I did: cobra-cli-ng
I've tackled #112 in my implementation, and added a --force flag, because sometimes we know what we're doing... ish... 😄
I've not yet tackled the author/license as of yet. I'll give you another ping once I've completed that.
Since I drew a ton of inspiration from your code, and preferring an MIT license, I want to ask if you could have a look at my code and see if it's different enough that a change of license from Apache 2.0 to MIT is legal.
Of course: No pressure and when you have a bit of spare time!!
Nonetheless, I cannot thank you enough for releasing this tool to the joy of so many!!
Cheers, Gus
Why not just contribute these to the main project? These have all bothered me too 😎
On Tue, Jul 22, 2025 at 5:09 AM gcarreno @.***> wrote:
gcarreno created an issue (spf13/cobra-cli#119) https://github.com/spf13/cobra-cli/issues/119
Hey @.*** https://github.com/spf13),
I've been using and loving this wonderful tool for quite a while. And it's been a great helper in my Go CLI forays!!
Alas, some things have bothered me:
- We can not opt out of any licensing related things( #115 https://github.com/spf13/cobra-cli/issues/115 ).
- The tool overwrites without asking( #112 https://github.com/spf13/cobra-cli/issues/112 ).
- A small gripe with the fact that if we init with a path, we then have to change to said path in order to add commands.
- There's been no activity for the past two years, as of July 2025.
Being a programmer myself, I have the means/tools to scratch this itch. And so I did: cobra-cli-ng https://github.com/gcarreno/cobra-cli-ng
I've tackled #112 https://github.com/spf13/cobra-cli/issues/112 in my implementation, and added a --force flag, because sometimes we know what we're doing... ish... 😄
I've not yet tackled the author/license as of yet. I'll give you another ping once I've completed that.
Since I drew a ton of inspiration from your code, and preferring an MIT license, I want to ask if you could have a look at my code and see if it's different enough that a change of license from Apache 2.0 to MIT is legal. Of course: No pressure and when you have a bit of spare time!!
Nonetheless, I cannot thank you enough for releasing this tool to the joy of so many!!
Cheers, Gus
— Reply to this email directly, view it on GitHub https://github.com/spf13/cobra-cli/issues/119, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABKKZESTN2HLDPS6B5IRJT3JX5WBAVCNFSM6AAAAACCCHIXO6VHI2DSMVQWIX3LMV43ASLTON2WKOZTGI2TCOBRHEZDSNA . You are receiving this because you were mentioned.Message ID: @.***>
Hey Steve,
Why not just contribute these to the main project?
OOFFF!!! Was dreading this question... Was expecting it, still, did not see it coming 😄
OK, putting my serious hat on.
Of course I had a look at your code. I could not whip out a copy of your features so quickly( cobra-cli-ng v0.0.1 ) if I didn't study it.
Setting aside programming habits/philosophies, and looking at your code objectively:
- You've skipped the separation of concern concept.
- Don't remember if
embedwas out 2 years ago, if not, no biggie. But I'm using it. - There's probably more stuff, but I don't want to be rude or in your face with picky details.
If you look at my code, you'll notice a big OOP influence... Yeah, I come from an Object Pascal/PHP background, and OOP is always my starting point in any new project. Even when I can only use the Interface concept.
But all of the above, is just a lot of filler to the main reason: I never quite felt comfortable, or qualified, to change legacy code. Sure, I am being a tad selfish. And the only excuse is no excuse at all: It is, what it is...
Soooooo.... What else can I say? I dunno...
Ultimately, if you think I'm going in the right direction, what we could do is just replace the current code base with mine. Again, a very selfish solution to a problem you don't have. And ultimately, it would probably break the huge amount of projects that are listed in the "Used By" section.
OK, enough babbling and beating around the bushes!! Please let me know if we have a path forward in terms of me contributing to this repo. If so, please, please, with sugar on top, give me some options for me to explore, or mull over.
I think that at this moment, that's the only thing I can say.
I deeply apologise if this is not what you had in mind. I'm old( 55 ), set in my ways, and it's a bit hard to nudge me 😄
Cheers, Gus
Hey Gus (@gcarreno),
Thank you for such a thoughtful reply. Your feelings about jumping into a "legacy" codebase are completely understandable. I've felt the same way about my own old projects. No apology needed.
You've hit on a core truth: projects evolve, and how we'd write something today differs from years ago. I first started this project over 10 years ago. A lot of things didn't exist yet. Your critiques about separation of concerns and missing embed features are spot-on.
This is what contributing to open source is about. It's not about being "qualified" or adopting existing styles perfectly. It's about bringing fresh perspectives and energy. You've identified problems and proven solutions in your own project, that's the hard part.
A full rewrite would disrupt thousands of projects, but evolving with your ideas is the perfect path forward.
A proposal for you:
You solved the "overwrite without prompting" issue (#112). Would you submit a PR for just that fix? It's a perfect way to get started, and it will breathe some life into this subproject with its first contribution in years.
For bigger architectural changes, open an issue like "Proposal: Refactor command logic for better separation." We can agree on direction before writing code.
Let's tackle the --license flag flexibility you described. I'm open to ideas on how to do this. It should be a relatively simple fix.
Your experience is a huge asset. The project needs your perspective. Let's start small and see where it takes us.
What do you think?
Cheers, Steve
Hey Steve(@spf13),
First of all, let me say that I'm gobsmacked by your kind words, after a rambling mess that was my response!! Thank you so much for those kind words !!
You solved the "overwrite without prompting" issue (https://github.com/spf13/cobra-cli/issues/112). Would you submit a PR for just that fix? It's a perfect way to get started, and it will breathe some life into this subproject with its first contribution in years.
That's actually not a bad idea. And starting small, usually takes the edge off. A major overhaul is indeed needed, cuz 10 years... Yeah, RUUF!!! 🤣 And tackling an overhaul, with this history will need a bit more time and a lot of discussion!!
For bigger architectural changes, open an issue like "Proposal: Refactor command logic for better separation." We can agree on direction before writing code.
Also a very good suggestion!! I'll tackle that when my brain decides to sleep more than 6 hours after a 24h+ stint 😄
I kinda did what you see on cobra-cli-ng in about 15 to 19 hours, straight. So yeah, tired 😄
Let's tackle the --license flag flexibility you described. I'm open to ideas on how to do this. It should be a relatively simple fix.
Yes, having a default of opt-out and not leaving empty license headers on the source 😜
I'll give you a bit more input on this when I, myself, have mulled it over.
At the moment I have nil license related code on cobra-cli-ng, so I haven't even put my brain to work on those.
When I do, I'll have some questions about it, so I'll ping'ya!!
Side note: I already have some questions to ask from the brief look at most of the code. Right now, there's that helpers.go file that has a single init() and, from a quick glance, doesn't seem to touch any variables on the code base. But don't explain it to me yet!!
I need to do a deep dive if I'm a tackle the addition of a --force flag on cobra-cli.
This will ensue a ton of other questions and picking apart your 10 year journey 😜
Let me ask, very politely, that my brain, please, give me a proper sleep period and I'll start tackling some of the above discussed issues.
Until then, in hopes all's fine and dandy on your side, I'll sign off 😃
Cheers, Gus
Hey Steve(@spf13),
Since I was too tired to code, but not tired enough to peruse the current issues and PRs, I kinda noticed one thing:
A lot of the past grievances have been either addressed in an issue, or has one or more PRs to fix it.
Not trying to be snarky, or anything, but there's about 2 dozen PRs that have been completely ignored. Some of them with rather clever solutions for a lot of the various iterations of the same issue.
I'm now worried that if I do get myself all hyped up and submit a PR, it will probably sit in that pile of a couple of dozen that already exists and just... gather dust and cobwebs...
Having said that, a lot of the PRs are now truly stale, both in terms of time, and in terms of the evolution of Go. Not sure trying to apply them would even make sense.
Steve, can you please give me your opinion of the current state of the accumulated PRs and, if it's not asking too much, why it got to this state of abandonment?
Many thanks in advance for your patience and time!!
Cheers, Gus
Hey Steve(@spf13),
After I looked at this project a little bit deeper, some red flags suddenly popped up.
Mainly the fact that a lot of the issues that abound, have one or more PRs to solve them.
But there's also the fact that none of those PRs have ever been applied, or even cleaned up, if they didn't match the philosophy of the project.
And I need to, strongly, point out that I understand:
- Having a busy life.
- Having too many projects in the air.
- Losing interest in a project.
- Getting bored of a project.
- Chasing the shinnies.
Heck, I'm guilty of all the above!!
So, I let some time pass. And GitHub is now telling me that 2 weeks have past. During these 2 weeks... crickets!! But the initial conversation, based on "I'm re-doing your project, instead of contributing to yours", that one had an immediate reaction. And, at least, one follow-up. But then... crickets...
I even, politely I hope, mentioned the lack of attention towards this project, never thinking that I would write this follow up. We had such a nice start of this conversation, that I kinda assumed, probably naively, that it would continue.
Alas, this was not the case. And it makes me sad because I don't understand why. I can speculate, and this takes me to some dark places, so I better not!!
In conclusion, at this point in time, there's not much incentive to be a good member of the open source community and add another PR that will just gather dust. Especially because of the fact that I have no, polite, way to influence you into action 🥲
And I don't know what more to say. This is not a post made in rage, but more in disappointment. ( So sorry for the cliche!! )
Cheers, Gus