Re: [Sugar-devel] licensing question

[Tony Anderson]

Hi, D. Joe

Sugar users should not need to do any of this. For some reason, the 
developers decided that somehow the installed activity should be git 
init. The setup.py complains if the master is not a git repository (as 
it is when downloaded as a zip). While this is not a problem for an 
Ubuntu system, an XO does not have the storage capacity for .git. What 
Sugar users expect and deserve to have is the ability to click on an 
activity in ASLO, have it downloaded and installed by Browse in Sugar.


On Thursday, 24 May, 2018 07:52 PM, D. Joe wrote:

On Thu, May 24, 2018 at 02:27:59PM +0800, Tony Anderson wrote:

[personal calumny and squabbling elided]

The only way Sugar users can access activities not already installed
is by ASLO (unless we have some really carefully hidden source).

Open the Terminal activity

if not yet installed, install git from upstream repos, eg

   dnf install git

or

   apt install git

depending on the underlying distro (which, remember, constitutes the bulk of 
the system and on which Sugar has a hard dependency).

Then

   git clone https://example.com/some/path

at this point, what's done depends on the package in question, but it's 
entirely possible to launch an activity from that directory, or to install it 
by copying it into ~/Activities

That's off the top of my head, from memory, and may require some minor tweaks, 
but I did see 10 people do this within the last month.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Tony Anderson]

Thanks for this. ASLO is our access to a rich library of Sugar 
activities. It has and continues to work well. Walter's recent post of 
Turtle Blocks version 218 is exemplary of the proper process and that it 
works.


