It's not okay to pretend your software is open source
drewdevault.com
drewdevault.com
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).
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.
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.
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.)
I'm far from an expert on that whole debate, but my casual understanding was that they offered the same code under GPL or proprietary licenses. And, that doing so had been found legal and had even gotten (somewhat grudging) approval from Stallman and the FSF as a way to ensure monetization and adoption of GPL-covered code. His justification has a weirdly deontological logic that I don't particularly accept ("you're not making proprietary code, just causing it to be made" is pretty thin), but I think I'm fine with the result.
More generally, though, I completely agree. Misrepresenting FOSS status to dual-license isn't ok, and has all the same problems as the Commons Clause. I think there's a strong case for restricting proprietary use via a single new, non-FOSS license (probably derived from an existing FOSS license) rather than via dual-licensing or worse, added clauses.
For quite a while, MySQL AB purported on the website and elsewhere that commercial use of MySQL required a paid proprietary license, and that the GPL did not allow commercial use, only non-commercial use.
Eventually, they stopped doing that, but it took a while.
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:
https://www.gnu.org/philosophy/free-sw.en.html
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.
Given how every Reddit/HN thread I come across has an argument on whether it is appropriate to use open source in this context, I strongly disagree with the phrase "most people". In my experience, most people call it open source, and it only misleads the minority that insists on owning the definition of the phrase.
I remember back in 2001, when Reddit and HN didn't exist yet, and the whole Internet was caught up in a seemingly unanimous furor about how, not only were most of Microsoft's just-released Shared Source licenses not open source, but even the ones like MS-PL that met the OSI definition still weren't open source simply because they had Shared Source cooties on them by virtue of being announced at the same time.
I fear that the bad old days were so far back now that people no longer remember why this stuff is important.
I've seen this in many activist communities. They (likely unintentionally) pick regular language to mean something very specific, and then spend endless amounts of time arguing that everyone else is using their terminology incorrectly. It's a huge waste of time. The rational thing to do is give your concepts unambiguous names - not ones where the majority that speak the English language could take to mean something else.
>I fear that the bad old days were so far back now that people no longer remember why this stuff is important.
Lumping those who disagree with your terminology with people who disagree with your philosophy isn't going to help the cause either. It alienates allies. In my experience, people by and large agree that it is important and are favorable with it. They merely disagree with the terminology.
And that's the other thing that happens with ideological movements. As they grow, many fall into a local optimum where the focus is on purity. Who amongst us is pure enough to be in our circle? We'll keep devising ways to root them out (insistence on poor terminology being one way).
The minority is those who insist on the OSI definition as the only appropriate way to use "open source".
>mainly people who are wondering if in the future they can exploit open source community in a similar manner.
The problem I'm seeing is the labeling of people who disagree about a single point (terminology) as bad actors (i.e. people who are bent on "exploiting"). As I mentioned in another comment, this is sadly a common path that ideological movements take - attributing intentions to others, and focusing on rooting out impure adherents.
No, it's not. I actually ran a poll on my Mastodon account last night:
https://www.strawpoll.me/16741426/r
I followed up with many of the "something else" folks and most of the people I spoke to said that they were confused by the premise because free/open source are different things, and one had a strange and political definition of open source as "software which helps people", and none of them agreed that the Commons Clause qualified.
>The problem I'm seeing is the labeling of people who disagree about a single point (terminology) as bad actors (i.e. people who are bent on "exploiting").
These people might not be bad actors or have bad intent from the start. But if, upon being corrected, they don't change their course, then they are bad actors. They prey on people who don't understand software licensing, and who only know that open source is "good".
Beyond that, your answers are leading, and don't include the proposed "Source availability". When you put a poll this way its obvious that people will choose specific answers.
If the license does not meet the OSI's definition of "open source", then it is not open source. If the license does not meet the FSF's definition of "free software", then is it not free software. Case closed. No ifs, ands, or buts about it. These organizations have existed for decades, and the definitions they have formalized for their respective terminologies have in turn existed for decades. The meanings of "open source" and "free software" are perfectly clear, and the sorts of licenses being discussed - like those using the Commons Clause - are very clearly neither open source nor free software by those very same well-established-for-decades definitions.
> Is this “Open Source”? No.
You make an interesting point about patent clauses. I think I would say that it isn't the OSI-approved licenses that make a project unusable commercially, it is the patents that companies hold. OSI classifies licenses as they stand alone, it doesn't classify patents or declare projects as safe from patents.
That said, I do think they should state that it is "non-commercial open source".
The patent grant is a red herring; they're copyright licenses, and judged as so. Unlike software copyright, software patents are not even valid in many countries.
How open something has to be, to be called open source is a matter of opinion, so is to some degree what open means in the context of open source. Otherwise they would have to call it "unconditional open source" but then a number of, if not most, licenses wouldn't qualify.
> The patent grant is a red herring; they're copyright licenses, and judged as so.
It isn't a red herring. I use it as an example to show that the openness in OSI approved licenses aren't absolute. Some licenses have other terms. They might for instance retain the moral rights of the author, try to avoid any liability or condition the distribution of software. If you can have those exceptions and still be considered open source I don't see an objective reason why you can't call software where the economic rights are retained open source as well (even though I can understand why people wouldn't want that).
There's nothing special about it, they're just two English words. What makes the term special is its origin and history - specifically, how it was coined and spread by the OSI and its members.
So, they should make their own history with a new term. In time it might be more relevant than open source, and that might be great. But don't mix them up.
But as I said I would still prefer "non-commercial open source". I grants you the right to modify etc. but only if you don't exploit it commercially. Just like copyleft open source grants you those rights, but only if you also distribute the source code.
Apparently though I guess if there was something that was a red herring it is this whole discussion as someone pointed out that common clause doesn't even call the license open source.
> 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".
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.
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.
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".
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."
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.)
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.
Unless Amazon becomes the new primary developers it does not solve the problem of paying the people actually doing the work.
Amazon takes your work and solves the "service layer" story, but having never distributed any binaries, they are not obligated to share their modifications in any way.
Under the AGPL, if you solve the core issue, and they borrow your solution adding a proper service layer to it, that would need to be released as source code, in a way that users could repeat the deployment on their own.
I say "potentially solves" because nobody is solving 80% of the problem better than anyone else can and releasing their 80% solution as AGPL, saving "Amazon jobs" for the Amazon people. And if they were, it would be easily circumvented; Amazon would simply never take the bait. Best case, they would figure out what makes your solution so much better and then implement those ideas for themselves in a clean-room.
Which, if they really are the dominant beneficiary, they probably will; whoever is making the most money from the software has the most financial interest in maintaining it, and that's the reason so many big corps that benefit from FOSS invest heavily back into those projects, either via sponsorship of projects or paying their own developers to work on the codebase or both.
But that doesn't serve the interests of the investors in the company doing the initial work, who invested in the hopes of capturing the downstream revenue later development of the work would produce. Which is understandable, but they shouldn't attempt to trade on the popularity of open source licenses with their non-open alternatives.
And that, not the “people doing the work”, is what the Commons Clause is about.
Who is the big player dominating revenue from OpenSSH? Projects with extremely diffuse benefit like that (or, perhaps more clearly, OpenSSL) do often have a problem here, but that's not what Commons Clause claims to be directed at.
> Or MySQL or Postgres for that matter.
Postgres definitely gets lots of support from significant commercializers of Postgres like EnterpriseDB, Postgres Pro, Citus, and Heroku.
MySQL, maybe not, but a GPL arrangement, especially one requiring copyright assignment, discourages third-party commercial contributions, especially when the owner is actively dual-licensing. Who wants to pay for development of IP someone else can sell more freely than you can?
(Permissively-licensed SQLite, OTOH, has huge contributions for downstream commercial users.)
> With Open Source there are a lot more takers than givers.
By design. There are also more givers than with propietary-licensed software, also by design.
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."
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...)
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.
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.
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.
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.
Because without it we all pay much higher prices than we normally would, and we get sub-par quality/innovation. Unless you're somehow intimating that proprietary software can be completely eliminated, but I don't think that's the case. I don't think that such views are grounded in reality.
"And how are they building these free software moats that stop other people?"
I think this has been demonstrated pretty clearly over the last 10-15 years: they use open source to direct the industry in ways that are beneficial to them, regardless of whether they are good for everyone else. And, it is often the case that there are serious issues for anyone that would want to compete against them in a specific area of software because they're now competing against "free". It forces companies to diversify into areas where they have little expertise, just to be able to compete. So, instead of a company being a developer tools company, they're now something else that also happens to give away developer tools. In the end, it favors large corporations over smaller enterprises in an industry that has traditionally been one with very low startup costs and lots of opportunity.
There has been no shortage of quality and innovative free software. I see no reason that restrictions on a users rights would encourage innovation or a quality product.
Reading the rest of your post, you also seem to view free software as primarily about price. The picture you paint sounds more like what Internet Explorer did to browsers than any free software I can think of.
> So, instead of a company being a developer tools company, they're now something else that also happens to give away developer tools
Or you can take the existing developer tools and improve and extend them. Having access to a large amount of your competitors resources allows you to more easily compete on an even field.
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.
CC licenses that are not NC absolutely allow third parties to sell the content. They just don't allow them to hinder others from sharing it for free.
As for CC licenses with NC, those do not comply with the Open Source definition either.
"Commons Clause" is not a Creative Commons license. The two are unrelated.
Consumer protection laws say otherwise. We live in a society with rules and punishments for breaking those rules for a reason.
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?
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.
> 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.)
CC0 or MIT actually releases them from those restrictions.
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.
No such right exists, so it is not implicitly reserved.
This is not the case, in law, with copyright.
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"
Open source does have a specific meaning, and twisting it like this does nobody any favors.
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.
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.
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.
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.
* 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.
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.
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.
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.
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.
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"?
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.
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.
I'm not going to argue about what a word or phrase "should" mean, but I am going to say that I think the FOSS community could benefit from being more open to different views in this area.
I think this is a case of dogmatism (that might not be the right word here, in this case i mean overly adhering to definitions) that is causing the entire community to be worse off.
Similar to how you said many people see the unwillingness to adopt a new term as "infringing on the ideals" of the original, I am seeing an attempt to be more honest and straightforward about the intent and ability to use a product.
GPL and friends "blackmail" companies into wanting to choose the proprietary license. It may not mean to do that, and there is normally no ill intentions, but it does in my experience.
Contrasted to Apache 2 + Common Clause, it's upfront about what you can and can't do. You can use this under the apache 2, unless you want to sell it, and then you can't. There's no need to dance around the fact, or try to play games where you don't "technically" restrict the right to sell, but in practice you do, or you introduce technical complexity to avoid triggering rather arbitrary parts of a license. The "official definition" is causing users to be in a worse position in some cases.
We can argue over semantics until the end of time, but at the end of the day "fair licensing" means nothing to me, but "open source" or "open source with restrictions" does. If the concept of the term "open source" changes, I feel nobody will be really impacted for the worse. Debian won't start suddenly allowing less-free software in their core, they will just continue to use the definition they do now and the list of licenses which are acceptable that they do now. But what will happen is we will see more experimentation with monetization methods that don't rely on loopholes or technicalities in existing licenses to achieve the same thing in practice.
Of course it does. It dilutes the concept, making it less relevant and useful. Currently I know that I can sell something I make using open source libraries; tomorrow, I won't. At each dilution, the concept is rendered less useful and more irrelevant.
But what will happen is we will see more experimentation with monetization methods that don't rely on loopholes or technicalities in existing licenses to achieve the same thing in practice.
More experimentation is great, but that doesn't justify reusing the terminology to mean other things.
It's not even a good PR move, considering the (completely predictable) pushback. It's just silly.
I'm not trying to twist your words, but that point has already been crossed in my opinion. You can sell some code, but it comes with a lot of extra work that you'll have to do in many cases (if it's copyleft), and all licenses have additional restrictions or aspects that must be followed.
Just because you can categorize many of those licenses into some umbrellas doesn't mean you can wholesale ignore the details of each since it's under some category of "open source".
"Open Source" already means many different things. Copyleft, permissive, are patents or trademarks included? Can you give a warranty? What form of distribution counts? How do you need to make the source available? All of these things vary wildly among OSI licenses, and in the end it's not causing any massive issues because the overarching term isn't used as a technical term, it's used as a colloquialism.
Me too. I like to see companies trying out these ways of making OSS a reasonable choice.
* pay to use the software * assure developers that they can also monetize their work * assure users that prices won't change unpredictably
https://github.com/db4j/pupl/blob/master/PUPL.md
would love any feedback or alternative licenses that capture similar elements