15 ms·
HashiCorp switching to BSL shows a need for open charter companies
- heipei 3y agoJust taking this opportunity to highlight again how stupid BSL licensing for HashiCorp Nomad is when they don't even offer their own cloud product for it...
- wmf 3y agoYeah, they relicensed all their products going back to Packer and Vagrant even though their "problems" seem to be related to Terraform and maybe Vault. It seems like an overreaction.
- nickstinemates 3y agoAre there alternate Terraform implementations? I assumed this was all about Vault.
- thinkmassive 3y agoThere’s a huge ecosystem of tools and cloud products that augment terraform. Refer to the list of OpenTF supporters: https://opentf.org/#output https://opentf.org/#output
- nickstinemates 3y agoWhen I clicked through the companies listed here previously, all of them seemed to support Terraform plugins which are not part of the re-licensing. They didn't maintain downstream forks of Terraform proper. I'll look again.
- candiddevmike 3y agoIMO, Nomad was already on life support, putting a nebulous BSL on it is a death sentence.
- fhaldridge7 3y agowhat makes you think so? I didn't use nomad but looked into it recently. The github repo has multiple commits every day and there are new nomad videos on the hashicorp youtube channel every few weeks
- justinclift 3y ago> Nomad was already on life support ... Ouch. Looking at Nomad has been on my ToDo list for ages. What's the better alterative?
- lantry 3y ago"better" is very subjective, but kubernetes is the most popular choice
- SirensOfTitan 3y agoSome managed k8s from a cloud provider, which is fairly close to cloud agnostic compute outside of persistent volumes. The HN trope is "you don't need k8s," but k8s manifests have a lot of mindshare behind them. I'd rather use a managed k8s versus manage my own Nomad pool. Sure, managed k8s is complex for cloud providers, but I can mostly offload that complexity provided I'm not full microservices inside the cluster.
- skinner927 3y agoI’ve yet to find anything that fills the void of running containers, VMs, and whatever else you want to add a “driver” for, in such a simple distribution. You can run nomad on one slow host or 30 monsters. Works great for teams who can’t use the cloud.
- GordonS 3y agoHuh, not sure why you'd think that? Seems to me like it's never been more popular.
- PlutoIsAPlanet 3y agoNomad has taken the same niche that home-lab Docker clusters had. Docker Swarms ease of use is an advantage over Kubernetes for small setups, but its filled with bugs and basically unsupported. Nomad is a viable replacement for that setup.
- mind-blight 3y agoDoes anyone know much about OCV? I haven't heard much about this firm, but the investment model seems really intriguing. I also appreciate that the article on staying open source and maintaining trust is written by a VC firm. That's really putting your money where your mouth is.
- neon_electro 3y agoThe author of the post, and the General Partner of the firm is Sid Sijbrandij, CEO of GitLab (@sytse on here, and @sytses on Twitter/X)
- sytse 3y agoYep, more about OCV on https://opencoreventures.com/ https://opencoreventures.com/ TLDR; we start new open core companies around existing open source projects.
- justinclift 3y agoHave you had much success with companies post-VC? eg after they're acquired, IPO'd, or dissolve? Asking because things seem to still be at an early stage with yourselves (thus far), so not remembering anything that's reached the end of the VC pipeline yet.
- sytse 3y agoIt is indeed early stage. The oldest company is Fleet https://fleetdm.com/ https://fleetdm.com/ who do open source device management and raised at $100m post in 2022 https://techcrunch.com/2022/04/28/fleet-nabs-20m-to-enable-enterprises-to-manage-their-devices/ https://techcrunch.com/2022/04/28/fleet-nabs-20m-to-enable-e...
- monksy 3y agoLet's not forget about Lightbend in this with Akka.
- marktani 3y agoContext: https://www.lightbend.com/blog/why-we-are-changing-the-license-for-akka https://www.lightbend.com/blog/why-we-are-changing-the-licen... TL;DR: In September 2022, Lightbend changed Akka's license from Apache 2.0 to BSL 1.1
- deleted 3y ago[deleted]
- bcantrill 3y agoWhat ended up happened there? Has Pekko gained momentum? If so, it would be helpful to add it to a list of these: part of the problem is that moving to the B(U)SL is viewed as having no risk -- when it fact, it is risking everything (e.g., Sun/Oracle and Hudson/Jenkins).
- monksy 3y agoLightbend put the cutoff on version 2.7, claims no more updates. They pushed the actual enforcement back 1 year. We'll see this fall about when this hits. Pekko is playing catchup right now. Also, they're a bit of a small crowd. (As in .. under lightbend Akka has developed a crowd.. but Pekko has to struggle to form now)
- candiddevmike 3y agoThey also published an FAQ recently: https://www.hashicorp.com/license-faq https://www.hashicorp.com/license-faq This all should be incorporated into the BSL, as the current terms are clearly vague enough that they require a separate (not legally binding) FAQ (as it can be changed at any point...)
- deleted 3y ago[deleted]
- z3tjjRrm2K 3y agoHashiCorp has stated that the FAQ is legally binding: "Our goal with the BSL license was to make it short and simple. This means the FAQs play an important role in providing interpretive guidance to our users. We view the guidance in these FAQs as binding, so users of our software should feel assured in relying on them as our official positions now and in the future." https://www.hashicorp.com/blog/hashicorp-updates-licensing-faq-based-on-community-questions https://www.hashicorp.com/blog/hashicorp-updates-licensing-f...
- yebyen 3y agoI don't think that's what GP means by "legally binding" When a company gives you a license that has terms written in it, that license is binding... on them as well as you. When a company gives you a document that refers to an FAQ that they can change on the fly to meet their needs, and make changes to it, that is a signal that they do not view the license's terms as binding on them. Only on you (the user / developer working on an integrated or derivative work.) The license that grants you permission to use the software as long as you remain on the right side of this line, which we can move as we deign it necessary to move the line is not much of a license grant. I just heard it called "bullshit license" and I think that's the best explanation for what BSL actually stands for now. I support Hashicorp's right to make money from their business, but I think these lawyers are in over their head. It doesn't make much sense to me. We'll have to see who gets a license grant from Hashi and how much they're going to pay for it.
- 3y ago
- RobotToaster 3y agoOpen core is just as bad as BSL.
- benatkin 3y agoNot true. GitLab may not be perfect but it is used in many open source places. HashiCorp's products have been rendered completely unworkable for places like Debian. https://salsa.debian.org/public https://salsa.debian.org/public
- tremon 3y agoWhat is that link supposed to show?
- benatkin 3y agoThat Debian is using GitLab. They have for some time.
- justinclift 3y agoHmmm, how does the change to BSL affect Debian's infrastructure?
- benatkin 3y agoI don't think Debian uses Terraform much, if at all, but if they do, I think they would start to phase it out. As for GitLab, it isn't changing to BSL, so they can keep using it.
- fomine3 3y agoWhat's the point that what Debian developers use? Historically, Linux developers used proprietary BitKeeper.
- 3y ago
- SirensOfTitan 3y agoDidn’t Pulumi accelerate its adoption by the use of Hashicorp terraform providers? Didn’t AWS use elastic search for free then fork when the license changed? I think there are a lot of challenges around building a sustainable business around OSS that requires a more delicate look than the black or white hot takes around here recently. …with that being said, I will say that I welcome companies like Pulumi to the IaC landscape. IaC makes a lot of sense conceptually, but unlike a lot of HN (from my perspective), I strongly dislike terraform and HCL and most Hashicorp products. There’s also enough of an impedance mismatch between TF and cloud providers that I’d be poised to just use cloud formation or ARM or something native over tf, which was never cloud agnostic anyway like their marketing claims.
- deleted 3y ago[deleted]
- candiddevmike 3y agoTerraform is cloud agnostic the way a fork is food agnostic. It's a tool, if you were thinking the tool abstracted clouds in a "write once deploy everywhere" way (which HashiCorp's marketing has hinted at), you probably shouldn't be using it.
- mburns 3y agoTerraform providers weren’t relicensed under the BSL.
- hypeatei 3y agoI don't ever recall getting the feeling that Terraform was cloud agnostic when I was new to IaC. There is different providers within it that provide platform-specific resources which is self explanatory.
- grudg3 3y agoPlease do not use ARM in 2023, Bicep is a much nicer alternative for a native IaC language.
- GordonS 3y ago
- cube2222 3y agoOn a related note, if you haven't seen it yet, make sure to check out the OpenTF Manifesto[0]. More info coming on Friday! [0]: https://opentf.org https://opentf.org Disclaimer: Work at Spacelift
- hrpnk 3y agoI recognize MixPanel as a big player. In the end with this level of interest, they should just move ahead and do the fork. Companies will switch to the open alternative, just like they did with Pekko for Akka. SaaS providers will offer two versions - the Terraform one and the open one - they won't really have a choice.
- lijok 3y agoHad a scan through the list. Checkout.com, Argo Devops Solutions are the other two big boys. Interested if this actually picks up steam.
- bcantrill 3y agoWe did a podcast on Monday with some of the OpenTF folks[0]; it was very inspiring to hear of their efforts -- and left us looking forward to Friday! [0] https://oxide-and-friends.transistor.fm/episodes/fork-in-the-road-for-terraform https://oxide-and-friends.transistor.fm/episodes/fork-in-the...
- philip1209 3y agoIt makes me sad that we don't appreciate the 10+ years that Hashicorp put into open-source. It's open - somebody else can pick up where they left off, if they really care (like OpenSearch did for Elasticsearch).
- deleted 3y ago[deleted]
- mixedCase 3y agoAs stated in the article, that's exactly what is being considered.
- birdyrooster 3y agoIt's obvious that Hashicorp projects will be forked, but less obvious why Hashicorp would fall on the sword like this because next is their irrelevance. I will miss what they once were.
- dwaite 3y ago> It makes me sad that we don't appreciate the 10+ years that Hashicorp put into open-source. I do appreciate it, in the sense that I am saddened they are throwing away that value and their good-will. There are almost certainly enough commercial interests in terraform to join together on a community fork. The nature of terraform providers in particular means that the community fork would almost certainly then become a primary target for providers. I suspect nowadays many people using the project don't even realize that the Jenkins CI system was actually a fork of another popular system at the time named Hudson. It was forked due to claims being made by Oracle legal, and even after they straightened things out and made Hudson an open project (with assignments to Eclipse foundation) the damage was done and Hudson died off.
- dzogchen 3y agoBoy am I happy I never invested too much time in their software.
- wmf 3y agoAs I said the other day, this open charter concept sounds like a suicide pact that removes future options and flexibility. But maybe it will turn out to be a constraint that triggers innovation in business models.
- Coryodaniel 3y agoHashiCorp hasn't been committed to open-source community in years, particularly with Terraform. Their own words https://github.com/hashicorp/terraform/blob/ad634f60a5acbaade1eb8c225564e17ad2267f00/.github/CONTRIBUTING.md#:~:text=Due%20to%20current https://github.com/hashicorp/terraform/blob/ad634f60a5acbaad...
- capableweb 3y agoNot accepting outside patches have nothing to do with if the software is "committed" to FOSS or not.
- Coryodaniel 3y agoI said > open-source _community_ Listen to the Hashi CEO talk about community @18m https://youtu.be/59rEiAyYEVk?t=18m https://youtu.be/59rEiAyYEVk?t=18m
- OnlyMortal 3y agoSo I gather “BSL” isn’t British Sign Language then?
- LAC-Tech 3y agoHowever, there’s a negative impact on commercial open source software. The more companies do this, the more the community loses trust. Fewer people will contribute to or adopt commercial open source. Is this generally considered a truism? Has about zero influence on me, or with director level decision makers at companies I've worked with.
- capableweb 3y agoYou're basically asking if software being FOSS or not would change the amount of contributions? For myself, I only contribute to FOSS just because it is FOSS. If I know it won't be FOSS in the future, I wouldn't contribute to it. I'm not interested in spending my time working for free for some company if I think they'll end up saying "Hey, actually, this thing you've contributed to, we've decided not everyone should equally be able to run this, so it won't be FOSS anymore, but thanks for the help". > or with director level decision makers at companies I've worked with That makes sense. I don't think there is a ton of "director level decision makers" people who are actually involved in writing FOSS on a day to day basis, and also aren't the ones carrying the ecosystem on their back.
- LAC-Tech 3y agoI guess I focused on 'adopt' over contribute' in the thing I quoted.
- capableweb 3y agoAh, but wouldn't less people eventually adopt it if fewer contributed to it? Opposite is true as well I suppose.
- bruce511 3y agoAdoption and contribution are not aligned. Cue xkcd so cliche by now I don't even need to link to it. The OSS Community is full of projects that are both immensely popular and yet maintained by individuals or very small numbers of contributors.
- cortesoft 3y agoThe issue never seems as big a deal to me as others make it out to be… when a company switches the license, it is only for new development going forward. Any versions you were already using continue to have the same license, and you can keep using them. The only thing you are losing is (perhaps) the ability to continue to receive free patches and updates from the project. This is no different than if the company went out of business completely. You can still make your own updates to the last OS version, and you are free to solicit contributions from others to your fork. Is Hashicorp switching to a BSL any more disruptive to users of the software than if Hashicorp went out of business?
- depr 3y agoIf they went out of business, then there would be a fork of their projects which would be adopted by some foundation or a new foundation would be created. It would be clear that these forks are where new development would be happening and everyone would migrate to them. If Terraform is forked now, there will be two Terraforms, bringing all kinds of complications, so going out of business is definitely different.
- m4rtink 3y agoAfter the license change the company & project is pretty much dead for any existing users & the will move to the fork.
- tzs 3y agoI doubt that. For companies using HashiCorp products just to manage their internal IT stuff the license change only affects that if their business is providing products or services that compete with the HashiCorp products and services they use. I would be surprised if more than a tiny fraction of their customers do so.
- growse 3y agoNobody has any clue what "competing with Hashicorp" actually means now, or what it might mean in the future (what if Oracle buys Hashicorp?). It's vaguely defined deliberately. Most businesses don't like to take vague legal risks.
- birdyrooster 3y agoone strange trick to kill your company
- miki123211 3y agoThere's one thing that a company can do if they want to prove to their users that they'll always stay open. Ask their external contributors to sign a DCO (developer certificate of origin) instead of a CLA (contributor license agreement.) The latter transfers the copyright to your contribution to the company, the former is merely an assertion that you do own that copyright and are legally allowed to contribute. This way, all external contributors own a small part of the copyright to the project. This makes changing the license almost impossible, as it would require either seeking permission from all those contributors or removing all of the code that they wrote. Whether a company uses a DCO or CLA should be the litmus test of how they really feel about open source. I'd strongly reconsider making your business dependent on any products from the latter.
- justinclift 3y ago> This way, all external contributors own a small part of the copyright to the project. People don't need to sign a DCO, or any other document, for that to be the case.
- verdverm 3y agoA DCO is more about protecting the project from using code it shouldn't, in that the developer certifies the origin (of the code) is safe to use, by either being their own creation or that the code used has a compatible license.
- justinclift 3y agoWhile interesting, maybe that should be a reply to the comment I'm replying to as well? :)
- verdverm 3y agoyeah, it would be cool if HN was more of a DAG than a tree
- TheCoreh 3y ago
- user6723 3y agoIf you don't have the internal resources to use some other tool you should pay up.
- gregwebs 3y agoThe other option is to use CLAs to try to allow only specific re-licensings. The Harmony CA [1] that states: We agree to license the Contribution only under the terms of the license or licences which We are using on the Submission Date for the Work in which the Contribution is included or the following additional licenses ... This would let the company re-license to selected other open source licenses for compatibility/strategy, etc, but not allow BSL, etc [1] https://harmonyagreements.org/comments https://harmonyagreements.org/comments
- pessimizer 3y agoIt could only restrict that company, though. Anyone else in the world could relicense open source code under any license that is more restrictive than the original. Any of their employees could start a company, and turn the product completely proprietary (as long as they adhere to whatever attribution clauses are in the open source license.) The point of open source is to allow people (giant corporations) to take the code and do whatever they want with it.
- gregwebs 3y agoThere must be some misunderstanding about re-licensing. That can only be done for code one has the copyright for. A CLA/CA assigns or grants copyright or grants the ability to perform actions on behalf of the copyright holder. So "that company" controls copyright and can relicense. Other parties cannot relicense because they don't control copyright. Depending on the license, a party without copyright may be able to create a derived work that incorporates the original. The derived work may have a different license as long as the incorporation satisfies the original license. This is what people normally think of as using open source licensed code, and it does not include re-licensing code.
- mdaniel 3y ago> switching to BSL I'm doing what I can to nip that typo in the bud: it's b*U*sl https://spdx.org/licenses/BUSL-1.1.html https://spdx.org/licenses/BUSL-1.1.html Yeah, yeah, context matters, Hashicorp did not switch to Boost Software License, but it would be so much better to be accurate than "you know what I meant"
- deleted 3y ago[deleted]
- bcantrill 3y agoI found Cory O'Daniel's take on this to be pretty hilarious[0] -- and he converted us all to your pronunciation over the course of the conversation! [0] https://www.youtube.com/watch?v=QaU94LY891M&t=1058s https://www.youtube.com/watch?v=QaU94LY891M&t=1058s
- floating-io 3y agoWhen I read about mid-stream license switches like this, the term bait & switch comes to mind. It seems unethical. People bought into the product based on various factors, one of which may have been the license. They put hundreds or even thousands of hours into integrating that product into their environment. Then someone pulls the rug out from under them. That Hashicorp were accepting community contributions from people who will never see a monetary return on that investment —- while Hashicorp makes money on their work —- adds insult to injury. Businesses who use that kind of tactic are not high on my list of people to give my money to.
- deleted 3y ago[deleted]
- jsmeaton 3y agoI don’t really get this angle. You can use the tools within your business. You can’t host the tools and ask for money for other businesses to use the tool. It creates a moat around monetising the tool, not using it. I certainly see the argument around free loaders.
- advaitruia 3y agoIm a OSS founder. This is a balanced article and I definitely agree about being clear on what constitutes competition. A few questions: 1. Does Gitlab see much competition from hyperscale providers like AWS? 2. Given that Gitlab has a thicker proprietary crust and a relatively smaller open source core (compared to hashi), is Gitlab more insulated from these types of issues?
- deleted 3y ago[deleted]
- steno132 3y agoIt also shows naked greed. Hashicorp’s founding as an open source company was a bet that a company could open source everything and still mint money. And mint it did, billions, in the IPO. And now, abandoning its ideals for the sake of money, I feel a lot less optimistic about open source going forward.
- pojzon 3y agoWhat about other companies that started building competing solutions based on HC oss tools ? Also makes me question OSS promise when w/e I build will be captured by CloudProvider or cheaper alternative. Why I would build anything OSS if my time will never pay off ?
- steno132 3y agoPersonally, I trusted the founders. Having followed Mitchell Hashimoto’s work on Vagrant, I felt like he and Armon were truly value driven and not purely money oriented. But it’s true, dollars corrupt and billions of dollars corrupt absolutely.
- robertlagrant 3y agoWhat are you talking about? Companies need to make money to pay people. Hashicorp made a net loss of $290m last year[0]. [0] https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-announces-fourth-quarter-and-fiscal-year-2023 https://ir.hashicorp.com/news-releases/news-release-details/...
- steno132 3y agoIdeals are more important than money. And Hashicorp’s founders sacrificed ideals for the sake of billions.
- robertlagrant 3y agoI don't know what this actually means. Should Hashicorp's employees work for no money, because ideals are more important than money? Money is just necessary. It doesn't matter if other things are more important on some theoretical hierarchy. If you need a necessary thing then that's all that matters.
- TRiG_Ireland 3y agoOn further investigation, this has nothing to do with British Sign Language.
- lamontcg 3y agoI tend to think that larger open source projects (large enough to need funding) need to be coming from nonprofit foundations, R&D arms of already-public corporations and educational and government institutions. Companies that want to go IPO is the wrong model.
- Patrickmi 3y ago[dead]
- subomi 3y ago> Adopting a non-compete license isn’t problematic in itself, it’s the trend of switching from an open source to a non-compete license after gaining significant success that is causing distrust in commercial open source software. I shared a similar sentiment here [0]. The future of open source companies is taking a serious posture for it and clarifying as best as possible to all stakeholders involved what this stance is. Love this piece. [0]: https://news.ycombinator.com/item?id=37215478 https://news.ycombinator.com/item?id=37215478
- kemitchell 3y agoI don't see how license changes that don't adversely affect the vast majority of users break trust, especially when the noops are effectively communicated. Hashi did a much job better job there than its predecessors. I don't see what locking corporations into future open releasing does to solve the general problem. The problem is fueling and operating maintenance and development for as long as those costs remain worthwhile. There are no perpetual motion machines. We have multiple data points from companies suggesting the rules of the game being played today create an inflection point away from universal permissive licensing. Restricting an organization's freedom of operation might maximize the time it holds out in forlorn hope on a pure, doomed model. It might also grind it to a halt when it could have kept going by compromise. A project steward going bust can send a clear signal to former free riders that they need to step up and organize or switch off. But in the meantime, what's to stop some other firm, without charter restrictions, stepping in to try the model the restricted firm wasn't allowed to? What's to stop the engineers at the restricted firm jumping ship? On the level of implementation, I wonder at the need for public benefit corporation structure, with all its vagueness, expenses, and complications. Are the feel-goods really worth the complication? You can put corporate-powers limitations in a "regular" corporation charter. That's a key part of how we turn C-corps into tax-exempt charities and business leagues. The restrictions we put in, say, 501(c)(3) charters also read vague, but they're statutory language we've been fighting about and refining by law over time. Conversely, putting eight novel, vaguely worded restrictions into a corporate charter, with or without line-by-line statements of intent, is putting a whole lot of fluff in the very beating heart of a governance structure. Who settles interpretation fights there, a judge in a shareholder derivative suit? I think the hullabaloo of the OpenAI Charter might be instructive.
- 0dayz 3y agoI would argue the issue I'd how companies that make open source wants to gave the cake and eat it too. Essentially, because the software is so close to the company it's hard to be certain that the project is independent, sure you can fork it but look at what it did to openelastic. Not much. Instead if it's maintained by a foundation then it's much harder for a company to assert full control. It doesn't solve freeloaders but it's I think a big reason for freeloaders existing.
- pico303 3y agoI don’t understand the complaints about this switch. Aren’t these companies doing this to protect themselves from the likes of Amazon, Microsoft, and Google cloud services reselling their services and competing with them, not stop the rest of us from using their software?
- jillesvangurp 3y agoThe only way a company can switch the license for a given bit of software if one of two things are true: 1) The license allows bundling of licensed code with code under alternate licenses. This kind of is the point of many business friendly licenses such as the widely used Apache 2.0 and MIT licenses. I don't see this as a bad thing. 2) Alternatively, the company simply owns the copyright to the entire code base and insists on copy right transfers for any outside contributions. Elastic did this. And they were using Apache 2.0 as their license as well. The best way to insure against companies re-licensing and controlling a code base is by diversifying the community of contributors. Most long lived open source projects have so many contributors across the industry that anyone taking the source code and closing it would just amount to a weird isolated fork that probably won't get much traction. Perfectly legal under some licenses. If you want a BSL licensed version of Apache httpd. You can just take the source code and start layering your BSL licensed patches on top. But there's very little point in doing that as everybody else will just keep on adding to the upstream OSS code base. Other licenses are designed to prevent this entirely. Which is where copyright transfers become relevant. Any company using AGPL v3 and insisting on copyright transfers is basically just trying to coerce people to buy their proprietary licensed version instead. It's a common strategy among some OSS companies. I don't think it works that well for many companies. Mostly you just throw away the baby with the bathwater. You alienate a lot of potential users as well as contributors. I use a few simple rules: - I avoid anything licensed under the AGPLv3. Just not worth the legal headaches. Luckily, this is easy because there isn't a whole lot of software under that license that I particularly care about. If I need a lawyer to figure out if my intended use of a given bit of software is allowed, morally justified, etc., I'm not interested. The attitude with a lot of users of this license seems to be leaning towards communism in the sense that all form of value creation is frowned upon and seen as profiteering. So, I respect that attitude by just ignoring anything under that license for personal or company use. No exceptions. - I don't contribute source code if there's a copyright transfer involved or if the software is not under a proper open source license. If you want to own your software that's fine, but that means you are responsible for fixing it as well. So, anything BSL or similarly licensed is not going to get patches from me. I might file a bug but I won't lift a finger to close it. A hard condition for me coding anything is either financial compensation or a proper OSS license. - I avoid using non open sourced software as much as I can. That future proofs what I do. I tend to gravitate to things with active communities. This put me a bit in a dilemma with Elasticsearch when they went closed their source and fractured their community (opensearch is the OSS fork). I still deal with Elasticsearch professionally. But I'm gradually shifting my attention to Opensearch. And my observation is that they fractured their customer base and that new users are defaulting to Opensearch. Hashicorp is likely to end up facing a similar situation. - For my own oss projects, I use the MIT license. Maximizes my user's flexibility to do whatever they need to do without limiting mine. Including creating valuable closed source products. That's a feature, not a bug. Go for it. I want you to create value and benefit from my software. More power to you. That's part of the OSS contract. Contributing back is appreciated but not required. Companies that value having active developer communities are mutually exclusive with overly restrictive licenses. What's nice about things like Linux is that the community is lots of companies taht build commercial and proprietary products on top of it. And they end up contributing back. It's this commercial success of Linux that drives its success and keeps its community healthy and diverse. GPLv2 was a happy accident that it contained enough loopholes for this to work.