search

llaske / sugarizer

Sugarizer is a web implementation of the Sugar platform to run on any device or browser
https://sugarizer.org
Apache License 2.0
197 stars 411 forks source link

Licensing "fun" #48

Closed davelab6 closed 5 years ago

davelab6 commented 8 years ago

@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 commented 8 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@walterbender can Conservancy advise?

walterbender commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

llaske commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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

llaske commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 https://github.com/llaske/sugarizer/issues/48#issuecomment-437395591, 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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 https://github.com/llaske/sugarizer/issues/48#issuecomment-437433476, 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

Shortly (see detailed explanation here) answers are:

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.