at least web.archive.org/web/2019062517 alludes to the RAP plugin being productized as a commercial standalone product outside of the grsecurity kernel patch.
Conversation
i don't think anyone here disagrees that you have the right to cut off people's grsecurity subscriptions if they bundle it with a product and have to abide by their GPL obligations; but building a product from a GPL SDK, in concert with a GPL program is a different question
1
I disagree with that. Granting license only with a threat of commercial retaliation if used is not following the gpl's requirement to license under gpl with no further conditions.
1
It's not an additional condition for what you already received. I think they distribute everything as source code anyway. The GCC plugins are GPLv2 only and GCC expects plugins to be GPLv3 but that has been inherited as a problem for the upstream plugins in the Linux kernel too.
1
2
There is no problem, you're forgetting about the GCC runtime library exemption: gnu.org/licenses/gcc-e If anyone had a problem with it, they wouldn't be linking to the code on their own site: gcc.gnu.org/wiki/plugins or could just shoot anyone a simple email...
1
1
anytime in oh the past decade? This is all outside misinformed nonsense originating from an obsessed troll, there's never been any substance to it. Nobody cares about facts, just repeating whatever misinformation they heard.
1
GPLv2 can't be used as the basis for upstream GCC features and losing the runtime library exception makes them generally unusable for userspace.
It's not necessarily a problem if the goal is simply having plugins that are forever downstream and only usable for the Linux kernel.
2
All we are discussing here is plugins for the Linux kernel. Nobody is saying ones intended for userland can be GPLv2.
1
Personally, I would not care if the plugins did need to be GPLv3 -- I'm not anti-v3 and wouldn't have any problem with relicensing under it. But they don't for the kernel, and nobody who matters (i.e. those actually holding relevant copyrights) have said otherwise in a decade.
1
What we won't do, however, is be bullied by disingenuous freeloaders not associated with the projects involved, who own no copyright, just because they think they deserve our work (even unpublished work!) for free.
1
1
I don't have a problem with your approach. I'm not sure the upstream kernel developers realize the implications of using GPLv2 for the plugins though. They used GPL2 for the one they wrote themselves. I don't think they really intended to make it partially incompatible with GCC.
yes, I too, don't really care about this. i was just curious what the deal with the RAP plugin was.
Sure they do, it was explicitly discussed when they were merged. Also, even the plugin they wrote themselves used gcc-common.h and shared the skeleton code.
If I recall correctly, some of your (PaX and grsecurity) plugins were GPLv2 only from the start and others were GPLv2/GPLv3 but then changed to GPLv2.
My understanding was it became an intentional choice to try to get sustainable funding through licensing it for userspace use.
1
Even if it were true (SIZE_OVERFLOW does appear to have been changed from v2 or newer to v2-only in 2016, others that started v2 or newer like sancov_plugin or cyc_complexity_plugin remain so), so what?
2
Show replies