The problem with ASLO is neglect of the actvities. Walter initiated a 
move of activity source code to github. The apparent goal of this 
initiative is to deal with the fact that the original contributor of 
most activities is no longer activie. Moving the source to github has no 
technical basis (the source code for an activity is in the xo bundle and 
has the advantage of being the code actually executed on the device. It 
is to open up maintenance of the activities to any member of the 
community - something not possible in the ASLO process.


One of the problems in ASLO is that the activity is claimed to work with 
all versions of Sugar bewteen 0.82 and 0.104 - something which not 
verifiable and probably not true.


One option is to assert that activities work on 0.110 and 0.112 since 
that assertion can be tested. We could have an LTS version of Sugar and 
assert that activities will be updated to work on that version over a 
period of time. Along with this we need a help line (h...@sugarlabs.org 
where users can report problems or ask how to accomplish a particular 
task, or to request a new capability. This could be monitored by 
experienced users (support gang). This technique was accomplished for 
OLPC by Adam Holt and was one of the most important factors in expanding 
use of the XO.


Tony


On Friday, 25 May, 2018 01:56 AM, Alex Perez wrote:

Folks,

These attitudes are totally unhelpful, and I urge you to drop it, stop 
hurling insults. To be honest, I think both of you have valid points, 
and for the time being, I am not a fan of shutting down the legacy 
ASLO, until we have data that it's _really_ not being used. Removing 
the link from the landing page of the next version of sugar is a 
different thing entirely, so let's not conflate them. The deployed 
base on XO machines is largely running very old versions of Sugar, and 
many of those activities likely work fine with those old versions of 
Sugar. This is something I do not think James is considering, but 
perhaps I'm wrong.


We have access logs for ASLO. We can easily determine how often, and 
which, activities are downloaded. I do not personally know which server.


What we may lack, metric-wise, is what the version of Sugar on the 
client machine is. Is this encoded into the user agent of the custom 
browser, by chance? I assume not, but it's worth asking the question.



Tony Anderson 
May 23, 2018 at 11:27 PM
James Cameron's devotion to alternate facts is what is amusing 
(actually sad). The only way Sugar users can access activities not 
already installed is by ASLO (unless we have some really carefully 
hidden source).


Tony




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
James Cameron 
May 23, 2018 at 5:54 PM
Copyright on the source code of these activities is held by their
original authors, and not by Sugar Labs.

The ASLO process is a distribution of software by Sugar Labs, and the
licenses are in the source code bundles.  It makes no real difference
what was entered into ASLO as metadata, what matters is the copyright
and license declaration in the source code.

Up until last year, ASLO did not require a license.  A pending change
to ASLO had not been put into production.  Since that change, each new
upload to ASLO has had to have a license field added if there wasn't
one.  But again, this license field is only a summary, and has little
bearing.  What matters is the copyright and license in the source.

Whether Sugar Labs has received a letter or not is immaterial; but as
a distributor Sugar Labs need only check that the license is
acceptable before distributing.

One of the issues at hand is bundling of TurtleBlocksJS inside
Sugarizer.  Sugarizer does not use ASLO, so what ASLO did or does is
immaterial.

TurtleBlocksJS is AGPLv3+ in js/activity.js, has bundled source of
various other licenses, and has no license metadata in activity.info.

I agree that one solution is for the authors of TurtleBlocksJS to
relicense their work to one more compatible with Sugarizer's Apache
2.0 license.  Another is for Sugarizer to relicense.  Best would be a
path from AGPLv3+ to Apache 2.0; I've not found one yet.

Perhaps the new availability of Scratch on Sugarizer reduces the demand
for TurtleBlocksJS.

I certainly don't agree with Tony's suggestion there has been
arbitrary choice of license in GitHub repositories, and have acted and
will act to change any incorrect choice.

The other issue of porting from Python to JavaScript is creating a
derivative work, so the original license does apply.

If the source license is GPLv2 then ask the original copyright owner

Re: [Sugar-devel] licensing question

[James Cameron]

G'day Alex,

Sorry if you saw insults.

No, I would not remove link from Sugar Labs master branch of Browse.

I would remove from my fork, based on Ubuntu 18.04.  Tony's
spreadsheets show which activities work, but ASLO presents non-working
activities to users of Ubuntu 18.04 systems.  It is a product quality
issue for me.  I don't have resources to maintain all activities.

Browse does send (aka leak) Sugar version in User-Agent of all
requests;

https://github.com/sugarlabs/browse-activity/blob/230a27806544de5eb4840af95bb76d1286ad6288/browser.py#L672

ASLO does parse this from request, assuming 0.112 if missing;

https://github.com/sugarlabs/aslo/blob/507369b38e6b8923bf148f2757a8ba7db8c24c88/site/app/config/core.php#L233

ASLO does not offer activities incompatible with Sugar version, but in
a quick look I've not found code.  There are SQL select statements
with version limiting.

But Sugar version is not a proxy for distribution version.

Yes, you should be able to capture usage by version, it may already be
in logs.

On Thu, May 24, 2018 at 10:56:19AM -0700, Alex Perez wrote:
> Folks,
> 
> These attitudes are totally unhelpful, and I urge you to drop it, stop hurling
> insults. To be honest, I think both of you have valid points, and for the time
> being, I am not a fan of shutting down the legacy ASLO, until we have data 
> that
> it's _really_ not being used. Removing the link from the landing page of the
> next version of sugar is a different thing entirely, so let's not conflate
> them. The deployed base on XO machines is largely running very old versions of
> Sugar, and many of those activities likely work fine with those old versions 
> of
> Sugar. This is something I do not think James is considering, but perhaps I'm
> wrong.
> 
> We have access logs for ASLO. We can easily determine how often, and which,
> activities are downloaded. I do not personally know which server.
> 
> What we may lack, metric-wise, is what the version of Sugar on the client
> machine is. Is this encoded into the user agent of the custom browser, by
> chance? I assume not, but it's worth asking the question.
> 
> [1]Tony Anderson
> May 23, 2018 at 11:27 PM
> James Cameron's devotion to alternate facts is what is amusing (actually
> sad). The only way Sugar users can access activities not already installed
> is by ASLO (unless we have some really carefully hidden source).
> 
> Tony
> 
> ___
> Sugar-devel mailing list
> [2]Sugar-devel@lists.sugarlabs.org
> [3]http://lists.sugarlabs.org/listinfo/sugar-devel
> [4]James Cameron
> May 23, 2018 at 5:54 PM
> 
> Copyright on the source code of these activities is held by their
> original authors, and not by Sugar Labs.
> 
> The ASLO process is a distribution of software by Sugar Labs, and the
> licenses are in the source code bundles.  It makes no real difference
> what was entered into ASLO as metadata, what matters is the copyright
> and license declaration in the source code.
> 
> Up until last year, ASLO did not require a license.  A pending change
> to ASLO had not been put into production.  Since that change, each new
> upload to ASLO has had to have a license field added if there wasn't
> one.  But again, this license field is only a summary, and has little
> bearing.  What matters is the copyright and license in the source.
> 
> Whether Sugar Labs has received a letter or not is immaterial; but as
> a distributor Sugar Labs need only check that the license is
> acceptable before distributing.
> 
> One of the issues at hand is bundling of TurtleBlocksJS inside
> Sugarizer.  Sugarizer does not use ASLO, so what ASLO did or does is
> immaterial.
> 
> TurtleBlocksJS is AGPLv3+ in js/activity.js, has bundled source of
> various other licenses, and has no license metadata in activity.info.
> 
> I agree that one solution is for the authors of TurtleBlocksJS to
> relicense their work to one more compatible with Sugarizer's Apache
> 2.0 license.  Another is for Sugarizer to relicense.  Best would be a
> path from AGPLv3+ to Apache 2.0; I've not found one yet.
> 
> Perhaps the new availability of Scratch on Sugarizer reduces the demand
> for TurtleBlocksJS.
> 
> I certainly don't agree with Tony's suggestion there has been
> arbitrary choice of license in GitHub repositories, and have acted and
> will act to change any incorrect choice.
> 
> The other issue of porting from Python to JavaScript is creating a
> derivative work, so the original license does apply.
> 
> If the source license is GPLv2 then ask the original copyright owner
> to relicense as GPLv2+ or GPLv3+.  If they cannot be contacted, stop.
> 
> If the source license is GPLv2+, then anyone can relicense as GPLv3+,
> though it is convenient to ask the original copyright owners to
> agree.
> 

Re: [Sugar-devel] licensing question

[James Cameron]

On Thu, May 24, 2018 at 11:52:31AM +, D. Joe wrote:
> [...]
> Then
> 
>   git clone https://example.com/some/path
> 
> at this point, what's done depends on the package in question, but it's 
> entirely possible to launch an activity from that directory, or to install it 
> by copying it into ~/Activities 
> 
> That's off the top of my head, from memory, and may require some minor 
> tweaks, but I did see 10 people do this within the last month.

Yes, that's a viable method for some users.

For non-english locales, an extra build step via setup.py sets up the
translations.

Cloning might be made more accessible by wrapping it in a user
interface;

- in the Develop activity https://github.com/godiard/develop-activity

- as a control panel extension in My Settings
  https://github.com/sugarlabs/sugar/tree/master/extensions/cpsection

Imagine an app store presentation embedded in Sugar, with GitHub as
backend.  No infrastructure required.

Would you like to take it on?  ;-)

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Alex Perez]

Folks,

These attitudes are totally unhelpful, and I urge you to drop it, stop 
hurling insults. To be honest, I think both of you have valid points, 
and for the time being, I am not a fan of shutting down the legacy ASLO, 
until we have data that it's _really_ not being used. Removing the link 
from the landing page of the next version of sugar is a different thing 
entirely, so let's not conflate them. The deployed base on XO machines 
is largely running very old versions of Sugar, and many of those 
activities likely work fine with those old versions of Sugar. This is 
something I do not think James is considering, but perhaps I'm wrong.


We have access logs for ASLO. We can easily determine how often, and 
which, activities are downloaded. I do not personally know which server.


What we may lack, metric-wise, is what the version of Sugar on the 
client machine is. Is this encoded into the user agent of the custom 
browser, by chance? I assume not, but it's worth asking the question.



Tony Anderson 
May 23, 2018 at 11:27 PM
James Cameron's devotion to alternate facts is what is amusing 
(actually sad). The only way Sugar users can access activities not 
already installed is by ASLO (unless we have some really carefully 
hidden source).


Tony




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
James Cameron 
May 23, 2018 at 5:54 PM
Copyright on the source code of these activities is held by their
original authors, and not by Sugar Labs.

The ASLO process is a distribution of software by Sugar Labs, and the
licenses are in the source code bundles.  It makes no real difference
what was entered into ASLO as metadata, what matters is the copyright
and license declaration in the source code.

Up until last year, ASLO did not require a license.  A pending change
to ASLO had not been put into production.  Since that change, each new
upload to ASLO has had to have a license field added if there wasn't
one.  But again, this license field is only a summary, and has little
bearing.  What matters is the copyright and license in the source.

Whether Sugar Labs has received a letter or not is immaterial; but as
a distributor Sugar Labs need only check that the license is
acceptable before distributing.

One of the issues at hand is bundling of TurtleBlocksJS inside
Sugarizer.  Sugarizer does not use ASLO, so what ASLO did or does is
immaterial.

TurtleBlocksJS is AGPLv3+ in js/activity.js, has bundled source of
various other licenses, and has no license metadata in activity.info.

I agree that one solution is for the authors of TurtleBlocksJS to
relicense their work to one more compatible with Sugarizer's Apache
2.0 license.  Another is for Sugarizer to relicense.  Best would be a
path from AGPLv3+ to Apache 2.0; I've not found one yet.

Perhaps the new availability of Scratch on Sugarizer reduces the demand
for TurtleBlocksJS.

I certainly don't agree with Tony's suggestion there has been
arbitrary choice of license in GitHub repositories, and have acted and
will act to change any incorrect choice.

The other issue of porting from Python to JavaScript is creating a
derivative work, so the original license does apply.

If the source license is GPLv2 then ask the original copyright owner
to relicense as GPLv2+ or GPLv3+.  If they cannot be contacted, stop.

If the source license is GPLv2+, then anyone can relicense as GPLv3+,
though it is convenient to ask the original copyright owners to
agree.

If the source license is GPLv3+, then anyone can relicense as Apache
2.0.

For the keeping of good records, these relicensing actions should be
commits with the intent clearly stated in commit messages.

Tony's insistence on ASLO continues to amuse me.  Most distribution of
activities now happens through bundles, tarballs, and GitHub.  ASLO is
rarely used by distributors or indeed useful for anything except
personal searches for broken activities.  Tony's numbers make it
plain.  My own plan is to remove the link to "activities" in Browse
default page; plenty of disk space these days to include all working
activities in a build.

On Thu, May 24, 2018 at 08:02:30AM +0800, Tony Anderson wrote:

The bulk of the Sugar Activities were contributed through the ASLO process.
This process assumes that the contributor is the copyright-holder. The
contributor was asked to specify a license. Unfortunately that selection is not
displayed on ASLO. Therefore, it is likely that the license clause in the
activities in Github were arbitrarily chosen.

If SugarLabs has not received a letter from a lawyer in 10 years probably means
that there is no objection or that the copyright holder sees our use as fair
use.

If gplv3 is ok, it would seem that turtleblocks.js needs to change license to
gpl3 - something that Walter is fully authorized to do.

Tony

On Thursday, 24 May, 2018 07:46 

Re: [Sugar-devel] licensing question

[Walter Bender]

On Thu, May 24, 2018 at 8:11 AM D. Joe  wrote:

> On Thu, May 24, 2018 at 07:25:25AM +0200, Bastien wrote:
>
> > 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
> > about ideas.
> >
> > There might be ann issue about design sometimes, when it has been
> > separately copyrighted -- but copyright on code does not cover design
> > ideas.
>
>
> Ah, I was wondering if/when "IANAL" would finally pop up in this thread :)
>
> I'm not one, either.
>
> That said, I am aware that questions of porting and derivative work have
> caused sufficient concern in the past to drive people to use clean-room
> design in their approach to re-implementation:
>
> https://en.wikipedia.org/wiki/Clean_room_design
>
> If people are using clean-room design for Sugar and adjacent projects, I
> haven't seen it yet. :-)
>
> In the case of free software re-implementations, the exposure to
> derivative work entanglements seems even greater, since the access isn't
> just to the binaries of the upstream implementation, but usually to the
> source code, as well.
>
> One might be aware there has been ongoing concern more generally about
> codebases being published publically on code-sharing sites, but without any
> license statements. This led, for instance, to the creation of
>
> https://choosealicense.com/
>
> Similar considerations apply here: If you have access to the source code,
> but no license to do what you're trying to do, you can paint yourself into
> a corner, sharply restricting what can be done with your work (eg, who is
> willing to use, distribute, work with, contribute back to, your code).
>
> --
> Joe
>
>
In the context of this thread, there was no instance of clean room design
or binary-only access. And in every case, an existing license was
available.

