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
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel