4 ms·
I'm curious on your take of this for library code (as opposed to a full application like a web server or database). By count of projects alone, most of the OSS
by gregmac 4y ago
I'm curious on your take of this for library code (as opposed to a full application like a web server or database).
By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that.
I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal.
- hardwaresofton 4y agoIANAL, I'm a yak shaver by trade. That said, I think it's completely different for library code. Library code is conveyed to the user, whereas network access is not conveying a work. They didn't mention this, but even more abstractly, network access to the result of some computation is clearly not a sustainable thing to try to control either. > By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that. > I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal. Yeah I think this is the fundamental breaking point -- AGPL is much more viral/complicated for conveyed works (as it was intended to be). Probably not a good idea in that use case. I should amend my post to note that AGPL is the future for self-hostable F/OSS, not necessarily library F/OSS. That said, I do think that it could be a great default license that encourages purchases for F/OSS though. If you're building F/OSS then the library is free for you. If you're not building F/OSS then pay for a separate license. If your goal is adoption (and the most users, arguably greatest good/utility) then AGPL stands in the way of that.
- adastra22 4y agoAre you familiar with the Mozilla Public License 2.0? It basically fulfills the role of library-compatible copyleft license in a way that LGPL never did. If a file is MPL-2, then all modifications to that file must be shared. But it is otherwise not viral, and so you can freely link with other proprietary code, or include it in a statically linked binary.