[1] http://blog.opalang.org/2012/05/opa-license-change-not-just-...
[2] http://www.infoworld.com/article/2611450/open-source-softwar...
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.
Sadly, I doubt the FSF will ever write such a license, given how they discourage use of even the LGPL unless absolutely necessary.
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.
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.
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 :(.)
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.
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.
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.
Is there a freeloader problem? How do we know if people just aren't that interested in the software?
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!
Regarding your "peek and return" scenario, GPL actually lets you do that, and I wouldn't consider you an actual "user".
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.
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?
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?
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.
I'm specifically thinking about sub-pixel font rendering, for which FreeType contains code which is disabled by default due to patents:
https://en.wikipedia.org/wiki/Subpixel_rendering#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.
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.
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 "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.
It would be more convincing if you gave a clear example. (that wasn't functionally an attempted end-run around software freedom.)
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.
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.
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".
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.
[1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op...
[2] https://www.joyent.com/blog/sdc-and-manta-are-now-open-sourc...
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.
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 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.
This is very demeaning and insulting. The revolution is alive and well.
Me too. :)
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 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.
[1] http://www.slideshare.net/bcantrill/corporate-open-source-an...
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?
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
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.
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?
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.
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.
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.
They don't give back code, but they do give resources.
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.
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.
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).
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.
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.
- Does your company contribute to any of the non-AGPL pieces of software it uses, either in code or money?
- Does it have propietary patches to these software that it does not contribute back?
- Has it published any open source packages of its own?
AGPL is an immediate no; GPL requires written approval from chief in house counsel and he will almost certainly say no.
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. ;)
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.