10 ms·

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 t

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. [1] http://blog.opalang.org/2012/05/opa-license-change-not-just-agpl.html http://blog.opalang.org/2012/05/opa-license-change-not-just-... [2] http://www.infoworld.com/article/2611450/open-source-software/oracle-switches-berkeley-db-license.html http://www.infoworld.com/article/2611450/open-source-softwar...

ScottBurson 10y ago
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.
- ScottBurson 10y ago
  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.
  - icebraining 10y ago
    Well, be happy while your users don't discover that the (L)GPL doesn't actually require them to contribute back.
    - ScottBurson 10y ago
      Please explain?
      - icebraining 10y ago
        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.
        ScottBurson 10y ago
        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.
    - michaelmrose 10y ago
      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?
  - adambrenecki 10y ago
    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.
    - icebraining 10y ago
      Can you provide an useful case for that? I'm struggling to find an example.
      - flukus 10y ago
        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.
        icebraining 10y ago
        Isn't that the LGPL? I'm struggling to see how the network part would enter into it.
        flukus 10y ago
        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.
        icebraining 10y ago
        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.
        Thrillington 10y ago
        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.
  - webmaven 10y ago
    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.
- abecedarius 10y ago
  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.
  - justincormack 10y ago
    In this case, reviving rethinkdb, the developers will not be the rights holders, so will be unable to offer rights under a different license.
omouse 10y ago
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.
- TeMPOraL 10y ago
  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 :(.)
  - belorn 10y ago
    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.
    - falcolas 10y ago
cyphar 10y ago
> 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.
- bcantrill 10y ago
  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. [1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-open-source/ http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op... [2] https://www.joyent.com/blog/sdc-and-manta-are-now-open-source https://www.joyent.com/blog/sdc-and-manta-are-now-open-sourc...
davexunit 10y ago
The AGPL is not toxic. More anti-copyleft propaganda.
mikekchar 10y ago
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.

ScottBurson 10y ago

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.

ScottBurson 10y ago
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.
- icebraining 10y ago
  Well, be happy while your users don't discover that the (L)GPL doesn't actually require them to contribute back.
  - ScottBurson 10y ago
    Please explain?
    - icebraining 10y ago
      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.
      - ScottBurson 10y ago
        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.
  - michaelmrose 10y ago
    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?
- adambrenecki 10y ago
  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.
  - icebraining 10y ago
    Can you provide an useful case for that? I'm struggling to find an example.
    - flukus 10y ago
      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.
      - icebraining 10y ago
        Isn't that the LGPL? I'm struggling to see how the network part would enter into it.
        flukus 10y ago
        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.
        icebraining 10y ago
        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.
        Thrillington 10y ago
        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.
- webmaven 10y ago
  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.
abecedarius 10y ago
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.
- justincormack 10y ago
  In this case, reviving rethinkdb, the developers will not be the rights holders, so will be unable to offer rights under a different license.

omouse 10y ago

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.

TeMPOraL 10y ago
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 :(.)
- belorn 10y ago
  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.
  - falcolas 10y ago

cyphar 10y ago

> 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.

bcantrill 10y ago
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. [1] http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-open-source/ http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-op... [2] https://www.joyent.com/blog/sdc-and-manta-are-now-open-source https://www.joyent.com/blog/sdc-and-manta-are-now-open-sourc...

davexunit 10y ago

The AGPL is not toxic. More anti-copyleft propaganda.

mikekchar 10y ago

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.