Licensing "fun"

[davelab6]

@llaske I am curious, why did you choose the Apache 2.0 license for Sugarizer?

I am worried that many python Sugar programs are licensed under GPLv2.

When you port a program from one language to another, the port is a derivative of the original under copyright (like translating a novel from French to English.) Therefore GPLv2 programs ported from Python to JavaScript must also be licensed under the GPLv2.

It seems that much of python Sugar is licensed under GPLv2. It also seems to me that any program written for the python Sugar desktop must be considered a combined work with the desktop, and thus required to be licensed under terms compatible with the GPLv2.

GPLv2 is not compatible with the Apache 2.0 license (but GPLv3 is.)

Therefore if you are keen to use Apache 2.0 instead of GPL, I guess we'll need to work with the community to re-license Sugar under GPLv3.

[llaske]

Apache 2.0 license is the one used by SugarLabs, specifically for Sugar-Web, it's the reason I've decided to take it for Sugarizer.

I don't see the issue regarding porting of activities from Sugar to Sugarizer because porting Python/Gtk to JavaScript/HTML5 is technically impossible. So it's more a rewriting than a real porting. I don't think it could have license infringement in that case.

[davelab6]

porting Python/Gtk to JavaScript/HTML5 is technically impossible

Kindly, I think this is not true :)

I would agree that automatically converting ("transpiling") is so error prone as to be 'impossible to do well,' yet there are projects that do it poorly (pyjamas, brython, various py2js...)

Still, porting from any language to any other language is certainly technically possible; we are all using Turing machines arranged in Von Neumann architectures, etc.

So it's more a rewriting than a real porting.

Well, the technical details are irrelevant. It is legal details that are relevant, and the way copyright works, if you were to translate an novel written in English to French, you must obtain permission from the English novel's copyright holder.

Similarly, if you study the source code of a program, that source code is subject to copyright, and then if you write another "new" program that was influenced by your understandings from the source code that you read, then the copyrights of the first program may be infringed. When the GPL license enters the picture, since the only access you have to the source code is subject to the terms, I think the situation is more clear: You can only port GPL if your ported version is also GPL.

I don't think it could have license infringement in that case.

I see that https://www.gnu.org/licenses/gpl-faq.en.html doesn't cover this question, which is regrettable. But https://stackoverflow.com/questions/11939125/ported-gpl-library-should-be-under-gpl-as-well has a pretty good explanation.

[bzg]

I think the SO answer is wrong.

One basis of copyright is that you don't have a copyright on ideas, you have a copyright on the expression of ideas. A compelling reason for this is that only the expression of ideas can let us assess their originality, which is one of the cornerstones for granting copyright.

So IANAL, but I seriously doubt that "porting a GPL software" imposes copyright conditions on the ported software.

[walterbender]

With all due respect, never mind the fact that the Python code was used as the basis of the JavaScript code, in many cases, the artwork was copied verbatim. As for the assertion that the authors were all asked, at least in my case, I was never asked. There are non-trivial differences between AGPL and Apache. As I said in the email thread, it would be good to get an informed read on this situation.

[bzg]

Hi @walterbender, we had a thorough discussion with @llaske about this yesterday.

The licensing information for the artworks must be fixed, this is a work in progress.

As for TurtleJS and Jappy, my understanding is that they cannot be bundled with Sugarizer for now. Lionel is aware of it and currently working on various propositions.

[llaske]

Sugar artwork (icons, ...) used in Sugarizer are on Apache v2: https://github.com/sugarlabs/sugar-artwork/blob/master/LICENSE

@bzg point me issues in some activities and contents currently included in Sugarier.
I'm working on that to see how we could fix this and I will release a new version to handle this.
Changing the issue state to indicate that.

[walterbender]

I am more than happy to have a discussion about how to remedy the license issue with TurtleJS et al. It is one of the reasons for this issue being of interest to me. I'd just like informed advice as to how to proceed.

[davelab6]

@walterbender can Conservancy advise?

[walterbender]

I will ask Adam to reach out to them. The person at the conservancy with whom I used to discuss these things is no longer there.

[bkuhn]

The person at the conservancy with whom I used to discuss these things is no longer there.

Fortunately, most of Conservancy's staff (@brettcs, @karensandler, @ossguy and I) plus our outside counsel @pchestek all have substantial experience in software freedom licensing issues.

I think @walterbender is referring to @keynote2k, who is no longer on staff, but he's still involved with our org. Adam got the matter to us in the proper way to us earlier today and Conservancy is looking into the matter.

[davelab6]

For the record, there is a parallel discussion on the sugar-dev mailing list today.

[llaske]

