5 ms·

> I am even more uncomfortable with the AGPL, which strikes me as a demonstration that freedom in the name of freedom is ultimately self-consuming and self-defe

> I am even more uncomfortable with the AGPL, which strikes me as a demonstration that freedom in the name of freedom is ultimately self-consuming and self-defeating I actually read the AGPL as driven by mostly pragmatic factors. It didn't even come from the FSF initially, but from a developer (Affero) who believed it fit their business strategy better than the existing licenses. One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. People who are willing to GPL their own software may incorporate your code under the GPL's terms. Other people who prefer more traditional commercial terms can, alternately, purchase a commercial license. In the webapp setting this approach no longer works, because the GPL only covers "distribution", and a webapp backend is never distributed. Therefore nobody will buy a commercial license. The AGPL more or less restores the traditional GPL terms in the webapp setting, where you have to GPL your product if you ship an app containing the GPL'd code: only now, deploying a public webapp is a form of "shipping" (which is how most software devs actually do see the situation... deploying a live webapp is a modern-day form of shipping software). And in practice, it seems the most common alternative to the AGPL in this setting is to just keep your code fully proprietary, so competitors can't build on it. I think in that sense AGPL is helpful if it encourages more releases, e.g. if it encourages more companies to take the Launchpad approach with their code (AGPL) rather than the GitHub approach to it (proprietary). The other common alternative is to release the source but under a non-OSI license like "free for noncommercial use only, commercial users must buy a license". The AGPL seems at least more generous than that.

jordigh 13y ago
> One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. He actually does like it: https://www.fsf.org/blogs/rms/selling-exceptions https://www.fsf.org/blogs/rms/selling-exceptions
- aaron-lebo 13y ago
  It isn't obvious to me why he makes this exception. He is very rigorous in many of his other beliefs (GNU/Linux, this "open vs "free" debate). If he does not agree with BSD/MIT licenses because they inevitably allow companies to limit the "freedom" of their customers, how is selling an exception any different except that the open source project is now making money? I mean an argument could be made at that point that you are selling off your principles to the highest bidder. I don't necessarily believe that, but still...
  - jordigh 13y ago
    He explains why he thinks this is a good thing: the non-copyleft licenses allow producing non-free software, and he doesn't think they're doing a bad thing by allowing this, just weaker. So if non-copyleft isn't ethically wrong, then selling exceptions isn't wrong either.
  - jasonlotito 13y ago
    I found his reasoning very clear. "Selling exceptions means that the copyright holder of the code releases it to the public under a free software license, then lets customers pay for permission to use the same code under different terms, for instance allowing its inclusion in proprietary applications." Users still have access to the same exact code. There is no loss. He goes to on further detail what you might find confusing: "We must distinguish the practice of selling exceptions from something crucially different: proprietary extensions or proprietary versions of a free program. These two activities, even if practiced simultaneously by one company, are different issues. In selling exceptions, the same code that the exception applies to is available to the general public as free software. An extension or a modified version that is only available under a proprietary license is proprietary software, pure and simple, and no better than any other proprietary software. This article is concerned with cases that involve strictly and only the sale of exceptions."
    - dragonwriter 13y ago
      > Users still have access to the same exact code. There is no loss. Sure, there's loss of what the other party builds on top of the code. While I don't think this is a real loss, the argument that it is is exactly the argument that Stallman uses against the desirability of non-copyleft licenses, so Stallman's positions on these issues seem incoherent viewed together, even if each might be viewed as reasonable enough on its own.
