3 ms·

> 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/proprietar

> 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!
- einhverfr 13y ago
  In terms of developer tools you are right, but in terms of redistributable libraries that come with those? I don't agree with you there.
  - _delirium 13y ago
    I'm thinking more in terms of production software, stuff like databases. If you want to license Oracle or WebSphere, you've got per-core or per-socket, per-concurrent-users, sometimes per-MIPS fees, may depend on field of endeavor, etc. Oracle and IBM are the masters of this particular art, but there are quite a lot of bits of proprietary software that include that kind of fee structure at least in part. Some game engines also charge you depending on your game's sales. A flat fee for any use, no royalties, seems limited to certain software niches, especially anything seen as non-enterprise.
    - einhverfr 13y ago
      So: Would you prefer MySQL or PostgreSQL? ;-) Here's a case of a BSD-licensed project overrunning a GPL-licensed one.

_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!

einhverfr 13y ago
In terms of developer tools you are right, but in terms of redistributable libraries that come with those? I don't agree with you there.
- _delirium 13y ago
  I'm thinking more in terms of production software, stuff like databases. If you want to license Oracle or WebSphere, you've got per-core or per-socket, per-concurrent-users, sometimes per-MIPS fees, may depend on field of endeavor, etc. Oracle and IBM are the masters of this particular art, but there are quite a lot of bits of proprietary software that include that kind of fee structure at least in part. Some game engines also charge you depending on your game's sales. A flat fee for any use, no royalties, seems limited to certain software niches, especially anything seen as non-enterprise.
  - einhverfr 13y ago
    So: Would you prefer MySQL or PostgreSQL? ;-) Here's a case of a BSD-licensed project overrunning a GPL-licensed one.