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).
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
> 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.
The Commons Clause doesn't really change any of that from the base license. It says so explicitly - "Without limiting other conditions..."
> They also want to eat and have a home.
This is the very thing that the Commons Clause tries to prohibit: "the License does not grant to you, the right to Sell the Software."
In other words, it's a way for the maintainers of a project to say that they get to sell the software, but nobody else does.
Which, hey, I develop proprietary software for a living, I'm fine with doing that in the general case. What I don't like is trying to mix that kind of restriction into an open source license. Because then what you're saying is, you want other people to contribute code, and you want to be able to benefit financially from those contributions, but you expect it to be a one-way street. There's a basic principle of fairness at play there.
If you want to do that kind of thing, I'd say it's much preferable to go with something more like the oldschool "dual GPL/commercial licensing" approach. Or, if it fits your needs better, something like one of the non-OSI Microsoft Shared Source licenses.
> they get to sell the software, but nobody else does... what you're saying is, you want other people to contribute code, and you want to be able to benefit financially from those contributions, but you expect it to be a one-way street.
It seems like a lot of the positive responses to the Commons Clause have missed or skipped past this entire concern.
People are understandably touchy about "AWS profits off this free code", and understandably concerned that "just make it AGPL" will scare away some big players but not actually keep the developers solvent.
But the Commons Clause isn't at all reducible to "pay us if you profit from selling our code". A clause like that might not be FOSS either, but I think there'd be a lot less anger over it. (Especially if it wasn't achieved by taking a FOSS license and adding on a misleadingly-named "...but not really" clause.) Instead, the Commons Clause restricts sale rights to one entity, leaving the software with a clear 'owner'. And that's what people are mad about: it turns an entire development community into a farm team for one license holder.
"Pay if you profit" has real potential, and as you say has been achieved in the past via dual licensing. It allows for ecosystems where free code is included in and extended from multiple paid projects, and while the code originator might be guaranteed revenue they aren't in control of the project. That's vastly preferable to the you-work-for-us structure of the Commons Clause.
I think the conversation has been undermined by the way the Commons Clause FAQ and authors have skipped across that nuance to say "GPL doesn't suffice here, therefore Commons Clause!" We'll all be better off if we don't let the middle ground stay excluded from the discussion.
> Pay if you profit" has real potential, and as you say has been achieved in the past via dual licensing.
But, often, that involved straight-out lying about a FOSS license, though, and presenting the dual license scheme as if it were the near-equivalent of Commons Clause. (E.g., the old MySQL GPL or commercial license scheme.)
>every OSS project that tries some new way of monetizing
These are not OSS projects.
>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).
4 requirements, upheld by two highly respected organizations. You can read them here:
People need to eat, and that's fine, they can license their software in any way that they think will put food on their table. But if it's not open source, don't call it open source.
The term most people use for this is "source available". Calling it "open source" is misleading, and continuing to call it that after it's been pointed out to you is flatly dishonest.
There is only one commonly accepted definition of open source. Just making the source code available is not enough, you also have to grant the right to be able to use the software for commercial purposes, etc. See: https://opensource.org/osd-annotated
> we want 10% if you're using this in a paid product"
> Confusing since what you've just described sounds very much like what is being railed against?
It's very much not.
"Free for private users, paid for corporations" and "free for free uses, paid to include in new products" are both existing licenses, which may be source available but are generally not open source.
The Commons Clause is different; it permits OSS-style contributions to the codebase while reserving the sale rights to one party. "...the License does not grant to you, the right to Sell the Software"
There seem to be two serious miscommunications here.
First, "source available and we monetize by controlling rights" is not universally hated. Most people less extreme than Stallman are fine with that, they just don't want it achieved by warping FOSS licenses and projects.
Second, the Commons Clause is a particularly bad road to monetized source-available projects. Applying it to an existing project has the effect of converting a FOSS community into an unpaid dev team for one license holder. That's very different from "we'd like a cut if you monetize this".
The "extreme hostility" is not against alternative development/licensing models, but against doing X but saying it's Y.
It's obviously everyone's choice to pick whatever license / licensing model you want. The Commons Clause is getting all the flak merely because it pretends to be OSS-compliant, which it (pretty obviously) is not.
> 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.
Sure, I can get behind that but it has nothing to do with this article which is about non-OSS software trying to trick developers who might want to contribute to OSS into contributing to them instead using naming tricks and deceptive terminology.
The monetization rules in the Commons Clause are quite narrow (for instance, no consulting profits) and that might have annoyed a lot of people no matter how it was implemented.
But I don't think people would be anywhere near this upset if it had been announced as "we started with the text of the Apache License and made a new source-available non-commercial license, we're calling it Use No Resale or UNR for short".
Instead we got "Here's a clause that breaks a core tenant of FOSS, for adding to FOSS licenses, but in our FAQ we admit it's not open source. And it's initialism conflicts with the Creative Commons, and its first big application will be called Apache License + Commons Clause, because no one will ever abbreviate that to Apache + Commons and confuse it with the existing Apache Commons." Plus a huge pile of FUD by alluding to unexplained 'malicious contributors' and 'preventing project shutdowns' to justify its existence.
There are so many different unpleasant aspects to this rollout that I don't really understand how even proponents of the license can view the backlash as "just more anti-monetization hostility".
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.
Using another analogy, it's like "vegan lasagna with meat". We all understand what it mean, but once you put some juicy meat there you can't call it vegan anymore.
I like that analogy even better. Adding some shit to a brownie ruins the brownie but doesn't take away it's "brownie-ness" in a sense. On the contrary, adding any amount of meat to a vegan lasagna instantly disqualifies it from being "vegan". There's an element of binary, black-and-white purity that "being vegan" and "being FOSS" have to have.
Non-metaphorically, I highly recommend ordering vegetarian pizza with extra meat. You get a bunch of excellent vegetables and meat to boot! Very delicious.
> 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.
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."
I think the "problem" the commons clause is aimed at is where AWS starts selling managed deployments of your product, and they make $$$$ from your work without giving you a cut. And maybe your business plan was to do that, but AWS has an existing billing relationship with everyone making them a much lower friction choice.
So, the model that AGPL was designed to combat, right?
Under the AGPL, Amazon would be free to do that, as long as they released the code for their managed deployment systems.
(This doesn't get you any money, but it saves you from the sense that your FOSS-work has been exploited by a commercial entity that doesn't give anything back, so long as it's actually enforceable.)
I think this is a lot of people's complaint with the Commons Clause.
It's defended by citing a real problem, but the AGPL also addresses that problem. Meanwhile, its impact on non-Amazon players like "some random user who wants to write and share a handy tool" is much less pleasant, because it effectively turns that user into a free profit source for the license holder.
I can imagine a healthy role for some intermediate license that goes beyond AGPL to say "actually Amazon, you have to pay us for this". But it would need to not distort what FOSS means for everybody the way this does.
Reminds me a bit of the QT licenses which are dual:
"Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations. With the commercial license you also have access to the official Qt Support and close strategic relationship with The Qt Company to make sure your development goals are met.
Qt for Application Development is also available under GPL and LGPLv3 open source licenses. Qt tools and some libraries are only available under GPL. See the comparison chart for details. The Qt open source licensing is ideal for use cases such as open source projects with open source distribution, student/academic purposes, hobby projects, internal research projects without external distribution, or other projects where all (L)GPL obligations can be met."
Fusion 360 is not in any way open code though, right?
I'm thinking of any _open_ product that says you have to pay once your derivative product goes commercial, even if it's also open. That would be decidedly non-free in the sense of restrictive and as an example, this is something that is not compatible with standard GPL, and not included in the basic general BSD/MIT licenses.
My definition of a free license would include the right to sell (any developer hours for bounty, support, stickers, socks, CDs, anything I want for cash, including unmodified copies of your software) without restriction or liability from upstreams, no obligations, other than that I must include the source code and my distribution must also be similarly unencumbered and without additional restrictions.
There's no comparison to be made with "free for personal use, binaries only." (But thanks for advancing the discussion...)
This is an interesting idea, but I wonder how fees would be assessed?
At one remove "source available, but pay for commercial use" seems very workable. The tricky part is handling it 3+ commercial layers out, where you're either building up a pyramid of fees or making direct payments several notches back along the chain. The first threatens to strangle commercial use past a few removes, the second might work better but opens all the "find the license holder" issues music has already.
I don't mean to dismiss the idea, rather I'm interested to think through what a low-impact way of implementing this might be.
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.
Free software started in the eighties over concerns about how proprietary software was being used. Embrace-extend-exstinquish was Microsoft's attack on a growing free software market, it had nothing to do with the web.
The "free" in "free software" never referred to the price, and is not business strategy. It's used like in "free speech," and it refers to the free modification and redistribution of the code.
Free software has a huge presence across computing. Honeypots use free software because everyone uses free software, free software enables bad actors like building roads enables drunk drivers.
Looking at your profile, either this is an elaborate troll or I am genuinely amazed in how long you've managed to misunderstand "free software." You use the GPL for your business.
Actually, he's 100% correct. The way that open source is used by very large tech companies today is way, way worse than anything MS ever did. MS never got a stranglehold on the network in the way that companies like Google have been able to do.
Back in the 90s, if you wanted to run Novell, UNIX, or Linux instead of WinNT Server, there was nobody stopping you and there were a lot of options. The same with Office suites: there were actual competitors to MS Office through most of the 90s. There is much less competition in many areas of commercial software today, and one of the primary reasons is that open source software has become a vehicle that large software companies use to drive competitors out of markets and solidify their positions in complementary markets. Yes, consumers benefit in the short term, but it allows these companies to build moats that make it very hard, or impossible, for future startup competitors to overcome. We all want to point our fingers at Oracle, MS, IBM, and say that they are the issue, but when every major player in the industry does the same thing, it starts to become more and more obvious that the problem may not be with the individual companies involved.
Also, public roads are a bad metaphor for software: there isn't a market for public roads, and software can always be innovated upon (as an aside, it drives me nuts when people declare something "solved", especially when the reason for doing so is ideological or political).
No. You agree with their end point. How they got there is not factual.
I don't understand your second paragraph. Why should I care about proprietary software competition? And how are they building these free software moats that stop other people?
>Also, public roads are a bad metaphor for software: there isn't a market for public roads, and software can always be innovated upon
My use was very narrow, the ability for bad actors to use infrastructure doesn't put the infrastructure at fault. That said, roads have a market and allow innovation.
I don't think you're really in disagreement. api didn't actually say FOSS started in the 90s, but that the "FOSS revolution" (which I read as the widespread use of FOSS licenses) did. And that statement still works if you read Free as "in speech".
I could be wrong, buy they seem to talk about how the "free" part was important to combat Microsoft's costly licence, and how that isn't an issue anymore.
The problem solved by FOSS licenses is nonfree software that users cannot fully control and redistribute. The adjusted solution for the cloud era is not Commons Clause, which removes freedoms from users, it's AGPL. But no one wants to hear that because they just see FOSS as a way to make a quick buck on the backs of others.
>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.
> That only comes in to play if you concern yourself with downstream users that care about licensing.
```
println!("gosh, no LICENSE!");
```
I just published some source code without choosing a license.
(Yes, yes, I do licence my actual projects. But letting legalistic bullshit put people off releasing their source, even by a microscopic amount, is something that I disapprove of strongly.)
When you walk by me in the street, you're implicitly reserving the right to throw me in to oncoming traffic.
In reality, despite being strictly possible, this barely ever occurs in practice. I don't think it's fair to use the term "implicit" in that way.
No-one is suggesting that you write your startup's infrastructure based on random bits of code, that's obviously a bad idea.
I'd basically consider 'no licence' as equivalent to WTFPL. It scares off big companies. That's probably what you want anyway. If anyone cares enough they'll ask you to relicense it.
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"
It hasn't, though. There's at least two different organizations that work to concretely operationalize what "open source" means. People may be confused about the term, but that doesn't mean we should stop trying to educate about it, and it definitely doesn't mean we should let other people go on polluting the ontological space with garbage that seems intentionally designed to confuse.
No, I'm well aware of what open-source is supposed to mean, as opposed to shared-source or whatever the proper term is for that type of arrangement.
I just try to deal with the world as it is, and the damage has been done already to the popular meaning of the term. I don't have the energy or interest to tilt at this particular wind-mill, so at this point if somebody says something is open-source, unless I have prior knowledge of what they think open-source means, I can't really infer anything in particular, and have to ask some more questions.
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.
"Open" doesn't mean "read", it means "freedom". If I look up the definition of "open-source" for instance on Wiktionary [1], it says "permit modifications and redistribution" (and refers to the OSI definition).
> 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.
People are talking past each other here b/c we can't decide if we're concerned primarily with the ethics of software freedom, or just with confusion of Open Source (TM) labeling.
This discussion says to me that maybe RMS was right to insist on using the term "free software", and to refuse to promote "open source". When we debate the merits of an "open source" (or more confusingly, a "FOSS") license, people end up talking past each other. Are we talking about what is an effective licensing / development strategy, or are we talking about software ethics? People who do not agree with the free software ethos are understandably confused to find themselves criticized on moral grounds for choosing a license that makes source available but does not permit full exercise of user freedom. Hey, I thought we called it open source b/c we didn't want to focus on user freedom as ideology? Right? Maybe that was a mistake.
My personal view is that there is no logical problem in an author talking about open source as the basis for a restrictive, source-available license -- as long as there is no implication that the license is endorsed by a particular standards body. And conversely if you are a proponent of software freedom, maybe you have to recognize that there is some merit in referring to this as "free software" instead of something else, to avoid confusion.
Blocking the sale or hosting of software is one thing; Commons Clause also blocks any "consulting/ support services related to the Software." That's way too broad; is a system that uses Redis "related to the Software"? It's also short-sighted: it limits the ecosystem's growth to the ability of one company to expand and take on "consulting/ support services."
At least non-free licensing gives us an easy way to tell which software is not worth using. It's funny how these recent packages in the news all have FLOSS alternatives:
* Mongo? Why not Pg?
* GitLab? Why not Fossil?
* Redis? Why not better architecture?
* Vespene? Why not Nix tools?
You may see each of these as flamebait. I see each of these as a discussion that, here on HN, usually ends in stalemate. What I'm suggesting, then, is that we simply allow these package authors to tip the scales decisively for us: Reject non-FLOSS and the path is clear.
Mongo and PG are not quite alternatives. That make different kinds of consistency promises. One FOSS alternative to Mongo that offers similar consistency behaviors is RethinkDB.
An alternative to Redis if you don't need persistence is plain old Memcache.
To Drew Devault: Just came across this article, and there's no comments section in your blog post.
> Finally, I have some praise to offer. Dgraph was briefly licensed under Apache plus the Commons Clause, and had the sort of misleading and false information this article decries on their marketing website, docs, and so on. However, they’ve rolled it back, and Dgraph is now using the Apache 2.0 license with no modifications. Thank you!
Please don't "praise" us. When we switched to the clause (back in April 2018), we had changed wordings on our site (we don't do any marketing, so not sure which marketing website you're referring to) to not mention open source but to mention liberally licensed (which I strongly hold that Apache + Commons Clause is, more so than AGPL). There was no false or misleading information. In fact, that was pointed out to you multiple times, but that didn't change your rhetoric.
Dgraph is no longer under Commons Clause and (its core) is under Apache 2.0 license, so I think I can speak as an open-source guy here. There are people like me out there, who'd like to ensure that they can make a livelihood out of writing open source software, without asking for donations, or doing another job. We'd also like to ensure that if we run a company around open source, that company can be sustainable and profitable. If your answer to these people is to switch to closed source, then you're doing a bad job of promoting open source.
In fact, your attitude towards open source is damaging to anybody who is willing to spend their time and effort building open source and expects to make a good living out of it.
If you don't like software with these new style licenses, then don't use software with these new style licenses. Explain what it is that apparently so deeply violates your right to exist, but puritanical screaming and finger-pointing black & white contrasts never really convinces people of anything. All these rants are lame.
The best comment I've heard so far w.r.t. CC is how it complicates acquisition of software by businesses. That's a hugely legit complaint -- but the same complaint applied to the GPL not more than 2 decades ago. Companies adjusted before, assuming value exists in this new breed of license, they'll adjust again.
Meanwhile as a free software author, I'm very happy to see smaller companies experimenting with methods to protect their work in whatever way they see fit. Hopefully something "socially acceptable" comes from all this that might be useful to me at some stage in future.
Finally it's worth remembering that there is a HUGE degree of freedom to explore between closed source, pay-only software and free software as we have it today. I have yet to see a recent example of a license that removes what for me is the greatest benefit of all: the ability to fix and debug things without opening a ticket. Fundamentalist shouting matches erupting every time someone tries something new reminds me of another modern debate - religion, and like there, the loudest and most annoying rarely have meaningful new information to share
----
There is another angle that seems very interesting. Industry consolidation and typical policy within large companies towards employees working on free software ("you can't unless it's approved & we own copyright") means 'the movement' that existed in the 90s is all but dead and gone. Any big real development that happens in the open typically happens because some employer is explicitly paying an employee to advance their agenda through technical means (see e.g. Kubernetes).
To me, a new license that not only incentivized but made practical and sustainable large software projects independent of those large consolidated employers is far more valuable than not having to toss a few dimes in the pot if that software is used in some circumstances where profit is made.
His problem with them is in the title of the post.
If you want to do something that is non-free, don't call it open source or free software, both words have accepted definitions, by osi and fsf/gnu respectively. Your reply is entirely off-topic.
“Apache+Commons Clause” does imo not pretend that it is free/open-source. It's a free/open-source license combined with a restriction. I think this is or should be plain for everybody who reads the license.
In a way I can accept that 'Commons' is being used as a restriction in order to restrict monetary profit. With land, air and especially water there are also restriction in place. E.g. there is much critic if a multinational comes and bottles the water and (in some places) impairs local usage. Rules are then necessary.
The Apache Foundation says it has gotten confused questions about this almost immediately and has asked that this combination not be used (it's own "brand guidelines" say to only use combinations like this if users are granted additional rights, not if the user is restricted further)
> If you want to do something that is non-free, don't call it open source or free software, both words have accepted definitions
If you want to do something that is non-free, don't call it Free Software. As free software advocates keep telling us, Open Source is not the same thing despite the two being historically linked.
I'm playing devil's advocate here, but why does "free software" only apply to some licenses with restrictions?
why are the restrictions that the GPL or AGPL puts on you okay to still be called "free", but Apache 2 + Common Clause has restrictions that aren't "free"?
For the term "Open Source", there is a list of criteria which from all I can tell goes back to pretty close to the creators of the term, and which is quite widely accepted: https://opensource.org/osd
I get that, but I'm asking why we adhere to that? I'd be more than happy to change the definition of "Open Source" if it means that more companies will participate, as doing so won't entirely rob them of most of their income from that product.
In fact, I'd consider it a significant improvement over the concept of "open core" that has been becoming more and more popular, where the core 80% of a product is open source, but the last 20% isn't, making it so you need to either pay or build that last 20% yourself to use the software.
Contrast with an "open source, except you can't sell it", you'd be more likely to get the whole 100% of the software "open sourced" (as in all other aspects of open-source code, without the ability to sell it), people not using it for profit can benefit immensely, and those who are using it for profit can license it like anything else.
Ostracizing the latter because they don't adhere to strict definitions seems wrong, especially when pretty much all of the alternatives (aside from going full GPL/AGPL) means there is less code out there usable by people, and less users will have the ability to see the code they use.
I'd personally prefer if the various proposals for these things picked their own term and filled that positively (e.g. one recent example used a label along the lines of "fair licensing").
Many projects have build on the foundation of these principles (E.g. Debian, where they originated, accepts only compliant software in the core distro) Many people feel quite strongly about things that can be perceived as corporate interests infringing on the ideals, and I think it would muddle the waters even further, and changing the term should have really widespread support to not feel icky. It's a departure from old ideas, it's not wrong to clearly acknowledge that, and unwillingness to do that looks somewhat questionable IMHO.
> Meanwhile as a free software author, I'm very happy to see smaller companies experimenting with methods to protect their work in whatever way they see fit. Hopefully something "socially acceptable" comes from all this that might be useful to me at some stage in future.
Me too. I like to see companies trying out these ways of making OSS a reasonable choice.
i'm sympathetic to (and in the same boat) as the developers that are considering "licenses" like this one. but i agree with the author that the language being used is fraudulent and the terms are one-sided (hence the quotes). i've made an attempt at coming up with a license that better bridges the gap between open and closed. my goals were:
* pay to use the software
* assure developers that they can also monetize their work
* assure users that prices won't change unpredictably
He should have been linked to one repo to have some context. Is the commons clause limited to the project itself or can I still sell my software using a library with a commons clause?
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.