[Scummvm-devel] RFC: Transitioning to GPLv3
Hein-Pieter van Braam-Stewart
hp at tmm.cx
Mon Oct 26 18:37:45 UTC 2020
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
More information about the Scummvm-devel
mailing list