Open Source Needs Open Source Companies
blog.jessitron.com
blog.jessitron.com
> 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.
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.
https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codeba...
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…
Quoted from https://changelog.com/podcast/300 .
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.
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'
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.
Someone needs to produce wheat and brew it.
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.
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.
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 ;)
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).
You're lacking perspective here.
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.
His writings include "Homesteading the Noosphere", where he talks about the gift economy of open source. Quoting http://www.catb.org/esr/writings/homesteading/homesteading/ :
> 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.
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 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".
https://www.theregister.co.uk/2019/03/12/aws_elasticsearch_d...
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.
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.
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.
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:
https://github.com/elastic/elasticsearch/blob/master/LICENSE...
Way easier to look at than the nightmare that is 100-character SPDX license expressions for distribution packages.
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.
So you're correct in that regard.
That’s very common in language communities with strong packaging norms, like npm and Ruby.
"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.
[1] https://www.elastic.co/blog/on-open-distros-open-source-and-...
"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."
https://news.ycombinator.com/item?id=19370085
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]
[1]: https://www.graylog.org/products/open-source-vs-enterprise
[2]: https://www.nginx.com/blog/dynamic-reconfiguration-with-ngin...
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?
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.
Don't come around complaining companies are taking advantage of business friendly licensing.
Choose "business friendly licensing" - Amazon sell your product as a service, then fork it away.
Users that understand businesses needs money to strive pay for a commercial license.
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.
Disclaimer: Ex-Amazon Employee.
https://github.com/awslabs/pgbouncer-rr-patch/issues/3
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.
Then they chose the wrong license.
I'm glad someone open sourced such basic security concepts and I don't care that it was Amazon.
Donations, buy their books, subscriptions, distribution CDs, whatever.
Otherwise don't come around complaining how their are selling themselves, while not being willing to pay for the tools of trade.
"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.
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?
Talking is easy Amazon.
Granted, that might not be the next Javascript framework one needs to fill developer ennui.