[Sugar-devel] licensing question
bzg at bzg.fr
Thu May 24 01:25:25 EDT 2018
yes, there are two questions, the one regarding TurtleBlocks JS and
the other about whether porting from one language to another is to be
considered as a "derivative work".
The issue of artworks having been copied verbatim is different from
the last one: for what I know, the upstream source of the artworks in
Sugarizer are released under one of the "permissive" license (Apache
2.0, MIT, CC-by, etc.), so the issue here is just about updating the
licensing information in Sugarizer.
Walter Bender <walter.bender at gmail.com> writes:
> TurtleBlocks JS is AGPL. One of the questions I have is in regard to
> the best way to include it in the Sugarizer bundle, which assigns
> Apache to everything it pulls in.
There is a confusion in github/llaske/sugarizer/README.md right now,
because the sentence
"This project is licensed under Apache v2 License. See LICENSE for
full license text."
is clearly too fuzzy. Sugarizer README.md should say: "[This content]
is release under [this license]." and be more specific in general.
Note that activities/TurtleBlocksJS.activity/COPYING clearly indicates
the GNU Affero Public License -- so strickly speacking, Sugarizer does
not "assign Apache 2.0 to everything it pulls in".
As long as TurtleBlocks JS is released under the AGPL, it cannot be
released with Sugarizer, because one cannot combine AGPL work with a
larger Apache 2.0 codebase and distribute the whole thing. You cannot
package an iOS application using AGPL work without releasing all your
application code under AGPL.
One simple path is to relicense TurtleBlocks JS under Apache 2.0.
Another possible solution is to use a "weak copyleft" license, such as
the Mozilla Public License or the Eclipse Public License. E.g. the
EPL license would allow for TurtleBlocks JS to be bundled in Sugarizer
and in any other application, even closed-source ones, but would still
make sure that any modification of the TurtleBlocks JS code is shared
under the EPL license.
That's what the FSF calls an "intermediary license": not as strict as
the AGPL or GPL, because it allows the code to be included basically
anywhere, but not as permissive than the Apache 2.0, MIT, etc. because
every change of the EPL'ed code should be publicly shared.
I guess the core question is: what is the motivation behind releasing
TurtleBlocks JS under AGPL?
> The other question regards the Python (GPL) activities that were
> translated to JS and given an Apache license. (Artwork was copied
> verbatim in many cases.) Is this OK? Not sure. In many cases we know
> the author of the Python code, but again, it is not clear to me at
> least the best path forward.
IANAL but I seriously doubt that "porting" an idea from one language
to another language counts as a derivative work. That would be very
bad for the whole free software world. Every FLOSS clone out there
is porting ideas from a software (e.g. Microsoft Office) to another
one (LibreOffice). I think "derivative" is about lines of code, not
There might be ann issue about design sometimes, when it has been
separately copyrighted -- but copyright on code does not cover design
At least that's my understanding.
> What I think everyone agrees is that we want to sort this out so
> that both the code bases can move forward.
Indeed! On the Sugarizer side, we are taking this very seriously.
More information about the Sugar-devel