They can still do this if the old code base is under a permissive license, since permissive licenses like BSD, Apache and MIT are compatible with proprietary licenses.
Mostly true, but only up to an extent: without a CLA, they can't just update LICENSE.txt to replace the contents with the text of the new license and be on their merry way without any trace of the old one.
They can't hide the fact that it was once MIT/BSD/Apache licensed, and they still have to include copies of that original license (and any notices) even after the switch, as that is one of the conditions that contributors make their work available under, and failure to do so would mean the org is in violation if they haven't otherwise received approval.
Even if one has to include the original license and notices with the new version, the original license and notices apply to the portions which were present in the older versions. The new portions added to the software after the license change must be used only as per the new license. MIT, BSD and Apache licenses don't forbid you to use a new license to your own derivative work.
Everything you just wrote is true, but it's not clear why you felt the need to spell it out, especially right here. (No one has said otherwise. No one has said anything that could be mistaken to mean otherwise.)
I think you are confusing re-licensing with sub-licensing, which are not the same. Under copyright law, the copyright holder is granted certain exclusive rights over their work and re-licensing is one of the rights. If the license grants sub-licensing, a licensee can pass on some or all of the rights in the license to a third party. Of the three licenses you mentioned, only the MIT license allows sub-licensing.
The license terms for a sub-license must be consistent with the original license terms, although not necessarily the same. The sub-licensor can use different words as in the original license, but they cannot override the terms and conditions that are required by that license. The sub-licensor cannot sub-license more rights than have been granted by the original license.
Works released under the Apache, BSD, and MIT license can be included in a larger work with a more restrictive license or modifications can be put under such a restrictive license, but the original license must remain intact.
If you are getting your information on re-licensing from the Wikipedia page below, it is wrong.
Over a decade ago, I remember that we were debating the merits of CLAs that got all of OpenOffice.org owned by Oracle (cf. https://lwn.net/Articles/443989/ as a random starting point).
I really think this was the FSF's fault - they insisted on copyright assignment for any contributions to GNU, because if the FSF held the entire copyright, they'd be in a better place to pursue legal action against violators. But history has shown that this clearly hasn't been required: Linux doesn't have this policy, and no Linux enforcement case has ever failed because the Linux Foundation wasn't able to demonstrate clear standing. And the FSF basically legitimized everyone else asking for CLAs. Had they stood firm and said that giving up ownership of your code to a central entity is antithetical to the spirit of free software, and the license is all that people can rely on, I think we would have been in a much better place today.
Unlike MIT/Apache/BSD-style Open Source licenses, Free Software can't be relicensed by anyone but the copyright owner. It's a completely different situation.
The current problems stem from pretending that Open Source has any more of a relationship with Free Software than it does to proprietary software - an expectation that reifies (and honestly necessitates) things like "the Spirit of Open Source" in the minds of developers. The Spirit of Open Source is that you're working for massive companies who can ignore you.
The only relationship between Open Source and Free Software is the fact that Open Source code can be arbitrarily relicensed and therefore can be relicensed as Free Software as easily as it can be as proprietary software.
Please stop spreading incorrect information. Re-licensing is an exclusive right granted to the copyright holder; it has a specific meaning under copyright law. There is nothing in the Apache, BSD, or MIT license that grants re-licensing. Using source code that has been licensed under a permissive license in a larger work that is licensed differently (including more restrictions) isn't re-licensing.
Absolutely true. There's a consequence of this that people tend to ignore: You cannot remove the (e.g.) MIT license text from an MIT-licensed work if you redistribute it as GPL.
The MIT license gives you "Permission ... subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
You can abide by that condition by distributing your software under the GPL and retaining the MIT license text for portions. You cannot abide by that condition by "relicensing" the software and removing the MIT license: you are in violation of the license.
> Using source code that has been licensed under a permissive license in a larger work that is licensed differently (including more restrictions) isn't re-licensing.
Whatever you want to call it is fine. I prefer to think that GPL'd software that incorporates Open Source takes a copy and makes it GPL (especially because if I modify the Open Source at all, my changes are not available under an Open Source license.) Other people who are using that piece of Open Source are not using my copy, which is GPL.
I gather you have some meaning of Free Software that is different from what the FSF means by it, and also different from what groups like Debian and Fedora mean by it. Can you expand on what you mean by "Free Software" and what relationship it has with the "Free Software" movement as defined by the FSF, Debian, Fedora, etc.?
Do you think that the FSF, therefore, works within "the Spirit of Open Source", that contributors to glibc are working for the FSF, which can ignore them?
You're selectively quoting. The important part wasn't that the FSF claims that those licenses are "GPL-Compatible," which nobody disputes; the important part was that the FSF claims that those licenses are "Free Software Licenses." Do you dispute that?
Elsewhere in this thread you imply that you believe that the GPL is not an Open Source license. Can you clarify that, too? Because, again, it sounds like you're using terms that don't match what the Free Software and Open Source communities mean by those terms. (In particular, GNU would disagree with this claim - https://www.gnu.org/philosophy/free-open-overlap.en.html - as would the OSI, of course.) So you should define them.
I recently chose to sign a CLA for an MR I wanted to make to a commercial entity's SDK. The feature I added will enable me to build a product and potential revenue stream. I could have forked the project and maintained my own version, but I'd rather do the work for free and have someone else maintain the library going forward. I don't care about who owns or has access to the the work I did in this instance, so I was comfortable with signing it.
I think they can effectively do the same thing if they own the copyright to a significant portion of the work.
Here's a thought experiment: Suppose that Mongo or Cockroach consists of 80% code for which they own the copyright (written by employees). And it's 20% written by contributors who have NOT signed the CLA.
Now can they relicence the whole codebase? No, but I think they can do something with thes same effect by relicensing their parts.
I think it's easier to see if they start a new project. Say Mongo starts a new project called "Dumbo".
Dumbo consists of 80% Mongo code relicensed. And they simply reuse the contributors' code under the existing open source license. So you distribute both licenses with the code.
But now it is still impossible (*) for Amazon or whoever to stand up a cloud service according to the license -- unless they want to rewrite 80% of the code.
I'm not a lawyer but that's my understanding of how it works. Interested in contrary (informed) opinions.
(*) edit: better to say that it's harder, not impossible. They can fork the old code under the old license. It really depends if the they "understand" the code.
If the initial license was GPL or the like, then it would prevent that, as long as they want to include any of the contributors' GPL code, they have to offer the whole package under GPL. MIT-style licenses would generally permit what you describe.
Also, they can't "unlicense" previously distributed code - if the system was previously distributed with an open source license, Amazon can use that version as the basis for a "Dumbo-compatible" cloud service without rewriting the 80% of the code as long as they're basing it on the last open release; they would only have to reimplement the new things that "Dumbo" added if they want; Amazon does not have to accept the new license if they don't need the new code and the old code with the old license fits their needs better.
>Also, they can't "unlicense" previously distributed code
The United States allows authors (and heirs), except work-for-hires, to clawback copyright transfers and terminate licenses after 35 years on works made after 1977. This is an inalienable statutory right, which means it cannot be waived even with a contract.
That said, it may be difficult to terminate licenses in practice because open source licensing is done informally in most cases and courts haven't ruled whether this impacts the right of termination. However, copyright assignment and contributor license agreements are subject to termination.
Okay, the consequences of this paragraph (https://www.copyright.gov/title17/92chap2.html#203) are potentially devastating if triggered, but 35 years is quite a long time in the tech world. It would be very interesting on how such a fork could proceed once the 35 year term (measured from the grant of that licence, essentially the last day the original open source version was distributed) happens if the copyright owner issues the termination letters, but for all the recent licence switches this won't be an issue until 2050s, and in any case the users would have at least two years of warning to switch to something else or possibly make the product compliant by rewriting whatever of the original 35 year old parts are still needed.
And IMO it's fair for Amazon to continue the development based off an old version. Forking is an important right in open source. Nobody who releases code as open source should expect that their code isn't forked.
A CLA certainly makes things clearer. But, as is common with legal questions, the answer is some combination of it's not 100% clear and it depends on the particulars. For example, around the time of GPLv3, there was some discussion of whether Linux could be relicensed to GPLv3 if Linus wanted to. (He didn't.) Eben Moglen for one was of the opinion that it probably could be. [1]
The problem with these licenses is that they're not open source and they're pretending to be. I doubt you could start a new project and get adoption if you start with these licenses.
There were problems with some OS projects keeping security / auth stuff out of the main project so that it could be used to drive commercial sales.
You can compete on hosting (very hard), support, customization, advanced / narrow features. But it needs to be in alignment with the users / contributors.
Would you say that GNU GPL is not open source? Maybe I don't understand the nuances, but I really don't see how these licenses are not much different then a more modern GNU GPL license?
The main difference to especially GPL is that GPL does not say anything about how you can use the software (to the extent that it actually explicitly says that there are no restrictions on how you use the software and such restrictions are outside of the scope of it) while SSPL does and does so in a way that causes it to cover random totally unrelated components of your overall infrastructure.
This is in direct conflict with zeroth freedom in FSF's "Free software definition". And also at least the reasoning behind all these "anti-cloud-provider licenses" is in conflict with either point 6 or 9 or both of DFSG/OSD (which assumes that the right to use the software in whatever way you see fit is implicit enough such that it does not need to be mentioned more than by what is implied from points 5 and 6).
That is certainly true, but there is reason why "the zeroth freedom" is "zeroth" and why GPL is worded the way it is in regards to that. Then there are licenses that completely depend on such a provision being obvious (somewhat notably the original DJB's license terms for qmail and daemontools).
Another issue is then whether such license terms are actually enforceable and not in conflict with the copyright(-related) law of given jurisdiction. For example Directive 2009/24/EC explicitly stipulates bunch of things that cannot be part of contract (ie. EULA) and if they are these parts are void, end result of this is that if you legally acquire some software the licensor cannot limit what you will use it for, not even by separate contract.
In fact Directive 2009/24/EC gives you as a user exactly the rights that GPL intends to preserve. What it does not do is make excercising these rights possible/efficient/effective, which GPL intends to do (and, well, for typical situation that motivated RMS to start GNU/FSF/GPL the difference is moot, you will end up disassembling the contents of whatever memory the thing runs from because that is the source of truth, not the source code that it was supposedly built from).
That is an incidental and unimportant difference, not the main one.
The main difference is that the newer licenses reserve certain rights that affect the use of the software. The GPL does not reserve any rights exclusively to anyone.
Incidentally, copyright holders are not themselves bound by their own public licenses, and that's why some entities use the GPL against its spirit to effectively reserve the right to make proprietary derivatives (or to license that exclusive right separately), but that's not at all part of the GPL. That's because the copyright holders no way of binding themselves to the license term (the best option for that is to assign the copyright to another entity that is committed to protecting the universal rights for everyone).
The GPL doesn't give e.g. Linus, a privileged position where he can sell Linux forks but others cannot. For him to do that with a GPL Linux, he'd either need to make everyone sign a CLA saying he owns their contributions, or not accept external contributions. I think it's fair to say Linux would not have taken off so much in that situation.
"Fair code" loses the symmetry of licenses, and gives the maintainer an advantage over users. This is especially egregious for services that arguably would not have reached the extent they have now without the comfort and promotion provided by being open source.
As a user, these projects provide more value to me than closed-source solutions for all the obvious reasons. As a developer, I understand why choosing such a licensing scheme may make a project commercially viable when it otherwise may not be.
But these are all immediate practical reasons. The long term result of this is a tremendous legal and technological minefield. One of the strongest arguments of the Free software movement was that it makes software free, not humans.
These "open core, single source" projects are not compatible with that vision, they come with all strings attached. The companies putting out these projects will inevitably go under or get acquired. Again, in the short term, as a user I get to keep that software alive for longer than I would have been able to with a closed solution.
However, at that point there can be no forks, no new development in public. The source code itself becomes toxic. Similarities between fragments of these projects and any newly developed software in that space will provide fuel for law suits. Given the vastly larger surface area and distribution of this IP, mega corporations who acquired the rights will have an easier time strangling entire market segments indefinitely.
On balance, I understand why developers are choosing this. They are tired of providing tools that enable billionaires to exist while they themselves are struggling. But in the long term, there will be more problems on the horizon due to this.
> Open source-licensed projects with a non-profit home, *neutral trademark ownership*, and multiple significant contributors are less likely to face pressures to relicense.
Maybe "ownership by a foundation" like Apache or Linux Foundation? Projects I've worked on for corporations have sometimes been donated to foundations for neutral ownership.
Presumably something like "Linux", where although it's owned by Linus Torvalds, there is no single bully organization that gets to use it to the exclusion of others. So, the opposite of something like Mozilla, where Mozilla Foundation owns the trademark, but there's a for-profit vendor that also gets to use it in exchange for kickbacks to the Mozilla Foundation, no one else in the community can operate under that banner, and they have to make it abundantly clear that their work is not endorsed by Mozilla.
That is almost certainly reference to several open source projects where building the thing from source and distributing the resulting build artifacts is "legally problematic" because of trademarks. In the 00's this was giant issue for Mozilla(TM) anything. If I understand it correctly there is some kind of related issue with for example "OpenShift(TM)".
On the other hand it somewhat seems that most projects learned from the mozilla shitstorm, at least looking at the amount of "foo"s with open core "foo-ium"s. The point there is that whatever sourcetree that the version with trademarked branding gets built from should be fork of the branding-free opensource project, not the other way around.
I don't remember if any damages were awarded, but I do remember that the infringing software were all removed from the market when SCUMMVM sued Atari for releasing Nintendo Wii games using their game engine without sharing anything at all.
Atari of course got stuck in a bad situation then, if they complied with GPL they would breach Nintendo NDA, so their choice was just stop selling the products in question entirely, so I must assume the lost sales were smaller than the potential damage if they were found guilty of copyright infringement.
In an acquisition, the acquirer will have full access to source code and may look for open source violations during technical due diligence. They may then use any violations to squeeze the valuation and/or demand remediation, either of which is a real cost to the company being acquired. It’s not in court, but is is a routine situation that does not require a whistleblower, where the violations are relatively easy to identify.
Cisco/Linksys had to make available the source code that became the basis for a whole ecosystem of open router software that offers enterprise features on much cheaper devices. Cisco also paid an undisclosed amount to FSF. Similar things have also happened to other router manufacturers.
Westinghouse had to pay the SFC $90k for shipping BusyBox without observing the license.
Most cases that are pursued are settled out of court though.
> In response to this pressure, many open-core or dual-license companies, including Confluent, MongoDB, Cockroach Labs, Redis Labs, Timescale, and Graylog moved away from OSI-approved licenses to licenses that are not ‘open source.’
Redis Labs gets undeserved flack for their licensing changes. Redis remains fully open source under the BSD 3-Clause License. The relicensing only applied to the modules that are part of Redis Labs' paid offerings. So it's the open core model, but even better because the non-core offerings are source-available.
So open source means only licenses that are most favourable to the big tech monopolists now?
As a user, I can use Elasticsearch just fine with the new license. I can read the code, modify it and use in my own projects.
So it is more difficult for Amazon to use their monopolistic power to build a competing service to the one that is financing Elasticsearch development? Yeah, good stuff.
If the big tech monopolists need something under a permissive license they should pay for its development.
How do you draw the line between "user" and "exploiter"? Was there any point in the past Amazon wasn't an "exploiter"? What if a user becomes an exploiter? Can an exploiter become a user through repentance? Where's the legal boundary?
legal boundary or moral boundary? (Not that I have an answer in either case, but my impression was that "exploiter" was an expression of moral judgement, not a legal judgement)
Not OP and not really invested. You can probably replace "exploiter" with provider. A user uses the software directly, a provider provides it to users. Amazon can be both simultaneously, they can run ES to analyze sales and find out what products of third party sellers are worth copying, and they can also offer ES as a service to other users.
That kind of difference is pretty common in non-source-related things, e.g. you can use the API for your business, but you can't resell access to the API.
Big companies or those with lawyers notice that the AGPLv3 says the software used to make something a service must be licensed under the same license. Much of that software isn't something a company controls. For example, you put the AGPLv3 software behind a load balancer. Does that software need to be AGPLv3? Some would say so and how often can a company control that license.
Companies with more are conservative on their risk.
Yeah. The boundaries of the GPL are mostly clear because they're essentially tied to Unix linking behavior. There are some edge case--I know people who don't think you shouldn't be able to load binary blobs for example--but mostly. There doesn't seem to be the same sort of clear consensus over how broadly the AGPL interacts with other code on the network.
No. It doesn't "infect" the load balancer. There's zero ambiguity about this.
A lot of companies have bad lawyers who try to eliminate rather than mitigate risk and who try to grab every scrap of IP for the company. This is the kind of company you're talking about.
This is also why many try to get you to sign away every profitable idea you've ever dreamed up in the shower: a combination of extreme risk aversion and flagrant greed.
I'd even venture as far as to say it's a feature not a bug if this type of company were forced to use expensive proprietary software or older, shittier versions.
> No. It doesn't "infect" the load balancer. There's zero ambiguity about this.
This is not true.
> A lot of companies have bad lawyers who try to eliminate rather than mitigate risk and who try to grab every scrap of IP for the company. This is the kind of company you're talking about.
I'm guessing you would claim all of the giants as obviously falling into this category (they all have bad lawyers).
I'd love to hear what Stripe thinks about using AGPL-licensed software.
Basically I've yet to hear of a large (> $1B revenue +) SaaS company that doesn't have concerns about using AGPL software as a core part of its service offering. I'd love to hear some counterexamples...
>I'm guessing you would claim all of the giants as obviously falling into this category
Google definitely counts as a company that tries to grab every scrap of IP for itself. They also heavily customize everything and compete in all software markets. For them this is ideological because it interferes with their profits as a monopoly. They want the license dead and buried because it targets them.
This is a feature, not a bug.
Small Podunk companies that shy away from installing mongo, OTOH are being legitimately dumb.
AGPLv3 get the exact same level of flak as GPL got. And will lose (lost?) in exactly the same way.
GPL was the fight against device manufacturers using linux et al and not giving back/selling closed source linux devices.
We completely lost with tainted kernel and such, as they corrupted the only software that they couldn't live without and was promoting an open source license. Case in point: you cannot build 1% of your android phone software, proving GPL code (android, linux kernel) is as useless for open software as MIT (ios, darwin)
Now the fight moved from OEM manufacturers vs GPL to cloud providers vs AGPLv3. And source-available licenses are the tainted-kernel compromise all over again: get the thing you cannot live without but is fighting you with a pro-opensource license, and offer a carrot so they change, and they all changed.
Without the change the article talks about, cloud providers would have people using the AGPLv3 code in their derivative work of projectX. while they paid the closed source version from the company dual licensing it. With this new arrangement, they can use all derivative work at will with zero consequence, for the same low price.
Just like tainted kernel was a hard blow in the face of everyone who contributed to linux (heh, specially the GNU folks porting their stuff) with open source in mind. This is nothing but a greedy bait and switch on the community.
I often see not 'just' AGPL, but AGPL+Source Attribution Policy (if you contribute to the main repo, you must assign copyright to the owner), and specifically around network/web oriented software.
This combination is pretty antithetical to the 'spirit' of open source (and especially 'libre software', which AGPL is supposed to be) since it basically ensures hegemony on any commercialization ecosystem to the original developer, unless one manages to create a 'leading fork' where contributions land, since only the original rights owner (who also gets the rights to the sum of all other contributions) has the legal means to commercialize (i.e: provide commercial hosting around) any extensions above and beyond what the community develops.
>This combination is pretty antithetical to the 'spirit' of open source (and especially 'libre software', which AGPL is supposed to be) since it basically ensures hegemony on any commercialization ecosystem to the original developer
The spirit of open source was never about giving away the software for free.
The community was concerned with free speech. You want free beer (freedom of commercialization).
AGPL also says that you have to make your changes available. It doesn't say you have to sign a CLA. If you value your "IP", don't. If you value having your changes pushed upstream, do. It's completely up to you.
In terms of 'freeing the source' AGPL without source attribution is just as 'libre' as with it - but with it, the effects I mention are possible - therefore it's radically different when used this way than with the license alone, and so has a 'different spirit'.
You are right though, that 'libre' software is not about economic freedom but keeping the software 'free'. One of the reasons I'm in the BSD/MIT camp - software doesn't exist in a vacuum.
AGPLv3 doesn't solve the problem of projects being used as components SaaS services, as far as I understand? So companies can still use the projects just fine without the need to contribute anything back.
AGPLv3 stipulates that network communication counts as linking, so that putting AGPv3 software behind a SaaS requires that the software's source must be made available to the users of the SaaS.
edit: thanks to pydry for pointing out that this interpretation isn't correct. It is more correct to say that if a user interacts with AGPL software over the network, they have a right to its source.
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
I'm not a lawyer, but that's my interpretation of this section.
Reading it again, it was wrong of me to say that network communications count as linking, though. It's more correct to say that if a user interacts with AGPL software via network communication, then its source must be made available to them.
I think the problem is just slightly wrong terminology. In GPL terms, a network connection under the AGPL is treated as distribution, not linking. If it counted as linking, that would mean that any software that makes a network connection to an AGPL service has to be AGPL as well.
Mainly talks about linking AGPL projects. What about just "using" AGPL projects? Like you'd use a precompiled ffmpeg, cat, grep, etc. without ever touching the source.
That's google and it's to be expected because many of the largest companies have a strict no GPL policy, naturally including AGPL. Doesn't mean tens of smaller startups won't use AGPL licensed software for their SaaS services without any sort of compensation or contribution to the orginal project. AGPL does nothing whatsoever to stop profitable companies from exploiting Open Source software without contributing back.
That's Google, a company half-built on GPL software and employing hundreds (thousands?) of engineers full time contributing to GPL software. Yet, lawyercats decided AGPL is a huge no-no.
Rational self-interest of wanting commodity software for infrastructure / tooling.
A clear winner means more companies use it, increasing demand for it. Which makes it more valuable to master.
If the commodity software is open source, I can learn it at home for a low cost. Then use it at work, again for a low cost. Employers have an interest in using it, as do I.
So I want to encourage Amazon, and other tech companies, to use as much open source as possible! Please increase demand for my skillset!
Of course, the eternal problem is how the software gets developed in the first place. But I really don't want software that bifurcates organizations vs. individuals to become a cultural norm. Even if the impact of any single case is minimal.
> "If it's open for you but not for him what's your problem?"
Now we have to deal with examining and getting approval for umpteen oddball custom software licenses instead of just the standard FOSS ones and, yeah, that is a problem. The pain of dealing with licenses was part of what drove adoption of FOSS in the first place.
The original spirit of open source was scratching an itch and sharing your code in hopes others found it useful. The current squabbles are about large for-profit corporations trying to extract money from other large for-profit corporations, so let's call these new licenses what they are: proprietary licenses with source availability.
>Now we have to deal with examining and getting approval
Your legal department's inability to keep up to date is not the fault of the open source community.
Corporate legal departments were exactly as useless, intransigent and belligerent when open source was first introduced.
Their tendency towards evil or laziness is not an excuse for anything.
>yeah, that is a problem
With your legal department. THEY need to change. JUST as they were dragged kicking and screaming into the age of open source.
>The original spirit of open source was scratching an itch and sharing your code
No it wasn't. It was about freedom of speech and freedom to do with as you will with what you have on your computer.
It's amazing the number of people I've come across today that misunderstood both the legality and the spirit of open source in a way that Google or Amazon would strongly approve of.
If I'm an independent contractor who wants to sell my ElasticSearch expertise as a service, namely by charging to setup and maintain ES instances on behalf of others, am I compliant with ElasticSearch's newfangled non-free license? Or am I "Amazon" in this context? Judging by how Elastic themselves describe their license[1], it looks a heck of a lot like I'm "Amazon" as far as they're concerned, since my labor would take the form of a "managed service" - never mind that my annual income is several orders of magnitude less than Amazon's, and probably would continue to be such even assuming my services sell like hotcakes.
We're thinking the exact same thing we've been thinking since the Debian Free Software Guidelines were written a quarter century ago:
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
> The license must not discriminate against any person or group of persons.
Was the DFSG misguided when it was written, or has something changed since then such that it's a good idea to restrict certain people from making use of the program?
> If it's open for you but not for him what's your problem?
How do I know it'll stay open for me? How am I supposed to make that determination on whether or not it even is open for me in the first place?
With a standard OSI or FSF approved license, I don't have to be a lawyer to have at least some idea of what the license entails, because their lawyers - and plenty of others - have already combed through them and put together layman-accessible descriptions of their stipulations - and further, by the very nature of their approval as "open source" or "free software" licenses, I know with reasonable certainty that even something as restrictive as the AGPLv3 will always permit me to use, modify, and redistribute that software, no matter what.
Contrast with these bespoke "source available" licenses, which are specific to certain products/companies and can change at any time. One might call it "FUD" to be skeptical of 'em, but they certainly seem to leave a lot of room for fear, uncertainty, and doubt given the legal pitfalls around, say, maintaining an independent fork.
Still, at least the software itself is transparent (i.e. it can be independently audited at any time, by anyone with the requisite knowledge, for any reason), so for most cases I would certainly pick such software over anything opaque / closed source any day. The lack of contingencies should the developers inevitably go out of business (whether from buyout or bankruptcy) still pushes me to prefer, you know, actual free and open source software.
Transparency is a dependency of trust, but it ain't the only one.
>How do I know it'll stay open for me? How am I supposed to make that determination on whether or not it even is open for me in the first place?
Technically any license can be changed if the company holds the copyright. This is why Microsoft makes you sign a CLA. This signals a plan to potentially de-open source in the future and capitalize upon their IP.
Source available licenses are about what you can do NOW and it's usually very very clear. For example, don't set up an elastic search SAAS. Of course, you're not Amazon so you won't.
>With a standard OSI or FSF approved license, I don't have to be a lawyer
Apparently you could do with a bit of training because the thing you were most worried about is enabled by a CLA not a source available license.
You are perfectly correct to be suspicious of Microsoft's CLA when combined with their "we turned over a new leaf with OSS" marketing. I am.
>One might call it "FUD"
Not gonna lie: thats the exactly what I was thinking when I read your comment.
> Technically any license can be changed if the company holds the copyright.
If a codebase uses a well-defined license - like, say, the GNU GPL or Mozilla MPL or Apache license - then unless the company is the FSF, Mozilla, or Apache (respectively), then I know with reasonable certainty that as long as they're using that license with that name, the terms won't be changing under my eyes.
The same can't be said of some product-specific "ElasticSearch License" or "CockroachDB License" or "MongoDB License" or what have you. With these, I'm back to having to read EULAs one by one, because the meaning of "$PRODUCT License" can change at pretty much any time.
That is, if you're going to jump immediately to some bald-faced snarky ad hominem like
> Apparently you could do with a bit of training
it would be a lot more effective if you actually understood and acknowledged what I'm talking about instead of going off on some tangent about Microsoft and CLAs.
To the contrary, if Amazon is providing a good hiring funnel for the developers/maintainers, regularly contributing patches back upstream, providing funding to the project's non-profit, and generally respecting the license, then what's the problem? I'm no fan of Amazon but how can I complain about them having a right to profit in cases where they actually are being good open source citizens? Are they really any different from any other cloud provider in that respect?
I am not sure what the problem there is, that is a patch that carries a non open source license, which is allowed by the original ISC license of pgbouncer.
Disclosure: I work for AWS, but I am not speaking for my employer. This post is based on my personal workplace experience.
The policy exists to enable collaboration and contribution, not to restrict it. These types of policies are common at companies like Amazon. Google has posted theirs publicly [1], and Amazon policies are similar. I have used the policy to contribute to more than one "upstream" open source software package, for example the Xen hypervisor [2].
Though I wish I had more recent commits, this should demonstrate that even in 2012 patches were flowing to Xen. More work on Xen by others can be found by searching for "amazon.co" in the commits [3].
They contributed a tiny fraction of development resources and they reap a disproportionate amount of the profit.
Letting the status quo continue would just ensure that Amazon gets even richer off the hard work done by Elastic while development dries up. We all lose while they suck profit out of this product.
It's not like they require elastic to survive. They're too big to fail. By being a dominant cloud provider they have a massive inbuilt advantage
Yes they are different to other cloud providers. They're big enough to throw their weight around and they do.
Because ultimately you are drawing a line between two for-profit corporations and asserting that one of them is exploitative and selfish (Amazon) and one of them is not (Elastic).
In my opinion, Elastic is being just as selfish and exploitative as Amazon is, which is just as much as any other private for-profit company is.
What I don't like is Elastic putting out PR and pretending as if they are some sort of divine for-profit corporation that doesn't do things out of their own self-interest, but is somehow only interested in open software.
In other words, Elastic is clearly not the same thing as the Apache Foundation, but they seem to want everyone to think that they are.
> Because ultimately you are drawing a line between two for-profit corporations and asserting that one of them is exploitative and selfish (Amazon) and one of them is not (Elastic).
There is obviously a difference between a monopolistic corporations like Amazon that is actively crushing any competition with its control of the market and a bigger tech company like Elastic that is mostly driven by technological innovation (for now).
Does not mean that one is more morally evil than the other. In fact monopolistic corporations can offer their workers much better working conditions because of the extra profits they make from abusing their position. Well Amazon is not exactly known for that but in general they do. I guess Developer are treated pretty well at least.
So again, the point is not a moral failure but the economic position and the system that creates such a situation. While the creation of big monopolies is more or less inevitable it is still a good idea to be critical of the social and economic dangers.
I would say the difference between Amazon and Elastic is that Amazon has to compete in the marketplace and keep their customers happy to earn money. Elastic now has a business model where they simply own a rare thing and charge people to look at it.
You have two choices: Either a mostly-open, company-backed ElasticSearch, or a community-backed, completely open ElasticSearch with possibly an order of magnitude fewer development resources. Which do you choose?
It's not open for me to set it up and sell as a service either.
I'm trying to think of a good analogy. Does anyone have a good one?
How about, the software is analogous to a floor plan. I come up with a great floor plan, and allow anyone to use it for their buildings. But I add a restriction that no one is allowed to sell buildings using this floor plan except me.
And to expand on that: if I get really good at building that floor plan, I can't sell my construction services to people who like that floor plan but suck at construction. And further, if I make a substantial improvement on that floorplan to address flaws with it or tailor it to different folks' needs, I can't sell that better floorplan or my services around building said better floorplan.
So now, if I want to make money with my skills and labor, I'm at the mercy of your architectural firm, which means I'm fundamentally at a disadvantage when it comes to negotiating fair compensation for my labor.
> As a user, I can use Elasticsearch just fine with the new license. I can read the code, modify it and use in my own projects.
This illustrates just one kind of user. And only in some situations. For example, lets say Elastic.co goes under. Under the license another company couldn't setup a replacement. So, the end user is screwed just as if a proprietary vendor had gone under.
What the companies behind the new licenses are attempting to do is have their cake and eat it, too. They want open source for all the cred and for one type of user. The want proprietary for the complete control of the stack right through some types of hosting situations.
It's hard to produce something completely open and yet monetize it in way that meets VC grown desires. That's why so many companies open source the common stuff but keep the special sauce proprietary.
> Under the license another company couldn't setup a replacement.
I'm confused here -- the new 'open core' is available under the SSPL, which clearly allows this, as long as you provide the source code of any management layers as well. The non-open parts already weren't available under the Apache license, so nothing has really changed there.
And, yes, this does mean Elastic is the only company able to build proprietary components on top of the code base, which means there isn't an even playing field with competitors. But once Elastic goes bankrupt this is no longer an issue.
> > Under the license another company couldn't setup a replacement.
> I'm confused here -- the new 'open core' is available under the SSPL, which clearly allows this, as long as you provide the source code of any management layers as well. The non-open parts already weren't available under the Apache license, so nothing has really changed there.
This is essentially a legal "gotcha", given that "management layers" is not defined anywhere. The purpose of the clause is not to encourage companies to "open source everything" (what does that even mean? Do they need to open source their IPMI firmware?), it's to prevent anyone from going anywhere near it.
Do elastic.co open source all the management layers in their stack?
> The purpose of the clause is not to encourage companies to "open source everything" (what does that even mean? Do they need to open source their IPMI firmware?), it's to prevent anyone from going anywhere near it.
Right. To make matters worse: it doesn't just require that all of the software used to run the service is open source, it requires that it be released under the SSPL. This immediately rules out using anything which you do not have the legal authority to relicense. So, for example, Linux.
Quoting the SSPL (emphasis mine):
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
...
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
Thanks for explaining that, that makes a lot of sense. I hadn't considered the terms would be effectively impossible to follow, even for a reuser/hoster with good intents.
> So open source means only licenses that are most favourable to the big tech monopolists now?
No, open source means the same thing it's always meant since the term was first coined. See the Open Source Initiative's Open Source Definition: https://opensource.org/osd.
Now someone will respond "why does OSI get to decide the meaning of the term?" Well, they don't have any _legal_ right to do so, but if you don't accept their definition, does that mean every person gets to come up with their own definition? And if they do, what's the point of using the term?
So it makes sense to take OSI's definition as canonical, the same way the Free Software Foundation's definition of Free Software is generally considered canonical (https://www.gnu.org/philosophy/free-sw.html).
Also, to forestall another common reply, I'm not defending Amazon or attacking Elastic. I'm simply trying to define a term that's at the center of this discussion. If we can't agree on the definition, then any discussion of whether a license is open source is moot. The same goes for discussing the impact and value of open source vs non-open licenses.
Are you sure the FSF's definition of Free Software is a good example of your point here? That definition is almost entirely only respected by western software developers who support the FSF's cause. Just type "free software" into your favorite search engine and see how commonly that definition is followed in practice.
Honestly, I think we should just say OSI-licensed if we mean OSI-licensed. Words are only as good as they can be used to communicate with others. If people misunderstand me, it's my fault.
I think this is a good solution. English is not a prescriptive language; loanwords are perfectly valid.
Of course, 'OSI-license' is more accurate still, as they don't have a monopoly on 'libre' either. Many would say the WTFPL is accurately described as libre, even if OSI doesn't.
The OSI should have picked their own term that they could have trademarked, not an existing simply descriptive term, then we wouldn't have this problem.
As far as I know, the term "open source" was coined by the same people who were involved in founding OSI (though the OSI founders were a subset of the people who first used the term). I'd be very curious to see examples of widespread use before 1997 or so.
You are misinformed. The term "open source" has a history that predates the OSI by at least eight years, possibly longer (but I can only provide cites going back eight years). Please see my full reply here: https://news.ycombinator.com/item?id=26507460
> As far as I know, the term "open source" was coined by the same people who were involved in founding OSI
I think this has been shown to be a bit of a myth.
They claim to have coined it in 1998 but there's evidence of it in use in context without even needing to explain the idea by other people as far back as 1993.
They did. "OSI" and "Open Source Initiative" are their trademarks. Which is why people should use these words instead. These do only have one clear meaning.
Unfortunately the word "free" has a dual meaning between "with no/few limitations" and "zero cost". Sometimes, people use the latter definition - using context clues to determine which version of the word is in use is needed similar to other English words with dual meanings.
If we're talking about "free software" in the context of licensing the FSF's definition is the only one that matters.
Obviously there is free (no cost) software as well, at least in English where we have one word for both meanings. This can be easily disambiguated in a discussion by the "free as in speech, not free as in beer" phrase, or if people are familiar with the term, using "libre software" to clarify.
Actually English does have a perfectly serviceable word, but for some reason no one is interested in calling at freedom software. yes it is grammatically awkward, but that’s a less worse problem than being semantically awkward, IMHO.
"Freedom software" sounds like word salad to my American ear, so I'm not sure how you see that as serviceable. If you showed me the phrase and put a gun to my head to guess what it meant, I'd probably guess it was a jokey way of talking about software written in France.
I like that. "Free software" will never stop causing misunderstandings. The first you come across "freedom software" you might google it, but the first time you see "free software" you will think it just means free ($0) software.
Unfamiliar terms should fail fast in peoples' minds, not be silently mistaken for familiar terms.
> No, open source means the same thing it's always meant since the term was first coined. See the Open Source Initiative's Open Source Definition: https://opensource.org/osd.
Problem: The OSI did not coin the term 'open source'. OSI partisans claim that Christine Peterson coined the term at a strategy meeting in Palo Alto on 3 February 1998. However, the term and the concept was well known prior to that. Martin Tournoij does a decent enough job of collecting prior citations [1] that go all the way back to 1990. All the OSI did was take an existing philosophy, scribble some new restrictions in crayon, and called it Open Source(tm)(c)(pat. pending).
Honestly, though, I do love it when this comes up. It gives me the opportunity to irk new guys telling them that Lyle Ball, head of public relations at Caldera, has an earlier citation than the OSI in the form of a press-release announcing Caldera OpenDOS[2][3]. :D
What do you hope to achieve with this? Ok, you win, the term "open source" predates the OSI. So what?
Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
I want people to use the OSI definition in order to elevate debates. I'd prefer to skip past definitions to more substantial matters, like whether "open source" (per OSI) is useful. Is it somehow better than closed source code? Is it _ethically_ valuable? Is there some subset of the OSI definition that provides more value than the rest? These are interesting discussions worth having.
Endless debating the meaning of "open source" is a huge waste of time.
Given that OSI is the only body I know of with a clear definition, let's use theirs and move on to more substantial topics.
The lack of ethics is what poisons the relationship between big tech companies and open source software and OSI was founded exactly for that, to strip the ethical principles of free/libre software and focus solely on technical and economical output. Thanks for remembering us who are OSI sponsors.
Do we really need a ‘legally clear’ definition of open source and free software? Both look like a common term. Want something you could claim ownership over and exact your specific meaning — pick some proper name like ‘Apache license’ or ‘lgpl license’ — pretty unambiguous.
The Apache are a group of culturally related Native American tribes in the Southwestern United States. I'm pretty sure none of their tribal authorities have given you a license for your software.
Talking about categories of things are useful. This is like saying "Do we really need a term for two-wheeled vehicles driven by pedals? Just say you have a Cannondale or a Schwinn."
>Do we really need a ‘legally clear’ definition of open source and free software?
The FSF has gone to great lengths to give a legally clear definition of free software. Something like the SSPL is not free software because it restricts Amazon's freedom to use the software. Stallman has always had an ideological goal when it came to Free software.
Not just Stallman, but OSI was founded with an ideological goal too. It's goal is to strip ethics from software development and focus solely on technical and economical output for companies while Stallman and FSF had focused exactly on the ethics of software development.
If we don't want the idea to be gradually chipped away until it's meaningless then yes, we need to draw a line in the sand and say that open source can have these restrictions but not those restrictions. And thankfully we already have that: the OSI's definition, Debian's DFSG, and the FSF's Free Software Decision are all substantially equivalent and represent a clear consensus on what is and isn't open-source; one that a lot of care and thought have already gone into.
> Given that OSI is the only body I know of with a clear definition
No, you can also use the common definition of "open source" = "not closed-source" = "not (source unavailable)". Nobody has branded this definition but that doesn't make it any less legitimate. See definition #1 on dictionary.com for "closed-source", or #2 for "open-source". [1] [2]
> I want people to use the OSI definition in order to elevate debates.
This is... obviously biased? Other people prefer to use other definitions to elevate debates. You can't claim only the definition you like is able to elevate debates.
And the parent is putting so much effort into arguing about the definition for the same reason you did in your comment. If it was so inconsequential, nobody would care. But evidently people find it a powerful thing, hence they argue about it. You can't simultaneously do that and then claim it's irrelevant.
I think this is the most sensible and inclusive definition, otherwise you have a lot of situations where it's not technically OSI "Open Source" but the source is literally open.
I've seen people use "source available" (?) in these situations, but I don't think it really makes sense because a lot of the time the only thing holding it back from being OSI "Open Source" is that their license has not been recognized by OSI.
But now we need a new term to mean what "open-source" has meant for two decades, just because for some reason we wanted to be inclusive of licenses where the source is viewable but not open for use. And once we've redefined it, we've rendered all discussion of open-source deceptive for the period where it had its traditional meaning. I don't see any benefit to this inclusion.
It's applicable to software, but it's not a good software license due to reservation of patent rights. CC was designed for scientific publications, in that context reservation of patent rights has an understandable meaning, but when applied to software it takes a very different unintended meaning.
(I also consider anything that fits the Open Source Definition to be "open source" and differentiate things actually approved by the OSI as "OSI certified", which should in principle be a subset of "open source".)
I see these sorts of licenses becoming increasingly common in the future, which is why I think it's silly to continue excluding them from being called open source.
The primary distinction in those licenses is that they're not generally open for use — they allow a carefully chosen, closed set of use cases. As an analogy, when a bar has a TV showing some preselected channel at a preselected volume, I don't consider that TV open to my use, even though I can use it for the use case the bar specifically chose to enable.
I do agree that licenses like this will become more common in the future, and that's why I think it's useful to have an identifying term for them rather than making "open-source" less precise to include them. Different words for different things is good, in my opinion.
I agree. My personal term for this sort of "We're OK with little people using the software but we don't want any competition" arrangement is "private-use source license," but I wouldn't be so bold as to argue that's The Best Name. My point is just that I don't think broadening "open-source" is a good answer, because all that does is make it harder to talk about the differences in licenses.
> My personal term for this sort of "We're OK with little people using the software but we don't want any competition"
Large companies are free to use Sentry. There are Fortune 50 companies running Sentry at scale internally without paying us a cent. That's totally cool.
You're also free to compete with Sentry. You're not free to repackage Sentry for the purposes of competing with us. There are lots of competing error and performance monitoring products out there that do perfectly fine without it.
I should also note that many components of Sentry are distributed with OSI-approved licenses that you are free to use to compete with us. For example, our Symbolication service (https://github.com/getsentry/symbolicator) ships with an MIT license, and it's an important part of our business.
The incentive is that running the infrastructure required to host Sentry is challenging and requires engineering resources. You can choose to use our hosted services for a fraction of the cost (engineers are expensive).
Aside, there seems to be confusion about what “relicensing” means. Even in this hypothetical scenario you’ve outlined, we can’t “relicense” already released software. Many users hosting Sentry internally are using years-old versions happily; they would continue to be able to do so. They could also choose to fork the last permissible version and maintain it themselves.
Personally, I think this scenario (relicensing such that self-hosted users could no longer do so) is incredibly unlikely. I don’t believe it would really do anything to grow the company.
I would describe it as "Restricted use" software which has existed for decades, generally as closed source.
Sure the SaaS server licenses are more or less open use with caveat, but why won't a process paralleling tivoization occur?
I wouldn't find it odd for a hardware vendor to release source code, "for review" without the rights to use it on any other hardware as some do for binaries.
In a way that could be worse than closed source as that is similar to the problem of suspicion of reading leaked source code, maybe you are tainted and can't actually write software licensable for competing hardware. Maybe you never read the code yet it will appear that way, but you shouldn't check.
Given the oddities of IP and copyright infringement, it is often the case that only the owner benefits from a process of publishing. I.e. what good is the disclosure of a modern patent?
Yup, this is a huge thing. Get students to use the code, get comfortable with it, then when they write something for their local city or whatever, now that local city is potentially in violation.
It’s kind of like that thing where software vendors give cheap or free licenses to educational users in order to get them hooked and then charge whatever company they might work for an arm and a leg to keep using it.
>Different words for different things is good, in my opinion.
And yet people are fighting tooth and nail to redefine open source to mean OSI approved licence instead of using OSI approved license to mean OSI approved license.
>To see why just change the thread title: What’s up with these new non-OSI approved licenses?
It's an article that you can have a reasonable debate about without stacking the deck against the people you're arguing against. Which is why the people who make money by stacking the deck are so dead set to redefine the word to mean exactly what makes them the most money.
>"Open source" and "free software" have always been mostly interchangeable and have since their inception not simply meant "source available".
Free software was coined in the 80s. I wasn't there for that.
Open source was coined in the 90s because we didn't want people to think that software which let you see the code was free of charge.
Then when they sold out a bunch of tech bros from SV decided that they knew best and redefined open source to mean whatever made their valuations go to the moon. The plan did work as expected because dot com crash.
The people around the OSI have always been share croppers that have been trying to get paid for other peoples work.
Writing "tech bro" and "sharecropper" makes it easy for people to stop trying to look for meaning in your writing.
Also, while I'm sure it's unintentional, your backwards of "sharecropper" smells racist.(It actually means paying someone for the right to do you your own work, and was an attempted to recreate slavery after slavery was banned in USA).
I think you are right "OSI approved license" is a much more precise term than "Open Source".
If OSI wanted to provide the official definition for what is "open source" and what is not, they could have perhaps trade-marked their term "Open Source".
But "OSI approved license" has its own vagueness about it. What does it mean that OSI "approves" a license? Approves it for what? To be called "Open Source"? But then unless they have the trademark for the term Open Source, they shouldn't be the one to give approvals for people to call their software that.
This reminds me of the debates about whether something is true Agile, or merely wannabe-Agile. Words are just words. It is good to have precise definitions but those can be specific to a given context. It is a bit like let x = y + z. Is that the correct definition of x? No, but it is a VALID definition of it, assuming y and z are well-defined as well.
> licenses trying to protect the business built on the open source code
A fundamental aspect of open source is that there is no limit to the number of businesses that can be built on it. If a single company wants a monopoly on building a business on the software, we have a term for that: proprietary software.
This exactly, people are crying "big tech, boo hoo", but the fact is these technology companies like elastic search and co thought they could make open source work for their business model but they struggled in the face of competition and so got defensive.
And this is the fundamental issue, can they build a strong company based on this software, it's potentially possible but that seem to think they can't be competitive hence the license moves.
They made a product in which they spent resources and time and provided as open source, then another company which has many more resources took their open sourced code (which legally they could), did some work (or not) on it and provided exactly the same service, behind their now closed source branch. Not only did this company have much more resources to allocate to it they didn't need to bear the discovery and development costs and took an already proved idea.
It is legal, it was a good business move by amazon but it definitively sucked for those who had invested in building that software.
So yeah, in a way I can understand that now anyone risking their business in creating software or services based on those might be going, "yeah no thanks, you can't fork our work and sell it".
Specially when companies are gigantic and a 0.01% of their budget equates to the whole budget of the company who produced the original source. You can't really "not struggle" in the face of the competition.
I have to dig more into GPL licensing but anyway, there certainly needs to be some licenses that are not "f$#%% me any way you want" for people doing open source products.
The license these businesses should be using is AGPL, clean and simple.
Run the software under AGPL and dual license it under a closed or restricted usage license if a customer doesn't want to use the AGPL license.
Instead we have people electing to create restrictive licenses with varying degrees of "use the software however you like unless we don't like you or your business" baked into them.
The dual full free + restrictive license model has worked very well in the past for FOSS based companies. Let people who are fine contributing back to your project and/or open their project up use it however they please and let everyone who doesn't like those terms pay for it like standard commercial software instead.
I like the idea, will have to read AGPL. In my mind an ideal version would be, when translated from legalese:
If your business is just an extension of the underlying software (the source) and you don't want to open source your part of the work, then pay a commercial license.
If your business uses the software (the source) just as an ancillary part most probably you're ok to source back any improvements back and keep them open source (no need to pay). If it's ancillary and you need to keep them closed, then pay for licensing anyway.
The only thing I don't understand but seen many time mentioned is the "infecting" nature of the GPL licensing?
The "infection" is the feature that makes GPL and AGPL useful. The basic idea is that if you are interfacing with the (A)GPL licensed software you are extending it's functionality and must comply with the license. The difference is that the interfacing with GPL is statically linking against the project. With AGPL the interfacing is also interfacing over the network. What this means is that software that clients or peers interacting with the software need to be available to the user. An additional stipulation for AGPL is that all necessary infrastructure to host the service be open sourced as well.
The reason for this is to prevent people from creating wrappers that allow them to profit off the licensed software without contributing back or open sourcing. The key thing to note is that you don't have to upstream changes. You only have to provide the source to users (and the license protections extend to them). This means you can still sell GPL and AGPL software but you do have to provide full usage permissions to the user once they've bought the product.
As a side note: I've always found it amusing that government contractors have traditionally been very afraid of (A)GPL despite being required to provide (A)GPL-esque usage permissions to the customer/government. Most of this I imagine is due to a fundamental misunderstanding that providing source to the user doesn't mean publicly make source available for everyone.
Now if you have an AGPL or GPL licensed dependency and you want to dual(+commercial) license your project, you have to work out a commercial license agreement with the dependency's maintainer. If a project has (A)GPL dependencies and doesn't have a commercial license but you'd like to use one, you'd have to work out commercial licenses with the project and all the dependencies (or have the project maintainer work said license out).
This infection effectively enforces users to either share their software or "pay" for all of it which is arguably a good thing for the health of the ecosystem as a whole. If (A)GPL+commercial licensure was standard practice, we likely wouldn't be seeing the [OpenSSL/xkcd-2347](https://xkcd.com/2347/) issue keep popping up time and again.
TLDR: The "infection" forces users/developers to either respect the "free" terms or pay for the full value of the software.
They tried to play a game with open source, they knew the rules and AWS did nothing wrong, not even ethically, it's all in the spirit and the letter of the licenses ES chose (for example).
I've literally no sympathy for ES whatsoever, they were either incompetent or playing games.
What ES invested and the size of AWS has literally nothing to do with the discussion, ES made a choice pure and simple. They are within their rights to make a new choice if they so choose.
Ethics don't come into play here and I also don't have any specific sympathy for ES, but I have sympathy for people and companies that provide open source software that others can read and tinker with.
I can like AWS because of providing me services I find useful. That doesn't mean that I have to like everything about them.
> What ES invested and the size of AWS has literally nothing to do with the discussion
Well, it does and doesn't. In a way it would be great to have open-source software be the default, but given that anybody with resources can simply take it and build a then non-open-source version of it and polish it or integrate into much higher leverage existing systems, it does pose some questions as towards what licensing open-source software should have in the first place and if it should be infecting or simply have multiple different clauses related to how it's being used.
But yeah, when playing a game make sure you know the rules and all.
Imo ES got benefit from open source sa marketing tool. Amd no matter what AWS contributed back the fact is ES doesn't want someone else to reap the benefit of that marketing play.
>otherwise you have a lot of situations where it's not technically OSI "Open Source" but the source is literally open.
Just because the source is available to you doesn't mean it's open source though. There are many companies that have the source code to Windows, but I would never describe Windows as being open source. That where the pedanticism comes in.
Definition #1 is, while imprecise, more consistent with OSI open source than “source available”; “intellectual property” is a set of exclusive rights, not the content to which the rights apply—“source available” provides the content to the public, but not necessarily any substantial subset (or even necessarily any) of the rights constituting intellectual property.
> Other people prefer to use other definitions to elevate debates.
No, they'd prefer other definitions to obfuscate differences, specifically, when trying to define “open source” as equivalent to “sourve available” to erase the distinction that having separate terms with distinct definitions provides.
> What do you hope to achieve with this? Ok, you win, the term "open source" predates the OSI. So what?
The point is to demonstrate that the term predates the OSI's alleged coinage thereof. They don't get to dictate language. This usage pre-exists them and obviously persists to this day.
> Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
Really? It seemed quite useful to the people cited in each of those earlier prior references. They seemed to know exactly what they were talking about in context. You have only to read the messages to see that.
> I want people to use the OSI definition in order to elevate debates.
No, I think you want people to use the OSI definition because that conveniently includes certain clauses that have nothing to do with being open source, much like the FSF's definition of free software has nothing to do with freedom.
> Endless debating the meaning of "open source" is a huge waste of time.
You're right. Equally useless is attempting to privilege the OSI's definition over others.
> Given that OSI is the only body I know of with a clear definition, let's use theirs and move on to more substantial topics.
The numerous citations you are now aware of make you aware of others with a clear definition, so... No.
Equally useless is attempting to privilege the OSI's definition over others.
The OSI definition was elevated over others (to the extent that there even are any others) by usage. You can dislike that all you want, but it doesn't change anything. Maybe, in time, usage will flip the meaning to something else... English has a way of doing that. But let's not stick our heads in the sand and pretend that current reality is anything other than what it is.
Language is not a popularity contest. Words and phrases can mean different things in different contexts. That the OSI came along and proffered its own definition does not mean we have to forget what came before and, moreover, is still current today. The OSI is an organization that co-opted a movement for their own business purposes... much like Eric Raymond co-opted the MIT Jargon File.
And companies releasing “open source” software which has hooks in it that put other companies in potential legal trouble (beyond their he usual GPL type stuff) are themselves co-opting the term for their own ends. It’s hiding behind “language flexibility” to use “open source” in this manner.
Your link doesn’t support your claim. Most of those seem closer to the OSI definition (BSD is the first one, GPL, Linux, etc) and the ones that might contradict it are rarer.
The way most people have been using “open source” is a lot closer to OSI than these companies are claiming. It’s misleading to use a different definition nowadays. And I think that’s the actual intent. If it wasn’t, then they’d be perfectly fine with using another unambiguous term like “source available.” If there was a strong desire to be clear and not misleading, they’d use such a term.
Language is not a popularity contest. Words and phrases can mean different things in different contexts.
Except.. it kinda is. I mean yes, it is obviously true that words can (and do) have multiple meanings. But within a given context, there are "generally accepted" definitions and there are idiosyncratic / obscure / unusual definitions. And in the kind of context we're talking about here, to use "Open Source' to mean anything other than what is defined by the OSD is to intentionally choose a non-standard, idiosyncratic definition. It wouldn't be reasonable for one to do that and then expect everybody else to understand / agree with their non-standard usage.
"They" don't have to dictate anything. The point is that "Opensource" as currently used means something else than shared source. Freeware means something else than free software and free speech does not mean zero cost cellphones.
Taken literally these words could mean something else, but they don't. And using them in a wrong, hoping that people will confuse them for something they like (free speech for phones is good, right?) is extremely dishonest.
> Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
Get with the program, dude. It's 2021, and the prevailing sentiment is that all definitions are now fluid. #GoForWoke #GoWokeOrGoHome
> Given that OSI is the only body I know of with a clear definition
If this is the only definition you're aware of, then apologies, but you're not the right person to be attempting to drive this discussion.
If you're aware of the many others but do not consider them 'clear', then there is something else going on here, and I am starting to wander about agenda.
I think the common-sense definition that a lot people use, especially people not deeply invested in the movement, is something along the lines of "the source is available for everyone to examine and make modifications to".
It's not as specific as the OSI definition of course, and it doesn't say anything about redistribution and such, but that's okay and it doesn't really need to be IMO. Some vagueness is okay, and even with the OSI definition there is a huge difference between something like MIT and AGPL, both of whom are "open source".
A large majority of software developers and related professions use OSI's definition in my experience. Even the ones apathetic or antipathetic to the movement. The elements of OSI's definition have practical consequences for them.
People talk about permissive and copyleft licenses when the distinction matters. Covering both doesn't make open source vague.
Alternative definitions restrict the freedom to run the software at all frequently. Never mind modifying it.
Yes, and butterfly is a fly made of butter. English words mean what people understand them to mean.
The only thing you are saying is that other people tried to use "open source" for something else and completely and utterly failed to convince people. Thus, today "open source" means what it means.
“Open source” has long been used used to describe research of publicly available information. A quick search in google books shows references back to at least the 70s. This meaning is consistent with the “source available” usage today.
> Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
Which is why you should call them "OSI Licenses" if you are referring to OSI licenses.
> let's use theirs and move on to more substantial topics.
This just isn't how English works. It isn't prescriptive. English is descriptive by nature and permits multiple uses, which have been around before OSI ever existed and are still valid.
Sure, but I think companies are actually abusing the common definition of open source (which roughly has been the OSI one) by calling their source-available (but private licensed) stuff “open source.”
> Which is why you should call them "OSI Licenses" if you are referring to OSI licenses.
1. They aren't written by or copyright or anything to the OSI. They aren't "OSI Licenses" they are "OSI-approved licenses"
2. The Open Source Definition as clearly defined by OSI (and accepted as the only consensus definition in the world) does not include OSI-approved as a factor. So, a license can be Open Source without the OSI having done the active approval to validate that they see it as Open Source.
"Open source" was used to refer to source-available material for decades before it ever OSI ever existed. This is the reason why OSI can't get a trademark on the term -- UTPTO won't let you trademark a generally descriptive term already in use.
> Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
Here’s the Cambridge Dictionary’s definition of open source: “Open-source software is free to use, and the original program can be changed by anyone.”
Merriam-Webster’s definition: “of software : having the source code freely available for possible modification and redistribution”
>If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
We can certainly be more specific as to OSI Open Source rather than just Open Source? Wouldn't that solve the problem? We dont have to define every single term to have no ambiguity, but we can certainly have specific term for specific purposes.
You are correct that two people discussing "open source" should agree what they mean. You are not correct that what they agree on needs to match the OSI's definition. This issue can be solved by just asking someone what they mean.
The important thing to take away from those references is that the term "open source" (not followed by the word "code") wasn't ever used in a consistent way, and that a bunch of people putting the word "open" to in front of "source code" is not the same thing. Open Source is something invented by and defined by the OSI, and I always capitalize it to sidestep the argument.
If you were talking about "opening your source code," or developing new versions of your product with "open source code," no one would be confused, or if they were confused, they'd ask a follow up. The claim isn't that "open" and "source" were not words with meanings, the claim is that "open source" didn't describe anything specific until OSI made it. This argument is like complaining that people had windows in their houses before MS Windows.
Your quote is exactly an example of what the parent describes, so I think you miss their point. It is at best ambiguous, but to me clearly reads as constructed by applying the modifier "open" to the compound noun "source code". Someone talking about red fruit flies hasn't made any reference to red fruit.
I make no claim, here, as to the ultimate disposition of the argument, I just don't like points being missed.
A lot of those usages of "open source" mean something different, totally unrelated to software. The word "source" there often doesn't mean source code, but more like sources of information, like when you cite your sources in a paper. That's the older meaning of "open source intelligence", meaning information you could get from freely available sources like phone books or maps. OSI even explicitly acknowledged those older meanings, and they also knew there were very scattered and inconsistent usage of the term before OSI.
This still doesn't mean that OSI didn't coin the meaning of open source: a watered-down synonym for free software that de-emphasised its political philosophy.
The fact remains, even openly acknowledged in Martin Tournojj's article when he looks at the growing usage of the term, that the reason we're all saying Open Source is because Tim O'Reilly bankrolled OSI's marketing campaign[1], and it was so effective, that they convinced us the term was so natural that it was our own idea. It wasn't. It was OSI's.
Now, I get the urge to say "OSI doesn't get to decide!" because you don't want to be told what to say or what to believe. You want the word to have a different meaning. You're a free agent, dammit, nobody gets to tell you how to talk. Well, you're not as free as you think you are, because you wouldn't be talking this way if it weren't for a whole society that was influenced by the power of the wealth of one individual in the late 1990s. Your fashion choices are not are individual as you think they are[2], and neither is your language, nor even your beliefs.
> All the OSI did was take an existing philosophy, scribble some new restrictions in crayon, and called it Open Source(tm)(c)(pat. pending).
I am starting to believe that the greatest mistake of the FSF and OSI is exactly that. They did not trademark the terms. And this resulted in endless debates about free as in beer vs free as in speech (vs free as in puppies :P ) and on the meaning of open and on shared source vs open source.
Stallman likes to call the GPL and copyleft a "hack" on top of copyright or a "hack" of copyright. Unfortunately Stallman was never opposed to IP as a whole. He is only opposed to software (only) pattents. If he were opposed to all IP he might have had the idea to "hack" the trademark system and use it to prevent all of this confusion using the threat of lawsuits. After all FLOSS is full of benevolent dictators.
Now we are stuck with "free", "open" and "libre" freely being redefined to suit the PR needs of anyone.
The people have decided that "open source" means OSI open source. Therefore that is its effective definition. Which means
Exactly. In common, everyday usage, when people talk about "Open Source" this is what the majority mean. It's not a "de jure" definition, but it is a "de facto" definition. Open Source means compliance with the OSD. There are terms for those other licenses - "shared source", "source available", etc. Use them if that's what you mean.
Worst case? You walk through use life using terms in non-standard, idiosyncratic ways, and people are constantly confused by your speech, or argue with you because you don't have a shared understanding of the world.
Except it isn't really idiosyncratic since there appears to be widespread confusion as to the meaning of that term.
You can't just hand wave that ambiguity away and pretend that only the OSI definition is understood and used. You have to accept the "open source" is an ambiguous term and you will need to use qualifiers or additional context if you want to avoid ambiguity when using that term.
Agreed. One of the issues is that from a Venn diagram or set theory point of view, all "Free Software"(by FSF definition) is "Open Source", but not all "Open Source" is "Free Software".
Yet people really only know of Open Source as a common term to describe these projects.
Uh, it is a practical one as being described in this thread.
Simply because the source is openly available to read, the licence can still say "you can read but no touchy touchy or compiling it".
While technically it doesn't stop you from actually doing this, in a court of law you'd be found to have violated the licence. So it wrecks the idea of businesses doing it, because usually the licence holder won't care unless someone is making money from it.
Free software lets you do whatever you want, but you gotta show your code. Big difference in practice, especially when it comes to running a business.
Nope. The debate in the community before OSI existed was between free software and open source as terms. Free software was the term preferred by the FSF and the GNU project, with their more stringent notions of free. "Open source" was the term coined counter to that to describe things like BSD licensed code. The OSI was founded as a way of promoting this whole world of software development to businesses, and they focused on "open source" as a labeling strategy so they could distance themselves from the FSF.
The OSI is really just a way of branding certain licenses so IT departments at companies can point their legal departments at the website and say, "Look, this is legit." We forget today that in the 1990's people would assume that software they didn't pay for was shoddy, or that if they were running it, it was stolen and they were going to be audited and sued.
I think Amazon running their own ElasticSearch service and competing with Elastic is entirely faithful to the original spirit of free software, where Stallman was backporting innovations from commercial Lisp Machines onto the MIT free Lisp Machine OS that anyone could use.
There is the model right now of founding a company to host your software or similar as a funding model. While it is popular, I doubt it is any more sustainable than any of the other models we've seen. My lesson from all of this is that capitalism lacks funding mechanisms for producing commons, and that the proper solution is to produce non-capitalist avenues for doing so.
The BSD licenses (that are in use today) are considered free software licenses and always have been. The FSF doesn't prefer them because they aren't copyleft.
from "Words to Avoid (or Use with Care) Because They Are Loaded or Confusing"
“Open”
Please avoid using the term “open” or “open source” as a substitute for “free software.” Those terms refer to a different set of views[1] based on different values. The free software movement campaigns for your freedom in your computing, as a matter of justice. The open source non-movement does not campaign for anything in this way.
When referring to the open source views, it's correct to use that name, but please do not use that term when talking about us, our software, or our views—that leads people to suppose our views are similar to theirs.
Instead of open source, we say, free software or free (libre) software.
So many comments in this thread seem to conflate Open Source definition with the original Free Software definition.
The companies who have restrictions on how their Open Source software can be used can technically be Open Source (depending on your definition) while failing to be Free Software.
The two links clarify that originally at least, they were not the same thing.
This has been going on for a long time and hence as with many language phrases the use/connotation/definition may change over time.
And so we have a HN comment fest over "What Really Is The Definition of Open Source?".
> So many comments in this thread seem to conflate Open Source definition with the original Free Software definition.
The Open Source Definition and Free Software Definition are virtually identical in application. Other than CC0 being withdrawn from OSI consideration (not denied) and accepted as a Free Software license, I can't think of any differences in practice.
The Open Source community and the Frr Software community have differing ideologies, but nearly identical minimum requirements for software licensing to meet those different visions.
Well, Open Source is a superset of Free Software. So it gets all the credit for what is actually Free Software.
Now as per my original point. This has been going on a long time, and as with language the definitions can change over time.
Early on they were different. Open Source basically implying "hey you can read the Source!" but not necessarily giving you any other freedoms to actually USE it.
But today, people are saying Open Source and Free Software are much the same thing.
I am all for them being the same thing. IE I am happy with Open Source in all practical ways having the same freedoms as Free Software.
But now we gotta call out those projects which define themselves as "Open Source" for marketing use of the goodwill around nice modern definition while operating under the old definition.
This sounds like "if A and B can't agree on a definition, terms are meaningless, so we need to use A's definition." Why not use B's definition?
The purists saying "open source is a narrow thing" only distract conversations about licensing. Word meanings drift over time. We manage. Talk about issues instead of gatekeeping terms.
In spanish* we have a word: "emparejado" which means a door is not open but not quite closed. It appears closed, but it's not. Maybe we should use "emparejado-source" :)
As a developer acting on behalf of an organization using open source, I benefit from being able to pay the vendor of my choice to host a given piece of software.
If only the single-source author can host it as a service, or you need the permission of the single source author to host it as a service, then my choices are either self-hosting, or paying whatever price the single legal-as-a-service-host wants to charge, at whatever service quality they provide. (The fact they can choose to allow other licensed hosts, perhaps for a free if they want, does not change their monopoly control). It is a form of vendor lock-in, and avoiding vendor lock-in is one popular motivation for using open source.
So yes, this restriction makes something not open source. This restriction also is not favourable to me as a user of the open source software. Open source was always about avoiding monopoly control of who is allowed to do what with the software. Monopoly control of who is allowed to host it as a service is such, and it is more favourable to me as a consumer when there is not that monopoly control.
Now, meanwhile, there are various market battles going on between various big tech cloud providers and other companies providing (previously) open source software. This is also true. Both things can be true.
For the consumer, as the OP suggests, your best bet is when there is software that can be produced sustainably by multiple entities collaborating, instead of a single company.
Now, if that's not sustainable, that's a problem. It's possible that open source is facing sustainability problems due to current conditions.
But that doesn't change the fact that monopolizing legal right to host software as a service is not open source, is rightly not approved by OSI, and is making consumers locked in to that single vendor (or their licencees), which is indeed contrary to intention of open source.
> It is a form of vendor lock-in, and avoiding vendor lock-in is one popular motivation for using open source.
Likely also a false one. For example, if you use WordPress guess who your vendor is? WordPress. More vexing, if you use Kubernetes provided by a cloud provider guess who your vendor is? The cloud provider, because of all those non-free doodads they put into their managed service.
It is possible for a company like AWS to continue to offer a managed service for things like elastic, but I suspect elastic wants the nature of the agreement to change; which as far as I can tell we're not privy to.
I can pay for a hosted wordpress on BlueHost, FlyWheel, GoDaddy (don't do it!), linode as a "marketplace app", and many many others.
None of these sites need any agreement with the wordpress authors at all, because wordpress is open source, anyone can run it. wordpress owners can't withdraw permission to offer hosted wordpress or make them pay for the right to host, because it's open source.
if I don't like the pricing or service on wordpress.com, I have many options for wordpress-as-a-service. If wordpress.com is the best price/quality, it's because they've done a good job, sure perhaps because they have the most expertise with the software since they write it -- not because they have a license that gives them a monopoly on wordpress hosting.
My point was that the term "vendor lock-in" is loaded. Your point is valid simultaneously.
Expanding on my point, I do think it's possible that AWS can provide services that continue to make software easy to run (like fully managed services). The way I see this is if AWS becomes the primary contributor and the dominant service provider, then the same situation you described happens in reverse. I think the solution here is probably about connecting the success of managed open source based services on AWS to keeping the companies that power them funded. If you balance contributions and money, it keeps the ecosystem in a better state.
I see what you mean, and this perhaps is related to the OP's suggestion that ideally you have a "open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors" -- multiple significant contributors.
But here's the thing. Open source means that even the single contributing entity can not take away your ability to use already-reased code, or anyone's ability to fork it and keep working on it without the permission of the original author.
Open source is designed this way exactly to avoid vendor lock-in -- you can always, in the "worst" case, fork the code without the participation of the original authors at all.
This won't necessarily be easy, cheap or even feasible; sure. Open source does not automatically solve all your problems or guarantee that you'll be able to get the software you want for free forever. It just takes out of the question needing to get permission to do what you want or need to do from the authors or a single owning vendor. This is what many mean by avoiding vendor lock-in.
In some cases open source may not be sustainable. In some cases as a consumer it may make sense to choose a non-open-source product; in many cases as a producer trying to make money producing open source may not make a business model. But if you want to limit people's ability to use whatever hosted service providers they want, including after a fork, including even if your business goes out of existence, that's not open source.
> I can read the code, modify it and use in my own projects.
That isn't clear. The license language can be read as requiring you to provide the source code for any software that interacts with ES (e.g., the Linux kernel that you are using to deploy ES over) under the terms of the SSPL to your own users, which you literally can't do.
Elastic claims in their FAQ that this is not the intention, and that may be enough, but it is debatable. Regardless, the SSPL is a bad license for having this ambiguity in the first place.
Similar kind of ambiguity is even in GPLv2. ie. what does "anything that is normally distributed with..." in section 3 mean and how all that interacts with notionally GPL licensed software which depends on 3rd party components with GPL-incompatible licenses (on Unix-like systems the issue is typically only with OpenSSL but for GPL licensed Windows-only software this is giant can of worms).
What makes SSPL and similar freedom-0 ignoring licenses problematic is that you have to care about these kinds of license ambiguities even if you are just using the software.
> So open source means only licenses that are most favourable to the big tech monopolists now?
Open source originated in the 1980s and 1990s in largely academic circles. It gained mainstream popularity as an alternative to closed source "shrink wrap" software and closed shareware.
Back then the legitimate fear was that closed-source vendors would lock everyone in and end up effectively owning the entire computing ecosystem and the Internet. By the mid-late 1990s Microsoft was well on its way to having a total OS monopoly on PCs and increasingly servers, and were it not for Linux and many other projects this likely would have come to pass.
Good news: open source mostly won! We now have a fairly open compute ecosystem. Even Windows was dragged into adopting more Posix-like standards, and the Mac is just a proprietary GUI and set of system services running on top of a mostly open BSD kernel. It's borderline trivial to port most software between Windows, Mac, BSD, and Linux, so we avoided OS lock-in!
Then along came the SaaS business model and closed Internet silos.
Cloud-hosted SaaS just totally upends everything. Now open source doesn't really matter from a freedom perspective. The cloud has all your data, and by keeping select bits of code (or even just the system configuration) secret and locked inside cloud servers vendors can achieve DRM that is effectively impossible to circumvent.
You can't even run the software yourself, and even if you could your data isn't yours. Having the source is meaningless. It's a model that's more closed than closed, and not only is it compatible with classical open source but is actually fed and sustained by it. Open source is free labor for closed cloud SaaS.
The OSI is fully industry captured and isn't interested in challenging this, which is why large projects are adopting non-OSI-compliant licenses.
I don't think your conclusion follows. Elastic effectively saying "Nobody can provide our software as a service" doesn't increase the openness of the overall system — it reduces the openness of the system in order to benefit Elastic, which would like a monopoly on providing Elasticsearch as a service.
From the user's perspective there is little difference. SaaS means you don't control the data or runtime.
If others want to host Elastic as SaaS they just have to negotiate a license. At least the authors of the software are supported.
In this case the authors being supported by their ownership of SaaS rights are releasing the source to their product under terms that allow you to run it yourself for reasons other than providing it as SaaS. That means you can in fact control the runtime and the data if you want to do that.
The alternative is to have someone else sell it as SaaS and not compensate the authors, running the risk that the open source will be abandoned. This is the SaaS equivalent of embrace-extend-extinguish.
> So open source means only licenses that are most favourable to the big tech monopolists now?
The article explains its point of view in the first paragraph:
"I’ve been asked repeatedly about a two-year trend in the open source ecosystem: ‘single source’ open source companies scrapping their Open Source Initiative-approved open source license for a ‘source available’ license."
First of all the 'spirit' of the new license is "you can do anything you like with the code, except if we don't want you to". Nobody knows when or whether one of these companies will turn around and say "that's now part of our business model, you can no longer do it". Perhaps they will decide that not only can Amazon not 'resell' their product, neither can anyone host it themselves, but everyone has to subscribe to their cloud service.
Secondly, although I love the Redis product for example, the company that sells it is no longer getting rewarded for their added value, as when they sold support or consultation, or as when AWS sells the fact of putting Redis on a machine and maintaining it. Instead they get paid for supplying something that no one else has, something which they have made artificially scarce.
Next, Amazon et al have resources and market power enough to push their own versions of these. Who will it serve when there's Amazon Redis, RedisLabs Redis, Community Redis, Azure Redis, all with slightly different interfaces? Who do you think will win? Amazon and Microsoft have the resources to destroy small competitors in these type of battles, and the user will be even more screwed. Just because Oracle failed with Jenkins, don't assume that no big tech is savvy enough to succeed at this game.
Lastly, free software wouldn't exist if everyone took your attitude. If Linus had told people that they could install his kernel for free, but that distros had to pay $2, Linux would never have been a thing. If you can't deal with sharing when someone else might end up putting in less and taking out more, you're not ready to share.
Disclosure: I work for AWS, but I am not speaking for the company.
The Redis case study is a nuanced one. The core Redis code is BSD-3 licensed, and adopted a lightweight community governance model in June of 2020 [1]. This model includes a core team of individuals, and seeks to empower individuals who demonstrate a long-term commitment to Redis as a community-driven project.
The core team is now made up of people who currently work for Redis Labs, AWS, and Alibaba [2].
From my perspective, on the core BSD-3 licensed Redis code, it is in all stakeholders interest to collaborate on the "upstream." There's one Redis, and it is the version that is produced by the Redis development community, and Redis Labs acts as the primary sponsor and steward of the project.
Fair, I am using Redis as an example here, because I know more about (the technical side of) their product than some of the others. I think similar considerations apply to Mongo, Elastic and the others.
A viewpoint that often gets left out of these discussions is the intersection of true open source and doing big things. So many orgs and people in these debates fall into the easy trap of assuming the world of potential open source users (and contributors) can be split into two camps: there are small-scale/small-business/hobby/startup projects running on true open source, and then there are Big Internet Things run by Big Money Machines that can afford to pay any price and should, and probably don't care about open principles in the first place and therefore don't mind running a closed-source version of some project.
The Wikimedia Foundation (WMF) doesn't fit these molds: Wikipedia is kind of a Big Thing on the Internet, and yet the WMF is committed to openness and transparency, and part of that commitment is that we only use real open source software. This is increasingly a challenging proposition with the shift towards "Open Core" concepts and specialty not-so-open licensing. The "Open Core" model is especially challenging for the WMF, as it's usually structured along the lines of "The hobbyist version of this product is open source, but if you want the features that are necessary to operate at big global scale, you need to buy licenses and run proprietary extensions or versions." The WMF's principled way of operating relies on there being real open source projects that actually work for doing big things.
I think the Internet (and the world) would be a better place if there were more principled organizations like the WMF which operate with a high degree of technical transparency and openness. If open source licensing models keep going down these darker paths, it's hard to imagine such organizations being very successful. It should not be a given that doing big things in the world implies going proprietary and commercial and running hidden code nobody else can see (or use to replicate your success at other open orgs!).
Honestly, I wonder whether GPL and AGPL world be considered open source licensing if they were released today. Ironically, it's commercial interests that have made the Apache-like licenses popular in the first place.
Careful when you read and modify it, since it’s not actually an open source license, you can poison yourself if later in your career you decide to write a new thing in the same space. Someone could come and argue that you are writing a derivative work, similar to if you spent years seeing closed source software inside a company and then went and made a similar product. That’s the actual safety from using something like MIT, BSD, or Apache: who cares whether or not the projects you read and maybe even contributed to inspired you, or if code you later write coincidentally looks similar to code from these projects, it’s no strings attached! These licenses however have many of the same legal subtleties as the GPL, except with a more explicit commercial intent, and owned by parties who have already demonstrated that they become unhappy when competitors make more money than them (as opposed to the “spirit” of the GPL which ultimately just wanted everyone to be able to see the code).
> So open source means only licenses that are most favourable to the big tech monopolists now?
Fully agree with your opinion here. In fact, I posted a lengthy comment on reddit about this, here it is copy/pasted. NB: "You" below refers to the OP on reddit I was replying to.
---
Yes, and that's why the phrase "open source" would be perfectly appropriate: open for inspection, review and modifications, but with possible restrictions on use and redistribution.
Now from your description and quick glance at approved OSI licenses, the problem is that OSI seems to like and approve "free source" licenses, "free" basically being the freedom to do what the heck you want with it. (Except for GPL and its variants as /u/nemec noted. Not to mention that Affero GPL is OSI-approved and comes with restrictions/obligations not unlike the new Elastic license.). [EDIT: this paragraph was meant to illustrate the ambiguity of "open" in the OSI's license collection.]
If somebody is the "enemy" of developers here (in terms of they getting fairly compensated), it's OSI: they've made a marketing stunt (which you seem to have bought -- and I don't mean anything bad by this -- you're not alone) by adopting the phrase "open source" instead of "free source", or even more explicit phrase "free-rider source". So now you have a bunch of developers striving for the OSI "seal of approval" and donating their work for free to huge companies. It almost seems like a plan devised by those big companies. Oh wait, look at the sponsors: https://opensource.org/sponsors
No, I do not believe that OSI is the result of a conspiracy of big companies. But those big companies have been smart and coopted OSI for their benefit and now contribute to OSI to keep the marketing stunt rolling on.
The whole movement is because some people are opposed to open source being too "for everyone" and there's certain classes of people that the projects would rather exclude from "everyone" (i.e. those who might run a competing service to their own).
Sure, and if that's your aim, use one of these licenses from the get go, compete on what you're able to make a living offering. You might find it harder to get that initial buy in, but with open source as a business model you are effectively trading off exclusivity for more widespread adoption.
Don't ride the wave of being open source to success and then try and close the doors after it's established you a position, and don't try and brand non-open source as open source and muddy the waters for the rest of us.
Things change, people change, priorities change.
It may not be convenient for you, but I support people pouring themselves into projects that have a license that matches their willingness to share.
What's up is that large companies started abusing the open source licenses to benefit themselves at the expense of open source communities. All it took was one jerk ignoring the spirit of open source and exploiting open source projects to the maximum extent that was legal under the old licenses. It's not hard to guess who it was either.
It's a good lesson. As soon as one person cheats or violates the spirit of a system, everyone else has to too or they'll fall behind. Unethical people ruin everything.
In a way, they do. There exists a "company culture", which is the collection of social norms that have formed inside the company. Most members of a group will behave in a way that does not stray too far from these norms.
There is a very good TED Talk by Dan Ariely "Our Buggy Moral Code" which describes how such a culture is facilitating unethical behavior by individuals.
While it would be nice if we could get away with people abiding by an unwritten 'spirit of the agreement' the reality is that if you don't want someone to do something with your code then it needs to be written down in a license. I think it is somewhat naive to expect it work any other way, as when you potentially have millions of devs using some code it is unrealistic to expect them all to grasp an unwritten set of rules from a culture they potentially know nothing about.
You can have quite relaxed rules as long as everyone abides by the spirit of the agreement. As soon as one party violates that spirit you are forced to make everything much more explicit, which inflicts collateral damage on use cases nobody would have objected to previously.
> You can have quite relaxed rules as long as everyone abides by the spirit of the agreement. As soon as one party violates that spirit you are forced to make everything much more explicit, which inflicts collateral damage on use cases nobody would have objected to previously.
How are newcomers to know what the mystical "spirit of the agreement" is if it's not written down?
How do you detect that there isn't, in fact, a precise consensus over the "spirit of the agreement" if it's not written down?
Newcomers can just look at what others are doing, and if what they want to do goes beyond standard practice should ask themselves "do I do undue harm to others?".
That's how society generally runs on all scales, whether we are talking about the office fridge or about national law. Things generally start with very few explicit rules, and new rules get made when they are proven necessary.
If law was as simple as reading what's written down, then what are all the lawyers and courts for. There is a lot of interpretation going on.
But really I was referring to the process of how the laws are formed in the first place. A lot of the time they start out under-specified, and as abuses emerge we make more concrete laws using our new understanding. Of course the latter part usually leads to a lot of discussion and resistance because of the collateral damage any new law causes by being slightly broader than necessary. Which is a major reason many industries self-regulate in the attempt to make explicit laws unnecessary.
Plus as a consumer I always thought the "spirit" of the open source agreement included avoiding vendor lock-in, in the first place. Now the argument is that the "spirit" all along was intended to require vendor lock-in, that consumers wanting the software hosted for them as a service should have only one option (Or authorized licencees of that one monopoly option), and that was always the "spirit" of open source?
I don't think so. I thought the "spirit" was the opposite of that, that open source would let consumers of software avoid vendor lock-in or monopoly control of the software.
The spirit of collaboration and working for a common good absolutely used to exist. Many of the internet's core protocols were built with the spirit of cooperation weren't they?
Think about email and the value it adds to the world. Would we ever get the protocols needed to create email if we started right now today? Not a chance.
IMO the previous generation(s) of tech people were way better than what we have today. They were interested in and enthusiastic about building awesome tech / products. Today the only thing anyone with influence is interested in building is a company that can IPO and make them a billionaire.
> The spirit of collaboration and working for a common good absolutely used to exist.
That currently still exists. It has nothing in particular to do with software, though. People collaborate, academics collaborate. Are you telling me that massive corporations were part of this back in the good old days, just helping people for the fun of it?
> This is not a thing that exists. What we have are licenses, not ghosts.
Before we had open source, we released software as public domain. The spirit existed before the trademark phrase was even invented and long after people were already giving away their software for free because of the spirit of the community. We used to go to computer swap meets in fairgrounds buildings and buy boxes of floppy disks with random software on them just to see what was around, people uploaded it to BBSes and shared the work they did - we had Donationware, Shareware, Postcardware (a personal favorite), Beerware and everything in between which was 100% based on the spirit of the community. We just called most of it Freeware.
You're projecting your good feelings about collaborating with other computer hobbyists onto a set of software licenses applied to extremely corporate, not-hobbyist software. And additionally complaining that the "abuse" of these licenses by massive corporations are keeping the authors of this software from getting rich.
If you're doing this for the pure joy of programming, you're already rich in spirit - Amazon taking your software and using it is actually a tribute.
I really don't think my comment said anything about people getting rich; I myself was involved in one report of GPL abuse to the EFF on behalf of Busybox, yet another early 2000s device created by 2 people in their bedroom who simply decided the license didn't apply and releasing the source code was not their responsibility - Busybox had a "Hall of Shame" web page up back then, you can still see it in the Internet Archive. It was pretty rampant, the sharks saw "free code" in the water and simply had the attitude "so, sue me and prove it in court" about early GPL. It took us collectively a decade or more to actual make things like the GPL enforced in courts of law, the dawn of our digital age started with bad guys trying to exploit the good guys who gave away code.
My thought is that you're focusing on the "gratis" part of FOSS, whereas I'm over here in the "libre" side of the house - as a (now) Linux systems guy, when (foo) doesn't work I reach and go down that rabbit hole of code until I figure out what's wrong and we fix things - that is what Open Source is about to me, it has no underpinnings of monetary compensation, it's all about two (sic) people who don't know each other being able to randomly see each other's code to solve the problem at hand (and then possibly submit fixes, bug reports, etc.). I've traced tons of open source software to solve problems both personally and professionally.
Getting paid for open source is a relatively new thing in my life timeline, I don't honestly subscribe to that idea but to each their own. I do, however, recognize the time effort and energy it takes to create said software, so I personally take these tech dollars I make at $job and donate to a lot of open source initiatives, coders and even public radio stations bringing me "free" music. There's no such thing as a free lunch as a wise sci-fi author once wrote.
As I remember it the 'community' was completely divided for most of its existence between those who held that the spirit meant writing your own software and sharing that of others who had agreed to do so, and a much larger group who believed that the spirit consisted of sharing anything you wanted, including plenty of closed and for-pay commercial software.
No I do not (I don't deny it was/is a thing), as I feel that was a different community (and it still exists today) - yes, the same technology was used but no, they were not/are not the same community. These are two distinct communities sharing common technology (just like Linux ISOs and pirated software are both distributed over BitTorrent today - the technology has changed but both groups still share it's use). I knew/know people from both communities, they're just two different groups of people who might happen to end up at a party together, that's about it really. I personally don't condone piracy, but then again I've been living inside Linux for 20 years so I don't really encounter it these days.
Me personally, I ran a BBS under OS/2 and was part of Fidonet (I actually roomed in college years with the local Fidonet hub guy), wrote my own widgets in TurboPascal and distributed the binaries and source without any licenses (if we even had any at the time), some of it can still be found in those old CD collections that folks used to sell. I lost my own source code over the years and was able to recover some of it out of those archives. :) (my career steered away from programming into systems engineering, not a coder by trade)
Well, I think a lot of the people who were doing piracy would argue that they embodied the spirit of the community, and the anti-pirates were just a small minority who had a particular approach. So I don't think it's possible for you speaking alone to say what was or wasn't the spirit or the community.
We're both talking about the open source community, right? This was the Parent comment I replied to and directly quoted, and I'm not seeing why you're intent on focusing on something I'm not talking about. You seem to have an axe to grind here on this specific topic of piracy, not open source.
I'm just using piracy here to illustrate how your take is not founded in reality.
You said:
>Before we had open source, we released software as public domain. The spirit existed before the trademark phrase
You're claiming that the shareware community was a thing, and is somehow the same, or a natural predecessor to the open source community, and that the software piracy community is something completely different and unrelated.
I think this claim is just you imposing a political slant on something much more ambiguous. Arguably the BBS community as a whole was strongly pro-piracy and pro-shareware, and generally indifferent, except for small sections, to things like sharing source code.
There are two broad spirits of open-source license: copyleft and corporate charity.
Copyleft licenses like the GPL encourage those using the code to contribute back to the open-source community.
Charity licenses like the BSD or Apache license are used by developers who want to work for exposure. They only encourage giving credit to the original developers, and implicitly allow closing the source. Letting people do that is the whole spirit of these licenses. People who don't want to be making charitable donations to megacorps shouldn't use charity licenses.
Not necessarily. The project I'm currently working on was initiated by a group of mostly-mega corps, staffed with dozens of full-time developers, and Apache licensed — all out of rational self-interest.
Just because megacorps sometimes release code under permissive licenses doesn't invalidate my point that permissive licenses are a way to make a charitable donation out of your work. Megacorps also make donations to charities. Charitable donations can be made out of rational self-interest!
Following the terms of the license is not abuse. The whole point of permissive licenses is to allow anybody to exploit the software as they wish. If that's not what you want then don't use a permissive license. AGPL is a good alternative choice.
There's a famous essay about the Tragedy of the Commons -- the high level idea is that if there is a resource that is commonly available for free then some users will exploit it for their own gain. It originally referred to ranchers who would overuse communal grazing lands, but I think the lessons apply equally well to open source as well.
In my opinion, a healthy open source ecosystem relies on people using and contributing back, supporting the distributed creators that make the ecosystem possible. This historically has been something of a gift economy or social contract, but it's become wildly distorted by companies (e.g. Amazon/AWS) attempting to overuse the commons resource and make profit from it.
So it comes as no surprise that when one rancher comes in and overgrazes the common resource, the other participants might want to make some changes in rules. These new licenses aren't "just because", they come from lived experience of entities like Amazon coming in an exploiting a shared resource.
And I get it, the letter of the law says, "Do whatever you want with this shared resource". And there are plenty of folks who believe that Amazon has done nothing wrong -- the rules allowed for overgrazing, so naturally the right thing for Amazon to do was to overgraze.
I personally see it differently -- Amazon is hiding behind the letter of the licenses and totally distorting a community, exploiting the gifts of the engineers' labor, and getting us to point our fingers at one another over the "one true definition of 'Open Source'" rather than constructively figuring out ways to protect the community of open development and reward the individual workers who volunteer their time.
I also find it befuddling that people here appear to be very opposed to their dependencies monetizing. We should be in favor of our deps being well monetized; we get high quality features, good engineering, fast (and ideally proactive) security, etc. Our eng teams are making multi-million dollar investments into our dependencies and having to port away is extremely costly, both in dollars and opportunity cost.
An essay famously refuted by the work of the first woman to win a Nobel prize in economics. She spent half her life collecting evidence showing that in reality what you describe is more often not what actually happens and outlining the conditions (derived emperically) under which commons resource management works. [1]
I don't think I claimed it was categorically true, it's just a useful essay to read and understand. I don't believe a frog gave a scorpion a ride across the river or that Paul Bunyan chopped trees out West either, but they are useful cultural artifacts to aid in understanding our world.
I'm not sure the tragedy of the commons applies here since there is no scarce resource. How does a big company profiting from open source code hurt the open source project?
The difference between not giving back to open source and over grazing is not contributing to open source doesn't actually hurt other. It's just not helping others.
It's not just that Amazon is not contributing back -- they are not contributing back at scale. They are consuming at scale. They have the scale to distort the established understanding of how a thing works.
Like, we've all seen the "have a penny/need a penny" trays at cash registers, and we all understand that sometimes we take or leave things there. Amazon is basically able to send someone to every single cash register in the city and take all the pennies. Sure, maybe that's not explicitly disallowed, but it definitely breaks the model.
A bit off topic, but is there some consensus about what the best way to license software so that non-commercial use = MIT, commercial use = 'proprietary, please negotiate a license' is?
If I, an open-source hobbyist, am thinking about incorporating some code from your software into my project which I want to allow unrestricted commercial use of (i.e., which I want to put under a standard F/OSS license), even though I am not making any money from it, are you okay with that?
If you're not okay with that, then the open-source-like properties of allowing derivatives / incorporation into other works probably just aren't appealing to you at all, and what you probably want is a simple "Non-commercial use is permitted" statement. But it won't actually be the MIT license, which permits unrestricted use, modification, and redistribution.
If you are okay with me incorporating your code, then how do you define how much of your code I can use? If I build a GUI around your program and I tell AWS that they can freely build a GUI, is that still okay with you? That's going to have to be a case-by-case thing, probably.
Another question is what you expect to do about contributions. If I, an open-source hobbyist, contribute some useful feature to your code, am I entitled to get paid a portion of what commercial users pay you? The simplest answer here might be to not accept contributions.
Some practical options, depending on what you're really trying to do, might be:
- licensing under the AGPL, on the assumption that many companies are scared by it even though it isn't a restriction on use (just a compliance headache for potential external use), and maybe clearly advertising a less restrictive commercial license (which could be MIT, or could be a super long contract/EULA) for money
- licensing a previous version of your code under the MIT license, but keeping the current version as just source-available
- marking commercial features as proprietary and source-available (what GitLab does, and what Elasticsearch used to do)
- capitalizing on the fact that you know the software really well, and selling consulting / support but using a free software license (what Red Hat, Canonical, etc. do)
- capitalizing on the fact that you know the software really well, and running it as SaaS (what Google does with Kubernetes, for instance)
- giving your software a simple "Non-commercial use permitted" statement, but saying that open source developers who are interested in parts of your code are free to contact you and you're willing to relicense limited parts of the code as MIT on request
Finally, what's your goal? Is it to prevent commercial use? Is it to make money from commercial users? Commercial software houses are, sort of by definition, good at writing software in-house - if your software is a really good idea as opposed to a really good implementation of an old idea, chances are that a motivated commercial developer will just make their own version of it.
1) Any entity that does/wants to derive commercial value from the software should compensate the copyright holder. Example entities here are both "I want to sell software that includes/is derived from your software" and "I'm a company/freelancer using your product as part of my business operations".
2) Any other entity can use the software in any way they see fit (like e.g. MIT) except that 1) applies transitively to any derived software.
The situation here is less "This is an open source thing where I take all your contributions and profit off it" but more "This is a commercial for-profit thing that would normally be proprietary closed-source, but everyone can copy/inspect/modify the source as long as they do not profit from it".
Contributions would either be disallowed, or under a CLA if for some reason someone wants to contribute to it (with the clear expectation that someone else is going to profit from it).
Sounds like a proprietary license with source available under some circumstances, similar to what e.g. Microsoft uses for Windows? I don't think it's worth worrying much about what licensing terms you'd apply to modifications or derivatives, because few people are going to put much time and effort into code that depends on your proprietary code.
If you're just sharing binaries then CC-BY-NC-SA (or some other variant of the creative commons licenses). For open source projects there isn't really an agreed upon equivalent. The most popular version is probably "AGPL, or talk to us for a more permissive licence". Most companies would rather pay you than use something under AGPL license terms, but for hobby use AGPL works just fine.
These companies should come up with a practical version of the AGPL or, if they don't find a need, just use it directly.
Cooking up your own license ala Mongo is not going to help you amongst the professional users. Companies that take their legal obligations seriously are not going to use your not-so-open-source offerings on the basis of interpreting your weird anti-amazon clause.
This article takes a purist stance driven by a rigid adherence to ideology. Let's look at this another way...
Open-source and proprietary licenses are at two ends of the software development spectrum. The open-source model maximizes ease-of-adoption but doesn't provide much incentive for the developers. Proprietary software provides a lot of incentive but adoption can be slow and burdensome.
Let's assume that a good goal for society is to maximize the rate of innovation in software. To do that, you need a mix of BOTH ease of adoption and suitable development incentives. Source-available licenses are an attempt to accomplish this.
Is this a perfect solution? Probably not. I think better licensing models are still waiting to be discovered.
However, my sense is that these new licenses will accelerate the development of software with limited downside for the user. After all, they are designed only to impact companies attempting to sell a SaaS.
In addition, they have the potential to weaken the tech monopolies which, in my mind, is a Very Good Thing.
> After all, they are designed only to impact companies attempting to sell a SaaS.
Well, that’s the PR message associated with the new wave of source-available licenses (source-available licensing is not, itself, new; its long been an established form of proprietary licensing.) But it doesn’t hold up: you can’t harm competing services providers without harming end users. There is a reason why the very different ideologies of the Free Software Movement and the Open Source Community nevertheless have stably settled on definitions which are virtually identical in practical applications (and even though those communities have very different preferences for licenses within the scope meeting their similar definitions.) It is because the space is not a continuum, and there is a minimum needed in each of a number of axes of liberty for the whole structure not to collapse into something which either community prefers free/open licensing. Particularly, without robust freedom that protects what other people can do with it (including there ability to sell you services built around the software that the original maker might also want to sell), you are not insulated against future actions of the copyright owner restricting the software or its or others services around it.
And this isn’t opaque to the people issuing these licenses; the overt motive is to enhance monetization by preventing licensees from competing with them to sell services: it is to create a moat enabling monopolization and monopoly rents. That’s the explicit idea: to create lock-in that free/open licenses would not support.
The benefit that the licensors seek directly depends on the harms that extend beyond competitors to end users.
> you can’t harm competing services providers without harming end users.
> the overt motive is to enhance monetization by preventing licensees from competing with them to sell services: it is to create a moat enabling monopolization and monopoly rents.
Here's the problem: Amazon, Microsoft, and Google are already able to charge something approaching monopoly rents because they have built a moat that others can't dream to cross. Heck, try to even build two services that talk to each other between the moats and you will get hit with massive data-egress charges. And they do this by monetizing free products with no compensation to the developer. If you are Redis, your hosted product, whose core you developed, is less competitive than that of the cloud providers who didn't contribute anything to the project. At the same time, the parent tech behemoths are engaged in all sorts of other bad behavior that only massive tech companies can get away with.
This state of affairs seriously threatens the open-source ecosystem and the source-available licenses are targeted to righting this imbalance. Again, are they perfect? No. If you are making money selling the software without modification, is it reasonable to ask for royalties to go to the developers? I think, on balance, that is reasonable.
If not source-available licensing, what is the better solution to the problem?
> Here's the problem: Amazon, Microsoft, and Google are already able to charge something approaching monopoly rents because they have built a moat that others can't dream to cross.
Even if that was true and they acted like a coordinated oligopoly rather than actively competing, including on price, more monopolies in adjacent markets make things worse, not better, for everyone (customers especially) except the additional monopolists.
> If you are Redis, your hosted product, whose core you developed, is less competitive than that of the cloud providers who didn't contribute anything to the project.
Yes, that F/OSS licensing advantages the firms that have the best infrastructure for monetizing services has been widely observed since it was just Free Software because OSI didn't exist yet, before cloud dominance that was mostly about professional services. And, yes, proprietary (and sometimes source-available) licenses which don't deliver the value of open source to end users have always been the “solution” to that.
What's novel recently is a bunch of firms ignoring well-known facts about the economic incentives around F/OSS, trying to build rapid-growth startups around F/OSS with no plan at all to address the strengths necessary to monetize F/OSS, then whining about the well-known advantages of established firms to pivot to proprietary licensing, then having the unmitigated gall to pretend their proprietary licenses provides the customer benefits of F/OSS licensing (which center on the fact that F/OSS doesn't create a vendor monopoly), despite the fact that not providing those benefits is central to the business reason for which they have adopted the proprietary license.
I disagree. I personally would prefer to license the code I write myself with a GPL copyleft or a 'no commercial use' type of license. However, I license it instead under MIT, specifically to make sure that your average corporate user will be ok using it because:
1. I would prefer that it be widely used. Not because I am seeking clout or advancement, but because that's why I share it.
2. Sharing benefits everyone, including me. Fragmentation and bureaucracy harms everyone, including me.
3. I don't support monopolistic practices by large tech, but this is not the way to stop them. What we had before widespread free software was worse than it is now, arguably held back human progress for years, and didn't stop Microsoft one bit.
> After all, they are designed only to impact companies attempting to sell a SaaS.
That might be the intent, but the problem is that integrating any non-free software to a bigger project becomes problematic because the combined project likely becomes non-free. Which is most apparent in that these non-free components will not be appearing on any major distros main repositories.
So the non-free software remains an isolated island rather than melding smoothly into the larger ecosystem. And this has impact well beyond some SaaS providers.
If these licensing models were worthwhile, they would be able to stand on their own merits. I've no objection to someone coming up with a new licensing model and trying to show that it's a good way to make software, good for society and all that. What I object to is freeloading on the success of the open-source model by obscuring the differences between your model and that model. If you're genuinely trying to pursue a new model that you think is worthwhile, own it! Give it a name that doesn't sound like "open source", that could never be mistaken for being the same thing as open source.
I don't think they are trying to hide anything and if anything are being generous because the source-available licenses do have most features of the open-source model with the narrow SaaS restriction.
It doesn’t seem all that purist? It describes the situation, but in the end it says to decide for yourself what you want to do.
There is some mild caution about knowing the differences between these licenses, and mild support for open source projects that aren’t controlled by a single vendor.
An important component that seems many people miss, is that both open source and free software licenses include a business model[1] in the definition: other people are free to sell services for the licensed software.
Some people claim _I can download the software and use it for free, so it is ok that Amazon should not make money out of it and allow ElasticSearch to have a cloud monopoly_.
This sounds like Tesla selling you a car that you are allowed to service yourself, but you cannot have a professional service it for you except for Tesla.
I don't have a strong opinion towards the practice (I'm also working for a company that does closed source after all), but I do believe it is important to show respect to the freedoms that both free software and open source try to protect.
Aren't most open source projects single source in practice? even the big non-profit projects tend to have a single company heavily promoting and developing them behind the scenes e.g. cloudera, databricks etc.
Databricks most popular open source contributions are with Spark, which is owned by Apache, not by Databricks. Looking at Delta Lake, a more recent project still owned by them, it uses a DCO, not a CLA, which means it only has the clauses that relate to a developer stating they have a legal right to license the software as open source (apache 2.0 in this case). Likewise Cloudera mostly works on Apache owned projects.
This is important, because it means that while Apache could relicense to give themselves an unfair advantage, Cloudera or Databricks could not. People trust Apache not to, being an independent non-profit and the act would destroy their reputation, and given the ASF's main product is being seen as vendor neutral and independent (well that or Apache httpd, but the latter is clearly becoming less and less relevant), would be a serious blow to the organisation.
The point of my post is that in practice these companies donated their effort to an apache project rather than building their own as it provided trust that licenses would not become too unfavorable in the future and adoption cheaper adoption path to traditional data centers.
In practice if Cloudera decided to they could fork hadoop to create "cloudoop" or otherwise stop submitting patches upstream and hadoop development would considerably slow. Given the nature of software, slow development is often equivalent to reverse development as dependencies fall out of date and the project becomes abandoned.
I wonder, what keeps a project like postgresql "healthy" and true to its open source/free software roots, and what makes redis/elasticsearch/etc go down this new path of "source available" licenses? From 30000 ft, they are all just data management software.
Is it just that Pg is older? Is the code too complex? Do they simply have more diverse group of contributors?
And, how do we keep Pg and other projects 'healthy'?
> Open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors are less likely to face pressures to relicense. Projects that are the main revenue generator for a ‘single source’ for-profit company have different dynamics.
To "protect" important projects, the more we can find a way to keep them running via a non-profit structure would probably help most of them.
This is why I think the Rust Foundation is an important step for that language, and gives me optimism. It's the right approach: basically, become supported by multiple businesses, effectively not putting all your eggs in one basket. I hope the Rust Foundation succeeds and becomes a paradigm more popular than "try to build a business on my open source project" concept.
Also, perhaps standardization could play a role. If the Redis / Mongo / etc were standardized by a neutral party, it may make it riskier for big techs to make their on proprietary or incompatible modifications.
Though I guess this doesn't apply too much to postgresql, since any serious RDBMS is much more than just SQL standards compliant.
> “the Open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors are less likely to face pressures to relicense”
It’s a good observation, but how many non-profit style open source projects actually exist and how do we create more of those?
The context is about licenses, and the correct answer is
"do not use a license". It is an unethical, evil system, or else there is no such thing as "unethical" and "evil".
Does a carpenter make a family sign a license restricting
how they use their roof? No. Does a plumber get a license
dictating how the toilets may be used? No. Does a janitor
get license royalties after cleaning a room? No.
Here is big tech's dirty secret: the insane profits and
salaries are due to an unjust, unethical, unproductive
system of #ImaginaryProperty, enforced by violence.
In my experience most people on HN do not want to hear that.
They want to pretened that somehow the hours they spend in
the day are really 1,000x more productive than the average
Jim. But that's just not true. Tech gets unequal wages due
to important work but mostly bad laws.
As people wake up to this what you will start to realize is
that the biggest ideas, the ones that change the world, that
win in the hearts and minds of the people in the long run,
have no licenses. Licenses are for losers.
Again, that’s a valid viewpoint but it’s not really relevant to share here. It’s kind of showing up to a congressional discussion on whether the tax rate be 10% or 15% and proclaiming that governments should not exist and that anarchy is the way that we should be moving. I’m not saying that you shouldn’t have a place to discuss your views, but it would be better suited as a response to “ugh I just want everyone to be able to use my software without lawyers being involved” rather than a preexisting discussion of “which license should I choose”.
If someone started a discussion with "which gas car should I choose?" I think it would be very helpful if someone pointed out—hey, did you know there's an option D: electric cars?
Side query but can their be like a Defanger license that everyone other than FAANG companies can use? Just so you know, to make em bleed... Or at least a clause that FAANG has to pay to use the software but it is open-source for everyone else just to level playing grounds?
353 comments
[ 4.1 ms ] story [ 295 ms ] threadProjects aren't able to do this (relicense a whole code base unilaterally) if you don't sign the CLA that assigns them your copyrights in the project.
Never sign a CLA to contribute to an open source project.
They can't hide the fact that it was once MIT/BSD/Apache licensed, and they still have to include copies of that original license (and any notices) even after the switch, as that is one of the conditions that contributors make their work available under, and failure to do so would mean the org is in violation if they haven't otherwise received approval.
The license terms for a sub-license must be consistent with the original license terms, although not necessarily the same. The sub-licensor can use different words as in the original license, but they cannot override the terms and conditions that are required by that license. The sub-licensor cannot sub-license more rights than have been granted by the original license.
Works released under the Apache, BSD, and MIT license can be included in a larger work with a more restrictive license or modifications can be put under such a restrictive license, but the original license must remain intact.
If you are getting your information on re-licensing from the Wikipedia page below, it is wrong.
https://en.wikipedia.org/wiki/Permissive_software_license
I really think this was the FSF's fault - they insisted on copyright assignment for any contributions to GNU, because if the FSF held the entire copyright, they'd be in a better place to pursue legal action against violators. But history has shown that this clearly hasn't been required: Linux doesn't have this policy, and no Linux enforcement case has ever failed because the Linux Foundation wasn't able to demonstrate clear standing. And the FSF basically legitimized everyone else asking for CLAs. Had they stood firm and said that giving up ownership of your code to a central entity is antithetical to the spirit of free software, and the license is all that people can rely on, I think we would have been in a much better place today.
The current problems stem from pretending that Open Source has any more of a relationship with Free Software than it does to proprietary software - an expectation that reifies (and honestly necessitates) things like "the Spirit of Open Source" in the minds of developers. The Spirit of Open Source is that you're working for massive companies who can ignore you.
The only relationship between Open Source and Free Software is the fact that Open Source code can be arbitrarily relicensed and therefore can be relicensed as Free Software as easily as it can be as proprietary software.
The MIT license gives you "Permission ... subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."
You can abide by that condition by distributing your software under the GPL and retaining the MIT license text for portions. You cannot abide by that condition by "relicensing" the software and removing the MIT license: you are in violation of the license.
Whatever you want to call it is fine. I prefer to think that GPL'd software that incorporates Open Source takes a copy and makes it GPL (especially because if I modify the Open Source at all, my changes are not available under an Open Source license.) Other people who are using that piece of Open Source are not using my copy, which is GPL.
I gather you have some meaning of Free Software that is different from what the FSF means by it, and also different from what groups like Debian and Fedora mean by it. Can you expand on what you mean by "Free Software" and what relationship it has with the "Free Software" movement as defined by the FSF, Debian, Fedora, etc.?
Do you think that the FSF, therefore, works within "the Spirit of Open Source", that contributors to glibc are working for the FSF, which can ignore them?
Of course they are. They can be placed into GPL software. They can be placed into any software.
> Do you think that [...] contributors to glibc are working for the FSF, which can ignore them?
Yes.
Elsewhere in this thread you imply that you believe that the GPL is not an Open Source license. Can you clarify that, too? Because, again, it sounds like you're using terms that don't match what the Free Software and Open Source communities mean by those terms. (In particular, GNU would disagree with this claim - https://www.gnu.org/philosophy/free-open-overlap.en.html - as would the OSI, of course.) So you should define them.
Here's a thought experiment: Suppose that Mongo or Cockroach consists of 80% code for which they own the copyright (written by employees). And it's 20% written by contributors who have NOT signed the CLA.
Now can they relicence the whole codebase? No, but I think they can do something with thes same effect by relicensing their parts.
I think it's easier to see if they start a new project. Say Mongo starts a new project called "Dumbo".
Dumbo consists of 80% Mongo code relicensed. And they simply reuse the contributors' code under the existing open source license. So you distribute both licenses with the code.
But now it is still impossible (*) for Amazon or whoever to stand up a cloud service according to the license -- unless they want to rewrite 80% of the code.
I'm not a lawyer but that's my understanding of how it works. Interested in contrary (informed) opinions.
(*) edit: better to say that it's harder, not impossible. They can fork the old code under the old license. It really depends if the they "understand" the code.
Also, they can't "unlicense" previously distributed code - if the system was previously distributed with an open source license, Amazon can use that version as the basis for a "Dumbo-compatible" cloud service without rewriting the 80% of the code as long as they're basing it on the last open release; they would only have to reimplement the new things that "Dumbo" added if they want; Amazon does not have to accept the new license if they don't need the new code and the old code with the old license fits their needs better.
The United States allows authors (and heirs), except work-for-hires, to clawback copyright transfers and terminate licenses after 35 years on works made after 1977. This is an inalienable statutory right, which means it cannot be waived even with a contract.
That said, it may be difficult to terminate licenses in practice because open source licensing is done informally in most cases and courts haven't ruled whether this impacts the right of termination. However, copyright assignment and contributor license agreements are subject to termination.
And IMO it's fair for Amazon to continue the development based off an old version. Forking is an important right in open source. Nobody who releases code as open source should expect that their code isn't forked.
[1] https://www.cnet.com/news/linux-to-gplv3-a-practical-matter-...
There were problems with some OS projects keeping security / auth stuff out of the main project so that it could be used to drive commercial sales.
You can compete on hosting (very hard), support, customization, advanced / narrow features. But it needs to be in alignment with the users / contributors.
This is in direct conflict with zeroth freedom in FSF's "Free software definition". And also at least the reasoning behind all these "anti-cloud-provider licenses" is in conflict with either point 6 or 9 or both of DFSG/OSD (which assumes that the right to use the software in whatever way you see fit is implicit enough such that it does not need to be mentioned more than by what is implied from points 5 and 6).
Another issue is then whether such license terms are actually enforceable and not in conflict with the copyright(-related) law of given jurisdiction. For example Directive 2009/24/EC explicitly stipulates bunch of things that cannot be part of contract (ie. EULA) and if they are these parts are void, end result of this is that if you legally acquire some software the licensor cannot limit what you will use it for, not even by separate contract.
In fact Directive 2009/24/EC gives you as a user exactly the rights that GPL intends to preserve. What it does not do is make excercising these rights possible/efficient/effective, which GPL intends to do (and, well, for typical situation that motivated RMS to start GNU/FSF/GPL the difference is moot, you will end up disassembling the contents of whatever memory the thing runs from because that is the source of truth, not the source code that it was supposedly built from).
The main difference is that the newer licenses reserve certain rights that affect the use of the software. The GPL does not reserve any rights exclusively to anyone.
Incidentally, copyright holders are not themselves bound by their own public licenses, and that's why some entities use the GPL against its spirit to effectively reserve the right to make proprietary derivatives (or to license that exclusive right separately), but that's not at all part of the GPL. That's because the copyright holders no way of binding themselves to the license term (the best option for that is to assign the copyright to another entity that is committed to protecting the universal rights for everyone).
They can sort of bind themselves, by signing a notarised commitment that has the same terms as the copyright licence.
"Fair code" loses the symmetry of licenses, and gives the maintainer an advantage over users. This is especially egregious for services that arguably would not have reached the extent they have now without the comfort and promotion provided by being open source.
As a user, these projects provide more value to me than closed-source solutions for all the obvious reasons. As a developer, I understand why choosing such a licensing scheme may make a project commercially viable when it otherwise may not be.
But these are all immediate practical reasons. The long term result of this is a tremendous legal and technological minefield. One of the strongest arguments of the Free software movement was that it makes software free, not humans.
These "open core, single source" projects are not compatible with that vision, they come with all strings attached. The companies putting out these projects will inevitably go under or get acquired. Again, in the short term, as a user I get to keep that software alive for longer than I would have been able to with a closed solution.
However, at that point there can be no forks, no new development in public. The source code itself becomes toxic. Similarities between fragments of these projects and any newly developed software in that space will provide fuel for law suits. Given the vastly larger surface area and distribution of this IP, mega corporations who acquired the rights will have an easier time strangling entire market segments indefinitely.
On balance, I understand why developers are choosing this. They are tired of providing tools that enable billionaires to exist while they themselves are struggling. But in the long term, there will be more problems on the horizon due to this.
What does "neutral trademark ownership" mean?
On the other hand it somewhat seems that most projects learned from the mozilla shitstorm, at least looking at the amount of "foo"s with open core "foo-ium"s. The point there is that whatever sourcetree that the version with trademarked branding gets built from should be fork of the branding-free opensource project, not the other way around.
I know Google v Oracle is still ongoing but other than that?
Unless there’s a whistleblower in your organization or your product itself is open source it seems impossible to identify, let alone litigate.
Atari of course got stuck in a bad situation then, if they complied with GPL they would breach Nintendo NDA, so their choice was just stop selling the products in question entirely, so I must assume the lost sales were smaller than the potential damage if they were found guilty of copyright infringement.
Westinghouse had to pay the SFC $90k for shipping BusyBox without observing the license.
Most cases that are pursued are settled out of court though.
Redis Labs gets undeserved flack for their licensing changes. Redis remains fully open source under the BSD 3-Clause License. The relicensing only applied to the modules that are part of Redis Labs' paid offerings. So it's the open core model, but even better because the non-core offerings are source-available.
As a user, I can use Elasticsearch just fine with the new license. I can read the code, modify it and use in my own projects.
So it is more difficult for Amazon to use their monopolistic power to build a competing service to the one that is financing Elasticsearch development? Yeah, good stuff.
If the big tech monopolists need something under a permissive license they should pay for its development.
Users aren't affected by any of the relicenses.
That kind of difference is pretty common in non-source-related things, e.g. you can use the API for your business, but you can't resell access to the API.
That's how you draw the line.
2) let’s give some love to BSD, since GPL is hostile to my intention of selling modified software
AGPLv3 is open source and isn't exactly favorable to tech monopolists, either.
Companies with more are conservative on their risk.
Not a lawyer and this is not legal advice
No. It doesn't "infect" the load balancer. There's zero ambiguity about this.
A lot of companies have bad lawyers who try to eliminate rather than mitigate risk and who try to grab every scrap of IP for the company. This is the kind of company you're talking about.
This is also why many try to get you to sign away every profitable idea you've ever dreamed up in the shower: a combination of extreme risk aversion and flagrant greed.
I'd even venture as far as to say it's a feature not a bug if this type of company were forced to use expensive proprietary software or older, shittier versions.
This is not true.
> A lot of companies have bad lawyers who try to eliminate rather than mitigate risk and who try to grab every scrap of IP for the company. This is the kind of company you're talking about.
I'm guessing you would claim all of the giants as obviously falling into this category (they all have bad lawyers).
They are all also the only ones worth suing.
Note that it's not just FAAMNG, Square made this determination too: https://hub.packtpub.com/square-updated-its-terms-of-service...
I'd love to hear what Stripe thinks about using AGPL-licensed software.
Basically I've yet to hear of a large (> $1B revenue +) SaaS company that doesn't have concerns about using AGPL software as a core part of its service offering. I'd love to hear some counterexamples...
Please stop spreading misinformation.
>I'm guessing you would claim all of the giants as obviously falling into this category
Google definitely counts as a company that tries to grab every scrap of IP for itself. They also heavily customize everything and compete in all software markets. For them this is ideological because it interferes with their profits as a monopoly. They want the license dead and buried because it targets them.
This is a feature, not a bug.
Small Podunk companies that shy away from installing mongo, OTOH are being legitimately dumb.
GPL was the fight against device manufacturers using linux et al and not giving back/selling closed source linux devices.
We completely lost with tainted kernel and such, as they corrupted the only software that they couldn't live without and was promoting an open source license. Case in point: you cannot build 1% of your android phone software, proving GPL code (android, linux kernel) is as useless for open software as MIT (ios, darwin)
Now the fight moved from OEM manufacturers vs GPL to cloud providers vs AGPLv3. And source-available licenses are the tainted-kernel compromise all over again: get the thing you cannot live without but is fighting you with a pro-opensource license, and offer a carrot so they change, and they all changed.
Without the change the article talks about, cloud providers would have people using the AGPLv3 code in their derivative work of projectX. while they paid the closed source version from the company dual licensing it. With this new arrangement, they can use all derivative work at will with zero consequence, for the same low price.
Just like tainted kernel was a hard blow in the face of everyone who contributed to linux (heh, specially the GNU folks porting their stuff) with open source in mind. This is nothing but a greedy bait and switch on the community.
This combination is pretty antithetical to the 'spirit' of open source (and especially 'libre software', which AGPL is supposed to be) since it basically ensures hegemony on any commercialization ecosystem to the original developer, unless one manages to create a 'leading fork' where contributions land, since only the original rights owner (who also gets the rights to the sum of all other contributions) has the legal means to commercialize (i.e: provide commercial hosting around) any extensions above and beyond what the community develops.
The spirit of open source was never about giving away the software for free.
https://www.gnu.org/philosophy/selling.en.html
The community was concerned with free speech. You want free beer (freedom of commercialization).
AGPL also says that you have to make your changes available. It doesn't say you have to sign a CLA. If you value your "IP", don't. If you value having your changes pushed upstream, do. It's completely up to you.
You are right though, that 'libre' software is not about economic freedom but keeping the software 'free'. One of the reasons I'm in the BSD/MIT camp - software doesn't exist in a vacuum.
edit: thanks to pydry for pointing out that this interpretation isn't correct. It is more correct to say that if a user interacts with AGPL software over the network, they have a right to its source.
https://medium.com/swlh/understanding-the-agpl-the-most-misu...
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
I'm not a lawyer, but that's my interpretation of this section.
Reading it again, it was wrong of me to say that network communications count as linking, though. It's more correct to say that if a user interacts with AGPL software via network communication, then its source must be made available to them.
[1] https://www.gnu.org/licenses/agpl-3.0.en.html
That's the policy. No exceptions. Don't touch any of it on a corp-issued device.
If it's open for you but not for him what's your problem?
A clear winner means more companies use it, increasing demand for it. Which makes it more valuable to master.
If the commodity software is open source, I can learn it at home for a low cost. Then use it at work, again for a low cost. Employers have an interest in using it, as do I.
So I want to encourage Amazon, and other tech companies, to use as much open source as possible! Please increase demand for my skillset!
Of course, the eternal problem is how the software gets developed in the first place. But I really don't want software that bifurcates organizations vs. individuals to become a cultural norm. Even if the impact of any single case is minimal.
Now we have to deal with examining and getting approval for umpteen oddball custom software licenses instead of just the standard FOSS ones and, yeah, that is a problem. The pain of dealing with licenses was part of what drove adoption of FOSS in the first place.
The original spirit of open source was scratching an itch and sharing your code in hopes others found it useful. The current squabbles are about large for-profit corporations trying to extract money from other large for-profit corporations, so let's call these new licenses what they are: proprietary licenses with source availability.
Your legal department's inability to keep up to date is not the fault of the open source community.
Corporate legal departments were exactly as useless, intransigent and belligerent when open source was first introduced.
Their tendency towards evil or laziness is not an excuse for anything.
>yeah, that is a problem
With your legal department. THEY need to change. JUST as they were dragged kicking and screaming into the age of open source.
>The original spirit of open source was scratching an itch and sharing your code
No it wasn't. It was about freedom of speech and freedom to do with as you will with what you have on your computer.
It's amazing the number of people I've come across today that misunderstood both the legality and the spirit of open source in a way that Google or Amazon would strongly approve of.
Not everyone has a legal department.
If I'm an independent contractor who wants to sell my ElasticSearch expertise as a service, namely by charging to setup and maintain ES instances on behalf of others, am I compliant with ElasticSearch's newfangled non-free license? Or am I "Amazon" in this context? Judging by how Elastic themselves describe their license[1], it looks a heck of a lot like I'm "Amazon" as far as they're concerned, since my labor would take the form of a "managed service" - never mind that my annual income is several orders of magnitude less than Amazon's, and probably would continue to be such even assuming my services sell like hotcakes.
----
[1]: https://www.elastic.co/pricing/faq/licensing
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
> The license must not discriminate against any person or group of persons.
Was the DFSG misguided when it was written, or has something changed since then such that it's a good idea to restrict certain people from making use of the program?
How do I know it'll stay open for me? How am I supposed to make that determination on whether or not it even is open for me in the first place?
With a standard OSI or FSF approved license, I don't have to be a lawyer to have at least some idea of what the license entails, because their lawyers - and plenty of others - have already combed through them and put together layman-accessible descriptions of their stipulations - and further, by the very nature of their approval as "open source" or "free software" licenses, I know with reasonable certainty that even something as restrictive as the AGPLv3 will always permit me to use, modify, and redistribute that software, no matter what.
Contrast with these bespoke "source available" licenses, which are specific to certain products/companies and can change at any time. One might call it "FUD" to be skeptical of 'em, but they certainly seem to leave a lot of room for fear, uncertainty, and doubt given the legal pitfalls around, say, maintaining an independent fork.
Still, at least the software itself is transparent (i.e. it can be independently audited at any time, by anyone with the requisite knowledge, for any reason), so for most cases I would certainly pick such software over anything opaque / closed source any day. The lack of contingencies should the developers inevitably go out of business (whether from buyout or bankruptcy) still pushes me to prefer, you know, actual free and open source software.
Transparency is a dependency of trust, but it ain't the only one.
Technically any license can be changed if the company holds the copyright. This is why Microsoft makes you sign a CLA. This signals a plan to potentially de-open source in the future and capitalize upon their IP.
Source available licenses are about what you can do NOW and it's usually very very clear. For example, don't set up an elastic search SAAS. Of course, you're not Amazon so you won't.
>With a standard OSI or FSF approved license, I don't have to be a lawyer
Apparently you could do with a bit of training because the thing you were most worried about is enabled by a CLA not a source available license.
You are perfectly correct to be suspicious of Microsoft's CLA when combined with their "we turned over a new leaf with OSS" marketing. I am.
>One might call it "FUD"
Not gonna lie: thats the exactly what I was thinking when I read your comment.
If a codebase uses a well-defined license - like, say, the GNU GPL or Mozilla MPL or Apache license - then unless the company is the FSF, Mozilla, or Apache (respectively), then I know with reasonable certainty that as long as they're using that license with that name, the terms won't be changing under my eyes.
The same can't be said of some product-specific "ElasticSearch License" or "CockroachDB License" or "MongoDB License" or what have you. With these, I'm back to having to read EULAs one by one, because the meaning of "$PRODUCT License" can change at pretty much any time.
That is, if you're going to jump immediately to some bald-faced snarky ad hominem like
> Apparently you could do with a bit of training
it would be a lot more effective if you actually understood and acknowledged what I'm talking about instead of going off on some tangent about Microsoft and CLAs.
The policy exists to enable collaboration and contribution, not to restrict it. These types of policies are common at companies like Amazon. Google has posted theirs publicly [1], and Amazon policies are similar. I have used the policy to contribute to more than one "upstream" open source software package, for example the Xen hypervisor [2].
Though I wish I had more recent commits, this should demonstrate that even in 2012 patches were flowing to Xen. More work on Xen by others can be found by searching for "amazon.co" in the commits [3].
[1] https://opensource.google/docs/
[2] http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=...
[3] http://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=HEAD&st=...
Letting the status quo continue would just ensure that Amazon gets even richer off the hard work done by Elastic while development dries up. We all lose while they suck profit out of this product.
It's not like they require elastic to survive. They're too big to fail. By being a dominant cloud provider they have a massive inbuilt advantage
Yes they are different to other cloud providers. They're big enough to throw their weight around and they do.
In my opinion, Elastic is being just as selfish and exploitative as Amazon is, which is just as much as any other private for-profit company is.
What I don't like is Elastic putting out PR and pretending as if they are some sort of divine for-profit corporation that doesn't do things out of their own self-interest, but is somehow only interested in open software.
In other words, Elastic is clearly not the same thing as the Apache Foundation, but they seem to want everyone to think that they are.
There is obviously a difference between a monopolistic corporations like Amazon that is actively crushing any competition with its control of the market and a bigger tech company like Elastic that is mostly driven by technological innovation (for now).
Does not mean that one is more morally evil than the other. In fact monopolistic corporations can offer their workers much better working conditions because of the extra profits they make from abusing their position. Well Amazon is not exactly known for that but in general they do. I guess Developer are treated pretty well at least.
So again, the point is not a moral failure but the economic position and the system that creates such a situation. While the creation of big monopolies is more or less inevitable it is still a good idea to be critical of the social and economic dangers.
I'm trying to think of a good analogy. Does anyone have a good one?
How about, the software is analogous to a floor plan. I come up with a great floor plan, and allow anyone to use it for their buildings. But I add a restriction that no one is allowed to sell buildings using this floor plan except me.
So now, if I want to make money with my skills and labor, I'm at the mercy of your architectural firm, which means I'm fundamentally at a disadvantage when it comes to negotiating fair compensation for my labor.
This illustrates just one kind of user. And only in some situations. For example, lets say Elastic.co goes under. Under the license another company couldn't setup a replacement. So, the end user is screwed just as if a proprietary vendor had gone under.
What the companies behind the new licenses are attempting to do is have their cake and eat it, too. They want open source for all the cred and for one type of user. The want proprietary for the complete control of the stack right through some types of hosting situations.
It's hard to produce something completely open and yet monetize it in way that meets VC grown desires. That's why so many companies open source the common stuff but keep the special sauce proprietary.
I'm confused here -- the new 'open core' is available under the SSPL, which clearly allows this, as long as you provide the source code of any management layers as well. The non-open parts already weren't available under the Apache license, so nothing has really changed there.
And, yes, this does mean Elastic is the only company able to build proprietary components on top of the code base, which means there isn't an even playing field with competitors. But once Elastic goes bankrupt this is no longer an issue.
> I'm confused here -- the new 'open core' is available under the SSPL, which clearly allows this, as long as you provide the source code of any management layers as well. The non-open parts already weren't available under the Apache license, so nothing has really changed there.
This is essentially a legal "gotcha", given that "management layers" is not defined anywhere. The purpose of the clause is not to encourage companies to "open source everything" (what does that even mean? Do they need to open source their IPMI firmware?), it's to prevent anyone from going anywhere near it.
Do elastic.co open source all the management layers in their stack?
Right. To make matters worse: it doesn't just require that all of the software used to run the service is open source, it requires that it be released under the SSPL. This immediately rules out using anything which you do not have the legal authority to relicense. So, for example, Linux.
Quoting the SSPL (emphasis mine):
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
...
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
No, open source means the same thing it's always meant since the term was first coined. See the Open Source Initiative's Open Source Definition: https://opensource.org/osd.
Now someone will respond "why does OSI get to decide the meaning of the term?" Well, they don't have any _legal_ right to do so, but if you don't accept their definition, does that mean every person gets to come up with their own definition? And if they do, what's the point of using the term?
So it makes sense to take OSI's definition as canonical, the same way the Free Software Foundation's definition of Free Software is generally considered canonical (https://www.gnu.org/philosophy/free-sw.html).
Also, to forestall another common reply, I'm not defending Amazon or attacking Elastic. I'm simply trying to define a term that's at the center of this discussion. If we can't agree on the definition, then any discussion of whether a license is open source is moot. The same goes for discussing the impact and value of open source vs non-open licenses.
Honestly, I think we should just say OSI-licensed if we mean OSI-licensed. Words are only as good as they can be used to communicate with others. If people misunderstand me, it's my fault.
Of course, 'OSI-license' is more accurate still, as they don't have a monopoly on 'libre' either. Many would say the WTFPL is accurately described as libre, even if OSI doesn't.
See the Wikipedia entry: https://en.wikipedia.org/wiki/Open_source
http://www.catb.org/~esr/open-source.html
I think this has been shown to be a bit of a myth.
They claim to have coined it in 1998 but there's evidence of it in use in context without even needing to explain the idea by other people as far back as 1993.
https://groups.google.com/forum/#!msg/comp.os.ms-windows.pro...
Also, the fact is the USPTO wouldn't allow them to trademark it because it has a simple existing descriptive term.
https://www.google.com/books/edition/Human_intelligence/VE9s...
Obviously there is free (no cost) software as well, at least in English where we have one word for both meanings. This can be easily disambiguated in a discussion by the "free as in speech, not free as in beer" phrase, or if people are familiar with the term, using "libre software" to clarify.
Unfamiliar terms should fail fast in peoples' minds, not be silently mistaken for familiar terms.
"Freedom" noun to me is almost interchangeable with "overtly American" noun.
While not the technical definition by proper english the connotations count.
Problem: The OSI did not coin the term 'open source'. OSI partisans claim that Christine Peterson coined the term at a strategy meeting in Palo Alto on 3 February 1998. However, the term and the concept was well known prior to that. Martin Tournoij does a decent enough job of collecting prior citations [1] that go all the way back to 1990. All the OSI did was take an existing philosophy, scribble some new restrictions in crayon, and called it Open Source(tm)(c)(pat. pending).
Honestly, though, I do love it when this comes up. It gives me the opportunity to irk new guys telling them that Lyle Ball, head of public relations at Caldera, has an earlier citation than the OSI in the form of a press-release announcing Caldera OpenDOS[2][3]. :D
[1] https://www.arp242.net/open-source.html
[2] http://www.xent.com/FoRK-archive/fall96/0269.html
[3] http://ftp.uni-bayreuth.de/pc/caldera/OpenDOS.701/license.tx...
Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
I want people to use the OSI definition in order to elevate debates. I'd prefer to skip past definitions to more substantial matters, like whether "open source" (per OSI) is useful. Is it somehow better than closed source code? Is it _ethically_ valuable? Is there some subset of the OSI definition that provides more value than the rest? These are interesting discussions worth having.
Endless debating the meaning of "open source" is a huge waste of time.
Given that OSI is the only body I know of with a clear definition, let's use theirs and move on to more substantial topics.
[0] https://opensource.org/sponsors
Either way, this is relevant: https://www.apache.org/apache-name/
The FSF has gone to great lengths to give a legally clear definition of free software. Something like the SSPL is not free software because it restricts Amazon's freedom to use the software. Stallman has always had an ideological goal when it came to Free software.
No, you can also use the common definition of "open source" = "not closed-source" = "not (source unavailable)". Nobody has branded this definition but that doesn't make it any less legitimate. See definition #1 on dictionary.com for "closed-source", or #2 for "open-source". [1] [2]
> I want people to use the OSI definition in order to elevate debates.
This is... obviously biased? Other people prefer to use other definitions to elevate debates. You can't claim only the definition you like is able to elevate debates.
And the parent is putting so much effort into arguing about the definition for the same reason you did in your comment. If it was so inconsequential, nobody would care. But evidently people find it a powerful thing, hence they argue about it. You can't simultaneously do that and then claim it's irrelevant.
[1] https://www.dictionary.com/browse/closed-source
[2] https://www.dictionary.com/browse/open-source
I've seen people use "source available" (?) in these situations, but I don't think it really makes sense because a lot of the time the only thing holding it back from being OSI "Open Source" is that their license has not been recognized by OSI.
[1] https://creativecommons.org/faq/#can-i-apply-a-creative-comm...
[2] https://opensource.org/licenses/0BSD
> Also, the CC0 Public Domain Dedication is GPL-compatible and acceptable for software. For details, see the relevant CC0 FAQ entry.
https://copyfree.org
https://copyfree.org/standard
(I also consider anything that fits the Open Source Definition to be "open source" and differentiate things actually approved by the OSI as "OSI certified", which should in principle be a subset of "open source".)
This is not true. Recent licenses trying to protect the business built on the open source code are in general, open for use:
- Sentry: https://news.ycombinator.com/item?id=21466967
- Elastic: https://news.ycombinator.com/item?id=25833781
I see these sorts of licenses becoming increasingly common in the future, which is why I think it's silly to continue excluding them from being called open source.
I do agree that licenses like this will become more common in the future, and that's why I think it's useful to have an identifying term for them rather than making "open-source" less precise to include them. Different words for different things is good, in my opinion.
I would argue that they prohibit far less use cases than they are open for.
In any case, how would you describe these licenses? I don't feel like "source available" is an accurate descriptor in this case.
> My personal term for this sort of "We're OK with little people using the software but we don't want any competition"
Large companies are free to use Sentry. There are Fortune 50 companies running Sentry at scale internally without paying us a cent. That's totally cool.
You're also free to compete with Sentry. You're not free to repackage Sentry for the purposes of competing with us. There are lots of competing error and performance monitoring products out there that do perfectly fine without it.
I should also note that many components of Sentry are distributed with OSI-approved licenses that you are free to use to compete with us. For example, our Symbolication service (https://github.com/getsentry/symbolicator) ships with an MIT license, and it's an important part of our business.
That seems like an obvious growth opportunity when investors need to see numbers go up
Aside, there seems to be confusion about what “relicensing” means. Even in this hypothetical scenario you’ve outlined, we can’t “relicense” already released software. Many users hosting Sentry internally are using years-old versions happily; they would continue to be able to do so. They could also choose to fork the last permissible version and maintain it themselves.
Personally, I think this scenario (relicensing such that self-hosted users could no longer do so) is incredibly unlikely. I don’t believe it would really do anything to grow the company.
Sure the SaaS server licenses are more or less open use with caveat, but why won't a process paralleling tivoization occur?
I wouldn't find it odd for a hardware vendor to release source code, "for review" without the rights to use it on any other hardware as some do for binaries.
In a way that could be worse than closed source as that is similar to the problem of suspicion of reading leaked source code, maybe you are tainted and can't actually write software licensable for competing hardware. Maybe you never read the code yet it will appear that way, but you shouldn't check.
Given the oddities of IP and copyright infringement, it is often the case that only the owner benefits from a process of publishing. I.e. what good is the disclosure of a modern patent?
It’s kind of like that thing where software vendors give cheap or free licenses to educational users in order to get them hooked and then charge whatever company they might work for an arm and a leg to keep using it.
And yet people are fighting tooth and nail to redefine open source to mean OSI approved licence instead of using OSI approved license to mean OSI approved license.
>To see why just change the thread title: What’s up with these new non-OSI approved licenses?
It's an article that you can have a reasonable debate about without stacking the deck against the people you're arguing against. Which is why the people who make money by stacking the deck are so dead set to redefine the word to mean exactly what makes them the most money.
The people trying to redefine anything are those ignorant of the history here.
Free software was coined in the 80s. I wasn't there for that.
Open source was coined in the 90s because we didn't want people to think that software which let you see the code was free of charge.
Then when they sold out a bunch of tech bros from SV decided that they knew best and redefined open source to mean whatever made their valuations go to the moon. The plan did work as expected because dot com crash.
The people around the OSI have always been share croppers that have been trying to get paid for other peoples work.
Also, while I'm sure it's unintentional, your backwards of "sharecropper" smells racist.(It actually means paying someone for the right to do you your own work, and was an attempted to recreate slavery after slavery was banned in USA).
Was it redefined? My impression is that it has always effectively been a synonym for free software, just not carrying the political leanings.
If OSI wanted to provide the official definition for what is "open source" and what is not, they could have perhaps trade-marked their term "Open Source".
But "OSI approved license" has its own vagueness about it. What does it mean that OSI "approves" a license? Approves it for what? To be called "Open Source"? But then unless they have the trademark for the term Open Source, they shouldn't be the one to give approvals for people to call their software that.
This reminds me of the debates about whether something is true Agile, or merely wannabe-Agile. Words are just words. It is good to have precise definitions but those can be specific to a given context. It is a bit like let x = y + z. Is that the correct definition of x? No, but it is a VALID definition of it, assuming y and z are well-defined as well.
A fundamental aspect of open source is that there is no limit to the number of businesses that can be built on it. If a single company wants a monopoly on building a business on the software, we have a term for that: proprietary software.
And this is the fundamental issue, can they build a strong company based on this software, it's potentially possible but that seem to think they can't be competitive hence the license moves.
It is legal, it was a good business move by amazon but it definitively sucked for those who had invested in building that software.
So yeah, in a way I can understand that now anyone risking their business in creating software or services based on those might be going, "yeah no thanks, you can't fork our work and sell it".
Specially when companies are gigantic and a 0.01% of their budget equates to the whole budget of the company who produced the original source. You can't really "not struggle" in the face of the competition.
I have to dig more into GPL licensing but anyway, there certainly needs to be some licenses that are not "f$#%% me any way you want" for people doing open source products.
Run the software under AGPL and dual license it under a closed or restricted usage license if a customer doesn't want to use the AGPL license.
Instead we have people electing to create restrictive licenses with varying degrees of "use the software however you like unless we don't like you or your business" baked into them.
The dual full free + restrictive license model has worked very well in the past for FOSS based companies. Let people who are fine contributing back to your project and/or open their project up use it however they please and let everyone who doesn't like those terms pay for it like standard commercial software instead.
If your business is just an extension of the underlying software (the source) and you don't want to open source your part of the work, then pay a commercial license.
If your business uses the software (the source) just as an ancillary part most probably you're ok to source back any improvements back and keep them open source (no need to pay). If it's ancillary and you need to keep them closed, then pay for licensing anyway.
The only thing I don't understand but seen many time mentioned is the "infecting" nature of the GPL licensing?
The reason for this is to prevent people from creating wrappers that allow them to profit off the licensed software without contributing back or open sourcing. The key thing to note is that you don't have to upstream changes. You only have to provide the source to users (and the license protections extend to them). This means you can still sell GPL and AGPL software but you do have to provide full usage permissions to the user once they've bought the product.
As a side note: I've always found it amusing that government contractors have traditionally been very afraid of (A)GPL despite being required to provide (A)GPL-esque usage permissions to the customer/government. Most of this I imagine is due to a fundamental misunderstanding that providing source to the user doesn't mean publicly make source available for everyone.
Now if you have an AGPL or GPL licensed dependency and you want to dual(+commercial) license your project, you have to work out a commercial license agreement with the dependency's maintainer. If a project has (A)GPL dependencies and doesn't have a commercial license but you'd like to use one, you'd have to work out commercial licenses with the project and all the dependencies (or have the project maintainer work said license out).
This infection effectively enforces users to either share their software or "pay" for all of it which is arguably a good thing for the health of the ecosystem as a whole. If (A)GPL+commercial licensure was standard practice, we likely wouldn't be seeing the [OpenSSL/xkcd-2347](https://xkcd.com/2347/) issue keep popping up time and again.
TLDR: The "infection" forces users/developers to either respect the "free" terms or pay for the full value of the software.
I've literally no sympathy for ES whatsoever, they were either incompetent or playing games.
What ES invested and the size of AWS has literally nothing to do with the discussion, ES made a choice pure and simple. They are within their rights to make a new choice if they so choose.
Ethics don't come into play here and I also don't have any specific sympathy for ES, but I have sympathy for people and companies that provide open source software that others can read and tinker with.
I can like AWS because of providing me services I find useful. That doesn't mean that I have to like everything about them.
> What ES invested and the size of AWS has literally nothing to do with the discussion
Well, it does and doesn't. In a way it would be great to have open-source software be the default, but given that anybody with resources can simply take it and build a then non-open-source version of it and polish it or integrate into much higher leverage existing systems, it does pose some questions as towards what licensing open-source software should have in the first place and if it should be infecting or simply have multiple different clauses related to how it's being used.
But yeah, when playing a game make sure you know the rules and all.
Just because the source is available to you doesn't mean it's open source though. There are many companies that have the source code to Windows, but I would never describe Windows as being open source. That where the pedanticism comes in.
> Other people prefer to use other definitions to elevate debates.
No, they'd prefer other definitions to obfuscate differences, specifically, when trying to define “open source” as equivalent to “sourve available” to erase the distinction that having separate terms with distinct definitions provides.
The point is to demonstrate that the term predates the OSI's alleged coinage thereof. They don't get to dictate language. This usage pre-exists them and obviously persists to this day.
> Using the term "open source" without any definition is useless. If we can't agree on a definition, it's impossible to know if we're actually talking about the same thing.
Really? It seemed quite useful to the people cited in each of those earlier prior references. They seemed to know exactly what they were talking about in context. You have only to read the messages to see that.
> I want people to use the OSI definition in order to elevate debates.
No, I think you want people to use the OSI definition because that conveniently includes certain clauses that have nothing to do with being open source, much like the FSF's definition of free software has nothing to do with freedom.
> Endless debating the meaning of "open source" is a huge waste of time.
You're right. Equally useless is attempting to privilege the OSI's definition over others.
> Given that OSI is the only body I know of with a clear definition, let's use theirs and move on to more substantial topics.
The numerous citations you are now aware of make you aware of others with a clear definition, so... No.
The OSI definition was elevated over others (to the extent that there even are any others) by usage. You can dislike that all you want, but it doesn't change anything. Maybe, in time, usage will flip the meaning to something else... English has a way of doing that. But let's not stick our heads in the sand and pretend that current reality is anything other than what it is.
[1] https://www.arp242.net/open-source.html
The way most people have been using “open source” is a lot closer to OSI than these companies are claiming. It’s misleading to use a different definition nowadays. And I think that’s the actual intent. If it wasn’t, then they’d be perfectly fine with using another unambiguous term like “source available.” If there was a strong desire to be clear and not misleading, they’d use such a term.
Except.. it kinda is. I mean yes, it is obviously true that words can (and do) have multiple meanings. But within a given context, there are "generally accepted" definitions and there are idiosyncratic / obscure / unusual definitions. And in the kind of context we're talking about here, to use "Open Source' to mean anything other than what is defined by the OSD is to intentionally choose a non-standard, idiosyncratic definition. It wouldn't be reasonable for one to do that and then expect everybody else to understand / agree with their non-standard usage.
Taken literally these words could mean something else, but they don't. And using them in a wrong, hoping that people will confuse them for something they like (free speech for phones is good, right?) is extremely dishonest.
Get with the program, dude. It's 2021, and the prevailing sentiment is that all definitions are now fluid. #GoForWoke #GoWokeOrGoHome
If this is the only definition you're aware of, then apologies, but you're not the right person to be attempting to drive this discussion.
If you're aware of the many others but do not consider them 'clear', then there is something else going on here, and I am starting to wander about agenda.
If I say "source is available and you can make modifications, but only if you have red hair and live in Brazil", is this open source?
It's not as specific as the OSI definition of course, and it doesn't say anything about redistribution and such, but that's okay and it doesn't really need to be IMO. Some vagueness is okay, and even with the OSI definition there is a huge difference between something like MIT and AGPL, both of whom are "open source".
People talk about permissive and copyleft licenses when the distinction matters. Covering both doesn't make open source vague.
Alternative definitions restrict the freedom to run the software at all frequently. Never mind modifying it.
The only thing you are saying is that other people tried to use "open source" for something else and completely and utterly failed to convince people. Thus, today "open source" means what it means.
Which is why you should call them "OSI Licenses" if you are referring to OSI licenses.
> let's use theirs and move on to more substantial topics.
This just isn't how English works. It isn't prescriptive. English is descriptive by nature and permits multiple uses, which have been around before OSI ever existed and are still valid.
1. They aren't written by or copyright or anything to the OSI. They aren't "OSI Licenses" they are "OSI-approved licenses"
2. The Open Source Definition as clearly defined by OSI (and accepted as the only consensus definition in the world) does not include OSI-approved as a factor. So, a license can be Open Source without the OSI having done the active approval to validate that they see it as Open Source.
The only thing you are saying is that "open source" sounds nicer and you want it for your term instead. Too late.
Here’s the Cambridge Dictionary’s definition of open source: “Open-source software is free to use, and the original program can be changed by anyone.”
Merriam-Webster’s definition: “of software : having the source code freely available for possible modification and redistribution”
We can certainly be more specific as to OSI Open Source rather than just Open Source? Wouldn't that solve the problem? We dont have to define every single term to have no ambiguity, but we can certainly have specific term for specific purposes.
If you were talking about "opening your source code," or developing new versions of your product with "open source code," no one would be confused, or if they were confused, they'd ask a follow up. The claim isn't that "open" and "source" were not words with meanings, the claim is that "open source" didn't describe anything specific until OSI made it. This argument is like complaining that people had windows in their houses before MS Windows.
Yes, and that claim is wrong. Each of Usenet posts cited in Martin Tournoij's blog make reference to open source (code) in one manner or another... like this one, for example: https://groups.google.com/d/msg/comp.os.linux/06y4cr6wr7o/fZ...
Quoting from the above:
> The GPL and the open source code have made Linux the success that it is.
That post is from 27 February 1993.
I don't think you can seriously continue claiming it didn't mean anything specific.
I make no claim, here, as to the ultimate disposition of the argument, I just don't like points being missed.
This still doesn't mean that OSI didn't coin the meaning of open source: a watered-down synonym for free software that de-emphasised its political philosophy.
The fact remains, even openly acknowledged in Martin Tournojj's article when he looks at the growing usage of the term, that the reason we're all saying Open Source is because Tim O'Reilly bankrolled OSI's marketing campaign[1], and it was so effective, that they convinced us the term was so natural that it was our own idea. It wasn't. It was OSI's.
Now, I get the urge to say "OSI doesn't get to decide!" because you don't want to be told what to say or what to believe. You want the word to have a different meaning. You're a free agent, dammit, nobody gets to tell you how to talk. Well, you're not as free as you think you are, because you wouldn't be talking this way if it weren't for a whole society that was influenced by the power of the wealth of one individual in the late 1990s. Your fashion choices are not are individual as you think they are[2], and neither is your language, nor even your beliefs.
[1] https://thebaffler.com/salvos/the-meme-hustler
[2] https://www.youtube.com/watch?v=Ja2fgquYTCg
I am starting to believe that the greatest mistake of the FSF and OSI is exactly that. They did not trademark the terms. And this resulted in endless debates about free as in beer vs free as in speech (vs free as in puppies :P ) and on the meaning of open and on shared source vs open source.
Stallman likes to call the GPL and copyleft a "hack" on top of copyright or a "hack" of copyright. Unfortunately Stallman was never opposed to IP as a whole. He is only opposed to software (only) pattents. If he were opposed to all IP he might have had the idea to "hack" the trademark system and use it to prevent all of this confusion using the threat of lawsuits. After all FLOSS is full of benevolent dictators.
Now we are stuck with "free", "open" and "libre" freely being redefined to suit the PR needs of anyone.
They don't. "Open source" is, foremost, a word and not a definition. Just as in any language, the people get to decide how language is used.
If you want to be specific about the meaning of open source, just say "OSI open source" or something.
> If you want to be specific about the meaning of open source, just say "OSI open source" or something.
is wrong. "OSI open source" and "open source" are synonyms.
Exactly. In common, everyday usage, when people talk about "Open Source" this is what the majority mean. It's not a "de jure" definition, but it is a "de facto" definition. Open Source means compliance with the OSD. There are terms for those other licenses - "shared source", "source available", etc. Use them if that's what you mean.
I am the people. I do not agree. Now what?
Worst case? You walk through use life using terms in non-standard, idiosyncratic ways, and people are constantly confused by your speech, or argue with you because you don't have a shared understanding of the world.
You can't just hand wave that ambiguity away and pretend that only the OSI definition is understood and used. You have to accept the "open source" is an ambiguous term and you will need to use qualifiers or additional context if you want to avoid ambiguity when using that term.
Yet people really only know of Open Source as a common term to describe these projects.
Simply because the source is openly available to read, the licence can still say "you can read but no touchy touchy or compiling it".
While technically it doesn't stop you from actually doing this, in a court of law you'd be found to have violated the licence. So it wrecks the idea of businesses doing it, because usually the licence holder won't care unless someone is making money from it.
Free software lets you do whatever you want, but you gotta show your code. Big difference in practice, especially when it comes to running a business.
The OSI is really just a way of branding certain licenses so IT departments at companies can point their legal departments at the website and say, "Look, this is legit." We forget today that in the 1990's people would assume that software they didn't pay for was shoddy, or that if they were running it, it was stolen and they were going to be audited and sued.
I think Amazon running their own ElasticSearch service and competing with Elastic is entirely faithful to the original spirit of free software, where Stallman was backporting innovations from commercial Lisp Machines onto the MIT free Lisp Machine OS that anyone could use.
There is the model right now of founding a company to host your software or similar as a funding model. While it is popular, I doubt it is any more sustainable than any of the other models we've seen. My lesson from all of this is that capitalism lacks funding mechanisms for producing commons, and that the proper solution is to produce non-capitalist avenues for doing so.
“Open”
Please avoid using the term “open” or “open source” as a substitute for “free software.” Those terms refer to a different set of views[1] based on different values. The free software movement campaigns for your freedom in your computing, as a matter of justice. The open source non-movement does not campaign for anything in this way.
When referring to the open source views, it's correct to use that name, but please do not use that term when talking about us, our software, or our views—that leads people to suppose our views are similar to theirs.
Instead of open source, we say, free software or free (libre) software.
https://www.gnu.org/philosophy/words-to-avoid.html#Open
[1] "Why Open Source misses the point of Free Software"
https://www.gnu.org/philosophy/open-source-misses-the-point....
The companies who have restrictions on how their Open Source software can be used can technically be Open Source (depending on your definition) while failing to be Free Software.
The two links clarify that originally at least, they were not the same thing.
This has been going on for a long time and hence as with many language phrases the use/connotation/definition may change over time.
And so we have a HN comment fest over "What Really Is The Definition of Open Source?".
The Open Source Definition and Free Software Definition are virtually identical in application. Other than CC0 being withdrawn from OSI consideration (not denied) and accepted as a Free Software license, I can't think of any differences in practice.
The Open Source community and the Frr Software community have differing ideologies, but nearly identical minimum requirements for software licensing to meet those different visions.
Now as per my original point. This has been going on a long time, and as with language the definitions can change over time.
Early on they were different. Open Source basically implying "hey you can read the Source!" but not necessarily giving you any other freedoms to actually USE it.
But today, people are saying Open Source and Free Software are much the same thing.
I am all for them being the same thing. IE I am happy with Open Source in all practical ways having the same freedoms as Free Software.
But now we gotta call out those projects which define themselves as "Open Source" for marketing use of the goodwill around nice modern definition while operating under the old definition.
Edit: for clarification
As far as I'm concerned, if they can play these language games, so can Elastic.
The purists saying "open source is a narrow thing" only distract conversations about licensing. Word meanings drift over time. We manage. Talk about issues instead of gatekeeping terms.
* Maybe it's just a mexicanism, IDK.
If only the single-source author can host it as a service, or you need the permission of the single source author to host it as a service, then my choices are either self-hosting, or paying whatever price the single legal-as-a-service-host wants to charge, at whatever service quality they provide. (The fact they can choose to allow other licensed hosts, perhaps for a free if they want, does not change their monopoly control). It is a form of vendor lock-in, and avoiding vendor lock-in is one popular motivation for using open source.
So yes, this restriction makes something not open source. This restriction also is not favourable to me as a user of the open source software. Open source was always about avoiding monopoly control of who is allowed to do what with the software. Monopoly control of who is allowed to host it as a service is such, and it is more favourable to me as a consumer when there is not that monopoly control.
Now, meanwhile, there are various market battles going on between various big tech cloud providers and other companies providing (previously) open source software. This is also true. Both things can be true.
For the consumer, as the OP suggests, your best bet is when there is software that can be produced sustainably by multiple entities collaborating, instead of a single company.
Now, if that's not sustainable, that's a problem. It's possible that open source is facing sustainability problems due to current conditions.
But that doesn't change the fact that monopolizing legal right to host software as a service is not open source, is rightly not approved by OSI, and is making consumers locked in to that single vendor (or their licencees), which is indeed contrary to intention of open source.
Likely also a false one. For example, if you use WordPress guess who your vendor is? WordPress. More vexing, if you use Kubernetes provided by a cloud provider guess who your vendor is? The cloud provider, because of all those non-free doodads they put into their managed service.
It is possible for a company like AWS to continue to offer a managed service for things like elastic, but I suspect elastic wants the nature of the agreement to change; which as far as I can tell we're not privy to.
None of these sites need any agreement with the wordpress authors at all, because wordpress is open source, anyone can run it. wordpress owners can't withdraw permission to offer hosted wordpress or make them pay for the right to host, because it's open source.
if I don't like the pricing or service on wordpress.com, I have many options for wordpress-as-a-service. If wordpress.com is the best price/quality, it's because they've done a good job, sure perhaps because they have the most expertise with the software since they write it -- not because they have a license that gives them a monopoly on wordpress hosting.
Expanding on my point, I do think it's possible that AWS can provide services that continue to make software easy to run (like fully managed services). The way I see this is if AWS becomes the primary contributor and the dominant service provider, then the same situation you described happens in reverse. I think the solution here is probably about connecting the success of managed open source based services on AWS to keeping the companies that power them funded. If you balance contributions and money, it keeps the ecosystem in a better state.
But here's the thing. Open source means that even the single contributing entity can not take away your ability to use already-reased code, or anyone's ability to fork it and keep working on it without the permission of the original author.
Open source is designed this way exactly to avoid vendor lock-in -- you can always, in the "worst" case, fork the code without the participation of the original authors at all.
This won't necessarily be easy, cheap or even feasible; sure. Open source does not automatically solve all your problems or guarantee that you'll be able to get the software you want for free forever. It just takes out of the question needing to get permission to do what you want or need to do from the authors or a single owning vendor. This is what many mean by avoiding vendor lock-in.
In some cases open source may not be sustainable. In some cases as a consumer it may make sense to choose a non-open-source product; in many cases as a producer trying to make money producing open source may not make a business model. But if you want to limit people's ability to use whatever hosted service providers they want, including after a fork, including even if your business goes out of existence, that's not open source.
That isn't clear. The license language can be read as requiring you to provide the source code for any software that interacts with ES (e.g., the Linux kernel that you are using to deploy ES over) under the terms of the SSPL to your own users, which you literally can't do.
Elastic claims in their FAQ that this is not the intention, and that may be enough, but it is debatable. Regardless, the SSPL is a bad license for having this ambiguity in the first place.
What makes SSPL and similar freedom-0 ignoring licenses problematic is that you have to care about these kinds of license ambiguities even if you are just using the software.
Open source originated in the 1980s and 1990s in largely academic circles. It gained mainstream popularity as an alternative to closed source "shrink wrap" software and closed shareware.
Back then the legitimate fear was that closed-source vendors would lock everyone in and end up effectively owning the entire computing ecosystem and the Internet. By the mid-late 1990s Microsoft was well on its way to having a total OS monopoly on PCs and increasingly servers, and were it not for Linux and many other projects this likely would have come to pass.
Good news: open source mostly won! We now have a fairly open compute ecosystem. Even Windows was dragged into adopting more Posix-like standards, and the Mac is just a proprietary GUI and set of system services running on top of a mostly open BSD kernel. It's borderline trivial to port most software between Windows, Mac, BSD, and Linux, so we avoided OS lock-in!
Then along came the SaaS business model and closed Internet silos.
Cloud-hosted SaaS just totally upends everything. Now open source doesn't really matter from a freedom perspective. The cloud has all your data, and by keeping select bits of code (or even just the system configuration) secret and locked inside cloud servers vendors can achieve DRM that is effectively impossible to circumvent.
You can't even run the software yourself, and even if you could your data isn't yours. Having the source is meaningless. It's a model that's more closed than closed, and not only is it compatible with classical open source but is actually fed and sustained by it. Open source is free labor for closed cloud SaaS.
The OSI is fully industry captured and isn't interested in challenging this, which is why large projects are adopting non-OSI-compliant licenses.
If others want to host Elastic as SaaS they just have to negotiate a license. At least the authors of the software are supported.
In this case the authors being supported by their ownership of SaaS rights are releasing the source to their product under terms that allow you to run it yourself for reasons other than providing it as SaaS. That means you can in fact control the runtime and the data if you want to do that.
The alternative is to have someone else sell it as SaaS and not compensate the authors, running the risk that the open source will be abandoned. This is the SaaS equivalent of embrace-extend-extinguish.
The article explains its point of view in the first paragraph:
"I’ve been asked repeatedly about a two-year trend in the open source ecosystem: ‘single source’ open source companies scrapping their Open Source Initiative-approved open source license for a ‘source available’ license."
Secondly, although I love the Redis product for example, the company that sells it is no longer getting rewarded for their added value, as when they sold support or consultation, or as when AWS sells the fact of putting Redis on a machine and maintaining it. Instead they get paid for supplying something that no one else has, something which they have made artificially scarce.
Next, Amazon et al have resources and market power enough to push their own versions of these. Who will it serve when there's Amazon Redis, RedisLabs Redis, Community Redis, Azure Redis, all with slightly different interfaces? Who do you think will win? Amazon and Microsoft have the resources to destroy small competitors in these type of battles, and the user will be even more screwed. Just because Oracle failed with Jenkins, don't assume that no big tech is savvy enough to succeed at this game.
Lastly, free software wouldn't exist if everyone took your attitude. If Linus had told people that they could install his kernel for free, but that distros had to pay $2, Linux would never have been a thing. If you can't deal with sharing when someone else might end up putting in less and taking out more, you're not ready to share.
The Redis case study is a nuanced one. The core Redis code is BSD-3 licensed, and adopted a lightweight community governance model in June of 2020 [1]. This model includes a core team of individuals, and seeks to empower individuals who demonstrate a long-term commitment to Redis as a community-driven project.
The core team is now made up of people who currently work for Redis Labs, AWS, and Alibaba [2].
From my perspective, on the core BSD-3 licensed Redis code, it is in all stakeholders interest to collaborate on the "upstream." There's one Redis, and it is the version that is produced by the Redis development community, and Redis Labs acts as the primary sponsor and steward of the project.
[1] https://redis.io/topics/governance
[2] https://redislabs.com/blog/redis-core-team-update/
The Wikimedia Foundation (WMF) doesn't fit these molds: Wikipedia is kind of a Big Thing on the Internet, and yet the WMF is committed to openness and transparency, and part of that commitment is that we only use real open source software. This is increasingly a challenging proposition with the shift towards "Open Core" concepts and specialty not-so-open licensing. The "Open Core" model is especially challenging for the WMF, as it's usually structured along the lines of "The hobbyist version of this product is open source, but if you want the features that are necessary to operate at big global scale, you need to buy licenses and run proprietary extensions or versions." The WMF's principled way of operating relies on there being real open source projects that actually work for doing big things.
I think the Internet (and the world) would be a better place if there were more principled organizations like the WMF which operate with a high degree of technical transparency and openness. If open source licensing models keep going down these darker paths, it's hard to imagine such organizations being very successful. It should not be a given that doing big things in the world implies going proprietary and commercial and running hidden code nobody else can see (or use to replicate your success at other open orgs!).
This is very misleading. For example, [L]GPLv3 explicitly introduced clauses to protect developers from patent trolling and to grant trademark usage.
When releasing code you can be sued over patent issues or trademark infringement and MIT/BSD provides no protection.
Fully agree with your opinion here. In fact, I posted a lengthy comment on reddit about this, here it is copy/pasted. NB: "You" below refers to the OP on reddit I was replying to.
---
Yes, and that's why the phrase "open source" would be perfectly appropriate: open for inspection, review and modifications, but with possible restrictions on use and redistribution.
Now from your description and quick glance at approved OSI licenses, the problem is that OSI seems to like and approve "free source" licenses, "free" basically being the freedom to do what the heck you want with it. (Except for GPL and its variants as /u/nemec noted. Not to mention that Affero GPL is OSI-approved and comes with restrictions/obligations not unlike the new Elastic license.). [EDIT: this paragraph was meant to illustrate the ambiguity of "open" in the OSI's license collection.]
If somebody is the "enemy" of developers here (in terms of they getting fairly compensated), it's OSI: they've made a marketing stunt (which you seem to have bought -- and I don't mean anything bad by this -- you're not alone) by adopting the phrase "open source" instead of "free source", or even more explicit phrase "free-rider source". So now you have a bunch of developers striving for the OSI "seal of approval" and donating their work for free to huge companies. It almost seems like a plan devised by those big companies. Oh wait, look at the sponsors: https://opensource.org/sponsors
No, I do not believe that OSI is the result of a conspiracy of big companies. But those big companies have been smart and coopted OSI for their benefit and now contribute to OSI to keep the marketing stunt rolling on.
Don't ride the wave of being open source to success and then try and close the doors after it's established you a position, and don't try and brand non-open source as open source and muddy the waters for the rest of us.
It's a good lesson. As soon as one person cheats or violates the spirit of a system, everyone else has to too or they'll fall behind. Unethical people ruin everything.
In this case, let's be clear: it was unethical companies.
And it's really far past time we stopped giving those people a pass because "it's the company, not me"
In a way, they do. There exists a "company culture", which is the collection of social norms that have formed inside the company. Most members of a group will behave in a way that does not stray too far from these norms.
There is a very good TED Talk by Dan Ariely "Our Buggy Moral Code" which describes how such a culture is facilitating unethical behavior by individuals.
How are newcomers to know what the mystical "spirit of the agreement" is if it's not written down?
How do you detect that there isn't, in fact, a precise consensus over the "spirit of the agreement" if it's not written down?
That's how society generally runs on all scales, whether we are talking about the office fridge or about national law. Things generally start with very few explicit rules, and new rules get made when they are proven necessary.
"Guesswork" doesn't seem like a good way to do anything without stumbling into a lot of confusion and miscommunication.
But really I was referring to the process of how the laws are formed in the first place. A lot of the time they start out under-specified, and as abuses emerge we make more concrete laws using our new understanding. Of course the latter part usually leads to a lot of discussion and resistance because of the collateral damage any new law causes by being slightly broader than necessary. Which is a major reason many industries self-regulate in the attempt to make explicit laws unnecessary.
I don't think so. I thought the "spirit" was the opposite of that, that open source would let consumers of software avoid vendor lock-in or monopoly control of the software.
This is not a thing that exists. What we have are licenses, not ghosts.
Think about email and the value it adds to the world. Would we ever get the protocols needed to create email if we started right now today? Not a chance.
IMO the previous generation(s) of tech people were way better than what we have today. They were interested in and enthusiastic about building awesome tech / products. Today the only thing anyone with influence is interested in building is a company that can IPO and make them a billionaire.
That currently still exists. It has nothing in particular to do with software, though. People collaborate, academics collaborate. Are you telling me that massive corporations were part of this back in the good old days, just helping people for the fun of it?
Or a law which only allowed companies to pursue the common good?
> This is not a thing that exists. What we have are licenses, not ghosts.
Before we had open source, we released software as public domain. The spirit existed before the trademark phrase was even invented and long after people were already giving away their software for free because of the spirit of the community. We used to go to computer swap meets in fairgrounds buildings and buy boxes of floppy disks with random software on them just to see what was around, people uploaded it to BBSes and shared the work they did - we had Donationware, Shareware, Postcardware (a personal favorite), Beerware and everything in between which was 100% based on the spirit of the community. We just called most of it Freeware.
We have licenses because the spirit was abused.
If you're doing this for the pure joy of programming, you're already rich in spirit - Amazon taking your software and using it is actually a tribute.
My thought is that you're focusing on the "gratis" part of FOSS, whereas I'm over here in the "libre" side of the house - as a (now) Linux systems guy, when (foo) doesn't work I reach and go down that rabbit hole of code until I figure out what's wrong and we fix things - that is what Open Source is about to me, it has no underpinnings of monetary compensation, it's all about two (sic) people who don't know each other being able to randomly see each other's code to solve the problem at hand (and then possibly submit fixes, bug reports, etc.). I've traced tons of open source software to solve problems both personally and professionally.
Getting paid for open source is a relatively new thing in my life timeline, I don't honestly subscribe to that idea but to each their own. I do, however, recognize the time effort and energy it takes to create said software, so I personally take these tech dollars I make at $job and donate to a lot of open source initiatives, coders and even public radio stations bringing me "free" music. There's no such thing as a free lunch as a wise sci-fi author once wrote.
As I remember it the 'community' was completely divided for most of its existence between those who held that the spirit meant writing your own software and sharing that of others who had agreed to do so, and a much larger group who believed that the spirit consisted of sharing anything you wanted, including plenty of closed and for-pay commercial software.
No I do not (I don't deny it was/is a thing), as I feel that was a different community (and it still exists today) - yes, the same technology was used but no, they were not/are not the same community. These are two distinct communities sharing common technology (just like Linux ISOs and pirated software are both distributed over BitTorrent today - the technology has changed but both groups still share it's use). I knew/know people from both communities, they're just two different groups of people who might happen to end up at a party together, that's about it really. I personally don't condone piracy, but then again I've been living inside Linux for 20 years so I don't really encounter it these days.
Me personally, I ran a BBS under OS/2 and was part of Fidonet (I actually roomed in college years with the local Fidonet hub guy), wrote my own widgets in TurboPascal and distributed the binaries and source without any licenses (if we even had any at the time), some of it can still be found in those old CD collections that folks used to sell. I lost my own source code over the years and was able to recover some of it out of those archives. :) (my career steered away from programming into systems engineering, not a coder by trade)
You said:
>Before we had open source, we released software as public domain. The spirit existed before the trademark phrase
You're claiming that the shareware community was a thing, and is somehow the same, or a natural predecessor to the open source community, and that the software piracy community is something completely different and unrelated.
I think this claim is just you imposing a political slant on something much more ambiguous. Arguably the BBS community as a whole was strongly pro-piracy and pro-shareware, and generally indifferent, except for small sections, to things like sharing source code.
Copyleft licenses like the GPL encourage those using the code to contribute back to the open-source community.
Charity licenses like the BSD or Apache license are used by developers who want to work for exposure. They only encourage giving credit to the original developers, and implicitly allow closing the source. Letting people do that is the whole spirit of these licenses. People who don't want to be making charitable donations to megacorps shouldn't use charity licenses.
They don’t want that happening so they use a non-permissive license.
Cue the holy war over the definition of open source.
In my opinion, a healthy open source ecosystem relies on people using and contributing back, supporting the distributed creators that make the ecosystem possible. This historically has been something of a gift economy or social contract, but it's become wildly distorted by companies (e.g. Amazon/AWS) attempting to overuse the commons resource and make profit from it.
So it comes as no surprise that when one rancher comes in and overgrazes the common resource, the other participants might want to make some changes in rules. These new licenses aren't "just because", they come from lived experience of entities like Amazon coming in an exploiting a shared resource.
And I get it, the letter of the law says, "Do whatever you want with this shared resource". And there are plenty of folks who believe that Amazon has done nothing wrong -- the rules allowed for overgrazing, so naturally the right thing for Amazon to do was to overgraze.
I personally see it differently -- Amazon is hiding behind the letter of the licenses and totally distorting a community, exploiting the gifts of the engineers' labor, and getting us to point our fingers at one another over the "one true definition of 'Open Source'" rather than constructively figuring out ways to protect the community of open development and reward the individual workers who volunteer their time.
An essay famously refuted by the work of the first woman to win a Nobel prize in economics. She spent half her life collecting evidence showing that in reality what you describe is more often not what actually happens and outlining the conditions (derived emperically) under which commons resource management works. [1]
1. https://en.m.wikipedia.org/wiki/Elinor_Ostrom#Research
Like, we've all seen the "have a penny/need a penny" trays at cash registers, and we all understand that sometimes we take or leave things there. Amazon is basically able to send someone to every single cash register in the city and take all the pennies. Sure, maybe that's not explicitly disallowed, but it definitely breaks the model.
Like, some standardized legalese or something.
If I, an open-source hobbyist, am thinking about incorporating some code from your software into my project which I want to allow unrestricted commercial use of (i.e., which I want to put under a standard F/OSS license), even though I am not making any money from it, are you okay with that?
If you're not okay with that, then the open-source-like properties of allowing derivatives / incorporation into other works probably just aren't appealing to you at all, and what you probably want is a simple "Non-commercial use is permitted" statement. But it won't actually be the MIT license, which permits unrestricted use, modification, and redistribution.
If you are okay with me incorporating your code, then how do you define how much of your code I can use? If I build a GUI around your program and I tell AWS that they can freely build a GUI, is that still okay with you? That's going to have to be a case-by-case thing, probably.
Another question is what you expect to do about contributions. If I, an open-source hobbyist, contribute some useful feature to your code, am I entitled to get paid a portion of what commercial users pay you? The simplest answer here might be to not accept contributions.
Some practical options, depending on what you're really trying to do, might be:
- licensing under the AGPL, on the assumption that many companies are scared by it even though it isn't a restriction on use (just a compliance headache for potential external use), and maybe clearly advertising a less restrictive commercial license (which could be MIT, or could be a super long contract/EULA) for money
- licensing a previous version of your code under the MIT license, but keeping the current version as just source-available
- marking commercial features as proprietary and source-available (what GitLab does, and what Elasticsearch used to do)
- capitalizing on the fact that you know the software really well, and selling consulting / support but using a free software license (what Red Hat, Canonical, etc. do)
- capitalizing on the fact that you know the software really well, and running it as SaaS (what Google does with Kubernetes, for instance)
- giving your software a simple "Non-commercial use permitted" statement, but saying that open source developers who are interested in parts of your code are free to contact you and you're willing to relicense limited parts of the code as MIT on request
Finally, what's your goal? Is it to prevent commercial use? Is it to make money from commercial users? Commercial software houses are, sort of by definition, good at writing software in-house - if your software is a really good idea as opposed to a really good implementation of an old idea, chances are that a motivated commercial developer will just make their own version of it.
Really, the licensing I envision would be:
1) Any entity that does/wants to derive commercial value from the software should compensate the copyright holder. Example entities here are both "I want to sell software that includes/is derived from your software" and "I'm a company/freelancer using your product as part of my business operations".
2) Any other entity can use the software in any way they see fit (like e.g. MIT) except that 1) applies transitively to any derived software.
The situation here is less "This is an open source thing where I take all your contributions and profit off it" but more "This is a commercial for-profit thing that would normally be proprietary closed-source, but everyone can copy/inspect/modify the source as long as they do not profit from it".
Contributions would either be disallowed, or under a CLA if for some reason someone wants to contribute to it (with the clear expectation that someone else is going to profit from it).
Cooking up your own license ala Mongo is not going to help you amongst the professional users. Companies that take their legal obligations seriously are not going to use your not-so-open-source offerings on the basis of interpreting your weird anti-amazon clause.
Open-source and proprietary licenses are at two ends of the software development spectrum. The open-source model maximizes ease-of-adoption but doesn't provide much incentive for the developers. Proprietary software provides a lot of incentive but adoption can be slow and burdensome.
Let's assume that a good goal for society is to maximize the rate of innovation in software. To do that, you need a mix of BOTH ease of adoption and suitable development incentives. Source-available licenses are an attempt to accomplish this.
Is this a perfect solution? Probably not. I think better licensing models are still waiting to be discovered.
However, my sense is that these new licenses will accelerate the development of software with limited downside for the user. After all, they are designed only to impact companies attempting to sell a SaaS.
In addition, they have the potential to weaken the tech monopolies which, in my mind, is a Very Good Thing.
Well, that’s the PR message associated with the new wave of source-available licenses (source-available licensing is not, itself, new; its long been an established form of proprietary licensing.) But it doesn’t hold up: you can’t harm competing services providers without harming end users. There is a reason why the very different ideologies of the Free Software Movement and the Open Source Community nevertheless have stably settled on definitions which are virtually identical in practical applications (and even though those communities have very different preferences for licenses within the scope meeting their similar definitions.) It is because the space is not a continuum, and there is a minimum needed in each of a number of axes of liberty for the whole structure not to collapse into something which either community prefers free/open licensing. Particularly, without robust freedom that protects what other people can do with it (including there ability to sell you services built around the software that the original maker might also want to sell), you are not insulated against future actions of the copyright owner restricting the software or its or others services around it.
And this isn’t opaque to the people issuing these licenses; the overt motive is to enhance monetization by preventing licensees from competing with them to sell services: it is to create a moat enabling monopolization and monopoly rents. That’s the explicit idea: to create lock-in that free/open licenses would not support.
The benefit that the licensors seek directly depends on the harms that extend beyond competitors to end users.
> the overt motive is to enhance monetization by preventing licensees from competing with them to sell services: it is to create a moat enabling monopolization and monopoly rents.
Here's the problem: Amazon, Microsoft, and Google are already able to charge something approaching monopoly rents because they have built a moat that others can't dream to cross. Heck, try to even build two services that talk to each other between the moats and you will get hit with massive data-egress charges. And they do this by monetizing free products with no compensation to the developer. If you are Redis, your hosted product, whose core you developed, is less competitive than that of the cloud providers who didn't contribute anything to the project. At the same time, the parent tech behemoths are engaged in all sorts of other bad behavior that only massive tech companies can get away with.
This state of affairs seriously threatens the open-source ecosystem and the source-available licenses are targeted to righting this imbalance. Again, are they perfect? No. If you are making money selling the software without modification, is it reasonable to ask for royalties to go to the developers? I think, on balance, that is reasonable.
If not source-available licensing, what is the better solution to the problem?
Even if that was true and they acted like a coordinated oligopoly rather than actively competing, including on price, more monopolies in adjacent markets make things worse, not better, for everyone (customers especially) except the additional monopolists.
> If you are Redis, your hosted product, whose core you developed, is less competitive than that of the cloud providers who didn't contribute anything to the project.
Yes, that F/OSS licensing advantages the firms that have the best infrastructure for monetizing services has been widely observed since it was just Free Software because OSI didn't exist yet, before cloud dominance that was mostly about professional services. And, yes, proprietary (and sometimes source-available) licenses which don't deliver the value of open source to end users have always been the “solution” to that.
What's novel recently is a bunch of firms ignoring well-known facts about the economic incentives around F/OSS, trying to build rapid-growth startups around F/OSS with no plan at all to address the strengths necessary to monetize F/OSS, then whining about the well-known advantages of established firms to pivot to proprietary licensing, then having the unmitigated gall to pretend their proprietary licenses provides the customer benefits of F/OSS licensing (which center on the fact that F/OSS doesn't create a vendor monopoly), despite the fact that not providing those benefits is central to the business reason for which they have adopted the proprietary license.
1. I would prefer that it be widely used. Not because I am seeking clout or advancement, but because that's why I share it. 2. Sharing benefits everyone, including me. Fragmentation and bureaucracy harms everyone, including me. 3. I don't support monopolistic practices by large tech, but this is not the way to stop them. What we had before widespread free software was worse than it is now, arguably held back human progress for years, and didn't stop Microsoft one bit.
That might be the intent, but the problem is that integrating any non-free software to a bigger project becomes problematic because the combined project likely becomes non-free. Which is most apparent in that these non-free components will not be appearing on any major distros main repositories.
So the non-free software remains an isolated island rather than melding smoothly into the larger ecosystem. And this has impact well beyond some SaaS providers.
Second FAQ: "Is this “Open Source”?" Answer: No.
I don't think they are trying to hide anything and if anything are being generous because the source-available licenses do have most features of the open-source model with the narrow SaaS restriction.
There is some mild caution about knowing the differences between these licenses, and mild support for open source projects that aren’t controlled by a single vendor.
Some people claim _I can download the software and use it for free, so it is ok that Amazon should not make money out of it and allow ElasticSearch to have a cloud monopoly_.
This sounds like Tesla selling you a car that you are allowed to service yourself, but you cannot have a professional service it for you except for Tesla.
I don't have a strong opinion towards the practice (I'm also working for a company that does closed source after all), but I do believe it is important to show respect to the freedoms that both free software and open source try to protect.
[1] https://www.gnu.org/philosophy/selling.en.html
This is important, because it means that while Apache could relicense to give themselves an unfair advantage, Cloudera or Databricks could not. People trust Apache not to, being an independent non-profit and the act would destroy their reputation, and given the ASF's main product is being seen as vendor neutral and independent (well that or Apache httpd, but the latter is clearly becoming less and less relevant), would be a serious blow to the organisation.
In practice if Cloudera decided to they could fork hadoop to create "cloudoop" or otherwise stop submitting patches upstream and hadoop development would considerably slow. Given the nature of software, slow development is often equivalent to reverse development as dependencies fall out of date and the project becomes abandoned.
Is it just that Pg is older? Is the code too complex? Do they simply have more diverse group of contributors?
And, how do we keep Pg and other projects 'healthy'?
Even today, it's contributors come from all over the place: https://www.postgresql.org/community/contributors/
I agree with the final statements of the article:
> Open source-licensed projects with a non-profit home, neutral trademark ownership, and multiple significant contributors are less likely to face pressures to relicense. Projects that are the main revenue generator for a ‘single source’ for-profit company have different dynamics.
To "protect" important projects, the more we can find a way to keep them running via a non-profit structure would probably help most of them.
This is why I think the Rust Foundation is an important step for that language, and gives me optimism. It's the right approach: basically, become supported by multiple businesses, effectively not putting all your eggs in one basket. I hope the Rust Foundation succeeds and becomes a paradigm more popular than "try to build a business on my open source project" concept.
Though I guess this doesn't apply too much to postgresql, since any serious RDBMS is much more than just SQL standards compliant.
It’s a good observation, but how many non-profit style open source projects actually exist and how do we create more of those?
Does a carpenter make a family sign a license restricting how they use their roof? No. Does a plumber get a license dictating how the toilets may be used? No. Does a janitor get license royalties after cleaning a room? No.
Here is big tech's dirty secret: the insane profits and salaries are due to an unjust, unethical, unproductive system of #ImaginaryProperty, enforced by violence.
In my experience most people on HN do not want to hear that. They want to pretened that somehow the hours they spend in the day are really 1,000x more productive than the average Jim. But that's just not true. Tech gets unequal wages due to important work but mostly bad laws.
As people wake up to this what you will start to realize is that the biggest ideas, the ones that change the world, that win in the hearts and minds of the people in the long run, have no licenses. Licenses are for losers.
I see lots of license-texts but less frequently any mention about who is allowed to copy the license-text to use it with their own software?
Take the Elastic License: https://www.elastic.co/licensing/elastic-license
Can I use it for my software?