[Scummvm-devel] RFC: Transitioning to GPLv3

Mon Oct 26 19:01:53 UTC 2020

We discussed the mixed licenses before sending the initial mail and
rejected it as not practical and bringing no obvious benefits.

The only benefit which we identified so far, is that the external GPLv2+
projects could still reuse our code, while after us switching to GPLv3+,
that will not be possible.

When you mix in some code in a vivid project, it is very challenging to
split it from the old code. Imagine, you are working on an engine which is
GPLv3 and during the development, as it often happens, you need to modify
the common code. Is it now GPLv2? GPLv3? Factually, it is inspired directly
by GPLv3. Then, you committed your engine cleanly and now somebody else
would like to reuse one of the formats or algorithms or just copy/paste
your fallback detection code. We will not be able to move this code to
GPLv2 part.

Also, mixing *incompatible* licenses is error-prone. Some ports use custom
build systems. What will happen if the GPLv3 code is occasionally compiled
with v2 code? How to make sure there is a "clean" GPLv2 area which is never
contaminated by GPLv3?

Moreover, IANAL, but take a look what the FAQ which Somaen referred to, is
explaining:

I want to license my code under GPLv2 or later and I want to use a library
> under GPLv3: If you have the ability to release the project under GPLv2 or
> any later version, you can choose to release it under GPLv3 or any later
> version—and once you do that, you'll be able to incorporate the code
> released under GPLv3.

Look, here it is talking about a *project*, not individual files.  And you
can incorporate v3 code *once* you moved your project to v3.

And things like that. No, we will not go this rabbit hole and it was NOT
the original question which Somaen posted.

The true question is. Are there are any compelling reasons for us to stay
on GPLv2+ or *not go* to GPLv3+, otherwise we would like moving forward
with GPLv3+.

Eugene

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

>
> That is true with the caveat that nobody would be legally able to
> distrubute a copy of ScummVM with both a GPLv3+ *and* a GPLv2 only
> engine enabled.
>
> So we may want to steer clear of that situation regardless.
>
> - HP
>
> On Mon, 2020-10-26 at 14:30 -0400, Matan Bareket via Scummvm-devel
> wrote:
> > 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
> > _______________________________________________
> > 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/6583e7dc/attachment-0001.htm>