26 ms·

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 haun

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.

bcantrill 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. 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.
  - 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.
coffeemug 10y ago
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).
- insaneirish 10y ago
  > 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.
  - mrkurt 10y ago
    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".
  - openmosix 10y ago
    +1 here. We use all sort of opensource software, we encourage open source software - but AGPL software is off limits.
  - jkarneges 10y ago
    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.
jontro 10y ago
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?
- detaro 10y ago
  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. See also https://www.gnu.org/licenses/licenses.html#AGPL https://www.gnu.org/licenses/licenses.html#AGPL
  - WorldMaker 10y ago
    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.

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

coffeemug 10y ago

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

insaneirish 10y ago
> 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.
- mrkurt 10y ago
  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".
- openmosix 10y ago
  +1 here. We use all sort of opensource software, we encourage open source software - but AGPL software is off limits.
- jkarneges 10y ago
  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.

jontro 10y ago

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?

detaro 10y ago
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. See also https://www.gnu.org/licenses/licenses.html#AGPL https://www.gnu.org/licenses/licenses.html#AGPL
- WorldMaker 10y ago
  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.