einhverfr 13y ago
> One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. People who are willing to GPL their own software may incorporate your code under the GPL's terms. Other people who prefer more traditional commercial terms can, alternately, purchase a commercial license. You can't effectively dual license software unless the public license has restrictions that don't serve your target market. The more restrictive the license, the more it favors dual licensing. This is actually my biggest concern with the GPL. > And in practice, it seems the most common alternative to the AGPL in this setting is to just keep your code fully proprietary, so competitors can't build on it. Efficito (of which I am a co-founder) offers hosting for a web-app based on open source software. We have few specific enhancements that don't make it upstream but those are really specific to our hosting offers (i.e. they don't provide customer-facing functionality, but provide functionality to us as hosting provider). Almost all of our work gets contributed back. The software is licensed under the GPL v2+, and the community is (I think rightly) hostile towards upgrading to the GPL v3. I don't like the AGPL. I think that once you start encumbering services, then you have added a series of restrictions which really are even unheard of in the proprietary software world. Yes, it is pragmatic, but this is the way real freedom is lost, by insisting that practice serve some notion of freedom rather than the other way around.
- _delirium 13y ago
  > I think that once you start encumbering services, then you have added a series of restrictions which really are even unheard of in the proprietary software world. In practice, the restrictions in the proprietary software world are insane compared to the AGPL, imo. There are restrictions on, to make a non-exhaustive list: 1. Commercial vs. non-commercial use. Just yesterday there was a JS chart library that got positive comments here on HN, whose terms for the free version are that you cannot make any money from sites using the charts, even indirectly (a single affiliate link on your website and it's a license violation!). 2. Number of developers. Your three-man team asked a fourth person to make some edits to the code? Now you need to upgrade your license to cover a 4-seat setup! 3. Number of deployed servers or sockets or CPUs. You're load-balancing across more than 32 cores? Now you need to negotiate an Enterprise license! 4. Number of users. You got linked on HN and got 10,000 hits today? You've exceeded the size of site that's eligible for the free license!

jordigh 13y ago

> One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. He actually does like it: https://www.fsf.org/blogs/rms/selling-exceptions https://www.fsf.org/blogs/rms/selling-exceptions

aaron-lebo 13y ago
It isn't obvious to me why he makes this exception. He is very rigorous in many of his other beliefs (GNU/Linux, this "open vs "free" debate). If he does not agree with BSD/MIT licenses because they inevitably allow companies to limit the "freedom" of their customers, how is selling an exception any different except that the open source project is now making money? I mean an argument could be made at that point that you are selling off your principles to the highest bidder. I don't necessarily believe that, but still...
- jordigh 13y ago
  He explains why he thinks this is a good thing: the non-copyleft licenses allow producing non-free software, and he doesn't think they're doing a bad thing by allowing this, just weaker. So if non-copyleft isn't ethically wrong, then selling exceptions isn't wrong either.
- jasonlotito 13y ago
  I found his reasoning very clear. "Selling exceptions means that the copyright holder of the code releases it to the public under a free software license, then lets customers pay for permission to use the same code under different terms, for instance allowing its inclusion in proprietary applications." Users still have access to the same exact code. There is no loss. He goes to on further detail what you might find confusing: "We must distinguish the practice of selling exceptions from something crucially different: proprietary extensions or proprietary versions of a free program. These two activities, even if practiced simultaneously by one company, are different issues. In selling exceptions, the same code that the exception applies to is available to the general public as free software. An extension or a modified version that is only available under a proprietary license is proprietary software, pure and simple, and no better than any other proprietary software. This article is concerned with cases that involve strictly and only the sale of exceptions."
  - dragonwriter 13y ago
    > Users still have access to the same exact code. There is no loss. Sure, there's loss of what the other party builds on top of the code. While I don't think this is a real loss, the argument that it is is exactly the argument that Stallman uses against the desirability of non-copyleft licenses, so Stallman's positions on these issues seem incoherent viewed together, even if each might be viewed as reasonable enough on its own.

einhverfr 13y ago

> One of the traditional business strategies built on the GPL, which RMS does not greatly like, but is quite possible to do, is the dual-licensed GPL/proprietary approach. People who are willing to GPL their own software may incorporate your code under the GPL's terms. Other people who prefer more traditional commercial terms can, alternately, purchase a commercial license. You can't effectively dual license software unless the public license has restrictions that don't serve your target market. The more restrictive the license, the more it favors dual licensing. This is actually my biggest concern with the GPL. > And in practice, it seems the most common alternative to the AGPL in this setting is to just keep your code fully proprietary, so competitors can't build on it. Efficito (of which I am a co-founder) offers hosting for a web-app based on open source software. We have few specific enhancements that don't make it upstream but those are really specific to our hosting offers (i.e. they don't provide customer-facing functionality, but provide functionality to us as hosting provider). Almost all of our work gets contributed back. The software is licensed under the GPL v2+, and the community is (I think rightly) hostile towards upgrading to the GPL v3. I don't like the AGPL. I think that once you start encumbering services, then you have added a series of restrictions which really are even unheard of in the proprietary software world. Yes, it is pragmatic, but this is the way real freedom is lost, by insisting that practice serve some notion of freedom rather than the other way around.

_delirium 13y ago
> I think that once you start encumbering services, then you have added a series of restrictions which really are even unheard of in the proprietary software world. In practice, the restrictions in the proprietary software world are insane compared to the AGPL, imo. There are restrictions on, to make a non-exhaustive list: 1. Commercial vs. non-commercial use. Just yesterday there was a JS chart library that got positive comments here on HN, whose terms for the free version are that you cannot make any money from sites using the charts, even indirectly (a single affiliate link on your website and it's a license violation!). 2. Number of developers. Your three-man team asked a fourth person to make some edits to the code? Now you need to upgrade your license to cover a 4-seat setup! 3. Number of deployed servers or sockets or CPUs. You're load-balancing across more than 32 cores? Now you need to negotiate an Enterprise license! 4. Number of users. You got linked on HN and got 10,000 hits today? You've exceeded the size of site that's eligible for the free license!