-walter


> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


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

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[D. Joe]

On Thu, May 24, 2018 at 07:25:25AM +0200, Bastien wrote:

> 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
> about ideas.
> 
> There might be ann issue about design sometimes, when it has been
> separately copyrighted -- but copyright on code does not cover design
> ideas.


Ah, I was wondering if/when "IANAL" would finally pop up in this thread :)

I'm not one, either.

That said, I am aware that questions of porting and derivative work have caused 
sufficient concern in the past to drive people to use clean-room design in 
their approach to re-implementation:

https://en.wikipedia.org/wiki/Clean_room_design

If people are using clean-room design for Sugar and adjacent projects, I 
haven't seen it yet. :-)

In the case of free software re-implementations, the exposure to derivative 
work entanglements seems even greater, since the access isn't just to the 
binaries of the upstream implementation, but usually to the source code, as 
well.

One might be aware there has been ongoing concern more generally about 
codebases being published publically on code-sharing sites, but without any 
license statements. This led, for instance, to the creation of 

https://choosealicense.com/

Similar considerations apply here: If you have access to the source code, but 
no license to do what you're trying to do, you can paint yourself into a 
corner, sharply restricting what can be done with your work (eg, who is willing 
to use, distribute, work with, contribute back to, your code).

-- 
Joe


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[D. Joe]

On Thu, May 24, 2018 at 02:27:59PM +0800, Tony Anderson wrote:

[personal calumny and squabbling elided]
> The only way Sugar users can access activities not already installed
> is by ASLO (unless we have some really carefully hidden source).

Open the Terminal activity

if not yet installed, install git from upstream repos, eg

  dnf install git 

or

  apt install git

depending on the underlying distro (which, remember, constitutes the bulk of 
the system and on which Sugar has a hard dependency).

Then

  git clone https://example.com/some/path

at this point, what's done depends on the package in question, but it's 
entirely possible to launch an activity from that directory, or to install it 
by copying it into ~/Activities 

That's off the top of my head, from memory, and may require some minor tweaks, 
but I did see 10 people do this within the last month.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Tony Anderson]

James Cameron's devotion to alternate facts is what is amusing (actually 
sad). The only way Sugar users can access activities not already 
installed is by ASLO (unless we have some really carefully hidden source).


Tony

On Thursday, 24 May, 2018 08:54 AM, James Cameron wrote:

Tony's insistence on ASLO continues to amuse me.  Most distribution of
activities now happens through bundles, tarballs, and GitHub.



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Bastien]

Hi Walter,

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  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
about ideas.

There might be ann issue about design sometimes, when it has been
separately copyrighted -- but copyright on code does not cover design
ideas.

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.

Best,

-- 
 Bastien
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Dave Crossland]

On Wed, May 23, 2018, 11:28 PM James Cameron  wrote:

> On Wed, May 23, 2018 at 11:23:24PM -0400, Dave Crossland wrote:
> >
> > On Wed, May 23, 2018, 8:54 PM James Cameron <[1]qu...@laptop.org> wrote:
> >
> > If the source license is GPLv3+, then anyone can relicense as Apache
> > 2.0.
> >
> > N :)
> >
> > This is ABSOLUTELY false.
> >
> > If the source license is GPLv3+, then anyone can add new code that
> > combines with the GPLv3(+) code under Apache 2.0, because the GPLv3
> > is _compatible_ with Apache 2.0.
> >
> > No one can relicense code other than the copyright holder(s).
>
> Yay, someone's listening.  ;-)  Thanks for the correction.
>

Haha :)

