IANAL, but I guess this comes down to the interpretation of "Required Components".
1.12 "Required Components" means any text, programs, scripts, schema, interface definitions, control files, or other works created by You which are required by a third party of average skill to successfully install and run Licensed Software containing Your Modifications, or to install and run Your Derivative Works.
You have to make the source of the required components available under the RPL (section 6.0-6.1).
Would provisioning software to operationalize a database within a cloud environment be considered a "required component"? Maybe. If the cloud provider made modifications to the db source to get it to run well inside of their cloud environment, and did it in a way that made it impossible to run the modified db outside of their cloud environment, without using their custom provisioning scripts, then I would argue that those provisioning scripts would be considered "required components" under the definition in 1.12. But if they are able to run the db without making modifications to it, so that it is the same as upstream, and a third party developer does not need the provisioning scripts to run the modified db, then the provisioning scripts would not be considered required components.
So, the RPL is perhaps stronger than the AGPL, but not strong enough for MongoDB or Redis Labs.
The phrase "Open Source" is not necessarily just the summation of the constituent words "open" and "source". "Open Source" is a unique concept with a unique meaning... and the de-facto definition of that concept, is the OSD[1].
Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3].
People trying to muddy the waters are generally being intentionally disingenuous because they want the general goodwill and positive buzz associated with being Open Source, without actually, ya know, being Open Source.
> The phrase "Open Source" is not necessarily just the summation of the constituent words "open" and "source". "Open Source" is a unique concept with a unique meaning... and the de-facto definition of that concept, is the OSD[1].
The use of the phrase "Open Source" predates the very _existence_ of the OSD by years[1], so it's somewhat laughable to claim that people are "trying to muddy the waters and being intentionally disingenuous" for simply not complying with the OSI's attempt to retroactively redefine the phrase to mean something other than the conventional and obvious meaning.
[1] The OSI was formed in February of 1998. The OSD had been drafted 9 months prior, in mid 1997. If, as claimed, the meaning of the phrase "Open Source" sprung forth from the ether with the OSD, then why, pray tell, is it dead easy to find uses prior to 1997 in which people are obviously referring to the ability to see the source-code and obviously _not_ referring to the ability to exploit it commercially?
> If a developer wants money for shareware,
paying the fee should automatically grant the user a copy of the source
code for their personal use. Restrictions could prohibit modifying and
redistributing binaries, but should allow distribution of "deltas" for
bug fixes, etc.
> Anyone else into "Source Code for NT"? The tools and stuff I'm writing
for NT will be released with source. If there are "proprietary" tricks
that MS wants to hide, the only way to subvert their hoarding is to post
source that illuminates (and I don't mean disclosing stuff obtained by
a non-disclosure agreement). Open Source is best for everyone in the
long run.
> Caldera believes an open source code model benefits the industry in many ways.
> ...
> Individuals can use OpenDOS source for personal use at no cost.
Individuals and organizations desiring to commercially redistribute
Caldera OpenDOS must acquire a license with an associated small fee.
I guess somebody should travel back in time and tell them they're "muddying the waters and being intentionally disingenuous"?
Or maybe, just maybe, it's the OSI that muddied the waters by trying to redefine a term to add their own ideological baggage to it.
Just because OSI wasn't formed as a legal entity until 1998 doesn't mean that the people involved weren't around and involved in those earlier discussions of "open source". All OSI did was formalize what was in common usage. And sure, you can cherry pick a few exceptions where individuals used the term in different ways. That has little or nothing to do with contemporary usage.
And in today's vernacular (dating back to at least 2000 or so) the de-facto definition is the OSI definition. A few lone-wolf dissenters don't change that.
Languages don't work like that. You don't just come up with a definition and try to force everyone to use it. People learn definitions from how they are used and mentioned in the things they encounter.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly. So, no, de-facto definition of open source is definitely not an OSI definition, but mostly literal meaning of open source software with most people presuming freely usable software as well to some degree. Take SQLite for example, it's open source, but not OSI open source and everyone is ok with that. Because this is where common meaning is. And trying to claim authority over it just invites bad PR for OSI. I guess OSI is already that irrelevant and it's pretty much consequence free to use a proper common meaning of open source.
You don't just come up with a definition and try to force everyone to use it.
Right, and nobody did that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly.
I haven't found that to be the case. At least not for people who are actually involved in the open source community to any serious level. Maybe for casual bystanders.
I don't know about RPL, but GPL has been tested a lot. For example, in the early 2000s, Linksys was forced to release the source code of their router firmware. This project was forked and is now maintained in the OpenWrt embedded linux distribution.
I have never used Redis so I cannot comment on what is in Redis vs whatever Redis Labs modules are. I did observe that when the license was changed there was much gnashing of teeth about the license change so clearly at least a subset of potential users were surprised or upset about the license change.
I do think much of conversation about license changes is missing what I think the main risk of taking a dependency on an open source project where the license can be changed by the primary contributors with little to no oversight from anyone. And indeed Oracle has demonstrated that this is an issue for software that while proprietary has been free.
It may still be the right thing to do to use Redis or MongoDB or the Oracle JVM. Users may be fine with the new licensing terms. Maybe things fork and go their own way. Maybe people wake up to the risk they actually run when signing a contributor agreement (depending on what it contains). I just think there is too little real analysis of the true risks that exist when taking a dependency on a component which might not be supported under the expected licensing terms in the future.
This is just typical "people are saying" weasel words. The GPL and similar licenses still definitely have a role to play in the current state of software.
I'd rather bet my life savings that at least some such companies are going to reject both these options (SSPL or commercial licence) and just keep using the last MongoDB version that was released under GPL, possibly maintaining a fork of that version just as MariaDB has done.
That wouldn't really be the worst outcome, either. Well, it would be for MongoDB themselves, but to the rest of the open source community, it would mean a much less restrictive version of MongoDB would be available and maintained, which to me seems like a win.
No - with GCC those improvements never got written, because the license used by GCC prevented it from happening in the first place. The decision whether to share the code usually happens before choosing the codebase to build upon, not the other way around.
In this specific case, Sony would have been forced to actually spend money doing a compiler from the ground up instead of cutting costs down costs while giving a few crumbs back to keep the plebe happy.
What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.
Only if you assume the only choices were 1. using GCC or 2. writing from scratch. Thing is, this assumption obviously doesn't match reality. Absurd assumptions -> absurd conclusions.
And no, BSD has nothing to do with shareware. Shareware was never about sharing sources; meanwhile, BSD-licensed projects are fine with respect to sharing - just take a look at Postgres, LLVM, FreeBSD, X11, or Python. GPL is an attempt to protect from a threat which was never real, and by doing so it makes life harder for everyone.
I have plenty of crufty shareware CDs and most likely unreadable floppies with source code on those .zip and .arj files.
FreeBSD vs what Linux has achieved, LLVM still lacking many of the hardware targets supported by GCC don't seem to be doing that great in company contributions. The others I don't know well enough to comment on.
Lets check again in about 10 years to see how far they managed to develop themselves.
How so? You mean the microkernel thingy? It somehow didn't hurt adoption of the most successful desktop Unix out there. The main thing that plays a role in adoption is whether something actually works.
No, while they don't have the AGPL section, the wording in section 13 is pretty clear:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
Now, this only applies if you've modified the source code. But being barred from the effective right (due to the requirement mentioned above) to use modified versions of software makes it obviously proprietary.
> I see this as very much in line with the original spirit of the GPL, regardless whether MogoDB's motivation might be primarily commercial or not.
I disagree. GPL was never about relicensing other people's software. The SSPL basically requires this if you read Section 13.
> CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
Just because many projects do this doesn't mean it's a good thing to do -- the FSF CLA is the only CLA I would find acceptable because it's purpose is to ensure they can relicense to later GPL versions as well as have litigation rights in the US. Several other "CLAs" (like Apache's) are actually just beefed up versions of the DCO.
But unconditional and asymmetric CLAs are the reason that OpenSolaris could become proprietary under Oracle, as well as many other horror stories in the history of free software. Many people use them, but that doesn't justify it.
I don't think you were misunderstood. But, I think the way you think of freedom is that one has an absolute freedom do do whatever, including infringing on other freedoms whereas others disagree.
By analogy; if one is free to rob someone, they're more free in absolute terms than they're free if they can't do that, but then the person who is about to get robbed isn't free to feel secure. So in other words, the robber is more free, but at the expense of the robbed.
In that sense, the BSD license is more absolutely/selfishly free for the individual, whereas the GPL is more freedom-perusing for the entire community.
> It seems like it is to me, it's just extremely protective of the source code owner's rights.
And you'd be mistaken. It isn't open source because (among other reasons) it discriminates based on your purpose for using the software. This tickles freedom zero of the free software definition and point six of the open source definition.
Be that as it may, my opinion is informed. Like the Commons Clause before it the SSPL is an effort at undermining open source. It violates the Open Source Definition in letter and in spirit.
The OSI isn't going to approve it and Mongo damn well knew this when they submitted it.
Probably true, non-open source code provokes multiple open source compeitors when successful, so this non-open (per OSD criterion 9) license will, when used, probably provoke more open source code to be written.
It directs licensing of software that is not a derived work of, or part of a combined work with, the software offered under the license, in violation of criterion 9 of the OSD.
(OTOH, it might be Free Software under the FSF Free Software Definition.)
> Individuals interpretations of this are unlikely to matter much until such a clause is tested in court.
If the interpretation is reasonably plausible and untenable for a user, they just won't use the SSPL licensed version of the software.
So, yes, they will matter substantially.
For a big-money cloud provider, it's probably less risky to fork and maintain their own version from the GPL version (and share it to get code from the community).
> And that is why BSDs will never be as big as Linux, companies don't like to give free beer back to the tap
BSDs will (perhaps) never be as big as Linux because Linux had first mover advantage in the FOSS operating system world, and hasn't (yet) fumbled it badly enough to be displaced.
OTOH, Postgres and SQLite do quite well (with plenty of contributions from big downstream users and sellers), despite being permissively-licensed, and (in Postgres case) despite having a GPL competitor that used to be much further ahead of it in acceptance.
> MySQL is not a competitor to Postgres when one cares about real SQL support.
Which almost no one does, at least not as the sole decision factor. Even while being recognized as better on that dimension, Postgres was far behind MySQL for a number of reasons and caught up because of much stronger contribution from downstream users.
> Since their primary goal is to help business, they can't help but disapprove; since they don't explicitly state this goal, they have no nominal basis to reject it without rejecting Free Software in general.
Without engaging with your characterization of OSI motives, the OSI has a clear basis to reject it without rejecting Free Software in general; unlike all other existing Free Software licenses, SSPL (which might be Free Software) violates criterion 9 of the Open Source definition by restricting licensing of other software not derivative of, or part of a shared work with, the software originally distributed under the SSPL.
Could you explain how the term does not apply? Its meaning seems to be: "to impose upon another's generosity or hospitality without sharing in the cost or responsibility involved".
Free software users are voluntarily given use of the software with only specified conditional responsibilities; them using the software and not taking on additional responsibilities is not an imposition of any kind, and not freeloading.
Isn't that the same as when someone offers me a couch to surf and a kitchen to use? Sure, it's unconditional and I'm not violating any agreement, but if I use their stuff and don't give anything back, am I not a freeloader?
But in that case, you are taking up space on their couch and eating their food - their resources are diminished by your use of them. That's not the case here.
I think "free-rider" is probably a better choice of term.
> when something is BSD can be relicensed by everybody
Relicensing is not something that the BSD license permits. The license family is permissive, but a user doesn't have the right to strip out the copyright notice and call it a day.
I think they meant sublicense, which is something that the BSD license permits (though not as explicitly as MIT) because otherwise you wouldn't be able to use BSD code in GPL projects.
I'm pretty sure that the new license does not "maintain the four freedoms".
I don't know if the FSF will approve of this new license, however by the Free Software definition it should be even more damning, first of all because it violates Freedom 0. The corresponding rule in OSI's definition is less strict ;-)
The "spirit of the GPL" has nothing to do with this license. The GPL is just a "copyright license", meaning that it's concerned only with distribution and with derived works, where distribution and "derived works" are defined by the copyright law.
The GPL is in fact very business friendly and that was by design.
51 comments
[ 0.25 ms ] story [ 110 ms ] thread1.12 "Required Components" means any text, programs, scripts, schema, interface definitions, control files, or other works created by You which are required by a third party of average skill to successfully install and run Licensed Software containing Your Modifications, or to install and run Your Derivative Works.
You have to make the source of the required components available under the RPL (section 6.0-6.1).
Would provisioning software to operationalize a database within a cloud environment be considered a "required component"? Maybe. If the cloud provider made modifications to the db source to get it to run well inside of their cloud environment, and did it in a way that made it impossible to run the modified db outside of their cloud environment, without using their custom provisioning scripts, then I would argue that those provisioning scripts would be considered "required components" under the definition in 1.12. But if they are able to run the db without making modifications to it, so that it is the same as upstream, and a third party developer does not need the provisioning scripts to run the modified db, then the provisioning scripts would not be considered required components.
So, the RPL is perhaps stronger than the AGPL, but not strong enough for MongoDB or Redis Labs.
Similarly, there are are de-facto terms for the "the source code is open for inspection" (but not otherwise Open Source) models: things like "Source Available"[2] and "Shared Source"[3].
People trying to muddy the waters are generally being intentionally disingenuous because they want the general goodwill and positive buzz associated with being Open Source, without actually, ya know, being Open Source.
[1]: https://opensource.org/osd-annotated
[2]: https://en.wikipedia.org/wiki/Source-available_software
[3]: https://en.wikipedia.org/wiki/Shared_Source_Initiative
The use of the phrase "Open Source" predates the very _existence_ of the OSD by years[1], so it's somewhat laughable to claim that people are "trying to muddy the waters and being intentionally disingenuous" for simply not complying with the OSI's attempt to retroactively redefine the phrase to mean something other than the conventional and obvious meaning.
[1] The OSI was formed in February of 1998. The OSD had been drafted 9 months prior, in mid 1997. If, as claimed, the meaning of the phrase "Open Source" sprung forth from the ether with the OSD, then why, pray tell, is it dead easy to find uses prior to 1997 in which people are obviously referring to the ability to see the source-code and obviously _not_ referring to the ability to exploit it commercially?
For instance, here's a post from 1993 on comp.os.ms-windows.programmer.win32 (https://groups.google.com/forum/#!msg/comp.os.ms-windows.pro...):
> If a developer wants money for shareware, paying the fee should automatically grant the user a copy of the source code for their personal use. Restrictions could prohibit modifying and redistributing binaries, but should allow distribution of "deltas" for bug fixes, etc.
> Anyone else into "Source Code for NT"? The tools and stuff I'm writing for NT will be released with source. If there are "proprietary" tricks that MS wants to hide, the only way to subvert their hoarding is to post source that illuminates (and I don't mean disclosing stuff obtained by a non-disclosure agreement). Open Source is best for everyone in the long run.
Or this email from 1996 (http://www.xent.com/FoRK-archive/fall96/0269.html):
> Caldera Announces Open Source for DOS.
> ...
> Caldera believes an open source code model benefits the industry in many ways.
> ...
> Individuals can use OpenDOS source for personal use at no cost. Individuals and organizations desiring to commercially redistribute Caldera OpenDOS must acquire a license with an associated small fee.
I guess somebody should travel back in time and tell them they're "muddying the waters and being intentionally disingenuous"?
Or maybe, just maybe, it's the OSI that muddied the waters by trying to redefine a term to add their own ideological baggage to it.
And in today's vernacular (dating back to at least 2000 or so) the de-facto definition is the OSI definition. A few lone-wolf dissenters don't change that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly. So, no, de-facto definition of open source is definitely not an OSI definition, but mostly literal meaning of open source software with most people presuming freely usable software as well to some degree. Take SQLite for example, it's open source, but not OSI open source and everyone is ok with that. Because this is where common meaning is. And trying to claim authority over it just invites bad PR for OSI. I guess OSI is already that irrelevant and it's pretty much consequence free to use a proper common meaning of open source.
Right, and nobody did that.
In reality almost no one is aware that OSI definition exists and those who do can't even remember what it is exactly.
I haven't found that to be the case. At least not for people who are actually involved in the open source community to any serious level. Maybe for casual bystanders.
For example, based on that could I release a web server and then sue anybody who wouldn't provide source code to their browser to me?
https://en.wikipedia.org/wiki/OpenWrt
Here is a list of GPL enforcement cases from the Free Software Foundation:
https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Cases
I do think much of conversation about license changes is missing what I think the main risk of taking a dependency on an open source project where the license can be changed by the primary contributors with little to no oversight from anyone. And indeed Oracle has demonstrated that this is an issue for software that while proprietary has been free.
It may still be the right thing to do to use Redis or MongoDB or the Oracle JVM. Users may be fine with the new licensing terms. Maybe things fork and go their own way. Maybe people wake up to the risk they actually run when signing a contributor agreement (depending on what it contains). I just think there is too little real analysis of the true risks that exist when taking a dependency on a component which might not be supported under the expected licensing terms in the future.
What I find ironic with the current anti-GPL trend is the eventual return of the shareware model, then lets see how well the MIT/BSD folks will appreciate it.
And no, BSD has nothing to do with shareware. Shareware was never about sharing sources; meanwhile, BSD-licensed projects are fine with respect to sharing - just take a look at Postgres, LLVM, FreeBSD, X11, or Python. GPL is an attempt to protect from a threat which was never real, and by doing so it makes life harder for everyone.
FreeBSD vs what Linux has achieved, LLVM still lacking many of the hardware targets supported by GCC don't seem to be doing that great in company contributions. The others I don't know well enough to comment on.
Lets check again in about 10 years to see how far they managed to develop themselves.
Maybe I will be wrong, maybe not.
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
Now, this only applies if you've modified the source code. But being barred from the effective right (due to the requirement mentioned above) to use modified versions of software makes it obviously proprietary.
I disagree. GPL was never about relicensing other people's software. The SSPL basically requires this if you read Section 13.
> CLAs are pretty common nowadays and they can be a problem for potential contributors but pointing at MongoDB, for just doing what many other large OpenSource projects do, isn't fair.
Just because many projects do this doesn't mean it's a good thing to do -- the FSF CLA is the only CLA I would find acceptable because it's purpose is to ensure they can relicense to later GPL versions as well as have litigation rights in the US. Several other "CLAs" (like Apache's) are actually just beefed up versions of the DCO.
But unconditional and asymmetric CLAs are the reason that OpenSolaris could become proprietary under Oracle, as well as many other horror stories in the history of free software. Many people use them, but that doesn't justify it.
I think that's the point...
By analogy; if one is free to rob someone, they're more free in absolute terms than they're free if they can't do that, but then the person who is about to get robbed isn't free to feel secure. So in other words, the robber is more free, but at the expense of the robbed.
In that sense, the BSD license is more absolutely/selfishly free for the individual, whereas the GPL is more freedom-perusing for the entire community.
And you'd be mistaken. It isn't open source because (among other reasons) it discriminates based on your purpose for using the software. This tickles freedom zero of the free software definition and point six of the open source definition.
The OSI isn't going to approve it and Mongo damn well knew this when they submitted it.
Probably true, non-open source code provokes multiple open source compeitors when successful, so this non-open (per OSD criterion 9) license will, when used, probably provoke more open source code to be written.
It directs licensing of software that is not a derived work of, or part of a combined work with, the software offered under the license, in violation of criterion 9 of the OSD.
(OTOH, it might be Free Software under the FSF Free Software Definition.)
If the interpretation is reasonably plausible and untenable for a user, they just won't use the SSPL licensed version of the software.
So, yes, they will matter substantially.
For a big-money cloud provider, it's probably less risky to fork and maintain their own version from the GPL version (and share it to get code from the community).
BSDs will (perhaps) never be as big as Linux because Linux had first mover advantage in the FOSS operating system world, and hasn't (yet) fumbled it badly enough to be displaced.
OTOH, Postgres and SQLite do quite well (with plenty of contributions from big downstream users and sellers), despite being permissively-licensed, and (in Postgres case) despite having a GPL competitor that used to be much further ahead of it in acceptance.
A suit that was settled in about 2 years, and Linux also had its own set of suits.
Most companies that use BSD seldom give anything back thanks to the license.
MySQL is not a competitor to Postgres when one cares about real SQL support.
Which almost no one does, at least not as the sole decision factor. Even while being recognized as better on that dimension, Postgres was far behind MySQL for a number of reasons and caught up because of much stronger contribution from downstream users.
Without engaging with your characterization of OSI motives, the OSI has a clear basis to reject it without rejecting Free Software in general; unlike all other existing Free Software licenses, SSPL (which might be Free Software) violates criterion 9 of the Open Source definition by restricting licensing of other software not derivative of, or part of a shared work with, the software originally distributed under the SSPL.
I think "free-rider" is probably a better choice of term.
Relicensing is not something that the BSD license permits. The license family is permissive, but a user doesn't have the right to strip out the copyright notice and call it a day.
I don't know if the FSF will approve of this new license, however by the Free Software definition it should be even more damning, first of all because it violates Freedom 0. The corresponding rule in OSI's definition is less strict ;-)
The "spirit of the GPL" has nothing to do with this license. The GPL is just a "copyright license", meaning that it's concerned only with distribution and with derived works, where distribution and "derived works" are defined by the copyright law.
The GPL is in fact very business friendly and that was by design.