That's another company that feels like they don't want to be an OSS company after all. After Elastic, I pay more attention to contributor agreements. Basically I consider any project that requires transfer of copyright for OSS contributions as likely to change their license at some point. It's fine; I'm not against that sort of thing and I sometimes pay for software. But I like to know what I'm getting into before and I don't appreciate the bait and switch. It also guides decisions as to what I contribute to actively.
I do a simple sanity check with any OSS software before using it:
- Make sure there is no contributor agreement requirements. This is a gigantic red flag that the license can and probably will be changed at some point.
- Make sure the license is not overly restrictive (like AGPL). I appreciate people have good reasons for picking this license; but it comes with some serious restrictions in a commercial environment. And like it or not, a lot of companies have active policies against this. Either way, I avoid anything with this license.
- Make sure the project is actively maintained. You don't want to get stuck with unmaintained software. Replacing dependencies is a PITA.
- Make sure the project is not overly dependent on VC funding. Startups fail all the time at which point anything they worked on turns into abandon ware.
- Ideally, make sure the project has a healthy diverse group of committers. Healthy here means more than one company is involved. Most projects that fail one or more of the above tests usually aren't very healthy in this sense.
The BSL doesn't make it closed source, it prevents a competitor from running their own DBaaS business using Cockroach as the backend. This has happened to various open source projects, AWS started selling their technology and ate their lunch.
BSL is a totally fair compromise for commercial open source licensing imho.
If you see BSL as the first step to an announcement like today's, that's a fair criticism. Not sure how often that happens. But BSL doesn't disqualify software from being open source.
Any license that prevents others from selling your code and eating your lunch is, by definition, not an open source license.
One good way of looking at the goals of open source licenses is to force companies to compete on offering services related to the code. Whether this is a sustainable idea is a different question, but this is one of the bedrock ideas about OSS (and FLOSS as well). The other is of course that the rights of those running the software are absolute and trump any rights that the original creators have, except where the users would try to prevent other users from gaining the same rights.
The OSI is a consortium of cloud platform vendors (really - check for yourself). Of course they'll define open source in a way that excludes licenses that restrict them from turning your work into closed-source cloud platforms. The good news is that we're not beholden to their definition as they have no official status whatsoever. We don't have to believe them just because they put the words Open Source in their company name.
The BSL is clearly not open source since it requires approval from the licensor in certain applications, but the OSI also rejected the SSPL, which is just an extended AGPL that requires source code publication in even more cases, and is clearly open source because of that.
OSI, and the open source definition they produced, predate the very notion of public cloud by close to a decade. While you don’t have to accept the definition, you are out of step with the industry at large, who broadly use “open source” to refer to things which meet the OSI definition. There’s no need for a competing definition: it’s fine for software to not be open source.
As to the specifics of SSPL, I personally don’t see the rationale for accepting AGPL but not SSPL.
At large? As you can see, there is room for a community with a different view on that. My personal definition of an "open source license" is that, as the name implies, I can access the code, preferably without much gatekeeping (e.g., creating a free account in a private GitLab instance). And, to be honest, I prefer the BSL with an Additional Use Grant over any other license, because this is the most reliable option to ensure that the project has a future and won’t be abandoned because no one wants to invest their time for free.
You are welcome to choose that, but in my opinion, it isn't open source. I think open source should means anyone can contribute or take, and contributions are shared, without undue discrimination. Nobody is forced to work on the project, but if they are then they have to give the results of their work back to the common pool they took from. You have just as much power to keep the project going as anyone else does, including the current "maintainer".
> The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License.
The first of these open source companies to switch to a closed source license because the big bad cloud was eating their lunch was MongoDB, which was already AGPL. The AGPL, by design, doesn't stop anyone from offering your code: it merely makes sure that they provide the source code and installation instructions to anyone who is using the service. Amazon is only to happy to provide this, and they always have for all of the services they offer (that require it). They even contribute to some of these projects.
Also, from the perspective of the free software movement at least, there is nothing to solve here. The whole point of the GPLs is that you don't get to have any special power over the code that you create: everyone who gets a copy has the exact same rights to it that you do, including the right to run your company under the ground if they can outcompete you.
Unfortunately you can't do commercial licenses unless you take full ownership of each and every source contribution. So, it means there is zero guarantees the project stays open. AGPL without that is a non starter for commercial usage.
Some of the most popular database and database related projects & products have been or are AGPL. MongoDB became massively successful as AGPL from the start. Grafana has been AGPL for 3+ years.
The AGPL is absolutely viable in commercial contexts. There are a handful of companies that have hangups about it, but the industry overall has long since realized that it is almost identical to the GPL for most practical purposes.
Mi d that those companies do dual licensing. All companies which worry about AGPL got to buy the commercial license to be on the safe side. While only the original vendor is able to do that, creating an imbalance between what they can do and an external contributor can do. (While external contributions are of limited interest for vendors who want to control a roadmap etc. and treat open source as marketing vehicle anyways)
Neither of those licenses require copyright ownership transfer. It's what makes Linux completely bullet proof against license changes. You'd have to track down every copyright holder (everyone that contributed, even if it's just a 1 line change) to get their permission for re-licensing their contribution. Which in the case of Linux is literally tens of thousands of individuals and companies, if not more.
Most GNU projects require a copyright assignment. For example, GNU coreutils: "note that non trivial changes require copyright assignment to the FSF as detailed in the “Copyright Assignment” section of the Coreutils HACKING notes." (from: https://www.gnu.org/software/coreutils/coreutils).
As far as I know, this is case for most GNU projects.
Linux only requires a confirmation that you wrote the patch; previous poster was mistaken about that, but they were correct about GNU.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
Note the "or any later version" verbiage in there. If the software is licensed under "GPLv3 or any later version" - no permission is required or assignment of copyright.
In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer.
> The "why they require a CLA" is for enforcement.
None of that seems like a "why" to me; to cynically paraphrase it, "our policies require our polices." Why does your record-keeping require a CLA? Why is a CLA required to enforce the GPL?
A CLA is required to be able to sue someone infringing the GPL and represent yourself as the legal owner of the entirety of that code. If you have a hugely fractured ownership like Linux, it may be very expensive to bring a suit against an infringer.
That might be true for the GNU foundation. But they don't actually control/host the vast majority of software licensed under the many GPL variants. None of the GPL licenses actually cover any form of copyright transfers. Including the AGPL. That's done via separate contributor agreements typically. The GNU foundation doesn't control the licenses either. That's a job done by the free software foundation. Which doesn't host any projects as far as I know.
At this point the GNU foundation mostly just runs relatively small, older projects and that definitely does not include the linux kernel. That one has its own foundation called the Linux foundation. The Linux foundation runs many hundreds of projects and they operate mostly without contributor licenses as far as I know. And in so far they do those agreements are not about transferring ownership of the copyright but asserting ownership to ensure that the contributions people make are actually legal.
Big corporations moving code bases under their control seems to be a regular thing and that includes some pretty high profile projects recently. And of course there are many more projects on Github that use one of the GPL licenses. The vast majority of which don't have any contributor license.
So, I don't think I'm that wrong here at all that this is not that common. The previous poster seems to confuse the license with the GNU foundation which is a tiny subset of the overall GPL licensed software ecosystem.
> But they don't actually control/host the vast majority of software licensed under the many GPL variants. None of the GPL licenses actually cover any form of copyright transfers.
No one claimed this is the case. The only person conflating "GNU" with "GPL" is you.
You said projects with copyright assignments should be distrusted. Someone pointed out that GNU projects require this, which you promptly denied, and I just wanted to correct the record on that. Nothing more, nothing less.
No, the FSF specifically requires ownership transfer for GNU projects, so that they can do things like go after infringements in court, or relicense GNU projects to newer versions of the GPL unconditionally, e.g. when GPLv3 was released.
Ironically, CLAs like the one Google and Meta use for their projects on GitHub do not require ownership transfer -- only the rights to redistribute, because the prevailing Lawyer-brain belief is (roughly, to my understanding) that just assuming that right from the license itself isn't necessarily sound.
For licenses like Apache 2.0, assignment/ownership is a kind of irrelevant practical distinction because entities can just distribute proprietary versions anyway (and because it's not clear if you really agree to much more than e.g. Apache 2.0 implies), which is the prevailing worry people have. Most of the people here actually want GPL-style copyleft licenses along with some vague idea of a "communal project", even if they don't know it. Because that's the only way to achieve the practical desired outcome, where your code and contributions stay open and are difficult to "rework" in this way. The talk about CLAs and all the other stuff is irrelevant; it's a matter of the politics and composition of the project, not the exact legal words in the license.
> everyone that contributed, even if it's just a 1 line change
That depends on the jurisdiction. There is a concept called the "threshold of originality" in the US which states roughly that some obvious, trivial things just can't be copyrighted. Typofix patches that change "form" to "from" aren't meaningful enough to be given copyright, so you literally do not need to be consulted on the matter at all. It is not clear that simple bugfixes fit under this definition either for example, because they may be obvious. Realistically, I'd say there are very few contributions that are going to fit in 1 line while being original enough for copyright to apply. They could also just not include your patch too or rewrite it, in that case, so the "1 line" case is pretty much meaningless in practice.
Absolutely! They want to have standing in court so they can defend infringers, and that's materially easier to establish with copyright assignment agreements.
So while I agree with other commenters that a CLA is a clear indication that the entity seeking to have copyright assigned wants to reserve the right to take some kind of legal action at some point (like changing the license), it also applies in cases where the legal action is benevolent rather than malevolent (like defending the copyright).
I do a simple sanity check with any OSS software before using it:
- Make sure there is no contributor agreement requirements. This is a gigantic red flag that the license can and probably will be changed at some point.
- Make sure the license is not overly restrictive (like AGPL). I appreciate people have good reasons for picking this license; but it comes with some serious restrictions in a commercial environment. And like it or not, a lot of companies have active policies against this. Either way, I avoid anything with this license.
- Make sure the project is actively maintained. You don't want to get stuck with unmaintained software. Replacing dependencies is a PITA.
- Make sure the project is not overly dependent on VC funding. Startups fail all the time at which point anything they worked on turns into abandon ware.
- Ideally, make sure the project has a healthy diverse group of committers. Healthy here means more than one company is involved. Most projects that fail one or more of the above tests usually aren't very healthy in this sense.