5 ms·
Gpl on commerce, in a nutshell: Sell this software without ability to modify: tyrant Use this software to create a closed REST API: no problem
by thatthatis 13y ago
Gpl on commerce, in a nutshell:
Sell this software without ability to modify: tyrant
Use this software to create a closed REST API: no problem
- dllthomas 13y agoThe license doesn't prevent the latter, but the FSF doesn't approve. There's also the AGPL, which would forbid the closed REST API. None of that means there's no opportunity to make money. People might pay for convenience (I don't have to set up and run my own server, even though I technically could) or access to networks - if Facebook AGPL'ed their whole stack, people using Facebook would keep using Facebook because their friends are on Facebook.
- thatthatis 13y agoSo, where is the line where providing services with the software becomes acceptable? An API is obviously a service provided with the software, but so is consulting using a GPL statistical package. How, and where, can you draw the line between those things?
- chriswarbo 13y agoThe customer is not the end-user of the GPL code; the consultant is. The customer is an end-user of the consultant. That relationship will be governed by a completely separate contract. On a related note, the output of a GPL program is not GPLed. I can compile non-GPLed code with GCC. Myths like this keep getting used as FUD. Licenses with a network-use clause, like AGPL and CPAL, define access over a network as distribution. This would cover an API, but would not cover going via a consultant, since the consultant isn't software. If you want to argue that people's minds are software, you may as well argue that our teachers hold the copyright to our thoughts.
- thatthatis 13y agoI'll have to look at those network use clauses. I've always found proprietary, BSD, and AGPL to have coherent philosophies. The GPL, on the other hand, has always felt to me to be much more of a mishmash of whatever Stallman likes or dislikes.
- dllthomas 13y agoI'm confused - it's the GPL that fails to make a distinction between the REST API and the consultant. I'd thought you were criticizing that distinction as being arbitrary.
- thatthatis 13y agoYes, that's what I think and what I thought I'd been saying. What of what I've said indicates otherwise?
- dllthomas 13y agoI see contradiction in: 1) The AGPL is philosophically well founded, the GPL is arbitrary. 2) The AGPL enforces an arbitrary distinction, the GPL does not.
- deleted 13y ago[deleted]
- thatthatis 13y agoI think I've found the confusion. I was still talking about the GPL in my second comment. I see why that was confusing given that you'd explicitly added the AGPL into the discussion, sorry. I might have better stated it as "I agree the AGPL removes the tension, I think the AGPL is philosophically coherent. But the FSF still primarily pushes the GPL. [transclude prior comment]"
- dllthomas 13y ago
- dllthomas 13y agoIn principle, the line is a gradient based on how much you're putting yourself in a position of power over your users. The consultant doesn't serve so much of the market that there won't be tons of competitors. If he makes some changes to better meet his particular needs, that has a very small impact on my options as a client. I would prefer that he share it, if anyone else is interested in it, but it doesn't matter very much at all. One API can potentially serve the entire market, and you wind up with just a few players all fighting for lock-in. Proprietary changes there matter quite a bit more.