What you said about "relicensing" GPLv2 to v3 isn't strictly correct
either, but it's less dangerous.

I think really what's going on there is you have permission to redistribute
using a newer version of the license, but you are not "relicensing" per se.

>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[James Cameron]

On Wed, May 23, 2018 at 11:23:24PM -0400, Dave Crossland wrote:
> 
> On Wed, May 23, 2018, 8:54 PM James Cameron <[1]qu...@laptop.org> wrote:
> 
> If the source license is GPLv3+, then anyone can relicense as Apache
> 2.0.
> 
> N :)
> 
> This is ABSOLUTELY false. 
> 
> If the source license is GPLv3+, then anyone can add new code that
> combines with the GPLv3(+) code under Apache 2.0, because the GPLv3
> is _compatible_ with Apache 2.0.
> 
> No one can relicense code other than the copyright holder(s).

Yay, someone's listening.  ;-)  Thanks for the correction.

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Dave Crossland]

On Wed, May 23, 2018, 8:54 PM James Cameron  wrote:

>
> If the source license is GPLv3+, then anyone can relicense as Apache
> 2.0.
>

N :)

>
This is ABSOLUTELY false.

If the source license is GPLv3+, then anyone can add new code that combines
with the GPLv3(+) code under Apache 2.0, because the GPLv3 is _compatible_
with Apache 2.0.

No one can relicense code other than the copyright holder(s).

What happens the "other way" when permissively licensed (Apache, MIT, BSD,
etc) code is combined with GPL code is the same: The original code remains
under it's original license, but with the additional of the new GPL code,
the whole & combined code becomes available under terms _compatible_ with
the GPL.

Affero is the same; if AGPL code becomes integrated into Sugarizer then the
whole thing must be distributed under terms compatible with the AGPL; the
majority of the work under Apache is still conveyed under Apache, but the
whole thing is also required to make source code available to every visitor.

This hinges on the definition of a derivative or combined work under
copyright, which is broad.

Similarly, while copyright doesn't cover ideas, and is limited to cover
expressions, it does cover expressions derived from earlier expressions.
Thusbit covers translation of code from one language to another.

(I found it helpful to think of it this way: it's the difference between
restrictions and requirements; restrictions are about what you can NOT do,
and requirements are about what you MUST do.

The A/GPL have additional requirements beyond those of permissive licenses,
but no additional restrictions; and the other way, the permissive licenses
have no additional restrictions beyond those in the A/GPL, which is why
they are compatible.)


Cheers
Dave

>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[James Cameron]

Copyright on the source code of these activities is held by their
original authors, and not by Sugar Labs.

The ASLO process is a distribution of software by Sugar Labs, and the
licenses are in the source code bundles.  It makes no real difference
what was entered into ASLO as metadata, what matters is the copyright
and license declaration in the source code.

Up until last year, ASLO did not require a license.  A pending change
to ASLO had not been put into production.  Since that change, each new
upload to ASLO has had to have a license field added if there wasn't
one.  But again, this license field is only a summary, and has little
bearing.  What matters is the copyright and license in the source.

Whether Sugar Labs has received a letter or not is immaterial; but as
a distributor Sugar Labs need only check that the license is
acceptable before distributing.

One of the issues at hand is bundling of TurtleBlocksJS inside
Sugarizer.  Sugarizer does not use ASLO, so what ASLO did or does is
immaterial.

TurtleBlocksJS is AGPLv3+ in js/activity.js, has bundled source of
various other licenses, and has no license metadata in activity.info.

I agree that one solution is for the authors of TurtleBlocksJS to
relicense their work to one more compatible with Sugarizer's Apache
2.0 license.  Another is for Sugarizer to relicense.  Best would be a
path from AGPLv3+ to Apache 2.0; I've not found one yet.

Perhaps the new availability of Scratch on Sugarizer reduces the demand
for TurtleBlocksJS.

I certainly don't agree with Tony's suggestion there has been
arbitrary choice of license in GitHub repositories, and have acted and
will act to change any incorrect choice.

The other issue of porting from Python to JavaScript is creating a
derivative work, so the original license does apply.

