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.
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
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.
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.
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...
> Also, the CC0 Public Domain Dedication is GPL-compatible and acceptable for software. For details, see the relevant CC0 FAQ entry.
(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.
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.
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.
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.
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.
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.
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.
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.
That's the policy. No exceptions. Don't touch any of it on a corp-issued device.
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
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!).
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.
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."
* Maybe it's just a mexicanism, IDK.
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.
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.
----
> 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.
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.