[Sugar-devel] Licensing of the javascript libraries

Daniel Narvaez dwnarvaez at gmail.com
Fri Jun 7 19:30:39 EDT 2013


I'm still undecided really but since it's important to make a call soon, my
vote goes for Apache, both for sugar-web and for activities we develop.

On Saturday, 8 June 2013, Daniel Narvaez wrote:

> We really need to make a call here, we start to have a sizeable amount of
> code and the first release is near. I tend to think gplv2 is not an option
> because of the apache incompatibility. I would go for Apache if we want to
> avoid issues with anti-tivoization, otherwise gplv3.
>
> To point out a concrete problem we could have with gpl3... My
> understanding is that you could not ship an activity based on sugar-web in
> the apple store, at least including the lib locally. I suppose it would be
> fine if you loaded it from a server, but then you need security
> restrictions if you implement any kind of system integration.
>
> On Friday, 3 May 2013, Daniel Narvaez wrote:
>
>> Hello,
>>
>> we need to decide how to license the new javascript libraries. I am
>> mostly clueless about the topic and I'm honestly scared to start this
>> thread, please be gentle :)
>>
>> Following is the rationale I came up with for Agora. I think it probably
>> applies to the sugar-html libraries too. Feedback would be very welcome as
>> we are no expert.
>>
>> ---
>>
>> I spent some time trying to decide which license is better for the
>> various part of Agora. It's an hard and important decision, I'm not a
>> lawyer and not even an expert but we need to make a call. My understanding
>> is that a license is better than nothing.
>>
>> (L)GPLv2
>>
>> * Copyleft. Requires all the modifications to be made freely available.
>> * Incompatible with Apache. Pretty bad, a lot of code already licensed
>> that way and growing fast (especially in the javascript world).
>>
>> (L)GPLv3
>>
>> * Copyleft
>> * Compatiible with Apache.
>> * Anti-tivoization clause. Mixed bag, would it prevent us to run on
>> hardware we are interested in? One problematic case I can think of is
>> distributing an activity through the Apple store. We wouldn't be able to do
>> that. Though people could still install the activity as a web app, from the
>> browser. Maybe that's good enough?
>> * Latest version. Better wording etc. Patents protection.
>> * We can distribute the sugar icons under LGPLv3, without requiring any
>> relicensing, because of the "or later" clause.
>> * My understanding is that if xi-* is LGPL, proprietary applications
>> could still use it without making modifications. The situation is not as
>> clear as for the traditional linked libraries case but from
>> http://www.gnu.org/licenses/lgpl-java.html I'd think we are fine.
>>
>> Apache
>>
>> * Non copyleft. It would be more friendly to companies that might want to
>> reuse code in their products. But is that likely to happen? Both xi and
>> omega are pretty agora specific. Still I think it's a good license to use
>> for more generic bits that we might develop (I used it for some python
>> helpers I'm using in eta for example).
>> * It seems to be the best permissive license because of the patents
>> protection. It's the most popular at least.
>>
>> So I think there two choices basically:
>>
>> 1 Copyleft VS non copyleft. I think copyleft has advantages and
>> practically no real disadvantages for eta, xi and omega.
>>
>> 2 GPLv2 VS GPLv3. Compatibility with Apache would be good (maybe not
>> essential though? We could still use apache libraries I would think, just
>> not freely cut/paste code). Anti-tivoization is tricky, I honestly can't
>> make strong points one way or another. While I was initially sympathetic
>> with the claims that v3 is political I think
>> http://tieguy.org/blog/2007/06/28/gpl-v3-the-qa-part-4-odds-and-ends/ is
>> a good rebuttal of that argument. I'm somewhat worried about not being able
>> to distribute on some devices but, especially since we can always run
>> remotely, I'm not convinced we should opt out of v3 because of that.,
>>
>> --
>> Daniel Narvaez
>>
>
>
> --
> Daniel Narvaez
>
>

-- 
Daniel Narvaez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20130608/da8a127a/attachment-0001.html>


More information about the Sugar-devel mailing list