[Scummvm-devel] RFC: Transitioning to GPLv3
Hein-Pieter van Braam-Stewart
hp at tmm.cx
Mon Oct 26 19:14:21 UTC 2020
Alright, sorry for stirring up a conversation that was already had.
And your concerns about copying code from a v3+ engine 'accidentally'
in to the v2+ part of scummvm is very valid.
I personally now believe you are correct and mixing v3+ code while
trying to keep the rest of scummvm v2+ is a bad idea and I wish I
hadn't started talk about it.
- HP
On Mon, 2020-10-26 at 20:01 +0100, Eugene Sandulenko via Scummvm-devel
wrote:
> 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
> _______________________________________________
> 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