3 ms·

Side question about the "core" approach. Can your core be *GPL (in case it needs/ships with GPL libraries/tools) while some "plugins/modules" would be closed so

by rplnt 9y ago

Side question about the "core" approach. Can your core be *GPL (in case it needs/ships with GPL libraries/tools) while some "plugins/modules" would be closed source? Let's say you have an IRC client that is GPL (because you want to use grep for example), but it's only a service with an API. You then make closed front-end that utilizes it. Or other way, there would be a closed tool that the client can use (e.g. auto reply module).

user5994461 9y ago
The short version is no. The long version is that it is unclear whether it's possible or not and it will vary depending on what integrates with what and how. GPL is a nightmare. Note there is a strong and justified barrage against GPL components in the enterprise world. Assuming you are doing a "core" model because you intend to sell it, that might be a problem.
- smichel17 9y ago
  I'd like to bring a bit of perspective to "GPL is a nightmare [because you cannot create proprietary derivatives]." That's the point of the GPL: to ensure that the code remains open rather than, for example, killed by 'embrace, extend, extinguish'[1]. The GPL is a user-focused license. It sacrifices some freedom for developers (the ability to produce proprietary derivatives) in order to safeguard other freedoms[4] for users. Whether that's a good trade-off is a matter of opinion, not a universal consensus as the parent comment might lead you to believe. [1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... [4]: https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/free-sw.html
  - zaarn 9y ago
    The GPL is a nightmare for Legal. Compliance can be difficult for larger corporations and as such expensive. Thusly corporations will avoid it in favor of licenses which aren't complicated. This goes doubly for the AGPL. In addition to that and as a side note; The GPL does not protect against EEE, only against EEE through a fork of the source code. No license can do anything about EEE through standards.
catern 9y ago
Yes, both of those would work. The "service with an API" approach dodges the GPL by keeping the client and server separated in separate processes or even separate servers, which is fine. (The AGPL was created as a stronger version of the GPL which prevents this dodge.) The "proprietary plugins" approach dodges the GPL by having the end user be the one to combine the main GPL program with a proprietary plugin. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins That FAQ has a lot more information which you may find useful. The sibling comment does not know what they are talking about, like most people when it comes to the GPL.

by rplnt 9y ago

user5994461 9y ago

The short version is no. The long version is that it is unclear whether it's possible or not and it will vary depending on what integrates with what and how. GPL is a nightmare. Note there is a strong and justified barrage against GPL components in the enterprise world. Assuming you are doing a "core" model because you intend to sell it, that might be a problem.

smichel17 9y ago
I'd like to bring a bit of perspective to "GPL is a nightmare [because you cannot create proprietary derivatives]." That's the point of the GPL: to ensure that the code remains open rather than, for example, killed by 'embrace, extend, extinguish'[1]. The GPL is a user-focused license. It sacrifices some freedom for developers (the ability to produce proprietary derivatives) in order to safeguard other freedoms[4] for users. Whether that's a good trade-off is a matter of opinion, not a universal consensus as the parent comment might lead you to believe. [1]: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... [4]: https://www.gnu.org/philosophy/free-sw.html https://www.gnu.org/philosophy/free-sw.html
- zaarn 9y ago
  The GPL is a nightmare for Legal. Compliance can be difficult for larger corporations and as such expensive. Thusly corporations will avoid it in favor of licenses which aren't complicated. This goes doubly for the AGPL. In addition to that and as a side note; The GPL does not protect against EEE, only against EEE through a fork of the source code. No license can do anything about EEE through standards.

catern 9y ago

Yes, both of those would work. The "service with an API" approach dodges the GPL by keeping the client and server separated in separate processes or even separate servers, which is fine. (The AGPL was created as a stronger version of the GPL which prevents this dodge.) The "proprietary plugins" approach dodges the GPL by having the end user be the one to combine the main GPL program with a proprietary plugin. See https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins That FAQ has a lot more information which you may find useful. The sibling comment does not know what they are talking about, like most people when it comes to the GPL.