[Scummvm-devel] RFC: Transitioning to GPLv3

[Paul Gilbert]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20201026/c65757dc/attachment.htm>