> Help! Companies are exploiting my open source software for profit!
Uh, you told them they could.
> Yeah, but they're doing it without contributing back! They're just taking what I wrote and building it into a proprietary product!
You told them they could.
> But how is it fair that they can make so much money off my code and I never see a cent?
You. Told. Them. They. Could.
Time and again I see the same sense of helpless outrage from OSS devs. You owe it to yourself to understand the consequences of the license you choose, now and in the future. All the proselytising about permissive vs reciprocal licenses has only masked the important personal choices involved. Choices that you need to make honestly and carefully, or end up burned by your own expectations.
Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all? If so, your code is a gift given unconditionally, and you should choose a permissive license.
If not, the answer isn't to release it under an MIT license and then complain about it, but to pick a license that matches your intent. The GPL exists for a reason. The MPL exists for a reason. Not because the people who use reciprocal licenses hate freedom, but because their idea of freedom is based on sharing rather than giving. A gift expects nothing in return. Sharing expects that you share as well.
Any choice is a fine choice as long as it aligns with your goals. What I don't get is trying to have both and then being upset when you're rebuffed by reality. Picking a permissive license is being the chill surfer dude who lives in a van and just, like, takes life as it comes, man. Lots of people like the idea of that dude, very few people want to actually be that dude. Don't pick the BSD license because of its cool I-don't-care image. Pick it because you actually don't care, or be forced to admit publicly and embarrassingly later that you actually did all along and it was all a show.
And for the love of god, don't pick a permissive license, slap a preface on top that says "but not really tho", and act like you've found some amazing lifehack. You're just lying to yourself and everyone else; wearing open source's uniform without making open source's sacrifices.
I agree. There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping. Maybe it's time to reconsider in times of cloud oligopoles. Because why would you want your software become part of the lock-in strategy of a cloud provider.
It's really sad that the GPL has essentially "gone out of fashion". It's sad that developers would be driven merely by fashion rather than careful consideration. The fact that we have free software at all is largely thanks to the GNU and the GPL.
GPL is great for infrastructure things: it allows easy sharing, but requires reciprocity and prevents takeovers. GPL gave us Linux, a wildly successful OS kernel. Also, GPL is compatible with commercial dual-licensing, which may be important in some cases, such as use in governmental agencies.
MIT/BSD is great for small, less important things, and allows for no-question-asked use of such software in basically any setting where software does not need certification. This is something many authors seem to cherish: "my piece is useful and popular!".
The problem is that a small fun hack may eventually grow into an important infrastructural piece, and at best you can try and re-license it under GPL / LGPL if you want more control, and all contributors agree.
OTOH going with AGPL usually means that no corporation will ever touch your software with a ten-foot pole, so corporate contributions to the codebase will be zero (unlike GPL software). This may keep that software more free in one's eyes, but also obscure.
> OTOH going with AGPL usually means that no corporation will ever touch your software with a ten-foot pole, so corporate contributions to the codebase will be zero (unlike GPL software).
As a practical matter, I think that you're right — but I think that this is in many cases quite short-sighted of the corporations who choose to go this route, in much the same way that for many years they resisted shipping GPLed software to customers. One can make profit on AGPLed server software in exactly the same fashion that one can make profit on GPLed client software.
If Amazon offered an AGPL Redis, they'd still be able to build whatever they want around it, and keep that proprietary. I'd still find value in paying them for their running-Redis-in-AWS. They'd still make money. Their competitors would get a Redis … the same way that they currently get a Redis.
But antirez and the rest of us would get to share in their performance patches &c. Would that alone make him as rich as he deserves? No, probably not. Would it alone even enable him to make a meager living? No, probably not. But it'd be better than a BSD license, which requires very little indeed.
GPL has neither of these qualities. GPL only requires pay-it-forward with reciprocity being incidental. GPL only prevents takeovers that require proprietization to be effective (which is some portion of takeovers, I'd agree)
Separately, the AGPL situation is obnoxious. AGPL does nothing wrong here. Corporations being anti-AGPL is bullshit (but is indeed all-too-widespread).
> at best you can try and re-license it under GPL / LGPL if you want more control, and all contributors agree
You actually don't need all contributors to agree, you only need one. The MIT and BSD licenses don't ban you from relicensing into more restrictive licenses (that's why they're popular with businesses, after all).
I've always wondered why GPL dual licensing isn't more popular. In particular, I've always wondered why "GPL or ask me for permission" isn't being explored more. That still allows you to be extremely permissive but you get the make the call.
Eg if I were coding a database like Redis, maybe I'd be totally cool with people freely using it in their moonshot VC-funded trike sharing site, but not with cloud providers offering it as a paid service (or, at least not without paying me some royalties).
> In particular, I've always wondered why "GPL or ask me for permission" isn't being explored more.
Maybe because then you need to have CLA's (Contributor License Agreements)? Otherwise, who is "you" that they need to ask? It's not just your code, it is based on work of many other contributers.
Possibly-ignorant legal question: Could the "CLA" be as simple as a checkbox on the PR submission form that says something to the effect of "You agree that your contributions to this repository, while owned by and credited to you, belong to (ownername) for the purposes of copyright and license enforcement?"
Basically, making anyone who contributes aware that the contribution doesn't give them a claim in the copyright of the project. Short and simple.
A CLA is basically a simple as you describe. It's just that some people (how many?) don't want their contributions to be ever closed source and might not agree to that term. Worse case, they fork your project, applying their changes to their fork.
It's the social issue, not the legal issue, that's annoying about CLAs.
I have been currently exploring the option of open sourcing a project of mine and have researched CLAs a bit, but would love to be corrected if mistaken.
It is as simple - and it is not. You need to take care of special cases, like contributions from company employees in their free time (their company could still own rights to this work), people contributing other people's code (SO answers), patents and whatnot. Fortunately there are existing CLA agreements (Apache for instance).
As for this being the social issue, I don't know yet how big a problem that is. It's never bothered me before, as I recognize that maintainer might want to take the project in another direction in the future and since I don't want to maintain it, I am just happy that they are doing it for me. I will use CLA for my project and if someone doesn't like it, it's fine too - I don't mind forks (if they are well maintained, I'll just switch to them ;), and if someone doesn't want to contribute because of this, I don't want their contribution to be in my code anyway, because it limits my options in the future. There's a new post today on HN [0] that presents options pretty nicely, and it is very aligned with the conclusions I came to.
> In particular, I've always wondered why "GPL or ask me for permission" isn't being explored more.
Because handling “ask me for permission” is expensive, even if you say no, and you can only do it if you sacrificing much of the main benefit to using open licensing, which getting free work from downstream, since people having to give code ownership to you makes them less likely to contribute back anything that you can use with your licensing model, even if they are doing GPL derivatives that the rest of the world can use without the “or ask me” part.
Do you posit that people are more inclined to share contributions to a codebase that does not ask them to share such contributions?
Or do you posit that GPL (or another reciprocal license) prevents adoption of software where a MIT (or another permissive license) would lead to adoption of that same software?
> Do you posit that people are more inclined to share contributions to a codebase that does not ask them to share such contributions?
I posit that people businesses share contributions because it brings them business value, and the business itself being able to use the code in proprietary derivatives often significantly enhances the business value from sharing contributions, which is why SQLite (available as public domain or permissive license) and PostgreSQL (permissive license) have significant upstream contributions from downstream proprietary users, and even Linux gets a fair amount from people whose main use motivating modifications is hosted use which does not require contributions (because it's GPL, not AGPL.)
I further posit that, OTOH, people who don't want to control downstream use are more likely to contribute if they can do so with a license that doesn't constrain downstream use.
But most critically I observe that a GPL-or-proprietary offer cannot use GPL-only contributions, it requires acquiring rights from downstream contributors to relicense code under a proprietary license. So even if people are contributing under the GPL, that isn't “giving back” to the vendor of software that is under a GPL-or-proprietary license scheme (where the value proposition is that the proprietary offers at least as much in all dimensions as the GPL version, and more in some), since by adopting that license scheme they have locked themselves out of use of community improvements that are offered only under the reciprocal provisions of the GPL, which can result in the proprietary version being supported by less aggregate development resources than a community, GPL-only fork.
> ... even Linux gets a fair amount from people whose main use motivating modifications is hosted use which does not require contributions (because it's GPL, not AGPL.)
I'm not aware of any Linux mods not being shared upstream (or at least intended to be eventually PRed to master), except maybe grsec? Please don't give them (AWS/Azure/Google) ideas; we might soon see eg. proprietary drivers for datacenter hardware or Docker/k8s-specific kernel mods. That's a case AGPL could've prevented (though again, I don't know of any proprietary kernel mods).
Hm, come to think of it, the possibility of security-piercing the kernel, then to offer the result as a Linux VM or worse, for hosting Docker-like containers, is concerning. One reason more to buy real VMs with a verifiable standard distro installed, rather than "containers" I guess.
> I'm not aware of any Linux mods not being shared upstream (or at least intended to be eventually PRed to master), except maybe grsec?
That's my point: they usually upstream changes even when they don't legally need to, because they benefit from the changes being upstream and not something they have to maintain in separately.
I would suggest that a project run by an foundation whose entire purpose is Free Software and which strongly prefers making its own software available under exclusive reciprocal license for ideological reasons tied to it's central purpose has a very different position with regard to securing contributions of code ownership from people interested in contributing to the community than a company licensing software under a GPL+proprietary scheme, whose implicit ideology is “we should get paid by commercial users for what we develop, but you should not for what you develop for us”.
There's a big push by larger corporations such as Google away from GPL-like licenses towards MIT licenses. Unfortunately many smaller developers seem to follow suit even if it doesn't necessarily suit their interest as much as it does FAANG's.
I was soured on the GPL by GPL v3. I don't want "or later", because that is giving control of my code to whoever ends up owning the FSF in the future. However, then you end up with a GPL v2 system, where some authors have passed away so relicensing is impossible, which you can't link to new versions of GNU libraries as they have gone v3 only. It's maddening.
No, try: "Do I want the end users of my software to have rights?"
That's what GPL ensures. You can use GPL software anywhere but if you're giving it to other people, you have to give them the same rights you were afforded. And sometimes that also means giving them access to your software too.
LGPL exists too. Makes it a bit more simple for drop-in-libraries.
If they will not use my free software because of the expectation that they contribute back even a little, then they are not users I want anyway, so who cares?
I find the entitlement complex that some software developers have over other peoples' software to be bizarre. "How dare you offer this free software under terms that don't allow me to exploit your labor commercially without the slightest contribution!" is a real thing that real people say every goddamn time you dare release anything not MIT/BSD licensed.
Well, both really. Even with open source, if I want to license my code under whatever license for whatever reason, I can't use GPL code.
And I'm not arguing for people to not use GPL. All I'm saying is there are valid reasons to use MIT (or whatever) if ones goal is to make their project as usable as possible.
Why do you think that? Linux is the most widely used operating system in the world and it's licensed under GPL. People don't choose not to use software because it's GPL. Why would they?
Because depending on the version of GPL (Linux is GPLv2) Some restrictions might not work with whatever you're doing. GPLv3 specifically has turned off many for various reasons.
You're mistaken. (Well, maybe not mistaken if I read exactly what you said literally, but people/companies most certainly do choose not to use GPL software if they're looking to build a system that they can exploit for profit-making purposes.)
It takes a very forward-thinking person to understand that they have more to gain from the thousands of eyes and the support of the community, than from a paywall that gates access to their creation. (And that person could reasonably choose to license their software as GPL or any other open license, there are lots of trade-offs.)
But if you're not building the system from scratch, you need to be aware of the licenses you've accepted, and for many businesses the addition of GPL software to the stack will be a non-starter. Do you think we'd have Apple as it is today if it wasn't for BSD Unix and the BSD license?
Would we have Android today were it not for GPLv2 and Linux licensed under it?
But indeed, GPL does limit the ways you can distribute software licensed under it. In particular, licensing something like a library, or another early-bound component under GPL forces the users to license their work under GPL, too. This is why LGPL exists.
Absolutely! Not saying that Apple model is right or wrong, but they certainly chose BSD consciously (whether or not it was because of the encumbrance of GPL, or any technical reasons).
It's simply wrong to say that nobody pays attention to this. It's a choice you make, and whether you view the consequences as "repercussions" or "features" depends entirely on your view and the actual outcomes of those choices.
Fwiw I understand that Darwin is also available as BSD, so it seems you can get some good actors that are willing to pay it forward without necessarily needing to add a license that goads them into it.
Apple/NeXT had serious experience with the GPL license when shipping their GCC-based Objective-C compiler.
Their subsequent choice to use BSD-licensed components, and to support/create BSD-licensed components where only GPLed components existed, must be seen in the light of this experience.
You're not talking about using the software, you're talking about making derivatives. The GPL doesn't restrict use of software in any way. It only prevents you from redistributing derivatives under more restrictive terms.
This is splitting hairs. Of course there is no restriction on use, but in order to produce a derivative work I will want to eat my own dogfood. If my company's legal department says that our product must remain proprietary and closed-source, then it stands to reason I will not be able to build it on a GPL base. Those people will likely have to choose not to use GPL software, at least to some extent.
(If they have a good legal department that understands intellectual property issues at all, and their product team knows they don't actually need to hack on the Linux kernel to make whatever they're building, then they will not likely be restricted against using Linux ... but the decision will necessarily restrict their choices when finding other components to use as part of the system they are building.)
Whether that is a good thing or a bad thing, I certainly feel is debatable and I'll reserve judgement. But it is provably wrong to say that nobody chooses not to use a GPL-licensed piece of software because of the license it is distributed under. Tons of people do.
No it's not splitting hairs. Using a piece of software and distributing a derivative of that piece of software are two completely different things. Nobody chooses not to use a piece of software because it's GPL. If people choose not to distribute derivatives under restrictive terms then that's great because that's exactly the reason I licensed it to them under the GPL.
You do what you want when you publish software! But if you take the entire class of people that produce derivative works, and count them as "not users" you are making a set error. Derivative works producers are also users.
GPL licensing will not stop me from using your software. It will stop some people. I do not say that I agree with those people and their decisions. I could not have built my career without GPL software, and it does not stop me.
tisk tisk, so many downvotes and knee jerk reactions, but this is pragmatically correct.
GPL is unpopular, and if you want people to use your software, it is the wrong license to choose.
Should it be? Perhaps not. ...but I don't think the parent comment is nearly as wrong as people seem to think.
It doesn't matter if the GPL technically is a better or worse license; the fact is that (perhaps indeed driven by large corporations) GPL has a very negative image right now, and since we do live in a 'look at my popular github repo with oh so many stars, aren't I popular, oh btw hire me pls' world now, that is actually a big deal.
The question is not, 'should I use GPL?', because the answer is no, if you want to have a successful popular open source project.
The question is; how do we actually change the perception of GPL so the answer becomes yes?
I'm not sure... but I think it's a far more important question.
(I can certainly say that I no longer use the GPL, after using it for many years, largely because it was requested I remove it from projects. What do you do in that situation? Since I really don't care that much why not just put it under something else? I don't have a good answer.)
Arguing for something automatically means you agree with it and support it, apparently. So if I say why would people use less restrictive license for certain project, I apparently hate GPL and/or don't understand it. I guess.
because they give me a service for free? Or just because we're all in this together?
I'm sure it depends on the examples you pick. I'm totally happy if people use my MITed code in a commerical product without reciprocating. I'm not writing it for them. I'm mostly writing it for myself. The payback is the joy I feel when others find it useful. I also feel joy by being part of the larger collection of people and companies that have given me so much free stuff. Python, clang, v8, firefox, chromium, electron, zlib, libjpeg, libpng, git, sdl, react, etc etc...
git is a good example. It's GPLv2, but that hasn't prevented it from being used to form a near-monopoly (github) for F/OSS, now bought by MS. Linux: used in the world's largest spynet (Android). Your joy and enthusiasm being taken advantage of for nefarious purposes.
Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.
You probably have the term linking in mind to draw the conclusion that if you're merely exec'ing an external binary, this exempts you from GPL restrictions. But that term is used in the L(!)GPL to state an ok method of bundling your code along with the licensed lib. AFAIK, that GPL code is ok to bundle with proprietary software whenever GPL-ed code is invoked in a separate process, though heard frequently, has yet to stand in court, especially when said proprietary software is just a wrapper or web interface.
git is a both domain specific programming language and library of software routines that enable version control. Curious why you don't see it this way.
It's a separate program though, so you're not repackaging, modifying or redistributing.
Let's take for example TortoiseGit, should they decide to sell TortoiseGit now, they wouldn't have a problem with the GPL because they're not redistributing git. They just say, download git and our program will connect to it. Git does not become part of TortoiseGit at any point. You could replace the git client with one that has the same interface and it would still work.
Whether TortoiseGit is a derivative work of Git is ultimately a legal question. Certainly just being a separate binary doesn't automatically make it not one. "You could replace the git client with one that has the same interface and it would still work." - that's true of any library used in any program.
Unless you're building (as your company's product) a Git client based on Git, then the license of Git is irrelevant. It does not enter into the question of how you must license your product when you publish it.
Most people who have chosen to include Git in their development stack don't suffer any consequence from the fact that it is licensed as GPLv2. TortoiseGit is another matter altogether – ~in fact it must be licensed as GPLv2, because it links to libgit2. If it was changed to wrap the Git binary instead, then what you say is probably true.~ (this is false, [1] libgit2 is licensed as GPLv2 with the Linking Exception. So clients that link to it need not be licensed as GPLv2.)
But most of us Git users are not actually building Git clients.
Describing git as a DSL stretches the term quite a bit.
('DSL' can be a valuable lens to view a program though. Just like viewing things as eg file systems or databases can sometimes give you deeper insight.)
Key differentiation here is that the person is not donating time so that a company necessarily profits off that labor. OP is getting what they (OP) are expecting out of it (joy by being a part of larger collection of people that have given them so much free stuff)
> There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping.
They aren't uncool, they just have terms that lots of people have good reasons not to want to deal with, and which many devs don't want to impose on downstream (in part because lots of people don't want to deal with them.)
Who are those people that don't want to deal with a reciprocal license?
Are they paying customers? Good, GPL and commercial dual-licensing is a thing, and thank them for their business!
Are they people who would like to just use the software for their benefit, modify it to their taste and distribute, and keep the improvements concealed from everyone who made it possible? Tough luck, nobody promised them a free ride like that. They're still free to run unmodified GPL'd software.
> Who are those people that don't want to deal with a reciprocal license?
My theory is: the HN crowd that hates reciprocal licenses are developers who dislike that they can't easily use that code for work - that is, their employers makes it hard for them to do so vs. BSD-type code. They care more about developer freedom (to integrate various pieces they feel entitled to), more than user freedom (to modify the resulting software).
>Because why would you want your software become part of the lock-in strategy of a cloud provider
Because I care more about that my software was found useful enough to be used, less so about by who and why? This is the main ethos behind licenses like BSD and MIT and APL. That, or I don't care enough to take a stance on license politics, and the BSDlike licenses are the only way I can put my work out there whilst giving any prospective downloader the least amount of need to think about license politics.
I don't share this "those evil corporations!" mindset that tends to drive so many that choose a GPL-series license.
From my experience, "those evil companies" isnt actually a common argument in free software circles. It's only a problem in the sense that they fail to pass on the freedoms required by the license (breaking copyright law) or attempt to circumvent the intent of it (see Tivoization).
It's pretty common to actually see the opposite. When companies genuinely create/modify/support free software they tend to be praised and actively supported in the free software community.
> and the BSDlike licenses are the only way I can put my work out there whilst giving any prospective downloader the least amount of need to think about license politics
But it also means that you won't be able to independently produce much software to begin with nor sustain such practice. If that's ok, then it doesn't really matter which license you choose. A few hobby libraries and utilities that you will be able to afford to write don't matter much.
Note: they are not reciprocal. They require passing on the freedoms. They are pay-it-forward, downstream licenses. If you get something back, it's incidental (though common).
Kubernetes makes it easy, but there are few missing pieces - for example there is no load balancer that you can use with commodity dedicated servers (there is metallb, but it requires routing facilities most hosting providers don't offer).
> Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all?
I suspect it's a lot easier to say "yes" to these questions when you're just starting out (and thus picking a license) than when you see a bunch of other co's profiting signficantly more than you are.
This seems to be an attempt to fix that mistake (I wonder if the Redis creators would call their license choice a mistake?). Like a train gone off the rails, there are probably only messy solutions that no one is super happy about at this point.
I think you are probably right. When starting the project, creators value their work very little, but value any attention given to their project very highly, thus a permissive license makes sense. Only after success hits do they regret it.
Even so, if someone was seeking fame and fortune through OSS (a somewhat foolish mission, but whatever), I would still probably recommend they release their software with a permissive license as companies are far more willing to get on board with MIT/Apache licensed software. I mean just look at the incredible amount of hate Facebook got for having the gall to offer a free patent grant with gasp a condition that you not sue them.
The best way to personally profit from OSS is very oblique. Assuming you make a kind of software useful to businesses like Redis (not end user software), it can look very good on a resume, can help you land some speaking gigs, maybe a book deal, and so on. If you build up your reputation like that, it should be possible to land a cushy, high paying job at a tech company somewhere or high paying support consulting.
This is true. Most people who start an open source project don't do it for financial reasons. Usually they want to learn, to build a reputation or to create a good product just for the sake of it.
Later, after many years, the developer sees other companies making a lot of money using their OSS project but they themselves are basically broke; they're forced to work for other companies during the day and they still need to spend nights and weekends to maintain their OSS project on the side.
I'm in this situation right now but actually I'm very happy that companies are making money on top of my OSS project; I'm 100% certain that these companies would not have used my project if it wasn't MIT open source licensed.
Most companies who used my project had alternatives in the form of other OSS projects or third party services so they put a lot of trust in me and my project at the beginning. People underestimate how hard it is to compete at the beginning... Even if you're giving away product for free; it's really hard.
Just try to launch an OSS project on GitHub and try to get it to 1000 stars; I see lots of people try all the time but almost none of them make it.
> I'm 100% certain that these companies would not have used my project if it wasn't MIT open source licensed.
Nope, instead they'd have hired you or a programmer like you — or figured out a way to make money from GPLed code.
The trouble with the MIT & BSD licenses is that they encourage corporations to freeload. That's why Google, Facebook, Amazon & Apple love them so much.
The great thing about the GPL is that it levels the playing field. We all get to share in a software commons.
In spite of the MIT license and my project having thousands of GitHub stars, it took several years before any big reputable company started actually using it.
The problem is that if tou want to make an impact in your industry, you need big companies to be using your project; to achieve this, you need to distribut your project under a license that they like.
Facebook got hate for making the patent grant skewed, i.e. you have no right to sue them for /any/ patent of yours that they use in return for not being sued for the /specific/ patents that cover React etc.
Nope. Nothing in the patent clause made any restrictions on your right to sue Facebook.
It simply made the patent grant conditional on not suing them for patent infringement. i.e. if you want Facebook to pay royalties on your patent, you would have to pay royalties on their patents. If that’s not reciprocal, what the hell is?
- If you, as the licensee, sue Facebook on /any/ of their patents (not just on the ones that are subject to the patent grant), the license terminates immediately.
- On the other hand, if Facebook, as the licensor, is only promising not to sue based on the /specific/ granted patents.
The "any" vs "specific" part is what people where annoyed about.
Note that if you required CLAs that allowed license change you can change it later (e.g. OpenText did that). If you just accepted contributions you can't change the license without agreement from all contributors.
Depends on the license. You can just fork a MIT project and incorporate it in a project with a different license. The MIT licensed part would still be MIT licensed, but any newly written code not. Makes little to l no practical difference.
I thought your comment was great, until I actually read the link. Once I read the link I’m happy to see this experimentation and evolution of licenses. As someone who builds services and develops open source code, this approach seems more appealing than GPL and seems to cover the concerns of the Redis project nicely. Time will tell how it actually works out, but I think it looks promising.
> the License does not grant to you, the right to Sell the Software. For purposes of the foregoing, “Sell” means ... a product or service whose value derives, entirely or substantially, from the functionality of the Software
> Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed
No, the value of your consulting derives from your skill and effort.
Definitely share with them any proposed wording changes that could clarify the matter. I’m sure that’s not their intent. Lawyer friends may be able to help both with interpretation and comments.
Think of this as “license r&d” rather than a rush to verdict.
> For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License 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.
If you consult for a company optimize a bunch of their redis queries, it could easily be argued that your consulting service has value that derives substantially from redis.
This licence worries me somewhat. I would definitely prefer a GPL and ask me if you want to licence it kind of situation as you definitely know where you are.
As for the consulting part, I doubt a license (short of a NDA) can restrict you from selling your expertise.
As for selling the software, there are creative ways of not distributing software technically, yet assemble proprietary and open-source bits at a customer's site such as using Docker with its layered images.
So while the intention might have merit, we have to wait if it holds up in court. My guess is it won't.
You don’t even have to go that far. This clause says the license trumps the clause, and most permissive licenses permit relicensing. So relicense without this clause. Problem solved.
It’s certainly not the intent, but I believe it’s what it actually says. Of course, IANAL and you’re an idiot if you take this ad legal advice, etc.
The comment is still generally great, except that it portrays redis labs as whiners while it looks like redis labs has put in some real effort to coniue to be as open source as possible towards the rest of the world while still trying to get some funding from the people who can afford it.
Right now, whats not to like about this for everyone of us?
That said: the parts of redis that this applies to is not open source anymore (as they admit) and I am afraid that a lot of other companies will try to abuse this to confuse users of their software.
> wearing open source's uniform without making open source's sacrifices.
Open source isn't a "sacrifice", for most people at least. Many release under permissive licences because they think there is more chance that people will use their software. They want to be popular and that makes them feel good and might get them a job. People release code under the GPL and if it becomes popular eventually benefit from patches coming back up stream. It's not supposed to be about sacrifice. It's supposed to be about being a good member of a community and sharing your work.
So rather than just blaming authors for their choices, it seems more worthwhile to look at the structural issues that lead people to make certain choices.
The Free Software movement was originally aimed mostly at personal freedom; the freedom to take something you owned and modify it. However in the intervening period it hass become integral to commercial tech. In a commoditise-your-compliments like strategy ("commoditise your dependencies", perhaps), there are now trillions of dollars of businesses that depend on open source software for their operation, but typically extract revenue from something proprietery built on top of that tech (e.g. surveillance advertising). And these companies are eager to release yet more open source software for critical (but not revenue-generating) parts of their stack. This has two key advantages for the company: it enables some of the cost of maintainance to be offloaded on the community, and anchors the cost of that component at zero. Take TensoeFlow, for example. If that's closed source then Google have to do all the work of keeping up with the state of the art, and can suffer if someone creates a superior alternative that can't be integrated into Google products. By opening it up they make it much more likely that new developments will be integrated into TensorFlow rather than into a competitor, and make it that much harder for a dirruptive competitor to usurp their position, because anyone looking to fund the development of such a competitor likely needs some revenue stream other than selling their software to finance the work, since they have to compete with free.
Now look at this from the point of view of someone developing some software. Unless you are targetting some niche market it's hard to make money through your software; by the mechanism above the expected price of such software is anchored at zero. Also many developers are aware that they have benefited from Free Software / Open Source and are keen to give something back. So creating software under an open source license makes sense; if you want your project to succeed the most valuable thing is to attract users who provide both motivation and contributions. In this way choosing a very permissive license is natural. And ususally this isn't a problem. But it does occasionally happen that projects are hugely successful, people want to continue working on them, and the funding available isn't commesurate to the amount of work that entails. In this case projects can be left struggling looking for a business model and a licensing decision that made perfect sense when the project was small can — from the point of view of securing funding — look suboptimal.
None of which is to say that Open Source (or Free Software) is a bad thing; I certainly don't believe that. But it does distort the market for software in an interesting way.
I think, BSD / MIT / Apache should be used for open source libraries, and MPL / GPL / AGPL for open source products. This way, a developer can build a new product using open source libraries without sharing its source code, but he cannot repackage an existing open source product without sharing its modifications.
The Redis protocol uses TCP connections, pretty much the perfect case for AGPL which deals with "interacting with it remotely through a computer network" etc. https://www.gnu.org/licenses/agpl.html
Sure, interpretation varies on what kind of interactions with what software cause what obligations, but imagine how much case law and clarity you can have with a license 10 years younger.
> So why aren't they simply re-licensing under AGPL? That's what I would do.
Because they want money from certain downstream commercial uses (or to block them so that they can monopolize those services), not to force people to release any modifications when they sell, e.g., hosted Redis services.
Dual licensing doesn't stop anything that AGPL doesn't stop if downstream users are fine with the AGPL. It only helps monetize those users that are not willing to pay money to get out of AGPL requirements. So, if the problem is big cloud vendors selling services around AGPL software (which it expressly is) while complying with AGPL requirements, AGPL with a proprietary alternative doesn't solve anything.
You need a license which expressly prohibits the use at issue unless a deal involving payment is made, hence, the Commons Clause.
That might make existing users/contributors motivated enough to make fork, with the code before the relicensing. If the major Redis-as-Service providers would stick with that version, it might end up being the defacto standard Redis.
This is always a possibility with FOSS, but probably way less likely with this added clause to only some modules.
One of the earliest questions asked on Open Source SE is on 'How can a project be relicensed?' [0]
Edit: further down that rabbit hole, there's a comment on a linked Programmers SE question [1]:
> What we do is have a contributor's agreement that contributors sign, and it assigns joint copyright (so both our corporation and the contributor own the code). In that way, we still have the ability to re-license, but they still have all rights that they had. This is the same way that SharpDevelop works.
This seems a sensible (or at least an open) way to allow the opportunity for future re-licensing.
Unfortunately, the truth seems to be that most people don't actually read the licenses they release their work under. You can see that a lot in the world of CMS plugins and themes (where the 'can share the work as you like') aspect of the GPL seems completely foreign to 'paid' plugin/theme developers and even with text and image based content under the Creative Commons licenses, where a site creator will often freak out about a competitor using their content despite clearly saying its under a Creative Commons license that allows reuse.
It's like they copy the idea from stuff like Wikipedia and then only later realise the implications of it. But yeah, that's why you should read the license you're planning to use and make sure it matches your intent before using it.
that's soooooo spot on. The good thing with the GPL is that it's so political that when you (carefully) read it, you understand your own motivation much better. The GPL is as much aggressive as a proprietary license, but it has different goals. Understanding it is so enlightening.
> wearing open source's uniform without making open source's sacrifices.
That’s an oddly... militaristic way of putting it. Are you sure you haven’t been watching too much Game of Thrones? Your version of open-source sounds like the Night’s Watch!
Uh, you told them they could.
> Yeah, but they're doing it without contributing back! They're just taking what I wrote and building it into a proprietary product!
You told them they could.
> But how is it fair that they can make so much money off my code and I never see a cent?
You. Told. Them. They. Could.
Time and again I see the same sense of helpless outrage from OSS devs. You owe it to yourself to understand the consequences of the license you choose, now and in the future. All the proselytising about permissive vs reciprocal licenses has only masked the important personal choices involved. Choices that you need to make honestly and carefully, or end up burned by your own expectations.
Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all? If so, your code is a gift given unconditionally, and you should choose a permissive license.
If not, the answer isn't to release it under an MIT license and then complain about it, but to pick a license that matches your intent. The GPL exists for a reason. The MPL exists for a reason. Not because the people who use reciprocal licenses hate freedom, but because their idea of freedom is based on sharing rather than giving. A gift expects nothing in return. Sharing expects that you share as well.
Any choice is a fine choice as long as it aligns with your goals. What I don't get is trying to have both and then being upset when you're rebuffed by reality. Picking a permissive license is being the chill surfer dude who lives in a van and just, like, takes life as it comes, man. Lots of people like the idea of that dude, very few people want to actually be that dude. Don't pick the BSD license because of its cool I-don't-care image. Pick it because you actually don't care, or be forced to admit publicly and embarrassingly later that you actually did all along and it was all a show.
And for the love of god, don't pick a permissive license, slap a preface on top that says "but not really tho", and act like you've found some amazing lifehack. You're just lying to yourself and everyone else; wearing open source's uniform without making open source's sacrifices.