Re: 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  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
>> 
>>
>> 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
>> 
>>
>> (check 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
>> 
>>
>> 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
>> ".
>> 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 

Re: GCompris and AGPL

[Harald Sitter]

On Mon, Feb 15, 2021 at 8:38 PM Timothée Giet  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
> 
>
> 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
> 
>
> (check 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
> 
>
> 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
> ".
> 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. W

Re: GCompris and AGPL

[Albert Astals Cid]

El dilluns, 15 de febrer de 2021, a les 20:36:08 CET, Timothée Giet va escriure:
> 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
> 
> 
> 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
> 
> 
> (check 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
> 
> 
> 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 

Just chiming in to explain how Catalan naming works, my name is

Name: Albert
1st Surname: Astals
2nd Surname: Cid

So I could be abbreviated to Albert, Albert Astals, Albert Astals C., Albert 
A.C., but not Albert A. Cid  

Sorry for the noise :)

Cheers,
  Albert

P.S: It's fine to make honest mistakes, hope y'all not annoyed by my correction

GCompris and AGPL

[Timothée Giet]

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


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


(check 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


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
".
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.

Cheers,

Timothée for the GCompris team