GCompris and AGPL

[Timothée Giet]

Le 19/02/2021 à 13:38, Harald Sitter a écrit :
> 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

Thank you Harald for the feedback!

If you think we don't need to update the policy and an agreement is
enough, that's OK for us.

About "3.0 exclusively", it's true that it can become a problem in the
future. Indeed if at some point we want to move to "later" GPL for the
rest of the code, then we may need to find a solution to replace this
library if it becomes not compatible.

About not adding any changes that aren't also upstream, that's almost
the case. We only added very few things to ease the integration, and all
the changes have some comments including the word "GCompris" to identify
them easily. We don't intend to make any not-upstream change to the main
logic of the code.

Timothée