I've been through relicensing exercises a couple of times. They're a pain, but a necessary pain because this stuff really does matter and can come back to haunt you. I might not agree with bcantrill on the "toxicity" of AGPL, but he's totally on point about the likely effect of failing to deal with the license issue. "Sitcom idea" only betrays the author's own ignorance.
My view on its toxicity comes in part from too many conversations with lawyers over the years: lawyers (like engineers, honestly) are conservative, worst-case thinkers by nature -- and with the AGPL, one needn't much imagination to get to a worst-case that threatens one's entire business. As further evidence: there are a few projects that have started as AGPL, but moved away from it as they have needed broader adoption[1] -- but there is one notable example of a project that moved to the AGPL. That project was BerkeleyDB -- which was relicensed to be AGPL by Oracle.[2] Oracle knew exactly what they were doing here: cynically using the AGPL's toxicity to drive enterprise adopters of BerkeleyDB towards a commercial license.
> My view on its toxicity comes in part from too many conversations with lawyers over the years: lawyers (like engineers, honestly) are conservative, worst-case thinkers by nature -- and with the AGPL, one needn't much imagination to get to a worst-case that threatens one's entire business.
Sure. But as an engineer, I can also think of many worst-cases that result for computer users if we commit to only using permissive licenses. In particular, there's no guarantee that a user will ever be given the source code for a product they buy. So there's suddenly a reduced ability for people to become self-taught programmers or to fix their own computers and devices. And the ultimate worst case is that we move to a fully proprietary world built on the ashes of all of these projects trying to be permissive because they "didn't care about making money".
Many new projects are designed around being networked and interacting through networked protocols. It would be facetious to claim that there isn't an issue with the current state of licenses which make no attempt to handle this situation. The AGPL attempts to do so.
And yes, I know you were never a fan of the original GPL, and that you've always been anti-AGPL. But clearly you see the benefits of copyleft because you've spent a majority of your life working on a copyleft codebase (illumos)!
> As further evidence: there are a few projects that have started as AGPL, but moved away from it as they have needed broader adoption[1]
There are also examples of projects which are not that way. Such as ownCloud and NextCloud. Interesting that you fail to mention the success stories of the AGPL. Several ISPs in Europe have started to set up NextCloud servers for their customers and thanks to the AGPL those customers can request the source for the ISPs modified version of NextCloud. That would not be possible under other licenses.
I feel that we're in a post-revolutionary phase of open source[1] -- and we no longer need the radical instruments of the GPL (and certainly not the AGPL). Yes, there are actors that consume open source, modify it in important ways and never give back (AWS: looking at you!), but in the new world of software services, no open source license (including the AGPL!) is going to coerce contributions from actors who have no intention of contributing -- licenses that attempt this simply will impede adoption of the software they cover. And indeed, I think coercion is the wrong way to think about it; rather, we must focus on encouraging contribution by lowering the barriers to adoption as much as possible. As you point out, I still do prefer the weak file-based copyleft of the MPLv2 as a compromise (which we selected for Triton and Manta[2]) -- but like any good compromise, it tends to be universally derided by the poles of the debate.
>I feel that we're in a post-revolutionary phase of open source[1] -- and we no longer need the radical instruments of the GPL
We need the GPL now more than ever. Free software is in everything, yet users are less free than ever. Almost everything users interact with on their phone is proprietary software built on permissively licensed free software. If you think the GPL is no longer needed, then user freedom was never your goal.
I used to be a big fan of prtmissive licenses until I bought a $700+ android phone a couple of years back and discovered that it did not "support" my native language (it could render the glyphs but system-wide support was not enabled).
Having extensive experience with unicode and how text is usually rendered, I knew exactly how to fix the issue; the fix was likely as simple as injecting an SO that hijacks a specific system library function. However, because the phone was locked down, I was unable to fix the problem myself. All important system apps including SMS and the browser displayed gibberish.
It was the most expensive brick I ever bought.
This experience taught me the true value of the GPL and why user freedom far outweighs the freedom of developers.
Thanks for sharing your story. I think English speaking people, particularly in first-world countries, don't realize how inaccessible a lot of software is for so many people because those people don't align with the business interests of a company.
I must stress that I do not blame developers for not catering for a language they do not speak, and I can't blame I company for not supporting a group of people if it doesn't make business sense.
I do, however, hold a grudge against a company that prevents me from fixing an issue in a product I payed for and own. More so when the fix is for a issue that renders the device useless and is incredibly easy to fix.
I disagree strongly. The only systems that are truly free are thanks to the GPL. Linux would not be as successful without the GPL. We wouldn't have free router firmware from Linksys without the GPL. The GPL works and works well.
As you say, users are less free than ever. The GPL works for what it does, but if you care about user freedom in the real world, and not only the ideas Stallman formed thirty years ago, look around. The GPL hasn't made any meaningful difference outside of developer circles.
> I feel that we're in a post-revolutionary phase of open source
It seems increasingly clear to me that this is true, albeit in the sense that the revolutionary aims of the FOSS movement (if we can genuinely lump things together) have been for the most part utterly defeated, and the handful of people who are sincerely concerned about them are now engaged in a tattered and obviously doomed rear-guard action.
Open source as an engineering approach is doing fine, of course: Its practical benefits turn out to provide a great deal of leverage for centralizing and consolidating power.
Can you elaborate please? This seems like an opinion without supporting evidence, but evidence probably exists? I just don't want to reject your argument out of hand because the health of the open source ecosystem is important.
a) open source as a technique and a body of work has become indispensable (or at least, for the moment, quite important) to a lot of industry and to the structure of the existing network that enables it. I don't think anyone very credible on the issue would seriously dispute this.
b) open source as a technique and a body of work has been instrumental in giving players like Google, Amazon, Facebook, Apple, Twitter (etc. ad infinitum) the leverage to build a service-oriented / centralized / siloed model of networked computing which is antithetical to the aims of user control and freedom expressed by the Free Software movement and a broad set of more-or-less related ideological impulses.
By some measures, the health of the open source ecosystem seems quite robust. By others, we're plainly fucked and I'm not sure what to do about it.
The idea of Open Source was, first and foremost, to allow the users of software to inspect and modify the source code. "free" in this regard has something of a political as well as an economic component. To summarise the political very broadly, I'd say that software (and the data it manages) are power, and giving broad access to both distributes that power among the users of software.
The economic aspects are not just cheap access to software, but also the benefits of increased competition result from access to the code, which allows the creation of data-compatible competitors.
These missions have failed for anyone but software developers, because so much of today's software runs on servers where the GPL does not enforce sharing of code, and because the community has become dominated by commercial players and permissive licenses like MIT. As a metaphor: the bakers are all happy because the flour and yeast are free. But bread is as expensive as ever, and most people eat in restaurants, anyway.
Since it was unclear from my comment: I consider myself an active (if entirely unimportant) participant in the movement, and the state of affairs I describe is one I'm deeply concerned by. I still see it as broadly true that we're in bad shape and losing ground fast.
Hmm, sorry for misinterpreting, but I disagree that we're in bad shape. Free software has never been more popular. I've never been able to do more with 100% free software than right now. I owe my career to free software. The threats are great, I agree, but we will keep fighting.
I'm not giving up - and I agree that both as an end user and a developer, there's plenty to appreciate right now. Still, I think there are a lot of hard, complicated thoughts to be had about the distribution of power and the direction things are headed.
> I feel that we're in a post-revolutionary phase of open source[1] -- and we no longer need the radical instruments of the GPL (and certainly not the AGPL).
I think this is the fundamental disagreement we have. I prioritise the needs of users to have software that they have the right to control and modify (which allows for "software mechanics" to fix bugs and so on).
Upstream contribution is not, and has never been, a goal of the GPL. The concept of "upstream" is a development workflow which is entirely separate to what license you use. Some people do attempt to force others to follow a workflow by using the GPL, but I think such attempts are doomed to fail in most cases. Others (such as Linux) do it by making their software move at a very fast pace to make out-of-tree maintenance hard, which actually works much better.
The GPL has always been a license for the benefit of users, not developers (though of course, developers are users too). So the focus on contribution and wide-spread use is IMO missing the point of the GPL. Yes, you get contributions (in general) from it, but that's because it just so happens that upstream contribution is one of the few viable workflows with free software. It's got nothing to do with the GPL.
I completely understand why you're prioritising contribution and creating a healthy community, but in my opinion building a community around the base of "I want this software to have a community around it so that the software works well for the community." isn't really as fulfilling as saying "I want this software to set users free from proprietary alternatives, and the community that has formed shares in these ideals." Of course, each to their own and all that.
I think this is really the core of the issue. For someone to "adopt" my software but not contribute in any way (whether that be patches, documentation, support, financial, repetitional, etc.) it's not an especially desirable outcome. I suppose there is something to be said for merely living generously (and I do license quite a bit of code that way) but as a society we have unfortunately not yet solved how to sustainably develop software projects without the sticks and carrots in the general case.
It is fair to look at whether e.g. AGPL limits adoption, but I think it is equally fair to ask if it makes sense that a software developer in a broom cupboard is donating his time to AWS, or whether AGPL allows software to be written that might otherwise not exist, or might not exist in the open.
But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?" So: do you want to grow the ecosystem around your software or not? Do you want AWS to at least create a market for people who understand your software? Do you want at least the intrinsic satisfaction that your software is being used in an important capacity, even if it doesn't mean immediate remuneration? Finally, if AWS runs your software and it becomes core to their business, there is a non-zero probability that they will contribute something tangible in the limit -- if they do not run it, there is, in fact, zero probability of such contributions. It's not dissimilar to the arguments around open sourcing otherwise proprietary software[1]: you need to get out of "what will this buy me?" and into "what does this cost me?"
> there is a non-zero probability that they will contribute something tangible in the limit
I wouldn't hold my breath for that, frankly. My experience in working for a few large companies has shown that they actively discourage contributions, since it opens the doors for lawsuits (frivolous or not), further contribution and maintenance expectations. To them, the cost is not worth the benefits.
There are, of course, the exceptions to this rule - but that's all they are, exceptions.
For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?
>For one great example, look at the plight of OpenSSL. Before it broke way open, how many companies really contributed to it? And how many just used it, not giving a second thought to using it unless there was a CVE?
So you think there were a large number of companies privately fixing bugs in OpenSSL? Or how would a less permissive license forced companies to contribute to a project they weren't actively improving?
And on your earlier points, keeping changes private likely requires more future contribution and maintenance expectations
> But here's the deal: for someone like AWS who isn't giving back, the choice is not "do they give back or don't they?" -- it's "do they run your software or someone else's?"
That assumes 1) the other software exists (GPL/AGPL has much more effect for software without viable competitors), 2) the license causes more of a problem than switching does, 3) you don't sell an alternative license that costs less than switching does.
> So: do you want to grow the ecosystem around your software or not?
In short: of course not. Or at least "not at any cost".
Open source projects do loads of things that reduce the potential ecosystem. People choose to work on projects that aren't web browsers, for example. Or they choose languages that aren't the #1 most popular. They target a platform that has less than 50% marketshare. All of those things turn away potential users in exchange for authorial convenience of some form or another.
It is a foreign concept to me to write e.g. a developer tool for a minority environment and then all of a sudden worry about the license being some major barrier.
But more broadly your position is very strange to me in its wider implications. Let us say that some voice actor could donate some spare reel to Disney. Or that some author could donate a manuscript to Penguin. Or that some musician could donate their track to Sony. Do you believe they should do so, under the theory that this in some way "grows the ecosystem" for their work?
How much is that "market for people who understand your software" worth? Sometimes those people are your competitors, using your own code plus local improvements (or "improvements") to sell against you. It's not as simple as saying you'll always win or you'll always lose. There are both opportunities and risks, which have to be weighed on a case by case basis. I've seen my own code sold against me too many times to believe permissive licensing is always the right answer.
I like thinking of GPL and AGPL as licenses that solve the freeloader problem. Corporations and their employees love to lower their costs and externalize their costs; therefore they use MIT/BSD/Apache licensed code as much as possible and rely on what is essentially free labour to maintain that code; they rarely if ever donate.
Not defending our evil corporate overlords, but from a little inside experience, it's not just about saving money on some code. It's often about the whole business strategy, with a healthy dose of CYA - the "toxicity" of GPL and AGPL restricts what they can do with a product, in a way that can make it unviable, or that would require a legal team to sort things out.
For instance, company I work in develops software for a customer that later sells it to various corporations, big and small. Were I to include an GPL dependency in the code, and were it to pass unnoticed by my boss and our customer, it could quickly turn out into a legal clusterfuck with damages orders of magnitude larger than my salary. So we do have a list of open source licenses that are allowed for dependencies of projects for our customer, and GPL/AGPL are prominently not on that list.
Now if there was some critical piece of code we absolutely need and there's no non-GPL alternative, I could ask my boss to talk to his boss to talk to the lawyers to figure something out. But in 99% of cases, you'll be asked to "Google harder", and then you'll find something with a "better" OS license - so it's easiest for the management to ban GPL by default (or, in our case, create a whitelist of allowed licenses).
(I desperately tried to get WTFPL on the whitelist list, but failed :(.)
This seems pointless to me. If you sell someone a piece of software with a GPL dependency, what is the risk to the customer? They're just going to use the software, right? That's explicitly allowed by the GPL. Are they really going to modify it? Can they even modify it?
Even if it was AGPL... and even if the customer modified the library, and even if they did get sued.... all three of which are vanishingly small probabilities... still all you'd have to do is release your modifications to the AGPL library. The notion that the AGPL will force you to open source your proprietary code is, as far as I can tell, completely spurious.
I really think that it's just a cultural "screw the hippies" kind of a thing, which you're buying into by making these sound like rational fears. There's nothing rational about it, it's just "oh my, we'd need just thousands of lawyers for that!" bogeymen.
Can you sneak in proprietary dependency in the code, making your customers pirates of some third companys product?
It sound to me that the only code allowed in the product is code you have written yourself, code you have hired someone to make so its yours, code you bought so its yours, or code which license make it indistinguishable from code you own.
Frequently, companies which make use of open source code will do scans, and identify (and immediately remove) such code.
It's a common occurrence in my experience in companies over 1k or so employees. Under 1k, getting hit with the GPL would probably just be a death knell.
> therefore they use MIT/BSD/Apache licensed code as much as possible and rely on what is essentially free labour to maintain that code; they rarely if ever donate.
Lots of permissively licensed software exists that is mainly corporate contributed code, or which is produced by projects which are primarily corporate funded (by corporations which use the code.)
You can't get free maintenance on your code by using permissively licensed open source if what you use diverges to far from what your free labor force has, after all.
It's fine if big companies or whomever want to use open source software without contributing back to it. There's no such thing as a freeloader in this context, the code is freely given so that people can freely use it with no quid pro quo other than respecting the code's license and copyright. If there was an expectation that someone using open source code give back (whether anyone wants their contributions or not), then that wouldn't be open source any more. I mean, it's great when users do contribute back, but there's no expectation of that, hence no concept of freeloaders. Heck, maybe you have a company that makes billions of dollars off of open source and never contributes back a single thing, ever. That's fine, if it were any other way then it wouldn't be open source- it would be just some weird variant of proprietary software where you're expected to send patches instead of license fees. When someone works on open source software (whether it's GPL, or something more simple and permissive), they shouldn't be doing it with an expectation that anyone else owes them anything. They will be very disappointed very quickly.
The purpose of the GPL is not to have developers give back to their upstreams, it's to give users freedom. To swing the balance of power in the user's favor rather than the developer's. Either the user controls the software, or the software controls the user.
> it would be just some weird variant of proprietary software where you're expected to send patches instead of license fees.
Why is this weird? As the author of the software, surely I get to decide how I prefer to be compensated?
If I'd like patches and user freedom, then your only decision is whether the software is worth that for you. Not whether my license is "weird" or "not open source".
I feel like MPL2 does that just as well, but by adding a file-level firewall ensures that it will gain adoption among people/organizations who need to be able to distribute it in a binary along with other code that has another license.
This way people still add features and upstream bugfixes, but a) it doesn't get forked to hell like the 200 Linux kernels that each Android manufacturer has to publish and b) you get much wider adoption faster, with more people being paid to fix bugs and add features to your code because it is being used alongside proprietary code.
Sure, it doesn't give you a nice stick-it-to-the-corporations dose of righteous satisfaction, but it feels to me far more pragmatic, and healthy for the project in the long run.
Copyleft addresses the freeloader problem, true - but GPL goes on to grab patent rights - that's what usually prevents corporate use. Sadly, you aren't the only one whom confuses copyleft with GPL; which has (unnecessarily) badly tainted the idea of copyleft, itself. GPL deserves its terrible reputation, copyleft doesn't. But someone (cough, cough) over-reached.
I'm curious how you believe the GPL has overstepped regarding patents in the context of a copyleft license.
GPLv2 says very little directly about patents, only touching on the topic by saying that they're not an excuse for not complying. That implies some things for patent holders on relevant topics but isn't explicit about it.
GPLv3 basically makes those implications explicit, stating clearly that if you hold or license any relevant patents you must be able to freely license them downstream.
To me that stuff is implied with copyleft, because how else could it work? Since patents restrict my ability to legally redistribute the code, and the whole point of copyleft is to ensure my ability to legally redistribute the code, I don't see how they're separable as long as software patents remain being a thing.
"To me that stuff is implied with copyleft, because how else could it work?"
The "copy" in Copyleft gives you your answer - it ought to be about sharing copyrights to code, not patents. You don't have to grab patents (which expire in twenty years.) Copypatentleft is what we really have, instead, with GPL, and that's a whole different beast.
So, it is of course logically possible to confer the copyright to code that exploits a patented idea without conferring the patent rights at the same time. That would mean that not everyone could use some shared code, without a license, even though they have a copyright license and can share and examine it. The patent holder would retain their patent rights. Why respect patent rights? Because the majority of value in American businesses is IP - trade secrets and patents being the bulk of that. GPL is therefore a non-starter in the corporate world, more often that not. You don't have to share patents. If you insist, then your code gets duplicated under another "more permissive" open software license at enormous expense, that's all.
If you want my work on your community code, great! If you want my ideas - my patented ideas, um, no.
Does it restrict your capability to distribute the code? Or the user's capability to run the code unless they have properly licensed the patent contained therein?
I'm specifically thinking about sub-pixel font rendering, for which FreeType contains code which is disabled by default due to patents:
That would imply that it's the latter. Which, of course, is still an issue for the user. But it does point to the GPL not requiring the patent clause in order to meet its copyleft goals.
Interesting angle. I'd say the courts haven't ruled on this.
FreeType wasn't created by Microsoft, obviously. It has no license for M's patented tech so it can't include the code live, period. I presume that FreeType is trying to skirt the law by making it easy for users to break the law without, they hope, being seen as breaking the law themselves. I don't know what the court would decide if Microsoft sued. Presumably FreeType would say that the code was there just to help future programmers catch up when the patent expires. I'm guessing they wouldn't win that one.
So, I'm going to say it's not a sufficient example.
"Downstream" means everybody, of course, forever. You've just lost your patented tech, so if you don't want to sell it outright, you can't touch anything GPL. Given how complex technologies are, now, that severely limits where GPL2 and 3 can be used.
So you might ask, why does Google use the Linux kernel? Perhaps because they don't have to modify the kernel to accommodate inventions they wish to preserve, for public software such as Android; but more importantly the kernel is useless by itself and the license doesn't extend to libraries (Google spent billions recreating the GNU libraries to be sure of that), so the license for the kernel has no practical importance. The rights granted are "stranded", as it were. Clever on the part of Google. But in most cases, the GPL or MPL can't be gotten around in that manner.
The googleable rubric for GPL2 is "GPL's Implied Patent Grant." In sum, the GPL seizes all relevant patent rights from any contributor (regardless of whether those contributions related to their patents, IIRC) and any distributor. In some cases that doesn't matter - in other cases, it does. If you want to retain control of who gets to use your patents, and patented tech, that's a big problem. If your invention is a hardware invention, the GPL still scoops it up - their language doesn't exclude rights to hardware inventions - so you may actually have the right to build any such patented hardware as long as you put Linux in it: if the patent owner touched Linux. It would take a court case to be certain this wasn't a risk.
This also seems to mean (even for GPL2) that if you explicitly license one entity to use GPLed software with your patented tech (hardware or software), then you've just given a free license to every soul on earth to do the same, with no royalties. In some cases, that might not matter. In many other cases, it does.
"In contrast, a GPLv2 licensee, under the doctrine of implied patent license, is free to practice any patent claims held by the licensor that cover “reasonably contemplated uses” of the GPL’d code, which may very well include creation and distribution of modified works since the GPL’s terms, under which the patented code is distributed, expressly permits such activity.
Further supporting this result is the Federal Circuit’s pronouncement that the recipient of a patented article has, not only an implied license to make, use, and sell the article, but also an implied patent license to repair the article to enable it to function properly, Bottom Line Mgmt., Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the Federal Circuit extended that rule to include any future recipients of the patented article, not just the direct recipient from the distributor. This theory comports well with the idea of Free Software, whereby software is distributed among many entities within the community for the purpose of constant evolution and improvement. In this way, the law of implied patent license used by the GPLv2 ensures that the community mutually benefits from the licensing of patents to any single community member."
The GPL does not have a terrible reputation. It does, however, have a vocal group of a corporate sponsored detractors that are trying to destroy it. Lots and lots of people are thankful for the GPL, myself included.
Speaking as a long-time contributor to and maintainer of permissive/BSD software: the thing about the GPL family which drives me away is partly philosophical disagreement, but mostly uncertainty. You can if you like say this is just the "U" in "FUD", but there's truth here.
For example: the FSF's stance on certain provisions of the GPL, like the ones on linking, is as far as I know completely untested in court and at odds with what appear to be both established legal and common-sense/intuitive notions of what constitutes a derivative work. And I'm not speaking from inexperience there: the Django project had to go many rounds on this because the maintained MySQL driver modules for Python are all GPL. Does this end up GPL'ing Django since it supports MySQL as an option and, thanks to the nature of Python's import system, will share address space with a GPL'd module if you use MySQL as your database? Or does the fact that it's an end-user choice and Django is simply shipping code to normalize API access to any of multiple drivers on multiple DB engines (leaning heavily on PEP 249, which itself is a normalized API for Python DB drivers to expose) avoid that? Nobody seems to be able to give a clear answer, because there is no clear answer, legally, on when the GPL's derivative-works clause is invoked or even if the GPL's derivative-works clause is legally sensible.
The linking aspect is only a line in the sand where fsf will enforce the license, and is not part of the license text. To my knowledge it comes from the idea that binaries with linked libraries will generally not work without those libraries and that that dependency is a strong indicator that we are dealing with a single work rather than multiple independent and separate works.
In contrast to uncertainty, I think we can be quite certain that django works without mysql (I personally run several sites with postgresql). Modules for django would likely not work without django, so they are likely derivative of django and not the other way around. I also vaguely recall fsf stating that they don't consider the linking guidelines to be that relevant for software written in languages without linking, which would include python programs.
Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software?
Is your problem with the license that FSF as an organization has an opinion on how derivate works can be identified for software?
My problem is that the FSF's opinion on what constitutes a derivative work is horribly broad, and has never to my knowledge been tested in court. So despite all the reasonable intuitive opinions in the world, who knows?
Yes, there is a freeloader problem - the vast majority of corporations using Linux get real business value but give back zero. But if you scare away the majority of businesses with your license, you haven't solved that freeloader problem.
How is that a problem? I take a book out of the library. (That institution is both about free as in speech and free as in beer.) If I become a huge fan, then I might buy the book for myself and start dressing up like the characters at conventions. If I'm not that into it, I return the book.
If one puts something out there for "free" then one is not entitled to a return. It's the model which is broken, not the users!
I was answering the second question, not whether free loading is an actual problem. The answer to that is of course up to the original author, who is entitled to use any license they like.
Regarding your "peek and return" scenario, GPL actually lets you do that, and I wouldn't consider you an actual "user".
But it's not about software patents - GPL makes absolutely no distinction between software and hardware patents, it wants them both! If they didn't grab hardware patent licenses (or licenses to mixed hardware/software inventions) that would be an entirely different worldview. I'd very much welcome that change.
It would mean anyone willing to use that software can use your hardware invention without paying you. No thanks. You can dispute this I suppose because the wording of the license is awful and far too terse, and hasn't been tested in court - but for businesses, that IS the risk, and therefore the problem.
I actually completely disagree with you on the toxicity issue, but WRT to rethinkDB I don't think you are wrong. AGPL + Apache drivers is unlikely to be a successful combination if you are going with opencore. If you want to use (A)GPL, I think that's fantastic, but I think you need to make a pure free software play.
While I differ with you on the choice of pejorative descriptions, one really has to study projects like Ghostscript to see what the problem is with GPL and open core. The GPL is actually used to restrict freedom rather than promote it because the non-free side of the project is a free rider on the free side.
What happens is that nobody contributes in such an unbalanced situation. As a business you have to maintain a product where many people are using it for free, but nobody is encouraged to hand you contributions for nothing. If you want to use (A)GPL in your product, you need a business plan that ensures freedom for your users, so that they are encouraged to join you.
If you want open-core (as rethinkDB apparently does) then you need a license that levels the playing field so that other non-free-software entities are willing to collaborate with you. Non-permissive free software licenses effectively block those contributions and so you are left with a lose-lose situation. Of course, if you are motivated by software freedom, you really don't care about this... but then you wouldn't be doing open-core.
As a disinterested observer -- I haven't used RethinkDB and have no stake in it -- I think you're probably right. I am familiar with my BigCo's approval process for open source components used in our products, and I know that the AGPL is a non-starter.
I should have added: the LGPL is fine; we use lots of LGPL components. The LGPL tends to be my choice for my personal projects as well. I think it strikes a good balance, allowing use in products, but requiring users who improve the component itself to contribute those changes back.
I kind of wish there was a ALGPL; a license that works like the AGPL in terms of access over a network being considered use, but could be used unmodified as a library in non-GPL-compatible software like LGPL libraries can.
Sadly, I doubt the FSF will ever write such a license, given how they discourage use of even the LGPL unless absolutely necessary.
The use case is when you want any and all modifications to be contributed back but not force anyone using the library to open source whatever is using it.
The GPLs (excepting AGPL) only require release of source code if it is distributed outside the company/person modifying it. It comes from a pre-networked time when most software required distribution to be useful.
Setting up a web service with GPL code doesn't meet the bar for distribution, so that situation does not require the code to be made available. That's what the AGPL addresses, network use triggers the requirement to make the code available.
If the make a modified version and use it in a web app then they are under no obligation to release the changes with the lgpl but with agpl the would be.
So if you used a library in a webapp, you'd have to release the changes to that library to your users, but not the rest of the app? Ok, that makes sense.
Couldn't they just publicly ask any customer to privately provide them with a copy? Failing that couldn't upstream as easily purchase a single license?
The GPL licenses are purely pay-it-forward. They only have to provide a copy to their users.
For example, the vast majority of the code I write is AGPL-licensed (derived from an AGPL licensed work by a third-party), yet you won't find a copy of it on the Internet. That's because we only have to provide that source to our customers, and while it's fully within their rights, they have no inclination to share it with anyone.
Oh, good point. I guess I've always conflated making the source available to one's customers with contributing it back, but you're right, these are not necessarily the same thing.
Just as the LGPL use-case can be covered with the GPL + an exception (and many other related use-cases like plugins need exceptions anyway), the use-case of a hypothetical ALGPL can be covered with the AGPL + an exception.
Why wouldn't BigCo offer to buy rights under a different license? I'm an outsider to this kind of deal, but it seems to me like a good way for both parties to get something they want -- open source projects being often short of funding.
The obvious case where that wouldn't work is a project like Linux with many contributors and no copyright assignment. But others like Clojure organize themselves differently.
I think AGPL introduces some measurable adoption friction, but it certainly isn't toxic. Licensing in general obviously matters, and my view is in this case AGPL would be suboptimal but fine.
In any case, I think it's important to move past these issues ASAP in a way that unites the community, and move forward with the project. RethinkDB may not have been successful as a business, but it seems very promising to me as an open-source project. I'm very excited to see it bloom in its new life (and will try to contribute myself if/when time permits).
> I think AGPL introduces some measurable adoption friction
I agree, not just in principle but because I've seen it happen. Where we might disagree is that I don't assume that's a bad thing. Who are the people/companies who will reject something because of AGPL? Would they have contributed under a different license? Overwhelmingly no. Whatever changes they made, if any, wouldn't have been available to the project anyway. If they want to pay for the software, or support etc., then they'd probably do so even if it's completely proprietary. For them there's dual licensing.
Anyone who might have wanted to contribute still has a way to do so. Ditto for anyone who might have wanted to pay. So, who's left? Those who might use but neither contribute nor pay. Are such users a net positive? They're good for the ego, but the support load associated with such users can kill a resource-constrained project. I've seen that happen too. Keeping them away might not be a bad thing. Maybe AGPL is "toxic" in the same way that chlorine is, keeping the pool clean without harming the swimmers. And yes, some people are extra-sensitive to either. ;)
> I think AGPL introduces some measurable adoption friction, but it certainly isn't toxic.
Let me first say that I respect you and RethinkDB immensely.
Rather than comment on toxicity, I'll state a fact: in the company I work for, which makes heavy use of open source software, is relatively sophisticated, and is legally cautious and conservative, AGPL software is verboten. It's a non-starter. Do not pass go. Do not collect $200.
So, in the absence of a company that can actually offer a valid license to the product, there's no chance of considering it, let alone using it. This may seem overly cautious and FUD inducing, but it is how things work in our litigious world.
I think your company is already in the minority, honestly. IBM is big and stodgy, but they got past the agpl, as have their customers that I had any contact with. agpl + Apache drivers seems perfectly workable to me ... though I agree with you, and also Slava's take of "suboptimal".
My example does. They contribute pretty heavily to apache licensed software and have a small but popular in the right niche high performance filesystem that they built.
AGPL is an immediate no; GPL requires written approval from chief in house counsel and he will almost certainly say no.
I think he means that even though the license is unsuitable for some users, it is fine for others. Probably most users are fine with the license actually, otherwise RethinkDB wouldn't be as popular as it is. After all, RethinkDB has been AGPL for years.
It is unfortunate that some users, such as yourself, must be left out, with no apparent remedy. But this does not mean RethinkDB cannot succeed elsewhere.
As I have understood it the AGPL forces you to have any code that uses the software to be open sourced.
Even though the drivers are of a different license it doesn't matter right?
AFAIK: No, the "infection" rules are like those of GPL (modifications of the code, or code that links to it), the difference is in with whom you have to share the source code. With the GPL, you only have to share it with those that you give a copy of the software -> if you run it on your servers only, you don't have to give out any source. The Affero GPL modifies this to cover this exact scenario: everyone using the software directly or over a network connection now has a right to the source code. The license does not "jump" over the network connection to the code of applications connecting to it.
The problem, and a reason why AGPL almost has to be considered toxic to date, is that we don't know whether or not the "infection" rules "jump" over the network connection. A big reason for this is that the AGPL hasn't yet been tested in a court of law. As a developer you don't want to have to explain to a jury of "peers" than may be less than technical how or why your software should not be "infected".
There are so many gray areas. Does a SPA JS application communicating with a REST API of an AGPL application count as "linked"? We don't know. To a jury that sure might look like the same application. Say that it does, does something then like a AWS Lambda "serverless" pipeline that utilizes that same REST API count as linked? We don't know. Maybe, maybe that counts as "mere aggregation" and at this point for the GPL there's a sort of well understood DMZ around that weasel term, because there have been enough "mere aggregation" situations over a couple decades, some of which were even litigated in a court of law, to sort of set up some fences of what that possibly means. For the AGPL no such DMZ has been established, at least not in a well-understood, applicable to every use of the license, manner.
The way the AGPL is directly written, in order to be as infectious as possible, as an intentional goal of its writing, we as a developer community have absolutely no idea how far the infection rabbit hole goes. The concern that the AGPL is toxic is as much the fear that we can't explain that infection rabbit hole to a jury in a court of law. We mostly know this because as developers a lot of us have already had a very hard time even explaining this rabbit hole to software company lawyers that may even be technically versed on both sides of the fence.
> It's a hundred times easier to solve any potential IP problems for a successful project
Tell that to the original author of libevhtp, who is currently homeless. To paraphrase him, "the ideals behind BSD are great until someone derives massive profits from your work and doesn't share."
Yes, there are other issues contributing to his being homeless; my point is that putting careful thought into your licensing is important, if only because you can't always change it later. Being clear on IP ownership is also quite important, especially with the threat of someone with an army of lawyers landing on your doorstep.
The original author of libevent --- if we're talking about the C library that provides a common event interface between select, poll, epoll, &c --- is Niels Provos. Niels is definitely not homeless; he works at Google and spends his weekends making Wootz steel and forging swords from it.
The person you're talking about is the author of libevhtp, a small HTTP library built on top of libevent. Apparently, Chromium uses or at some point used libevhtp.
It replaces one feature of libevent, is built on top of libevent, has fewer users than libevent, and is substantially smaller in code size than libevent. That's all I meant to communicate by the word "small".
Sure, there are smaller and larger libraries. The fact that the author of the smaller library is homeless doesn't make it less tragic. I mean the pathos of the OP still holds even if the named person (and number of lines of code) is different.
I hadn't even heard of libevhtp before it was brought up as a failure of the open source model. But I'll bet a pretty big chunk of readers know what libevent is. That's not a minor mixup. All I'm interested in is correcting it, and now that I have, I'm not not interested in litigating any of the rest of this.
I'm not surprised. He seems quite smart and engaged with the project. But he became a maintainer in 2015; the project itself goes back to something like 2002.
That is a reason to use the AGPL when working on free software. Using a BSD license gives you (the creator) zero protection from bad commercial actors who want to use the software without contributing back. The AGPL is not the right choice for every project but I do believe it is a good choice for software which can be trivially setup as a service. For instance, an open source web application, an open source database, an open source irc server, etc... I think Linus did the right thing going with the GPL for Linux and sticking with version 2.
Protection from what? Most people release their open-source work in the "just do whatever the f you want" spirit. If there is a commercial opportunity you can always re-license / offer paid support.
Protection from someone monitizing your work before you can monetize on it. If they get a copy of the code released under the BSD license, no amount of re-licensing will help get a penny.
In fact, many people will simply re-host re-licensed work, in an effort to keep the "free" version available.
> Tell that to the original author of libevent, who is currently homeless.
Can you cite your sources for this claim? I checked the Wikipedia article for Libevent[0]. The original author, Niels Provos, appears to work for Google[1].
Or the hundreds of other licenses out there from the dozens of creative commons to Apache, Python, and more.
How would a different license (say, AGPL) have helped? He could have gotten paid for his work via a dual license. Putting code out there under a BSD style license effectively eliminates that option from the table; what corporation is going to pay for something that's legally and morally free?
If this had been GPL or AGPL, even dual licensed, it wouldn't have been included in a BSD-style licensed product like Chromium. And Google or any entity behind such a product probably would have written something similar themselves. There is a nonzero chance that they would have acquihired Libevthtp Inc. to get his expertise and IP and allow them to relicense as whatever they wanted... but that's a small chance indeed. So there were really no paying customers, and the market clearing price for a copyleft libevhtp is effectively $0.
Like a startup, writing open source requires that you find customers (or employers) who will pay, or you do it as a passion project. In an ideal world people would have basic income and could write open source all day long, but that's not our world.
Well, there were no customers who would pay the original author. Chromium still required developers to incorporate and maintain the library. Money was spent on the library, it's just that none of that money was given back to the original developer.
> or you do it as a passion project
Doing a "passion project" doesn't mean that you need to give everything away. If there's the chance my passion project could make money, why deprive myself of that chance before I even begin?
Lots of passion projects licensed GPL which make money; and lots of passion projects licensed BSD which don't have a single user.
He's extremely right. I like RethinkDB, but it's not going to fail because of accidental success attracting parasitic litigious organisms in the post-corporate open-source phase. It's going to fail because the only people who know the code well enough to work on it aren't working on it anymore.
I like RethinkDB a lot, but A) I have no time to contribute and B) my ability to use and enjoy databases does not automatically confer the ability to write them. I think most people who liked RethinkDB are in a similar boat to me. I'd love to see this project take off. But I didn't have money or time for it before and I still don't. I don't have those things for Postgres either but it doesn't seem to need them as direly.
If code would be Apache licensed, I personally would consider to start new company around it. Maybe it would not 'scale', but it would be enough to pay my bills.
> I like RethinkDB, but it's not going to fail because of accidental success attracting parasitic litigious organisms in the post-corporate open-source phase
Legal risk is basically a tax -- it is a cost that is born by the end-user but which does not go to the supplier. A selective tax on one product as opposed to alternatives absolutely can kill it.
You could die of a meteorite landing on your head, but you won't. You're probably going to die of a car crash, heart disease, stroke or cancer.
Open-RethinkDB is not going to fail because of AGPL, IP issues or litigation. It's going fail because of lack of users, developers, and growth. And that's sad. But it isn't going to fail for political or legal reasons.
> Open-RethinkDB is not going to fail because of AGPL, IP issues or litigation. It's going fail because of lack of users, developers, and growth.
AGPL (which is an IP issue and is a source of perceived risk of litigation) is a contributor to lack of users, which is a contributor to lack of developers.
You are treating deeply linked issues as if they were orthogonal.
No, I'm saying that what you're preoccupied with is not ultimately the biggest problem. And I don't think they are as deeply linked as you do.
That's fine though; ultimately, you will be able to blame RethinkDB's death on this non-problem and you'll have a clean conscience. It's easier to point to this as the cause of death than the much harder problem of getting people interested in the product in the state it's currently in. I think this is like blaming a cancer death on a lack of handwashing. Sure, washing your hands is important. But it won't cure cancer.
> No, I'm saying that what you're preoccupied with is not ultimately the biggest problem.
Stating a specific reason to doubt the dismissal of it as a serious and potentially fatal concern is neither preoocupation nor stating a belief that it is "the biggest" problem.
> Sure, washing your hands is important. But it won't cure cancer
Which is not to say failing that kind for basic hygiene doesn't make you more likely to die sooner with a cancer that has already left you immunocompromised -- more dangerous in that condition than for the average healthy person.
Which is pretty much a perfect analogy for where I think the licensing issue fits into the space of problems facing RethinkDB.
There's nothing theoretical about the billions that have already been spent (wasted) replacing GPL projects with code with a more permissive license - namely one that actually permits companies to keep their patents, among other things. Think about Chromium (which is not derived from webkit, that had to be replaced by Blink) and Android (replacing the GNU libraries and making them redundant. Total waste, caused by a license that over-reaches. Not everyone wants to abandon the idea of having patents.
The billions that have already been wasted on software patent could be used to pay developers making better software rather than reinventing around patents. That some handful companies decides to re-implement existing software just so they can go after developers with patents is a waste, one that most companies can't afford nor would it be good if they could. A total waste, caused by law that over-reaches with no legal or conclusive definition (According to the European Patent Office).
Software is protected as works of literature under the Berne Convention, yet a work of literature is not patentable. We don't patent underlying methodologies of writing a story. We don't have hundred of patent with slight different wording of the concept of "hero and villain", nor trolls trying to sue every time someone writes a successful book. We don't have patents of "every day concept, but this time its a book". That would be a total waste, caused by over-reaching lobbyists that get to write their own laws if they just spend enough money on the winning candidate.
> Not everyone wants to abandon the idea of having patents.
That is fine, but then replacing GNU libraries is not waste, but investment. The authors of GNU libraries give their work for free, and would also like to be able to use other people's (potentially patentable) work in return.
Not everyone wants to abandon the idea of having patents.
That's funny. How much waste has there been due to people having to work around patents? Is waste only a problem if nobody can profit from it?
Yes, one can avoid that by paying the price of the patent; but the same is true with the GPL, you can follow the license. It's just a price in another kind. The waste resulting from not wanting to pay it applies to both cases.
Actually, a lot of nice discoveries started with someone who had to get around a patent. But yes, the free market involves waste - just not anything like as much waste as either not encouraging innovation, or keeping everything as trade secrets that can create monopolies for centuries (see the history of the forceps) resulting in uncounted deaths - plus trade secrets can be lost.
Open source wasn't originally about creating waste and duplication. Let's not do that; since the bonus of encouraging innovation with financial reward doesn't happen, just the waste.
The GPL hobbling software patents sounds like a massive plus, and anyone who considers it not a massive plus to be the sort of people the GPL was explicitly designed to protect against.
For one more time, it's NOT just software patents. Plus you forgot the "IF" at the start of your sentence. Has it really discouraged software patents? No, patents (of both kinds) have sidelined GPL. As stated above the license given to the Linux kernel is "stranded" and therefore harmless, a special case.
Give me a clear example of the GPL affecting a hardware patent. (Where the hardware patent isn't really obviously an attempted end run around the GPL.) C'mon, something convincing.
All the patent ills you're attributing to the GPL apply to the Apache License too, btw. AL2 is where GPL3 took its cue on patents.
Are you actually blaming gpl project creators for the waste created by others who didn't want to abide by the gpl? Isn't that a little backwards? Either you ought to acknowledge that everyone has a right to do their own thing or you ought to blame the other parties for the waste.
The license rendered the product useless to businesses. If you think that's fine 'cause the revolution's imminent anyway, and patents will be put in history's dustbin, great. But the tragedy was easily avoided, with a license that didn't grab patents.
Less and less use. But the waste is that the whole effort had to be duplicated, and was. That's very real time and very real money. Don't pretend to be green if you think that's fine, no matter how avoidable.
For those of us who don't follow RethinkDB story: I was initially confused about this - they're talking about "open-rethinkdb", even though RethinkDB itself is open source.
It seems that the company between RethinkDB is shutting down, but trying to let the project be continued by the community. Some context I found here: https://rethinkdb.com/blog/rethinkdb-shutdown/.
This is simply untrue, and bad advice to anyone thinking of using the product in a way that's inconsistent with the license. Is the author actually suggesting people should do that?
Seems fairly straightforward to me. The more viral nature of AGPL is limiting their options for stewardship.
One way of getting around that is to be the owner of the original IP, whereby you could relicense it under something that wouldn't limit stewardship options. It seems that's not a possibility, because:
"One of the creditors owns the IP and IMO they're unlikely to sell it unless the project raises fairly substantial sums of money"
So, basically, they will have to sort out stewardship with fewer options than what would be optimal.
There seems to be a "far left" and "far right" view on the thread. The "far left" is that the issues above somehow don't matter at all. The "far right" view is that they are showstoppers for any kind of stewardship solution.
It's not clear. Supposedly yes as long as it's a separate component (like using RethinkDB from another process), but not if it's linked into the same executable. Then again, some people disagree with the FSF on that regarding, saying that simply linking isn't enough to make it a derived work.
I'm not sure any of this has been well tested in court.
Look, Slava and Mike are incredible guys and ridiculously smart. If Slava thinks "I wouldn't spend a dime of that money on IP" then you should do that for two reasons:
1) He's the original founder and should be respected out of courtesy.
2) He just gave you an amazing opportunity to not worry, so take it.
I explore more of my thoughts on Open Source license and the post-mortem on this just-released The Change Log podcast episode - https://changelog.com/podcast .
One of the things that we are doing is making sure to always license our code as MIT or ZLIB or Apache 2. This is a promise (and a legal one too) to developers that the ideals and values of Open Source will always be there, first and foremost. In fact, the license was determined by a community vote (see here: https://github.com/amark/gun/issues/17 ).
People have asked why others (like us) won't shut down in the same way Parse and Rethink have, I think the answer is simple:
5 billion new people are coming online by 2020 and the technical challenges of creating scalable systems still exists. So the opportunity is enormous and proportional to how scalable your system can be - which means decentralized tools will win out over time compared to their centralized alternatives.
Second, unlike attempts to sell support licenses or DBaaS or crippleware premium upgrades, we're taking the approach of partnering with developers/companies that build industry transformational product and solutions for governments and enterprises. We believe that if we can enable others to be able to create answers for the needs of large organizations, then we both can mutually benefit by creating revenue shared partnerships. This is already happening with several companies, and we're rolling out to a government (but I can't disclose who/what/how yet).
We think this will work, and it will pave the pathway for other Open Source vendors that a real business model can work, without any of the unfortunate alternatives strategies others have taken (open core crippleware, unlikely support licenses, struggling DBaaS). This creates the best "win-win-win" environment, where startups get to piggy back for free while governments and enterprises pay for the much needed technology solutions to handle the coming transformation.
What transformation am I talking about? Again, the 5B new people, the advent of IoT and every autonomous car or burrito delivery drone, and the demand for doing machine learning on the whole system, at a global scale - see this article on distributed machine learning with gun: http://myrighttocode.org/blog/artificial%20intelligence/part... .
This transformation won't succeed unless it can be built on top of truly Open technology, and that is why license is important.
>then you should do that for two reasons:
>1) He's the original founder and should be respected out of courtesy.
>2) He just gave you an amazing opportunity to not worry, so take it.
I don't have anything against the AGPL, but it seems like you're just saying "The AGPL isn't a problem because RethinkDB's founders are nice smart people". And then you explain how it's a great thing that a project yours is using a less-restrictive license like the AGPL critics are hoping for.
Yes, I know that sounds contradictory, but it is still true. While it is ideal to have MIT/ZLIB/Apache2, that isn't a reality (and now confirmed, with Slava's comment) that is going to happen.
Initially, that might be scary, but Slava /also/ said people shouldn't spend a dime on it or distract from the amazing momentum of carrying RethinkDB forward (RethinkDB fits certain solutions that GUN isn't optimal for, so it still has an important niche and place).
You guys are here to do this as a community, for the benefit of all. If you are afraid the IP owners (when they said they won't) will capitalize on your success after the community has overcome the challenge... then the intent and motive is in the wrong place, and that isn't conducive to anybody.
Worse case scenario: So what if they do? The community won't be forgotten, everybody would still win. Losing momentum is far more dangerous.