If the source license is GPLv2 then ask the original copyright owner
to relicense as GPLv2+ or GPLv3+.  If they cannot be contacted, stop.

If the source license is GPLv2+, then anyone can relicense as GPLv3+,
though it is convenient to ask the original copyright owners to
agree.

If the source license is GPLv3+, then anyone can relicense as Apache
2.0.

For the keeping of good records, these relicensing actions should be
commits with the intent clearly stated in commit messages.

Tony's insistence on ASLO continues to amuse me.  Most distribution of
activities now happens through bundles, tarballs, and GitHub.  ASLO is
rarely used by distributors or indeed useful for anything except
personal searches for broken activities.  Tony's numbers make it
plain.  My own plan is to remove the link to "activities" in Browse
default page; plenty of disk space these days to include all working
activities in a build.

On Thu, May 24, 2018 at 08:02:30AM +0800, Tony Anderson wrote:
> The bulk of the Sugar Activities were contributed through the ASLO process.
> This process assumes that the contributor is the copyright-holder. The
> contributor was asked to specify a license. Unfortunately that selection is 
> not
> displayed on ASLO. Therefore, it is likely that the license clause in the
> activities in Github were arbitrarily chosen.
> 
> If SugarLabs has not received a letter from a lawyer in 10 years probably 
> means
> that there is no objection or that the copyright holder sees our use as fair
> use.
> 
> If gplv3 is ok, it would seem that turtleblocks.js needs to change license to
> gpl3 - something that Walter is fully authorized to do.
> 
> Tony
> 
> On Thursday, 24 May, 2018 07:46 AM, Walter Bender wrote:
> 
> Thank you! 
> 
> On Wed, May 23, 2018, 7:03 PM Adam Holt <[1]h...@laptop.org> wrote:
> 
> On Wed, May 23, 2018 at 6:41 PM, Walter Bender <[2]
> walter.ben...@gmail.com> wrote:
> 
> We are struggling with a licensing question [1] and were hoping
> that the SFC might be able to advise us. Can you please reach out
> to them in your role as liaison?
> 
> I've emailed Karen Sandler (SFConservancy) asking how/who we should
> approach -
> 
> Adam
> 
> thx
> 
> -walter
> 
> [1] [3]https://github.com/llaske/sugarizer/issues/48
> 
> --
> Walter Bender
> Sugar Labs
> [4]http://www.sugarlabs.org
> 
> --
> [5]Unsung Heroes of OLPC, interviewed live @ [6]http://
> unleashkids.org !
>
> 
>
> ___
> Sugar-devel mailing list
> [7]Sugar-devel@lists.sugarlabs.org
> [8]http://lists.sugarlabs.org/listinfo/sugar-devel
> 
> References:
> 
> [1] mailto:h...@laptop.org
> [2] mailto:walter.ben...@gmail.com
> [3] https://github.com/llaske/sugarizer/issues/48
> [4] http://www.sugarlabs.org/
> [5] http://www.sugarlabs.org/
> [6] http://unleashkids.org/
> [7] mailto:Sugar-devel@lists.sugarlabs.org
> [8] http://lists.sugarlabs.org/listinfo/sugar-devel

> 

Re: [Sugar-devel] licensing question

[Walter Bender]

On Wed, May 23, 2018 at 8:03 PM Tony Anderson  wrote:

> The bulk of the Sugar Activities were contributed through the ASLO
> process. This process assumes that the contributor is the copyright-holder.
> The contributor was asked to specify a license. Unfortunately that
> selection is not displayed on ASLO. Therefore, it is likely that the
> license clause in the activities in Github were arbitrarily chosen.
>

We've been trying to take great care to find evidence of the aiuthor's
intent before adding any missing license information on the github repos.
If it is not obvious, we try to contact the author. We are not choosing
licenses arbitrarily.

>
> If SugarLabs has not received a letter from a lawyer in 10 years probably
> means that there is no objection or that the copyright holder sees our use
> as fair use.
>
> If gplv3 is ok, it would seem that turtleblocks.js needs to change license
> to gpl3 - something that Walter is fully authorized to do.
>

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.
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. What I think everyone agrees is that we want to sort this out so
that both the code bases can move forward.

