Re: [E-devel] COPYING spec files
On Tuesday, 17 August 2010, at 07:53:22 (+0100), Rui Miguel Silva Seabra wrote: His opinion of that BSD license, like any other, is the same: it is not Good and Right because it fails to guarantee the freedoms of software recipients. An important consideration to make in such statements is that that would only be true if one is talking about the original BSD license... http://www.gnu.org/licenses/license-list.html#OriginalBSD ...which includes what's known as the obnoxious advertising clause. Actually, that would only be true if he concluded that the original BSD license was non-free license. It is a free software license. It's just permissive and non-copyleft and is incompatible with the GPL. The modified BSD license is also permissive and non-copyleft, but it's GPL compatible. That's why he says it's reasonable. (Yes, he has a practical argument as well, and a valid one, but that's not his primary reason.) What most people think of when they say bsd license nowadays is actually the Modified BSD or three-clause BSD license. If one reads what he writes about it in... http://www.gnu.org/licenses/license-list.html#ModifiedBSD ... one can actually read an endorsement: If you want a simple, permissive non-copyleft free software license, the modified BSD license is a reasonable choice. However, it is risky to recommend use of ?the BSD license?, because confusion could easily occur and lead to use of the flawed original BSD license. To avoid this risk, you can suggest the X11 license instead. The X11 license and the revised BSD license are more or less equivalent. This license is sometimes referred to as the 3-clause BSD license. He supports use of the modified BSD license IFF[1] you require a free software license which is non-copyleft. That's like saying, If you refuse to walk everywhere, at least drive something that runs on biodiesel. That's not the same as saying, I support your right to drive your car. If you won't do things his way, or in special circumstances where his Free Software movement benefits from doing things differently, other licenses are permissible. But those are situations where it's Necessary not to do things Right. Being the next best option doesn't make something Good and Right. (And not being Good and Right doesn't mean Evil either...any free license is better than a non-free license.) His perfect world would entail ALL software being GPL'd, all documentation being FDL'd, etc. But he's a pragmatic strategist; he knows that compromises must be made to progress toward the goal. Trust me. I work for UCB *and* LBL (which you'll find mentioned in your first link) with some of the people who created BSD, and I've spoken to RMS in person about this very subject. I know where he's coming from, and I know that we have fundamental differences on what constitutes Freedom and how best to use licenses to achieve it. Anything one may interpret as an endorsement of a non-GPL software license is simply a means to an end (e.g., popularizing a Free replacement to multiple Proprietary media formats). Michael [1] iff means if, and only if, ... -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- You can bend over for Blue Cross, and you can bend over for Kaiser. Blue Cross is nice because they give you two ways to bend over. -- anonymous co-worker -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Domingo 15 Agosto 2010 14:33:06 Joerg Sonnenberger escribió: edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. Edje's COPYING file[1] is quite similar to the Vorbis BSD-Like license[2] which was endorsed by Stallman[3] itself. Perhaps looking at the Vorbis pkgsrc might solve your packaging issues? [1] http://trac.enlightenment.org/e/browser/trunk/edje/COPYING [2] http://www.xiph.org/licenses/bsd/ [3] http://en.wikipedia.org/wiki/Vorbis#Licensing The licence war thing was already done and OSI compliance was not preferred nor considered a requirement IIRC. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Sun, Aug 15, 2010 at 6:41 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 16 Aug 2010 00:33:33 +0200 Joerg Sonnenberger jo...@britannica.bec.de said: On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote: edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. if you only ship OSI approved software then you won't be shipping efl. :) but yes. copyright notice seems to have vanished. odd. need to fix that. anyway - the license is the 2 clause bsd with addendum that effectively makes it like lgpl which removes the gpl incompatibility. it provides no restrictions on apps or libs that link to the the efl lib. it provides for restrictions for people distributing the efl lib as stand-alone or statically compiled. if by incompatibility you mean either gpl apps using efl libraries OR gpl apps shipping along inside a distro package set with these efl apps. The 2-clause BSD license is GPL compatible. The primary difference between 2-clause BSD license and MIT license is the clarification that binary distributions have to provide the copyright notice separately in text form. From the COPYING-PLAIN, I can't find a reason to not use the straight forward 2-clause BSD license, if the above is your only concern. well the intent is to still get some kind of acknowledgment. be it via a simple ldd and see what it links to or a ls /usr/lib and see libevas.so* or via a notice in documentation, source code publication or email etc. - some mechanism to say hey - we used your stuff. the 2 clause bsd doesn't. the 3 clause does but creates compat issues. the efl modified 3 clause should be issue-free. Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) argh. sachiel... why did you add that in? as such we dont put separate copyright notices per file (mostly because it creates maintenance hassle and is not strictly needed - it's a legal nicety if someone steals a file wholesale - but then they wont be shipping it as source anyway and so will be hidden no matter what). WTF?!?!? I don't like at all the *GPL, when did I add that? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Mon, 16 Aug 2010 15:01:02 -0300 Iván Briano (Sachiel) sachi...@gmail.com said: Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) argh. sachiel... why did you add that in? as such we dont put separate copyright notices per file (mostly because it creates maintenance hassle and is not strictly needed - it's a legal nicety if someone steals a file wholesale - but then they wont be shipping it as source anyway and so will be hidden no matter what). WTF?!?!? I don't like at all the *GPL, when did I add that? rev 42552 - you added in a patch from thiago, fabio + lima. removed. 42552sachiel * This library is free software; you can redistribute it and/or 42552sachiel * modify it under the terms of the GNU Lesser General Public -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Mon, Aug 16, 2010 at 5:22 PM, Carsten Haitzler ras...@rasterman.com wrote: On Mon, 16 Aug 2010 15:01:02 -0300 Iván Briano (Sachiel) sachi...@gmail.com said: Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) argh. sachiel... why did you add that in? as such we dont put separate copyright notices per file (mostly because it creates maintenance hassle and is not strictly needed - it's a legal nicety if someone steals a file wholesale - but then they wont be shipping it as source anyway and so will be hidden no matter what). WTF?!?!? I don't like at all the *GPL, when did I add that? rev 42552 - you added in a patch from thiago, fabio + lima. removed. 42552 sachiel * This library is free software; you can redistribute it and/or 42552 sachiel * modify it under the terms of the GNU Lesser General Public Yeah, thought it would be something like that. But it was probably some fix in the formatting of it. The copyright itself was from cedric, so I guess he added the header in there. Anyway, gone now and we can all be happy again. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler) ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Monday, 16 August 2010, at 09:41:37 (-0300), Andres Blanc wrote: Edje's COPYING file[1] is quite similar to the Vorbis BSD-Like license[2] which was endorsed by Stallman[3] itself. I think you misunderstood. Stallman wasn't endorsing the license. He was endorsing the change in that *particular* instance because it furthers his overall agenda: providing Free alternatives for all Non-Free software. His opinion of that BSD license, like any other, is the same: it is not Good and Right because it fails to guarantee the freedoms of software recipients. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- A woman broke up with me and sent me pictures of her and her new boyfriend in bed together. Solution? I sent them to her dad. -- Christopher Case -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] COPYING spec files
Hi all, I'm just going over the various COPYING files to prepare tagging the appropiate licenses for pkgsrc. e_dbus: I'm not sure if this is intentional, but this is certainly not the MIT license and it looks like it is functionally equal or stronger than the original BSD license. E.g. it might not be GPL compatible. See the third paragraph (... its documentation and marketing publicy materials, ...). So calling it a BSD license in the spec file is only partially true. ecore: License in spec should be MIT if RPM distinguishes this. edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. eet: Same as edje. efreet: Same as e_dbus. embryo: Same as edje. enlightenment: Same as edje evas: Same as edje Summary: Having two licenses that aren't OSI approved is suboptimal. It would make corporate usage at least somewhat easier to have only OSI approved licenses as there are a lot of guidelines dealing with those already. At the very least, it would be useful to only have a single non-LGPL license, in which case the (weaker) edje version is preferable. I'm bringing this up (again) now since having consistency useful for EFL 1.0.0. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Sun, 15 Aug 2010 19:33:06 +0200 Joerg Sonnenberger jo...@britannica.bec.de said: Hi all, I'm just going over the various COPYING files to prepare tagging the appropiate licenses for pkgsrc. e_dbus: I'm not sure if this is intentional, but this is certainly not the MIT license and it looks like it is functionally equal or stronger than the original BSD license. E.g. it might not be GPL compatible. See the third paragraph (... its documentation and marketing publicy materials, ...). So calling it a BSD license in the spec file is only partially true. indeed something that needs to be done for alpha - it needs a COPYING-PLAIN that clarifies this clause. see copying-plain. that boils it down to having an acknowledgement of some sort. as such dynamically linking to the library is an acknowledgement. statically linking though is hiding that. of course if you then ship the source like you would have to with LGPL, you then acknowledge use.. so... it acts as LGPL in that case. - thus the advertising clause kicks in with documentation etc. etc. etc. - we've been through this before with redhat asking about the license. though i am talking of the copying etc. you see in eet, evas, etc. here we are just missing the COPYING-PLAIN and have the old style advertising clause with no exemptions that remove gpl incompatibility. i don't know why the licensing here is different to evas/edje/eet etc. can someone clarify? ecore: License in spec should be MIT if RPM distinguishes this. COPYING-PLAIN included but COPYING is wrong - see evas + edje + eet. it should have been that. edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. if you only ship OSI approved software then you won't be shipping efl. :) but yes. copyright notice seems to have vanished. odd. need to fix that. anyway - the license is the 2 clause bsd with addendum that effectively makes it like lgpl which removes the gpl incompatibility. it provides no restrictions on apps or libs that link to the the efl lib. it provides for restrictions for people distributing the efl lib as stand-alone or statically compiled. if by incompatibility you mean either gpl apps using efl libraries OR gpl apps shipping along inside a distro package set with these efl apps. eet: Same as edje. efreet: Same as e_dbus. embryo: Same as edje. enlightenment: Same as edje evas: Same as edje Summary: Having two licenses that aren't OSI approved is suboptimal. It would make corporate usage at least somewhat easier to have only OSI approved licenses as there are a lot of guidelines dealing with those already. At the very least, it would be useful to only have a single non-LGPL license, in which case the (weaker) edje version is preferable. I'm bringing this up (again) now since having consistency useful for EFL 1.0.0. yup. agreed. at least the intent is to have the weaker one. efreet, e_dbus and eeze too are imho not set up right - the intent at least is they should be compatible if they want to come out of our svn and release. the choice is lgpl or efl license. i fixed the copyright missing bit in the other libs. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote: edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. if you only ship OSI approved software then you won't be shipping efl. :) but yes. copyright notice seems to have vanished. odd. need to fix that. anyway - the license is the 2 clause bsd with addendum that effectively makes it like lgpl which removes the gpl incompatibility. it provides no restrictions on apps or libs that link to the the efl lib. it provides for restrictions for people distributing the efl lib as stand-alone or statically compiled. if by incompatibility you mean either gpl apps using efl libraries OR gpl apps shipping along inside a distro package set with these efl apps. The 2-clause BSD license is GPL compatible. The primary difference between 2-clause BSD license and MIT license is the clarification that binary distributions have to provide the copyright notice separately in text form. From the COPYING-PLAIN, I can't find a reason to not use the straight forward 2-clause BSD license, if the above is your only concern. Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Mon, 16 Aug 2010 00:33:33 +0200 Joerg Sonnenberger jo...@britannica.bec.de said: On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote: edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. if you only ship OSI approved software then you won't be shipping efl. :) but yes. copyright notice seems to have vanished. odd. need to fix that. anyway - the license is the 2 clause bsd with addendum that effectively makes it like lgpl which removes the gpl incompatibility. it provides no restrictions on apps or libs that link to the the efl lib. it provides for restrictions for people distributing the efl lib as stand-alone or statically compiled. if by incompatibility you mean either gpl apps using efl libraries OR gpl apps shipping along inside a distro package set with these efl apps. The 2-clause BSD license is GPL compatible. The primary difference between 2-clause BSD license and MIT license is the clarification that binary distributions have to provide the copyright notice separately in text form. From the COPYING-PLAIN, I can't find a reason to not use the straight forward 2-clause BSD license, if the above is your only concern. well the intent is to still get some kind of acknowledgment. be it via a simple ldd and see what it links to or a ls /usr/lib and see libevas.so* or via a notice in documentation, source code publication or email etc. - some mechanism to say hey - we used your stuff. the 2 clause bsd doesn't. the 3 clause does but creates compat issues. the efl modified 3 clause should be issue-free. Just by chance, edje_cache.c has a copyright and LGPL license header. It might be useful to carefully check for those as well :) argh. sachiel... why did you add that in? as such we dont put separate copyright notices per file (mostly because it creates maintenance hassle and is not strictly needed - it's a legal nicety if someone steals a file wholesale - but then they wont be shipping it as source anyway and so will be hidden no matter what). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] COPYING spec files
On Mon, Aug 16, 2010 at 07:41:01AM +1000, Carsten Haitzler wrote: On Mon, 16 Aug 2010 00:33:33 +0200 Joerg Sonnenberger jo...@britannica.bec.de said: On Mon, Aug 16, 2010 at 07:13:13AM +1000, Carsten Haitzler wrote: edje: The second paragraph is non-OSI and some parts are weird, e.g. the file doesn't actually contain a copyright notice. I think the 2-clause BSD license covers the intention and is OSI approved, but that's your call. if you only ship OSI approved software then you won't be shipping efl. :) but yes. copyright notice seems to have vanished. odd. need to fix that. anyway - the license is the 2 clause bsd with addendum that effectively makes it like lgpl which removes the gpl incompatibility. it provides no restrictions on apps or libs that link to the the efl lib. it provides for restrictions for people distributing the efl lib as stand-alone or statically compiled. if by incompatibility you mean either gpl apps using efl libraries OR gpl apps shipping along inside a distro package set with these efl apps. The 2-clause BSD license is GPL compatible. The primary difference between 2-clause BSD license and MIT license is the clarification that binary distributions have to provide the copyright notice separately in text form. From the COPYING-PLAIN, I can't find a reason to not use the straight forward 2-clause BSD license, if the above is your only concern. well the intent is to still get some kind of acknowledgment. be it via a simple ldd and see what it links to or a ls /usr/lib and see libevas.so* or via a notice in documentation, source code publication or email etc. - some mechanism to say hey - we used your stuff. the 2 clause bsd doesn't. the 3 clause does but creates compat issues. the efl modified 3 clause should be issue-free. To avoid confusion: http://opensource.org/licenses/bsd-license.php is the canonical reference. 2-clause BSD license drops the endorsement clause. The normal way to fulfill clause 2 (Redistribution in binary form) is to either also provide source code or to have a LEGAL file somewhere. The difference to the original (4-clause) BSD license is that you don't have to put it in the fine print of your ads or at the end of the user manual. The difference to the (L)GPL is that you don't have to provide the source code. The note in the place you would normally place the (L)GPL source offer is good enough. In theory, putting it as file into the flash of the machine or on the CD-ROM with the electronical manual is good enough. The legal hassle for this is reduced by having a single top-level file like COPYING. It could get even easier if that file lists the exceptions and that it is authoritive for the rest. E.g. Makefile.in and configure are not covered by COPYING. If you want a mechanism of if you use this, you have to tell us about it, you get the same problem with the GPL as the original BSD license. Just to be clear, the difference here is that it requires actively telling about the use and such it is considered by the FSF an additional restriction. Joerg -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