I've just released a v1.0.1 that specifically indicate license used for each activity and give a warning for the whole package telling that Apache v2 is not the license for all activities.
Plus, starting with this version v1.0.1, TurtleBlockJS and Jappy activities that use a license (AGPL, GPL v3) incompatible with deployment in stores are no longer integrated with Sugarizer in store (Apple Store, Play Store, Amazon Store, F-droid store, Chrome OS Desktop store and Windows Store).

[walterbender]

Did we ever hear anything back from the SFC about this??? We ask them for advice quite some time ago. I am happy to make Turtle available under another license, but would like some guidance from someone more knowledgeable about the best way to do this.

[bkuhn]

Did we ever hear anything back from the SFC about this??? We ask them for advice quite some time ago.

The issue is queued for legal review and is quite complex so it may take some time. Also, as you know, Sugar Labs has demanded a lot of Conservancy staff time on another matter in the last month, which we understood to be your priority.

[walterbender]

FWIW, https://www.gnu.org/licenses/gpl-faq.html#TranslateCode

[llaske]

There is no translation of Python/Gtk code to JavaScript/HTML5 in Sugarizer.
These two environments are so different than "translation" of code has no sense.

[walterbender]

In almost every case, the students used the original Python code as a basis on their JavaScript design. I am not a lawyer, which is why I asked the SFC to look into this in the first place.

…

On Fri, Nov 9, 2018 at 10:32 AM Lionel LASKE ***@***.***> wrote: There is no translation of Python/Gtk code to JavaScript/HTML5 in Sugarizer. These two environments are so different than "translation" of code has no sense. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADz74ZYEB0peINAwN4NgZrZeVYvtcC_Hks5utaAUgaJpZM4H-shv> .

-- Walter Bender Sugar Labs http://www.sugarlabs.org <http://www.sugarlabs.org>

[llaske]

I told about Sugarizer Core where there is clearly no code translation.
BTW, regarding this point my policy is now very clear: any activity not compatible with Apache v2 license will be exclude of Sugarizer deployment. It's already the case with TurtleJS and Jappy, it will be the case for any other activities if need.

[walterbender]

I am not sure what you are referring to in regard to Sugarizer core, but there are many activities that were "translated" from Sugar activities in Sugarizer. That said, my goal from the beginning has been to come up with a way to resolve this, not to build walls.

…

On Fri, Nov 9, 2018 at 12:28 PM Lionel LASKE ***@***.***> wrote: I told about Sugarizer Core where there is clearly no code translation. BTW, regarding this point my policy is now very clear: any activity not compatible with Apache v2 license will be exclude of Sugarizer deployment. It's already the case with TurtleJS and Jappy, it will be the case for any other activities if need. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADz74W2qYJEBaXgWyR7wYBjLhHhQUhXqks5utbsqgaJpZM4H-shv> .

-- Walter Bender Sugar Labs http://www.sugarlabs.org <http://www.sugarlabs.org>

[llaske]

Thanks to say that. I really want to resolve it and wait for SFC recommendation for taht.
What I'm calling Sugarizer core is everything expect activities.
Regarding activities, I'm sure that those I supervised during GSoC are clearly not translated. I think specifically to Record, Calculate, Memorize, Paint, Chat, Physics, Speak, TamTam, Labyrinth.

[aperezbios]

As a newly-minted Sugar Labs Oversight Board member, I would also like to see this resolved, and we need the feedback from SFC in order to do that. It has been ~five months since the last comment from SFC for this issue. @bkuhn, is the review of this still queued for legal review, and if not, any rough ETA on when we might expect it to be reviwed? Thanks!

[bkuhn]

It is still queued. This is a very complex issue and will take a lot of resources from Conservancy, and as you may not be aware as an incoming PLC member, Sugar Labs took substantial resources from Conservancy last two years for logistics needs (happy to explain to you privately what those things were).

We would expect the legal fees and staff time to be high on this matter, as it will require careful analysis with a lawyer and technical person to analyze the situation and come to a conclusion. I'd be glad to talk with you not on a public ticket about how to get this done.

[llaske]

To solve this issue, we took decision to contract with a professional attorney from Inno3, a french company specialized in Open Source license.

Questions was:

• Is it legal to distribute Sugarizer and Sugarizer activities under the Apache 2.0 license instead of GPLv3?
• Can we distribute TurtleBlockJS (AGPLv3+) and Jappy (GPLv3+) with Sugarizer?
• Can we distribute Sugarizer and Sugarizer activities through the online "stores", specifically through Apple Store?

Shortly (see detailed explanation here) answers are:

• Yes
• Yes
• Yes, expect for activities under GPL/AGPL

Only the third point could require an update but as mentioned before both TurtleBlockJS and Jappy are now exclude from Sugarizer version deployed in store.