>
> Tony
>
>
> On Thursday, 24 May, 2018 07:46 AM, Walter Bender wrote:
>
> Thank you!
>
> On Wed, May 23, 2018, 7:03 PM Adam Holt  wrote:
>
>> On Wed, May 23, 2018 at 6:41 PM, Walter Bender 
>> wrote:
>>
>>> We are struggling with a licensing question [1] and were hoping that the
>>> SFC might be able to advise us. Can you please reach out to them in your
>>> role as liaison?
>>>
>>
>> I've emailed Karen Sandler (SFConservancy) asking how/who we should
>> approach -
>>
>> Adam
>>
>> thx
>>>
>>> -walter
>>>
>>> [1] https://github.com/llaske/sugarizer/issues/48
>>>
>>> --
>>> Walter Bender
>>> Sugar Labs
>>> http://www.sugarlabs.org
>>>
>>> --
>>> 
>>> Unsung Heroes of OLPC, interviewed live @ 
>>> http://unleashkids.org !
>>>
>>
>
> ___
> Sugar-devel mailing 
> listSugar-devel@lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>

regards.

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

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Tony Anderson]

The bulk of the Sugar Activities were contributed through the ASLO 
process. This process assumes that the contributor is the 
copyright-holder. The contributor was asked to specify a license. 
Unfortunately that selection is not displayed on ASLO. Therefore, it is 
likely that the license clause in the activities in Github were 
arbitrarily chosen.


If SugarLabs has not received a letter from a lawyer in 10 years 
probably means that there is no objection or that the copyright holder 
sees our use as fair use.


If gplv3 is ok, it would seem that turtleblocks.js needs to change 
license to gpl3 - something that Walter is fully authorized to do.


Tony


On Thursday, 24 May, 2018 07:46 AM, Walter Bender wrote:

Thank you!

On Wed, May 23, 2018, 7:03 PM Adam Holt > wrote:


On Wed, May 23, 2018 at 6:41 PM, Walter Bender
> wrote:

We are struggling with a licensing question [1] and were
hoping that the SFC might be able to advise us. Can you please
reach out to them in your role as liaison?


I've emailed Karen Sandler (SFConservancy) asking how/who we
should approach -

Adam

thx

-walter

[1] https://github.com/llaske/sugarizer/issues/48

-- 
Walter Bender

Sugar Labs
http://www.sugarlabs.org

-- 
Unsung Heroes of OLPC, interviewed live @

http://unleashkids.org !



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Walter Bender]

Thank you!

On Wed, May 23, 2018, 7:03 PM Adam Holt  wrote:

> On Wed, May 23, 2018 at 6:41 PM, Walter Bender 
> wrote:
>
>> We are struggling with a licensing question [1] and were hoping that the
>> SFC might be able to advise us. Can you please reach out to them in your
>> role as liaison?
>>
>
> I've emailed Karen Sandler (SFConservancy) asking how/who we should
> approach -
>
> Adam
>
> thx
>>
>> -walter
>>
>> [1] https://github.com/llaske/sugarizer/issues/48
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>>
>> --
>> 
>> 
>> Unsung Heroes of OLPC, interviewed live @ 
>> http://unleashkids.org !
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] licensing question

[Adam Holt]

On Wed, May 23, 2018 at 6:41 PM, Walter Bender 
wrote:

> We are struggling with a licensing question [1] and were hoping that the
> SFC might be able to advise us. Can you please reach out to them in your
> role as liaison?
>

I've emailed Karen Sandler (SFConservancy) asking how/who we should
approach -

Adam

thx
>
> -walter
>
> [1] https://github.com/llaske/sugarizer/issues/48
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
> --
> 
> 
> Unsung Heroes of OLPC, interviewed live @ 
> http://unleashkids.org !
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] licensing question

[Walter Bender]

We are struggling with a licensing question [1] and were hoping that the
SFC might be able to advise us. Can you please reach out to them in your
role as liaison?

thx

-walter

[1] https://github.com/llaske/sugarizer/issues/48

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

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel