The entire crux of the post's commentary is an intentional misinterpretation of the original post. The motivating quote with the actual context is:
> At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution remains open and free of proprietary code so that the community can build on the project freely
Amazon's core complaint is:
> Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base.
> Within the "x-pack" folder, source code in a given file is licensed under the
> Elastic License, unless otherwise noted at the beginning of the file or a
> LICENSE file present in the directory subtree declares a separate license.
If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows.
What Amazon seems to be asserting is that a project that is open source shouldn't change the license terms. That is not an assertion, as this blog post claims, that the original developers must maintain the project indefinitely.
> If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows.
GitLab recently proposed a similar action. See the below link for the trouble they had maintaining two codes bases for one application. I have dealt with git submodules-it is not fun.
This is what GitLab proposed. I thought they handled it very transparently. Other companies should take note.
The gitlab-ce and gitlab-ee repositories are replaced with a single gitlab repository, with all open issues and merge requests moved into the single repository.
All frontend assets (JavaScript, CSS, images, views) will be open sourced under the MIT license.
All proprietary backend code is located in the /ee repository.
All documentation is merged together and clearly states which features belong to which feature set. Documentation is already licensed under CC-BY-SA.
I distribute open source software. I give a big advantage to those willing to pay me through a support contract.
And as for the (unwritten) "promise the maintainer made", that social contract goes both ways. If that exists, then what of the promise that users will support the maintainer?
Remember esr's hyping of the "gift culture" to open source? In practice it's balderdash. Or as Zed Shaw puts it:
> There was sort of like this unwritten contract in open source that we had; the unwritten contract with corporations was if you wrote open source that they were using, you got some sort of job, or consulting fees, or at least some respect so that way you could find jobs.
> ... I started to realize that “No, that contract has completely been rewritten. It’s totally different now. If you write open source, you’re not gonna get a job”, and now what’s been happening - and part of my tweet storm and whatnot about open source - is that it’s gone the opposite direction, where what I see is sort of like almost direct action to prevent open source developers from making money…
There is no ‘promise that users will support the maintainer’ and never has been.
Open source was originally about developers sharing code with each other and jointly contributing to it, to make their lives easier. Look at all the original GNU projects, they’re almost entirely developer tools, shared infrastructure and games. The core right of open source is for users to modify the code, because in the GOL no distinction is made between users and developers, they are the same.
The fact that some people have been able to build companies on open source software is essentially a happy coincidence. That outcome wasn’t considered or deliberately provided for in the licences or by the movement. If it hadn’t been possible at all, the movement would have been fine with that.
Now that we have decades and generations growing up with commercialised open source, people are thinking that this was by design and something is wrong if open source isn’t commercialisable in this way or that. No. Nothing is wrong. Commercialisation is occasionally an incidental side effect. It is not the point.
Read, especially, the part about people selling free software to the government and the fact that early open source engineers got donations or sponsorships (second page).
That was all still a side effect though. If such activities had not been compatible with open source, or the OGL in particular, it wouldn't have made any difference to the licenses or the reasons they were written the way they were.
I wrote "If that exists" because as you see in my first sentence, I agree with you - I don't think it exists at all.
Instead, I'm pointing out that if there's a social contract one way, which places expectations about what upstream must do for downstream, then it also must be read in a reciprocal way.
I called out to esr to emphasize that we're talking about "open source" and not "free software". Raymond is one of the group who decided to use that term in 1998, and one of its most ardent early proponents.
> There are reasons general to every gift culture why peer repute (prestige) is worth playing for: ...
> Thirdly, if your gift economy is in contact with or intertwined with an exchange economy or a command hierarchy, your reputation may spill over and earn you higher status there.
This is an argument that open source gains reputation which gains "higher status" in an exchange economy. (Meaning 'control of things (not necessarily material things) to use or trade', including money.; quoting http://www.catb.org/esr/writings/homesteading/homesteading/a... )
Other examples of people suggesting that such a 'promise' exists are not hard to find. For example, "How contributing to open source can help you land your first job; Six compelling reasons why, warm fuzzy feelings aside, contributing to open source is good for your career." https://about.gitlab.com/2018/04/06/contribute-to-open-sourc...
Stallman and the FSF's view of free software and the mechanisms for funding such are different than those expressed by the major open source proponents, so I don't consider it useful to point to the original GNU projects for a discussion of the implicit social contract described by open source proponents.
FWIW, my projects followed the free software path for nearly 10 years, until I could no longer support my (growing) family on the "incidental side effect commercialisation" of that movement.
> Instead, I'm pointing out that if there's a social contract one way, which places expectations about what upstream must do for downstream, then it also must be read in a reciprocal way.
I don't agree at all. That you reputation 'may spill over', or that contributing to open source 'can help you' is hardly the language of obligation.
If you do want to impose obligations on downstream, it's grossly unfair and duplicitous to make them implied and unspoken. What sort of chance does that give downstream to understand what they're getting into? Put it in the license, up front.
I didn't use the term "obligation", I said "expectation".
I was unsure what 'obligation' meant so I looked at https://en.wikipedia.org/wiki/Obligation . "An obligation is a course of action that someone is required to take, whether legal or moral."
I did not say they were required, I said there were expectations of what is required.
Raymond's paper makes explicit mention of some open source obligations, like his description of taboos like "There is strong social pressure against forking projects. It does not happen except under plea of dire necessity, with much public self-justification, and requires a renaming." (That this is no longer true highlights a weakness of his argument.)
However, in reference to the text I quoted, neither I nor Raymond was saying that there is an obligation.
Raymond's argument is that participating in the gift economy of open source development is more likely to lead to a higher status in an exchange economy than not participating. It is expectation of this increased propensity which was the implied social contract.
Yes, you are absolutely right that "it's grossly unfair and duplicitous to make them implied and unspoken".
However, some open source proponents - eg, in Raymond's paper - say that they exist, and as such they are making an assertation that there is a social contract when - as both you and I agree - there isn't.
That's my point.
Thus, arguments like AWS's "This was part of the promise the maintainer made when they gained developers’ trust to adopt the software. When the core open source software is completely open for anyone to use and contribute to, the maintainer (and anyone else) can and should be able to build proprietary software to generate revenue." are simply wrong because they depend on a social contract that doesn't exist. Where did the maintainer explicitly make the promise? Where did the maintainer demand that developers trust the maintainer?
My point is that if AWS's implied social contract is meaningful, that social contract must be read both ways in the context of the cultural expectation.
I'll note in passing that AWS's view rejects AGPL as being open source, as AGPL does not allow the construction of proprietary software for cases when "proprietary" means something other than "for internal use only".
Maybe our positions aren't as far apart as I thought, but I do think you're stretching some of Raymond's quotes. Also not every open source pioneer sees things the same way. Bruce Perens is on record saying in his opinion forking is a fundemantal part of open source and healthy for the ecosystem, and has no sympathy for companies unable to make money off the back of it -
Just to check - you think that Bruce Perens, author of the Debian Social Contract, didn't think there was an existing, albeit ill-defined, implicit and non-universal, social contract for free software projects before he wrote that document?
My comments here concern the advocacy from when open source was new, so pointing to Perens' comment from a few days ago doesn't provide insight to what he thought 20 years previous. I'm sure if you ask Raymond about forks now, his answer would be different than it was in 1998.
My observation is that his analysis then was flawed because it made a specific prediction about preventing forking. Things can be influential even if flawed, so confirming that there is a flaw doesn't mean it wasn't influential.
>There is no ‘promise that users will support the maintainer’ and never has been.
Certainly not officially...
>Open source was originally about developers sharing code with each other and jointly contributing to it, to make their lives easier. Look at all the original GNU projects, they’re almost entirely developer tools, shared infrastructure and games. The core right of open source is for users to modify the code, because in the GOL no distinction is made between users and developers, they are the same.
I would argue that _is_ the promise of supporting the maintainer ;)
There was also the unwritten contract that users of open source would support their developers.
Instead, every time someone posts something where they are trying to make a living out of their open source dream, there is a pile of posts complaining about having to pay even 0.01 to them, posting free alternatives with half of the features, or forking the project.
Even on a place like HN, which was supposed to be about creating companies in first place.
What's the point of living in an artifical bubble leading people down the wrong path?
Building software doesn't guarantee that it's worth anything to anyone else. If it is and is meaningfully better than free alternatives they will pay. If not then that's literally the life of an 'entrepreneur'.
Similarly with OSS, no one de facto deserves funding just because they maintain open source software, popular or not. And if you think that companies will support you and play ball with your own whims then you're living in a fantasy world.
The crux is the naivety of the people involved. If you don't like that CompanyX will use or fork your code with no financial contributions then don't use those licenses and roll the dice to see how that works out for you like any other business.
Those freedoms they grant you are granted to everyone whether a one man band or a global enterprise.
If you want to play pick and choose then you're using the wrong definition of 'free'
> There was also the unwritten contract that users of open source would support their developers.
Doesn't match my recollection. Back when FOSS was a rising star, the rallying cry was "free as in beer and free as in speech". No suggestion of an unwritten contract was there and it was amply clear that the vast majority who were piling on to FOSS were infinitely more interested in the free as in beer part than the other.
FOSS created the widespread belief that software and digital information should be gratis; that's the only unwritten contract.
Sure, but the vast majority using the code don't care and never will. The FOSS movement built its momentum by attracting freeloaders intentionally; turning around a couple decades later and saying to them "but you have to support the developers too; pay up" is doomed to failure.
Moreover, it was clear that what we're seeing today was an inevitable outcome from the beginning, much as the true believers denied it at the time.
> No, that contract has completely been rewritten. It’s totally different now. If you write open source, you’re not gonna get a job
Writing popular OSS software (e.g. via github/gitlab) is still one of the best ways to attract the attention of employers. The bottleneck is not "writing software" in the abstract, it's support - which also includes maintenance and addressing custom feature requests. And there's nothing wrong with requesting that support be paid for, nor is this per se incompatible with open source licensing. So, I'd say that ESR's argument still succeeds. People just seem to want things from OSS (or even "open core") development models that would be far from feasible with plain-old proprietary development - such as economic returns in the billion dollar range. This is quite silly, in my view - if the "problem" with FLOSS is that we aren't getting that kind of money from it, that just means that there's not much to complain about.
While Amazon is most definitely not the best messenger to be delivering this message, they're correct in drawing a bright line between what is open source and what is proprietary.
From an open source contributor's point of view, if Elastic is just going to exclusively license your contribution under their proprietary license, then you're just doing unpaid labor for Elastic and all its customers with no benefit to the open source community.
From an open source developer's point of view, you want to make sure that if you do use Elasticsearch in your software, you absolutely don't want to subject the rest of your software to Elastic's proprietary license just because of confusion around what code is licensed with what.
There is nothing wrong with monetizing open source software (people need to eat, after all), but claiming software as open source while having a very nebulous code licensing situation is not open source at all.
If you contribute code to a project under Apache 2.0 terms, or a CLA without any copyright assignment, how can a company license it "exclusively ... under their proprietary license"?
You mentioned subjecting an entire project that uses Elastic proprietary code to their proprietary license. Are you confusing source-available terms for copyleft terms?
The licensing situation for Elastic work is far less nebulous than for much other open source, both legally, and in public notices. See:
> If you contribute code to a project under Apache 2.0 terms
Apache 2.0 is applied per source file, not per the whole project. This is unlike copyleft licenses like the GPL, which have a demand for the whole project to be licensed under GPL-compatible terms. In other words, for a repository that mixes Apache 2.0 with proprietary code, your contribution isn't necessarily licensed under Apache 2.0, unless you're explicit about it (e.g. the source file has the license header).
That said, even if the license if liberal (like Apache 2.0 is), that doesn't mean anybody can change it without your approval. This is a common misconception with liberal licenses. Just because the license is very permissive, that doesn't mean you can copy / paste that code and re-license it in any way you want, without explicit permission from the author.
Despite Amazon's posturing about its care for open source, Elastic's response was pathetic. If Elastic doesn't like their Apache 2.0 software getting forked, maybe they're the ones with "fake altruism or benevolence" (their words). If Elastic is feeling threatened by AWS, they've chosen the wrong business model.
From what I could tell from the response, Elastic didn't have a problem with Amazon forking their product. It was more rebuttal of Amazon's claims that Elastic doesn't really support open source.
"Our products were forked, redistributed and rebundled so many times I lost count. It is a sign of success and the reach our products have. From various vendors, to large Chinese entities, to now, Amazon. There was always a "reason", at times masked with fake altruism or benevolence. None of these have lasted. They were built to serve their own needs, drive confusion, and splinter the community."
They're saying Amazon "forked, redistributed and rebundled" just to "to serve their own needs, drive confusion, and splinter the community". That's all BS, except the "serve their own needs", which the license that Elastic has chosen (and benefited from) explicitly grants.
"We build something on Elastic - and trying to work with them to get licensing was at best a major PITA. In ~2017 Elastic decided they wanted to go Enterprise Only. They started to charge $100k for x-pack, though one could get a dev license for $50K.
We quickly built a SQL parser for Elastic, an alerting engine, some other bits. These are all bits that just went poof yesterday when Amazon released opendistro - and I couldn't be happier. Sure we'll have to slice out a bunch of code, but at the end of the day it didn't have value to our core business."
The trouble is, once an open source company puts essential stuff under a shared source license, and calls it open source, you don't know if that's all they're going to do, or if they're going to keep charging more, or putting more essential stuff under a non open source license.
The simplicity that drew people into using the open source product is gone, and there's an uncertain future.
It's hard to find an open core product that has only enterprise features in its enterprise offering. For instance, in Greylog2, views and a user audit log would be useful to pretty much anyone. [1] And people would probably be happy to implement and contribute it themselves. And the company wouldn't merge it in because it competes with their enterprise offering. With nginx, a feature whose usefulness is not limited to enterprise that is only in nginx plus is dynamic reconfiguration, which can be used to implement rolling restarts. [2]
If the MBA's were looking for a system to commoditize the nerds, they could not have come up with a better system than open source.
A nerd writes an scalable, robust, communication library and makes it open source. Do the big bucks go to the nerd? The one time popular kid in high school, pays a college student to wrap it in a chat app and becomes a billionaire.
Nerds write a database. The database is opensource so they get a pittance. The business people put the database behind a web service and make billions.
Nerds write a full text search engine. Do they get rich? No, but the business people sell it as a SAAS and get rich.
The nerds reward: They get to work as drones for the business people, who will lay claim to all their efforts both inside and outside the company.
I cannot see our current open source environment lasting 20 years. Relying on support is going to be more and more of a problem. What scenario do you think will make the Fortune 500 CEO happy: a) You bought support for open source product X from small company YZ which developed and open sourced X but which no body has heard of, or b) that you bought a support contract from fellow Fortune 500 company C which everybody has heard of, but does not contribute any upstream changes to X?
“who will lay claim to all their efforts both inside and outside the company”
Ah, yes, the infamous “inventions” clause which pretty much any and all developers need to sign to get a job. Here in California, we have a key exception encoded in law: Anything I do on my own time, with my own gear, not related to my day job is something I can release as open source code.
And there are starting to be companies with “open source Fridays” out there who can and do let people openly work on open source while on the clock.
The "Open Source" rhetoric and appeal to a mythical "Open Source Community" seems out of place coming from both Elastic and AWS when the truth is that both companies, and their developers, need compensation, or simply wouldn't exist otherwise. Elastic uses Apache Licensing to make inroads (do they have outside contributors?), and AWS needs commodity software to sell infrastructure. Why not be honest about it?
I agree. It sucks when some giant company forks your project and gives you nothing. But that's exactly the point of open source licences. If Elastic doesn't like getting their projects forked why did they use Apache 2.0 in the first place ? They could have used a proprietary licence.
Don't forget that ElasticSearch is built on Lucene (which is the core of their search engine) and is an Apache 2 Open Source project which existed long before ElasticSearch. So they benefited tremendously from the work of thousands of Engineers too.
Then choose a proprietary licence. Enterprise customers will not be afraid to touch your code and nobody will be able to fork it without your permission.
Then it is hard to get initial customers to build a healthy user base and compete with close source competitors. After all if I am paying upfront I would expect a very different user experience, and more entitled to demand more.
Open source just scales better in that regard. It is low barrier, low maintainence, and self organized. Had it be proprietary Elasticsearch will never see the day of going public.
So open source is how it initially comes to being, then they find there is commercial opportunity in it, and for a long time, those objectives can coexist.
But open source is open source. I don't think it guarantees you can make money of it. You are open sourcing your code, then accusing other parties for using it under the license permission, is ... contradictary. There is after all, an element of freedom in the open source dogma since its founding, be it this free or that free.
I am not a fan of SV vulture capital approach of building commercial for profitable companies around established open source projects. They are not doing anything different than Amazon in my opinion. If more and more essential features are moving to closed source land, then the open source is broken way before Amazon took over.
So let money do money's stuff, and open source be open source. It has a definition anyway, if that what that code is permitted to be used, so be it.
I have personal repos that has thousands of stars. I thought for a very short period of time, had I not open source it might give me additional several grand of income, after all there are several companies contact me. But I know it is too late to think that way, I already enjoy all the attention can exposure by open sourcing it, now I wish I can eat the cake and have it? That is no magic open source could offer.
I am so surprised people here are taking Amazons side. Whilst technically yes open-source implies open, the movement was never about giving away free stuff to mutli-national conglomerates, who themselves do hardly any open-source. With Amazon, its all take. Take take take.
Eh... rarely is a pretty harsh outlook. We forget that these companies tend to have their employees supplying patches and features to many open source projects that matter (like the Linux kernel), working on standards, etc.
Amazon's record with OSS contributions is notoriously poor. For example, see their refusal to allow their query routing extensions to pgbouncer to be used on anything other than AWS:
There's certainly room to criticize Elastic for their approach to OSS and/or their response to Amazon here, but Amazon's "open-sourcing" of a bundle of the OSS bits of Elasticsearch plus a few third-party OSS plugins is nothing other than self-serving, opportunistic PR.
I'm taking Amazon's side because of Elastic's decision to keep security features (auth) behind a paywall. I will gladly support my company's use of Amazon's Open Distro if it means we can grant the right access to the right people at the right time without going from a lowish cost (we do pay for some features and support from Elastic) to an unsupportable high cost environment because of something as basic as authentication and authorization.
I'm glad someone open sourced such basic security concepts and I don't care that it was Amazon.
What people seems to forget frequently is that a lot of the value proposition from elasticsearch comes from lucene, which is an Apache foundation project. And they are able to deliver more value over it because it's permissive Apache license. It's not like elasticsearch built everything from the scratch and there are others approfiting from it.
This is really the only viable way to support FOSS. Considering the amount of money some people make in tech, they should allocate a % of that to donating to open source projects each year. But no, nothing’s going to change the way we live because we can always take but never give, and now things are changing for the worse.
"At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution... does not advantage any one company over another. "
The actual, original quote from the AWS blog:
"At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution remains open and free of proprietary code so that the community can build on the project freely, and the distribution does not advantage any one company over another."
It's a misquoting, designed to change the meaning to suit his needs. Once you read the original blog post in its entirety, this guy's arguments lose their foundational premise.
It feels to me like there was a lot of social pressure over the last 10 years or so for open source projects to use the most permissive open source license they could. You were cool and "more free" if you used Apache, BSD, or MIT licenses. I wonder if this is coming back to bite us now.
Red Hat built a very successful business selling mostly GPL software. Would things be different for the companies we've been talking about lately (mongo, redis, elastisearch, etc.) if they had gone with a GPL license and a Red Hat-like business model from the start?
What I think is that Open Source needs less of these sort of "Open Source companies". Especially the kind that are mostly focused in abusing open source to peddle their proprietary software.
OK, Amazon, I agree. We need more open source out there. Let’s start by releasing your Bookerly font under an open font license, just like how Google released their corresponding Literata font under the SIL Open Font license.
Open source will always be a tool used by corporations to do terrible things. That's why corporations backed it over Stallman's free software movement. They knew that someone like Stallman, who actually wanted to give users power over their computing, was fundamentally going to stop them from being total sleezebags. Open source gives them the ability to pretend to care, while using the software in nefarious ways.
so I don't get it, why don't people use GPL3/AGPL3 etc ?it seems like it allows projects to make money on their products, and also be free software at the same time. when things are licensed APL2 mit bsd etc whatever do people expect an implicit agreement where we want them to promise they won't use it anyway they want?
There's more than just companies or people working in their free time. This might not be very popular for the libertarian fringe, but state support is an option that's probably better than other models. And we already got that to a large degree, with plenty of software coming from universities or state-funded research projects.
Granted, that might not be the next Javascript framework one needs to fill developer ennui.
> At AWS, we believe that maintainers of an open source project have a responsibility to ensure that the primary open source distribution remains open and free of proprietary code so that the community can build on the project freely
Amazon's core complaint is:
> Unfortunately, since June 2018, we have witnessed significant intermingling of proprietary code into the code base.
The Elastic license itself professes to include code that isn't covered under the original Apache 2.0 license: https://github.com/elastic/elasticsearch/blob/master/LICENSE...
> Within the "x-pack" folder, source code in a given file is licensed under the
> Elastic License, unless otherwise noted at the beginning of the file or a
> LICENSE file present in the directory subtree declares a separate license.
If Elastic wants to adopt an open core model, that's perfectly fine, but mixing the open source and proprietary bits in the same repo is messy and should raise eyebrows.
What Amazon seems to be asserting is that a project that is open source shouldn't change the license terms. That is not an assertion, as this blog post claims, that the original developers must maintain the project indefinitely.