[Scummvm-devel] RFC: Transitioning to GPLv3

Matan Bareket mataniko at gmail.com
Mon Oct 26 18:30:56 UTC 2020


That matches the matrix provided, which allows us to incorporate GPLv3 code
in our GPLv2 or Later code - which gives us more flexibility than going all
in on GPLv3 and losing the ability to work with GPL2 Only code

In that case it makes more sense to just stay as is - and incorporate GPLv3
code.

On Mon, Oct 26, 2020 at 12:13 PM Hein-Pieter van Braam-Stewart via
Scummvm-devel <scummvm-devel at lists.scummvm.org> wrote:

> You are correct that everything would have to be GPLv3 but only if
> there's actually any GPLv3 code in the binary. The GPL is a
> distribution license only. Only when someone gives someone a copy of
> ScummVM does the license even comes into play.
>
> So if there is GPLv3 code calling into GPLv2 (or later) APIs then those
> v2 APIs would get 'automatically' upgraded to GPLv3. But only for that
> particular combination.
>
> The choice of what version of GPL to use is always up to the person
> distributing the software to users. Right now already I could make a
> build of ScummVM, stick it on my website, and proclaim that build of
> ScummVM is covered by the GPLv3. However the next person to distribute
> it can choose the GPLv2. As long as I didn't violate the GPLv3 when
> distributing than that is all how this is intended to function.
>
> Of course if someone distributes a copy of ScummVM with a v3 engine in
> it then 'v2' would no longer be a legal option.
>
> In practice this barely matters. For clarity it could be beneficial to
> just change all of the license headers to v3 or later, but legally
> speaking we can just merge a v3 engine, we just have to make sure that
> if scummvm is built with a v3 licensed engine we show the v3 license in
> place of the v2, if we show it anywhere now.
>
> - HP
>
> On Mon, 2020-10-26 at 09:02 -0700, Paul Gilbert via Scummvm-devel
> wrote:
> > Hi all,
> > Another example of GPL3 software is the FreeDink engine, which
> > coincidentally enough according to their website is looking for a new
> > maintainer. With the many fan-made games "mods" done using the
> > engine, adding to ScummVM would give us a bunch of new games. And
> > another engine for fan games to written for. As to the previous reply
> > about just letting people building the executable choose, since
> > engines access the system API and classes, wouldn't that mandate
> > everything be GPL3? I was under the impression that GPL in general
> > requires that everything that GPL code connects to is GPL as well. Or
> > is it sufficient that the backend code is GPL2 already.
> >
> > In any case, I'm curious if there are any particular disadvantages to
> > making everything GPL3? As far as I'm aware, it wouldn't affect our
> > normal releases. And companies could still release games with ScummVM
> > bundled commercially (except on consoles :P ), as long as they
> > provide the source code (i.e. that remains unchanged). So I don't see
> > any downside to updating to GPL3. It gives us access to potentially
> > merging more engines in, and would keep license issues from getting
> > more complicated.
> >
> > Paul.
> >
> > On Mon, Oct 26, 2020 at 8:22 AM Hein-Pieter van Braam-Stewart via
> > Scummvm-devel <scummvm-devel at lists.scummvm.org> wrote:
> > > Hi all,
> > >
> > > I'm not very active so I'm not going to weigh in on the matter of
> > > whether or not to migrate to GPLv3. However, there's no actual need
> > > to
> > > do so to be able to merge GPLv3 licensed code.
> > >
> > > The situation would essentially be as follows:
> > >
> > > * A binary built without any GPLv3 engines included would be
> > > licensed
> > > under the GPLv2 (or at your option) GPLv3. The way this works is
> > > that
> > > the person who *distributes* the engine gets to choose between the
> > > two
> > > already.
> > > * A binary built WITH a GPLv3 engine would be GPLv3 (or later). A
> > > distributer of that binary does not get an option. Except to use a
> > > potential future GPLv4 instead.
> > >
> > > I hope that clears that up. As long as everything is licensed as
> > > 'or
> > > later' this decision will never actually need to be made, legally
> > > speaking.
> > >
> > > - HP
> > >
> > > On Mon, 2020-10-26 at 16:07 +0100, Einar Johan Trøan Sømåen via
> > > Scummvm-devel wrote:
> > > > Hi team
> > > >
> > > > Recently the topic of which license to use has come up again. In
> > > > particular whether or not we should be moving towards GPLv3. As
> > > far
> > > > as I understand GPLv3 is compatible with the same licenses that
> > > GPLv2
> > > > is, in terms of what code (and thus engines) we can integrate,
> > > but it
> > > > is in addition compatible with GPLv3.
> > > >
> > > > https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility gives
> > > a
> > > > quick idea of how that works out.
> > > >
> > > > So the net gain for us, is that we would be able to integrate
> > > code
> > > > that is itself licensed under GPLv3, one _potential_ example
> > > would be
> > > > for instance the HPL engine:
> > > > https://github.com/FrictionalGames/HPL1Engine
> > > >
> > > > Technically we can perform this change because we are licensed
> > > under
> > > > “GPLv2 (or later)”, which means that we can transition to v3
> > > without
> > > > having to seek new approval from all historical contributors.
> > > (The
> > > > linux kernel is a counter example, where they lack the “or
> > > later”,
> > > > and would thus need to seek explicit permission from all
> > > > contributors, as the license they got the code under does not
> > > allow
> > > > for upgrades).
> > > >
> > > > Since this is a fairly large, and completely irreversible change,
> > > so
> > > > we’d like to hear what the opinions are among the team, should we
> > > > stay at v2, or move to v3?
> > > >
> > > > Regards
> > > >
> > > > The leadership team
> > > >
> > > > _______________________________________________
> > > > Scummvm-devel mailing list
> > > > Scummvm-devel at lists.scummvm.org
> > > > https://lists.scummvm.org/listinfo/scummvm-devel
> > >
> > >
> > > _______________________________________________
> > > Scummvm-devel mailing list
> > > Scummvm-devel at lists.scummvm.org
> > > https://lists.scummvm.org/listinfo/scummvm-devel
> > _______________________________________________
> > Scummvm-devel mailing list
> > Scummvm-devel at lists.scummvm.org
> > https://lists.scummvm.org/listinfo/scummvm-devel
>
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> https://lists.scummvm.org/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20201026/cf1b69e3/attachment.htm>


More information about the Scummvm-devel mailing list