Ultimately, if I choose to, I will license my project however I want. If I want to restrict others from selling my product I will do so.
Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions". That said, I do see the issue that people may use this software and not understand that the restrictions are there (but they clearly didn't look at the license) so changing the name is a reasonable ask.
This article definitely reads as overdramatic, as do the repeated comments on the subject.
These are brownies, but they happen to contain a bit of horse shit. Not a lot, it's just like a tiny sprinkling on top, but they are definitely still brownies!
You can't make a substantive change to a license and pretend it's a small deal. You can't hijack core tenants of a license, and then just put a little disclaimer at the bottom. "Buy one get one half off! *The one half off is actually just a plastic model and doesn't do anything"
Abusing FOSS licenses to try and control your users software while still using their claim strikes me as pretty bad faith. If you want to use a dual license, that's fine - just do that. "Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done, easy, nobody upset. Don't pretend "Hey, this is open source, except it isn't, and please give me your money."
I won't address your analogy since I think it's obviously quite different.
Ultimately, people want to keep their code open, develop in the open, bring in contributors, make it easy to adopt and audit their code, etc. They also want to eat and have a home.
The extreme hostility I've seen over the years to every OSS project that tries some new way of monetizing is just absurd and damaging to the concept.
> "Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done,
Confusing since what you've just described sounds very much like what is being railed against? You're just talking about taking an open source license and adding a restriction around monetizing the code - this is not open source, as it violates one of the 10 or so requirements to be Truly Open Source (by some organization's standards).
To be fair, “brownies with a sprinkling of horseshit” is extremely descriptive yet concise. I understand what this is faster than reading the recipe for what this thing is.
> Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product
Is that an actual license? Because that's not what I've seen most often recently, at all.
An honest FOSS license + dual licensed for commercial would say "it's fine if you make money, and we don't need a cut... unless you've integrated our software AND you don't want your final product to be similarly open-source."
The recent example that's coming to mind is the new CKEditor real-time collaborative version that came out recently. You can integrate this in a commercial product, as long as the users of the product are free to stand up their own instance (instead of paying you to host it, using their editor product as an integrated part of your commercial product.) If your product is closed and you want it to integrate their CKeditor, the other license that is available costs $25/mo per 25 Monthly Active Users.
Even if your product is open-source and users are free to go off and host their own instance, it seems likely that many will opt to pay you to host it instead. Doing this supports your development effort and keeps you in business, meanwhile entitling your paid users to whatever degree of support you're offering subject to availability.
If it's not worth $X/mo per user to you, to keep the users locked-in to the product that you borrowed part of, and such that the users don't have this other option in case your company goes belly-up, then maybe you should really be open-source? Or maybe you should just build your own whatever-it-is that you wanted for free, to make a part of your product.
Tenants are people who occupy land or property owned by someone else. Tenets are principles or beliefs, with the connotation that they're strongly held principles.
I agree with your point, I think there should be a new visible-source (semi-free?) license that includes commercial fees to make it easier for people to evaluate these things without stepping onto a mine.
The Commons Clause might be clunky, but its an attempt to address the changes that have happened in the world since the late 1990s.
For those who don't know, the FOSS revolution came about in the late 1990s and as a popular movement was largely fueled by concern over the extent to which Microsoft was dominating the PC and (then) PC-based server industries. MS was moving to embrace-extend-extinguish the web at the time too. The Free part of FOSS was critical to competing with Microsoft in the late 1990s, since MS's Achilles heel in the market was its costly and cumbersome licensing schemes.
Times have changed quite a bit since then. Today's behemoths are not based in software but in services with network effects. The bad behavior of those behemoths revolves more around exploitation of network effects to lock people into services (not software), and of course the mass surveillance and manipulation of public discourse that becomes possible when everyone is working in a closed silo.
FOSS is utterly worthless as a strategy to resist network effect oligopolies and surveillance capitalism. In fact it might be worse than worthless, since many of these surveillance honeypots run on open source software. If you write and release FOSS today you're likely giving free labor to people who will use your tools to spy on you and manipulate you.
The difficulty we face now is finding a viable alternative to surveillance capitalism as a way to fund software. The Commons Clause is an experiment in that direction. It may not work, but experiments are welcome.
>These are brownies, but they happen to contain a bit of horse shit. Not a lot, it's just like a tiny sprinkling on top, but they are definitely still brownies!
Don't buy them, don't eat them.
>"Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done, easy, nobody upset. Don't pretend "Hey, this is open source, except it isn't, and please give me your money."
None of that makes any sense. Creative Commons simply restricts selling the software itself. The software is still distributed free, and you can still sell a derivative.
> Ultimately, if I choose to, I will license my project however I want. If I want to restrict others from selling my product I will do so.
I don't think you're in the minority here.
> Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions".
You may be in the minority here. Marketing what you're selling under the name of something else with the deliberate goal of tricking and confusing your users is scummy.
You are free to make a bicycle sharing app, and you are free to refer to it colloquially as "Uber for bikes", but when you start putting your app in the app store under "Uber+ Bikes" then you're heading into scam territory.
The article states two different issues at play. I agree with you on the first one: everyone can license their project however they want. It is your code after all.
The second issue is a bit more complicated, and I can't agree with you on this. If adding the Commons Clause to a license changes the license, using the parent's license name to take advantage of brand recognition is misleading for the end users. It is false advertising, and it hurts the brand of the parent license.
If "Apache 2.0 + Commons Clause" is so common and so appreciated, surely it wouldn't be problematic to rename the whole thing and avoid this issue.
I think the main issue is that you state something that's not true, https://github.com/antirez/redis-doc/pull/984 shows that, Redis Labs is claiming license is OSI-approved, when it's not.
I went into this thread expecting to find Commons Clause apologists, and you did not disappoint.
>Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions"
And that is exactly the problem. You are not interested in the Apache 2.0 license, so stop attaching your own terms to it and undermining it like a parasite. Find another license that has the terms you're interested in or write your own.
You don't want a FOSS license, and you aren't interested in writing FOSS software. You do not care about the Apache 2.0 license, you just want to slap it on your software as if it was a brand. You are interested in the marketting opportunity that branding your project with such a license brings to you, not the actual terms of the license itself. That is exactly the point of the blog post, and so you should stop using it.
You are undermining FOSS. These licenses were written on the good faith assumption that people would not go and add restrictive terms to them that are directly opposed to the principles and ethics of the license. You are doing that, and that means you are undermining the license and the efforts of all FOSS licensing by legitimising this kind of parasitic behaviour.
Just fucking stop, and write your own god damn license.
Extremely well known? It was created only 6 months ago, and practically no one had heard of until a couple months ago when Redis Labs adopted it, to much controversy.
> If I want to restrict others from selling my product I will do so.
Of course, and the article says so. The question is whether it OK for you to use a non open-source license (by most common interpretations), and yet call yourself open-source source, enjoying the PR benefits.
You can license your project however you want. People are upset because the contributed to these modules assuming they would stay open source, accepted a CLA, and how they are relicensed as closed source. By the way, this is the situation that a DCO addresses https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-l...
Apache 2.0 with restrictions would have already been much clearer than + Common Clause since it prevents confusion with Creative Commons and Apache Commons.
It would have been better still to just call it the Redis license since the restrictions fundamentally alter the license. Many projects using Apache 2.0 software like Debian can't accept the new license.
The language hijacking of the word 'commons' is unethical (a point mentioned in the essay). Congress does it all the time with the names of their bills though.
I don't understand why everyone is so against his point as far as I'm aware even wikipedia says under "Open source license"[1] that "Licenses which only permit non-commercial redistribution or modification of the source code for personal use only are generally not considered as open-source licenses."
So his point is valid you can't advertise your product as open source if it's not and you shouldn't be allowed to trick the community into thinking it is.
Companies can use whatever license they like it's their right but advertising it as open source when it isn't just to take advantage of the now large community of open source contributors is not acceptable.
Using “Apache+Commons Clause” is just one way used to trick people into believing it's open source when it's not; you may not be using it like that but do you honestly think a company with a team of lawyers didn't do this intentionally so they can take advantage of the open source community?
I agree that if you've labeled your software incorrectly as open source and you've been corrected, it should be re-labeled and the problem shouldn't be ignored.
I will say, though, that personally I feel "free" software has a labelling problem. I'm not heavily engaged in the open-source movement, and a lot of the terms and wording and licensing confuses me to the point where I don't want to use it because I'm not sure what legal or press hell I might be unleashing in the future. The fact that "free" needs to be clarified with "free as in beer" or "free as in speech" is the most notable. Any thesaurus can give a dozen or more great words to use other than the ambiguous "free".
Some of the OSI/FSF licenses can be (in my opinion) just as restrictive and encumbered (albeit in different ways) as non-free/non-open licenses. The biggest ambiguity to me is having multiple pieces of software with different licenses. I've seen some Ruby gems where they're GPL'd, and I'm not sure what the definition of "modified" means as it pertains to when I need to redistribute the code. If I used MIT licensed code inside of a GPL application, do I need to release the MIT code too? What if I need to use non-free code in an otherwise GPL codebase? I'm just SOL? Do I need to guarantee my released GPL code works, or can I release completely broken code and still satisfy the license?
And this post highlights that pretty well those franken-licensing problems. What the hell is Commons Clause? I've never even heard of it... or maybe I did hear of it and like the post says I just thought it was Apache Commons or Creative Commons. Again, ambiguous terms that have tons of better words in a thesaurus.
FSF/OSI have changed the world for the better for sure, but like with the million and a half Linux distros, the tyranny of choice ends up making the process harder. I've never released any of my code as open-source because to be honest, I have no idea what "open source" actually means.
If you want to provide the source to your software, you put the code on the Internet and you're done.
You don't need to even choose a licence. That only comes in to play if you concern yourself with downstream users that care about licensing.
It really only becomes complicated when you want to release it and _also_ monetise it or restrict its use.
Licenses exist because of how this is ultimately at odds with how software actually works - it's basically legal DRM.
(I think licensing has valid uses in the current environment, but it's worth keeping in mind how absurd it is as a concept, it's basically a massive hack).
Copyright applies by default. You do need to choose a license:
> When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), “nobody” starts including you.
Labeling is a problem, and I think the accepted defintion of "open source" is not a very good one. We have "free" software, "open source" software, and "free and open source" software, but I feel these terms are too amorphous and overlap needlessly. It would be easier to describe some of these "kind of open source" licenses if "free" and "open source" had more disjoint definitions.
Free software gives you the freedom to do whatever you want with the software: run it however you want, modify it, redistribute it, whatever. It should be possible to have "free" software that is not open source, i.e., software that requires more roundabout hacking to modify. You'd have the right to redistribute your modifications, even if they were made without the benefit of having the original source. I would expect most free software to also be open source, but it needn't be required
Open source software ought to simply describe software that is 'open' in the sense that you peer into it, see how it works, tinker with it, and otherwise extend it with the benefit of having the original source code. It shouldn't necessarily imply the same level of freedom as 'free' software. The right to resell, for example, need not be guaranteed.
Free and open source would combine the rights conferred by being both free and open source, just as it does today: you can use, modify, and redistribute the software and/or its source code (which is freely available) however you like, give or take some licensing nuances like reciprocity.
On a side note, I agree about the ambiguity of 'free' and the the confusion regarding "free as in speech" and "free as in beer". I will also note that I misunderstood "free as in beer" for a very long time. I'd originally assumed it related to the fact that no one 'owns' beer (in the IP sense): everyone is free to make and sell it.
>I will also note that I misunderstood "free as in beer" for a very long time.
Yup. When I first heard about it in high school forever ago, I thought it sarcastically meant for-pay software, because beer costs money. A free ($0) beer is very rare.
Creative commons licenses have had optional NC (no commercial use) and ND (no derivative works) clauses for years. FOSS purists don't like them, but a lot of artists depend on those clauses to make a living.
There is no widely recognized equivalent of a CC-BY-NC license for software, partly because neither the FSF nor OSI will recognize such a license. Maybe someone needs to write one nonetheless. And stick it on their software clearly and unambiguously. They obviously think that OSI-approved licenses don't suit their needs. Then don't use them, period.
The author is right that "Apache 2.0 + Commons Clause" is potentially misleading. We've seen "GPLv2 + Classpath Exception" before, but that was to give additional permissions, not a restriction. Similarly, most examples of dual-licensing don't add restrictions to either license. Adding a restriction is something new. It's understandable that people find it disingenuous.
Just write a new license already and call it Redis Labs Open License (RLOL) or something like that.
I'm sure antirez would be rather unhappy if you forked Redis, deleted a bunch of features, and called it Redis Lite. At least have the courtesy of changing the name if you're going to use an incompatible license.
This post seemed aggressive and vague to me. I'm not even sure what problem the author has with these licenses. I _think_ the issue is confusing naming - which seems pretty solvable - and not a fundamental problem with "dual licensing" / "source available" / "commons clause" software?
People can develop software out in the open and say "use it as it is, for free!", "use it as part of a new product, for free!", but also say "please do not sell this software as it is" and "please do not make and sell an almost-identical product using this software". That seems good to me, if the other option is closed-source.
E.g. I could make a product, you can use it for free, I will try to make money selling consulting services around the product (you can compete with me on that!) just don't sell the software.
I am happy to be corrected if there is a problem with these licenses being misused (or misrepresented as free and open source), but the post didn't give any examples.
>People can develop software out in the open and say "use it as it is, for free!", "use it as part of a new product, for free!", but also say "please do not sell this software as it is" and "please do not make and sell an almost-identical product using this software".
The Common Clause isn't about preventing shovelware, it's specifically about restricting the user's freedom to sell any derivative work--it straight up says in the 1st FAQ that it's to transition existing actually FOSS projects to non-libre software.
There are two issues. First, naming is confusing, as you said, and wording implies "<open source license> + something more" instead of "<open source license> but with more restrictions". Second, some open-source projects choosing the Commons Clause still say they are FOSS. Choosing Commons Clause is your choice, lying to your users is different.
> I could make a product, you can use it for free, I will try to make money selling consulting services around the product (you can compete with me on that!) just don't sell the software.
I agree that even if it's not FOSS, this is a healthy and reasonable way to profit from software. Unfortunately, the Commons Clause explicitly forbids this healthy use.
“Sell” means...to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software
Imagine that you create new a new project greatly improving Commons Clause software, offer it for free, and offer paid consulting exclusively on your project, while refusing any work that involves consulting about the code you didn't write. That would still violate the license, which says that only the original license holder can do consulting on anything that's substantially derived from the core code. As written, there's no way at all to make money downstream from Commons Clause code, no matter how much value you add.
At the end of the day, open source projects need developers... and developers need to eat.
These license changes have been forced by the business reality of larger cloud companies capturing all the value created by open source communities and leaving OSS developers to starve.
Who deserves the value created by Redis? Antirez and the Redis Labs developers? Or Jeff Bezos?
Open-source doesn't necessarily imply everything that the FOSS and GPL folks think it does outside of their semantic bubble. It's one of those bastardized terms that has become so mangled and situationally-dependent as to be almost meaningless.
For a significant number of people "open-source" just means, "I found this on GitHub"
So this is just a very harsh discussion of semantics? Moreover, one where the argument is based on common understanding of a term, rather than a literal interpretation of the term.
Because a literal interpretation of open-source is a system where the 'source'(code) is open (to read). Indeed many people understand it to mean more, but that doesn't make that understanding indisputably correct.
> These license changes have been forced by the business reality of larger cloud companies capturing all the value created by open source communities and leaving OSS developers to starve.
No, they haven't, because the “big industry players capture the revenue, while open source devs mostly work for those players, either directly or through sponsored projects” isn't something that started with the cloud; it's why Linus Torvalds isn't a billionaire.
It's forced by firms wanting the economics of classic proprietary software and the PR benefits of F/OSS, in many cases, apparently, because they have investors who bought in to F/OSS-based endeavors based on expectations that were unrealistic ab initio given the economics of the industry.
If you want to publish open source and not have cloud companies use it for their own profit without contributing back, there's a license for that called the GPL.
If you want to write software and get paid for it, then ask for money for your software instead of handing it out as open source then changing your mind once it's popular. In common parlance that's called a bait and switch.
People are upvoting the title because I guess they agree to some extent.
It seems everyone starting an open source project nowadays needs to protect against the cloud providers.
The topic on here about the new CI tool from the creator of Ansible also had an element of this. But I actually quite liked his solution. He gives everything away for free and the source is open. You just cannot profit from his work unless you join a partner system.
Maybe I'm being naive but that seemed like it may work. Although not sure how you qualify not being used for commercial benefit if the software you're building with the CI tool produces a paid product. I think the software creator would only really enforce the license if you started a business up doing hosted CI with it or offering it as a cloud service.
The question is not whether it works or not. This new alternative to open source may be great, we're just asking people to clearly distinguish their new model as such.
Readit News
Ultimately, if I choose to, I will license my project however I want. If I want to restrict others from selling my product I will do so.
Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions". That said, I do see the issue that people may use this software and not understand that the restrictions are there (but they clearly didn't look at the license) so changing the name is a reasonable ask.
This article definitely reads as overdramatic, as do the repeated comments on the subject.
You can't make a substantive change to a license and pretend it's a small deal. You can't hijack core tenants of a license, and then just put a little disclaimer at the bottom. "Buy one get one half off! *The one half off is actually just a plastic model and doesn't do anything"
Abusing FOSS licenses to try and control your users software while still using their claim strikes me as pretty bad faith. If you want to use a dual license, that's fine - just do that. "Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done, easy, nobody upset. Don't pretend "Hey, this is open source, except it isn't, and please give me your money."
Ultimately, people want to keep their code open, develop in the open, bring in contributors, make it easy to adopt and audit their code, etc. They also want to eat and have a home.
The extreme hostility I've seen over the years to every OSS project that tries some new way of monetizing is just absurd and damaging to the concept.
> "Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done,
Confusing since what you've just described sounds very much like what is being railed against? You're just talking about taking an open source license and adding a restriction around monetizing the code - this is not open source, as it violates one of the 10 or so requirements to be Truly Open Source (by some organization's standards).
Is that an actual license? Because that's not what I've seen most often recently, at all.
An honest FOSS license + dual licensed for commercial would say "it's fine if you make money, and we don't need a cut... unless you've integrated our software AND you don't want your final product to be similarly open-source."
The recent example that's coming to mind is the new CKEditor real-time collaborative version that came out recently. You can integrate this in a commercial product, as long as the users of the product are free to stand up their own instance (instead of paying you to host it, using their editor product as an integrated part of your commercial product.) If your product is closed and you want it to integrate their CKeditor, the other license that is available costs $25/mo per 25 Monthly Active Users.
Even if your product is open-source and users are free to go off and host their own instance, it seems likely that many will opt to pay you to host it instead. Doing this supports your development effort and keeps you in business, meanwhile entitling your paid users to whatever degree of support you're offering subject to availability.
If it's not worth $X/mo per user to you, to keep the users locked-in to the product that you borrowed part of, and such that the users don't have this other option in case your company goes belly-up, then maybe you should really be open-source? Or maybe you should just build your own whatever-it-is that you wanted for free, to make a part of your product.
I agree with your point, I think there should be a new visible-source (semi-free?) license that includes commercial fees to make it easier for people to evaluate these things without stepping onto a mine.
Deleted Comment
For those who don't know, the FOSS revolution came about in the late 1990s and as a popular movement was largely fueled by concern over the extent to which Microsoft was dominating the PC and (then) PC-based server industries. MS was moving to embrace-extend-extinguish the web at the time too. The Free part of FOSS was critical to competing with Microsoft in the late 1990s, since MS's Achilles heel in the market was its costly and cumbersome licensing schemes.
Times have changed quite a bit since then. Today's behemoths are not based in software but in services with network effects. The bad behavior of those behemoths revolves more around exploitation of network effects to lock people into services (not software), and of course the mass surveillance and manipulation of public discourse that becomes possible when everyone is working in a closed silo.
FOSS is utterly worthless as a strategy to resist network effect oligopolies and surveillance capitalism. In fact it might be worse than worthless, since many of these surveillance honeypots run on open source software. If you write and release FOSS today you're likely giving free labor to people who will use your tools to spy on you and manipulate you.
The difficulty we face now is finding a viable alternative to surveillance capitalism as a way to fund software. The Commons Clause is an experiment in that direction. It may not work, but experiments are welcome.
Don't buy them, don't eat them.
>"Hey, you can use this for free if you don't make any money, but we want 10% if you're using this in a paid product" -> See? Done, easy, nobody upset. Don't pretend "Hey, this is open source, except it isn't, and please give me your money."
None of that makes any sense. Creative Commons simply restricts selling the software itself. The software is still distributed free, and you can still sell a derivative.
I don't think you're in the minority here.
> Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions".
You may be in the minority here. Marketing what you're selling under the name of something else with the deliberate goal of tricking and confusing your users is scummy.
You are free to make a bicycle sharing app, and you are free to refer to it colloquially as "Uber for bikes", but when you start putting your app in the app store under "Uber+ Bikes" then you're heading into scam territory.
The second issue is a bit more complicated, and I can't agree with you on this. If adding the Commons Clause to a license changes the license, using the parent's license name to take advantage of brand recognition is misleading for the end users. It is false advertising, and it hurts the brand of the parent license.
If "Apache 2.0 + Commons Clause" is so common and so appreciated, surely it wouldn't be problematic to rename the whole thing and avoid this issue.
... and apparently this mattered a lot to some people / organizations — they forked those Redis modules: https://goodformcode.com
>Calling it Apache 2.0 + Common Clause makes sense, it's an extremely well known license and it's easier to start there and then say "but with some restrictions"
And that is exactly the problem. You are not interested in the Apache 2.0 license, so stop attaching your own terms to it and undermining it like a parasite. Find another license that has the terms you're interested in or write your own.
You don't want a FOSS license, and you aren't interested in writing FOSS software. You do not care about the Apache 2.0 license, you just want to slap it on your software as if it was a brand. You are interested in the marketting opportunity that branding your project with such a license brings to you, not the actual terms of the license itself. That is exactly the point of the blog post, and so you should stop using it.
You are undermining FOSS. These licenses were written on the good faith assumption that people would not go and add restrictive terms to them that are directly opposed to the principles and ethics of the license. You are doing that, and that means you are undermining the license and the efforts of all FOSS licensing by legitimising this kind of parasitic behaviour.
Just fucking stop, and write your own god damn license.
Extremely well known? It was created only 6 months ago, and practically no one had heard of until a couple months ago when Redis Labs adopted it, to much controversy.
> If I want to restrict others from selling my product I will do so.
Of course, and the article says so. The question is whether it OK for you to use a non open-source license (by most common interpretations), and yet call yourself open-source source, enjoying the PR benefits.
Apache 2.0 with restrictions would have already been much clearer than + Common Clause since it prevents confusion with Creative Commons and Apache Commons.
It would have been better still to just call it the Redis license since the restrictions fundamentally alter the license. Many projects using Apache 2.0 software like Debian can't accept the new license.
You basically want to freeload of the work of people, contributing to your project but want to reap the profits should any of them make money.
I'm sorry but you can't have your cake and eat it to. Either make it Free for personal use / students / non profits etc and paid for commercial use.
or just do us all a favor and keep your project closed source.
Kosher + Fat supplement²
Good work/life balance + Long Weekend Clause³
¹ Chicken
² Pork fat
³ Work also on weekends
So his point is valid you can't advertise your product as open source if it's not and you shouldn't be allowed to trick the community into thinking it is.
Companies can use whatever license they like it's their right but advertising it as open source when it isn't just to take advantage of the now large community of open source contributors is not acceptable.
Using “Apache+Commons Clause” is just one way used to trick people into believing it's open source when it's not; you may not be using it like that but do you honestly think a company with a team of lawyers didn't do this intentionally so they can take advantage of the open source community?
[1](https://en.wikipedia.org/wiki/Open-source_license)
I will say, though, that personally I feel "free" software has a labelling problem. I'm not heavily engaged in the open-source movement, and a lot of the terms and wording and licensing confuses me to the point where I don't want to use it because I'm not sure what legal or press hell I might be unleashing in the future. The fact that "free" needs to be clarified with "free as in beer" or "free as in speech" is the most notable. Any thesaurus can give a dozen or more great words to use other than the ambiguous "free".
Some of the OSI/FSF licenses can be (in my opinion) just as restrictive and encumbered (albeit in different ways) as non-free/non-open licenses. The biggest ambiguity to me is having multiple pieces of software with different licenses. I've seen some Ruby gems where they're GPL'd, and I'm not sure what the definition of "modified" means as it pertains to when I need to redistribute the code. If I used MIT licensed code inside of a GPL application, do I need to release the MIT code too? What if I need to use non-free code in an otherwise GPL codebase? I'm just SOL? Do I need to guarantee my released GPL code works, or can I release completely broken code and still satisfy the license?
And this post highlights that pretty well those franken-licensing problems. What the hell is Commons Clause? I've never even heard of it... or maybe I did hear of it and like the post says I just thought it was Apache Commons or Creative Commons. Again, ambiguous terms that have tons of better words in a thesaurus.
FSF/OSI have changed the world for the better for sure, but like with the million and a half Linux distros, the tyranny of choice ends up making the process harder. I've never released any of my code as open-source because to be honest, I have no idea what "open source" actually means.
You don't need to even choose a licence. That only comes in to play if you concern yourself with downstream users that care about licensing.
It really only becomes complicated when you want to release it and _also_ monetise it or restrict its use.
Licenses exist because of how this is ultimately at odds with how software actually works - it's basically legal DRM.
(I think licensing has valid uses in the current environment, but it's worth keeping in mind how absurd it is as a concept, it's basically a massive hack).
> When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. Once the work has other contributors (each a copyright holder), “nobody” starts including you.
See https://choosealicense.com/no-permission/
CC0 or MIT actually releases them from those restrictions.
Free software gives you the freedom to do whatever you want with the software: run it however you want, modify it, redistribute it, whatever. It should be possible to have "free" software that is not open source, i.e., software that requires more roundabout hacking to modify. You'd have the right to redistribute your modifications, even if they were made without the benefit of having the original source. I would expect most free software to also be open source, but it needn't be required
Open source software ought to simply describe software that is 'open' in the sense that you peer into it, see how it works, tinker with it, and otherwise extend it with the benefit of having the original source code. It shouldn't necessarily imply the same level of freedom as 'free' software. The right to resell, for example, need not be guaranteed.
Free and open source would combine the rights conferred by being both free and open source, just as it does today: you can use, modify, and redistribute the software and/or its source code (which is freely available) however you like, give or take some licensing nuances like reciprocity.
On a side note, I agree about the ambiguity of 'free' and the the confusion regarding "free as in speech" and "free as in beer". I will also note that I misunderstood "free as in beer" for a very long time. I'd originally assumed it related to the fact that no one 'owns' beer (in the IP sense): everyone is free to make and sell it.
Yup. When I first heard about it in high school forever ago, I thought it sarcastically meant for-pay software, because beer costs money. A free ($0) beer is very rare.
There is no widely recognized equivalent of a CC-BY-NC license for software, partly because neither the FSF nor OSI will recognize such a license. Maybe someone needs to write one nonetheless. And stick it on their software clearly and unambiguously. They obviously think that OSI-approved licenses don't suit their needs. Then don't use them, period.
The author is right that "Apache 2.0 + Commons Clause" is potentially misleading. We've seen "GPLv2 + Classpath Exception" before, but that was to give additional permissions, not a restriction. Similarly, most examples of dual-licensing don't add restrictions to either license. Adding a restriction is something new. It's understandable that people find it disingenuous.
Just write a new license already and call it Redis Labs Open License (RLOL) or something like that.
I'm sure antirez would be rather unhappy if you forked Redis, deleted a bunch of features, and called it Redis Lite. At least have the courtesy of changing the name if you're going to use an incompatible license.
- Source-available software (https://en.wikipedia.org/wiki/Source-available_software)
- Shared source (https://en.wikipedia.org/wiki/Shared_Source_Initiative)
So that it's clear that source code is available in some form, but it's not open source.
I don't think it's a good idea to expand the meaning to cover software that isn't Microsoft's.
People can develop software out in the open and say "use it as it is, for free!", "use it as part of a new product, for free!", but also say "please do not sell this software as it is" and "please do not make and sell an almost-identical product using this software". That seems good to me, if the other option is closed-source.
E.g. I could make a product, you can use it for free, I will try to make money selling consulting services around the product (you can compete with me on that!) just don't sell the software.
I am happy to be corrected if there is a problem with these licenses being misused (or misrepresented as free and open source), but the post didn't give any examples.
>People can develop software out in the open and say "use it as it is, for free!", "use it as part of a new product, for free!", but also say "please do not sell this software as it is" and "please do not make and sell an almost-identical product using this software".
The Common Clause isn't about preventing shovelware, it's specifically about restricting the user's freedom to sell any derivative work--it straight up says in the 1st FAQ that it's to transition existing actually FOSS projects to non-libre software.
Also that's just the way SirCmpwn writes!
I agree that even if it's not FOSS, this is a healthy and reasonable way to profit from software. Unfortunately, the Commons Clause explicitly forbids this healthy use.
“Sell” means...to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software
Imagine that you create new a new project greatly improving Commons Clause software, offer it for free, and offer paid consulting exclusively on your project, while refusing any work that involves consulting about the code you didn't write. That would still violate the license, which says that only the original license holder can do consulting on anything that's substantially derived from the core code. As written, there's no way at all to make money downstream from Commons Clause code, no matter how much value you add.
These license changes have been forced by the business reality of larger cloud companies capturing all the value created by open source communities and leaving OSS developers to starve.
Who deserves the value created by Redis? Antirez and the Redis Labs developers? Or Jeff Bezos?
The point is: stop calling open-source stuff that isn't. You shouldn't lie to your users.
For a significant number of people "open-source" just means, "I found this on GitHub"
Because a literal interpretation of open-source is a system where the 'source'(code) is open (to read). Indeed many people understand it to mean more, but that doesn't make that understanding indisputably correct.
No, they haven't, because the “big industry players capture the revenue, while open source devs mostly work for those players, either directly or through sponsored projects” isn't something that started with the cloud; it's why Linus Torvalds isn't a billionaire.
It's forced by firms wanting the economics of classic proprietary software and the PR benefits of F/OSS, in many cases, apparently, because they have investors who bought in to F/OSS-based endeavors based on expectations that were unrealistic ab initio given the economics of the industry.
Deleted Comment
If you want to write software and get paid for it, then ask for money for your software instead of handing it out as open source then changing your mind once it's popular. In common parlance that's called a bait and switch.
It seems everyone starting an open source project nowadays needs to protect against the cloud providers.
The topic on here about the new CI tool from the creator of Ansible also had an element of this. But I actually quite liked his solution. He gives everything away for free and the source is open. You just cannot profit from his work unless you join a partner system.
Maybe I'm being naive but that seemed like it may work. Although not sure how you qualify not being used for commercial benefit if the software you're building with the CI tool produces a paid product. I think the software creator would only really enforce the license if you started a business up doing hosted CI with it or offering it as a cloud service.