Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licensing "fun" #48

Open
davelab6 opened this Issue Apr 3, 2016 · 22 comments

Comments

Projects
None yet
6 participants
@davelab6
Copy link
Contributor

commented Apr 3, 2016

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

@davelab6 davelab6 changed the title LICENSE? Licensing "fun" Apr 3, 2016

@llaske

This comment has been minimized.

Copy link
Owner

commented Apr 4, 2016

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.

@llaske llaske added the wontfix label Nov 26, 2017

@davelab6

This comment has been minimized.

Copy link
Contributor Author

commented May 18, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 18, 2018

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

This comment has been minimized.

Copy link

commented May 22, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2018

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 llaske added bug and removed wontfix labels May 22, 2018

@llaske

This comment has been minimized.

Copy link
Owner

commented May 22, 2018

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

This comment has been minimized.

Copy link

commented May 22, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2018

@walterbender can Conservancy advise?

@walterbender

This comment has been minimized.

Copy link

commented May 23, 2018

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

This comment has been minimized.

Copy link

commented May 24, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 24, 2018

@llaske

This comment has been minimized.

Copy link
Owner

commented Jul 7, 2018

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

This comment has been minimized.

Copy link

commented Jul 7, 2018

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

This comment has been minimized.

Copy link

commented Jul 9, 2018

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

This comment has been minimized.

@llaske

This comment has been minimized.

Copy link
Owner

commented Nov 9, 2018

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

This comment has been minimized.

Copy link

commented Nov 9, 2018

@llaske

This comment has been minimized.

Copy link
Owner

commented Nov 9, 2018

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

This comment has been minimized.

Copy link

commented Nov 9, 2018

@llaske

This comment has been minimized.

Copy link
Owner

commented Nov 9, 2018

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

This comment has been minimized.

Copy link

commented Dec 15, 2018

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

This comment has been minimized.

Copy link

commented Dec 17, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.