GCompris and AGPL

[Harald Sitter]

On Mon, Feb 15, 2021 at 8:38 PM Timothée Giet <animtim at gmail.com> wrote:
>
> Hi,
>
> Last year, in order to create the Analog Electricity activity in
> GCompris, we had to integrate some existing code for the electric
> circuit simulation engine. The code weintegratedis under the AGPLv3
> license...
>
> First publication of the original code, without any license:
> https://github.com/zupolgec/circuit-simulator/blob/master/js/cktsim.js
> <https://github.com/zupolgec/circuit-simulator/blob/master/js/cktsim.js>
>
> Then it was republished here with the AGPLv3 license:
> https://github.com/edx/edx-platform/blob/master/common/lib/xmodule/xmodule/js/src/capa/schematic.js
> <https://github.com/edx/edx-platform/blob/master/common/lib/xmodule/xmodule/js/src/capa/schematic.js>
>
> (check https://github.com/zupolgec/circuit-simulator/issues/1
> <https://github.com/zupolgec/circuit-simulator/issues/1>for the
> licensing history).
>
> Integration of the code in GCompris:
> https://invent.kde.org/education/gcompris/-/blob/master/src/activities/analog_electricity/cktsim.js
> <https://invent.kde.org/education/gcompris/-/blob/master/src/activities/analog_electricity/cktsim.js>
>
> We searched a lot, but this was the only option we found for a JS
> electric simulation engine that would be compatible with QML.
>
> As the GPLv3 clearly state that combining some AGPLv3 work to it is
> allowed, just the special requirements of the AGPLv3 will apply to the
> resulting package/installer ("the combination as such"), license-wise it
> looks OK.
>
> This means that now, the binary/package of GCompris has to be released
> under AGPLv3.
> Of course we keep licensing all the rest of our new code under GPLv3+ as
> before, so if at some point we can replace the simulation engine with
> some GPLv3+ code, we can return to releasing our package under this license.
>
> However, as Albert A. Cid commented, "technically KDE doesn't allow
> non-server AGPL projects, see
> https://community.kde.org/Policies/Licensing_Policy
> <https://community.kde.org/Policies/Licensing_Policy>".
> So he suggested that we bring the topic to the community list.
>
>
> As the KDE License Policy pages states, "this licence policy is designed
> to allow maximum code reuse with the community of KDE and beyond while
> making exceptions for the few cases which need it", we would like to ask
> to add a new exception to the list to cover our case.
>
> I propose to add something like this:
>
> "17. If a project under GPLv3(+) really needs to integrate some existing
> code under AGPLv3(+) to add a specific feature, it is tolerated to do
> so. The resulting combined work will then be under AGPLv3(+) as long as
> this code is part of the project. However, all new code created on this
> project should still be under the original GPLv3(+) license."
>
> We hope the community will agree with this.
>
> Note that we also recently tried to contact the copyright holders of
> this piece of code to ask if they would agree to relicense it under
> GPLv3+, but so far we didn't get any reply from them. If someone on this
> list has some contacts with some MIT people who could help on this
> relicensing question, it would be very welcome.

Hej

First off I'm sure we don't need to add yet more text to the policy to
grant an exception, we just need to reach agreement.  ;) If the issue
pops up multiple times we can think about adding it to the policy,
otherwise it just adds to the already weighty list of policy points
making the document yet more intimidating.

The problem at hand is perhaps a bit tricky though.

>From my understanding if anything in gcompris is AGPL that triggers
the over-the-network provision for every networked use case gcompris
might conceivably have. Remote desktop over intertubes, some VM over
intertubes thing, thin clients, thin client KIOSKs, what have you...
I'm not saying that is a bad thing, just clarifying.

Now, I would argue it's actually OK to have AGPL code if we don't read
the policy quite as literally. Notably if we accept that point 6
applies to sources rather than applications (what's an application
anyway) the intent of the source matters not of the application.
Otherwise it'd be a bit wonky since we then also couldn't link a
library that is AGPL as the combined work with AGPL is always AGPL, as
far as I know.

That brings me to the bigger problem though: it is 3.0 exclusively.
This is at odds with the policy's intent as a fixed version license is
severely constraining code reuse. We have absolutely been bitten and
continue to suffer from having sources without some or-later
provision.

At the same time, to pick up the example from above: if I understand
it correctly we use it more like a third party library that lives in
our tree instead of it actually being a "library" of sorts?
If so I would argue that we should treat it as such and allow it even
as AGPL-3.0 exclusively, perhaps with the additional constraint that
it shouldn't get any changes that aren't also upstream. What we
definitely want to avoid is us maintain the file, or actively add code
to it, while it has version constrained licensing terms which will
come to haunt us in 10 years time. To that end a prominent warning
comment in the file might be handy.

With all that in mind it's a bit meh but in lieu of options I'm +1 on
allowing it.

HS