Re: [dev] [license] gpl issues

From: NRK <>
Date: Tue, 9 May 2023 00:48:31 +0600

On Sun, May 07, 2023 at 11:31:04AM +0200, Страхиња Радић wrote:
> but the arguments presented in it leave me unconvinced.

The "maneuverings" argument in specific was entirely misdiagnosed. Even
in his own example (redhat trying to remove /etc) you can clearly see it
has nothing to do with GPL and everything to do with _adoption_.

Let's imagine a world where the linux ecosystem (including the GNU
tools) were permissively licensed. And now redhat wants to remove
`/etc`. Of course, if redhat was the only distro that did this, most
applications wouldn't adopt their policy - leaving them with an insane
amount of packages which will be broken on their distro - making this
plan infeasible.

According to that article's logic:

        This kind of "hijacking" and political maneuverings never happen
        with a permissive license like the BSD or MIT licenses.

in this imaginary universe, redhat would just go, "Hmm, we didn't get
what we wanted, but since linux is BSD licensed, we'll just give up."
Does that sound realistic? Of course not. They would've done exactly
what they're doing right now - trying to push their policies unto every
(or at least most) distros via the virus that is systemd so that their
policies gain _adoption_ among applications/libraries. Linux being
GPL/BSD makes zero difference when you need adoption from a massive
amount of third party applications.

If you want a real world example, just look at wayland-protocol, which
is MIT licensed. According to that articles logic, Valve can just fork
it and add their custom-protocol and implement it in their compositor.

But if Valve's compositor is the only compositor that implement's a
protocol, then most applications won't follow/adopt it and thus the
protocol will be useless.

So the reality of the situation is that Valve is still "maneuvering" and
trying to get what they want into the upstream wayland-protocol so that
it gains adoption. The MIT license made zero difference.

Received on Mon May 08 2023 - 20:48:31 CEST

This archive was generated by hypermail 2.3.0 : Mon May 08 2023 - 21:00:08 CEST