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