Re: [License-discuss] Strong and weak copyleft
Well, the FSF itself uses the concept of weak: For example, when describing WxWidgets: Like the LGPL it is a weak copyleft license, so we recommend it only in special circumstances. So, at least according to https://www.gnu.org/philosophy/license-list.html, the FSF considers LGPL as weak copyleft. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
On 09/04/15 15:27, Jim Jagielski wrote: Well, the FSF itself uses the concept of weak: For example, when describing WxWidgets: Like the LGPL it is a weak copyleft license, so we recommend it only in special circumstances. So, at least according to https://www.gnu.org/philosophy/license-list.html, the FSF considers LGPL as weak copyleft. One occasionally wonders if the FSF doesn't consider the GPLv2 to be a weak copyleft ;-) The normal definition of weak that I have seen is a copyleft whose scope applies only to the code specifically licensed under it, e.g. the MPLv2. The LGPL rather falls in between this definition of weak, and the strong copyleft of the GPL. Gerv ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
Quoting Gervase Markham (g...@mozilla.org): The normal definition of weak that I have seen is a copyleft whose scope applies only to the code specifically licensed under it, e.g. the MPLv2. The LGPL rather falls in between this definition of weak, and the strong copyleft of the GPL. This matches my understanding of the term, FWIW. My recollection is that MPL is the canonical example about which the term was coined. -- Cheers, I'm ashamed at how often I use a thesaurus. I mean bashful. Rick MoenEmbarrassed! Wait--humiliated. Repentant. Chagrined! Sh*t! r...@linuxmafia.com-- @cinemasins McQ! (4x80) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
Maybe we can summarize so far: ULTRA-STRONG(AGPL) STRONG (GPL) MORE THAN WEAK (LGPL) ALMOST WEAK (EPL) WEAK(MPL) VERY WEAK (APACHE) ULTRA-WEAK (CC0) This rather simple scale is not reflected in copyright law or any relevant cases. It is not part of the Free Software Guidelines or the Open Source Definition. It bears no resemblance whatsoever to the definition of derivative work. It is based here in this thread on obscure quotes from various websites or opinions about license author's intent without quoting the actual provisions of the licenses that enable these vague distinctions. This is one of the issues raised by the VMware complaint in Germany, and we're expecting a court to make a decision about how strong the GPL is. This email thread is still not very helpful. /Larry ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
Jim Jagielski scripsit: So, at least according to https://www.gnu.org/philosophy/license-list.html, the FSF considers LGPL as weak copyleft. Looking at the uses of 'weak' on that page suggests that to the FSF, at least, a weak copyleft license is one that permits the licensed work to be incorporated in a larger proprietary work, whereas a strong copyleft license does not (at least in the FSF's opinion). This seems an appropriate distinction for general use. Neither of these should be confused with Grave and Perilous Licenses. -- John Cowan http://www.ccil.org/~cowanco...@ccil.org No, John. I want formats that are actually useful, rather than over- featured megaliths that address all questions by piling on ridiculous internal links in forms which are hideously over-complex. --Simon St. Laurent on xml-dev ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
Interesting - I always thought that the distinction between strong and weak copyleft was in respect of how the code is linked. Are there any/many examples however of weak copyleft given that definition? I would have thought that weak copyleft under that definition would be largely ineffective, as it would be easy enough to hide any modifications to third-party copyleft code in other proprietary source files with function calls. Therefore, ought the definition of weak copyleft extend to include any code additionally referred to in the third party source file? Also, ought then the distinction not be on how individual source files are licenced, but instead the subdivisions (e.g. functions) within the source files? This has probably already been considered and dealt with before - I'm just being verbose and thinking out loud in my lunch break. -- Maximilian On 07/04/2015 19:40, Simon Phipps wrote: It looks like you may consider LGPL to be a weak copyleft license; my apologies if you don't! But if you do... I do not believe the LGPL to be a weak copyleft license. Strong copyleft implies that the scope of the required reciprocity is the source needed to create the distributed binary, while weak copyleft implies that scope to be the altered source file alone. The LGPL requirements, like those of the GPL, are scoped at the distributed binary, but there is a restriction to what constitutes the distributed binary. Thus I refer to LGPL as scope-limited strong copyleft and discourage clients from regarding it as weak copyleft. Treating LGPL as weak copyleft is a dangerous thing to do as, in the absence of conditions to make the limitation of scope apply, LGPL has all the same consequences as GPL. S. On Tue, Apr 7, 2015 at 7:29 PM, Ben Tilly bti...@gmail.com wrote: I believe that the legal key is distribution of the licensed code, not linking to it. The LGPL defines a Combined Work and has requirements on what is required when you distribute a combined work together. The intent is clearly that if you distribute the combined work together and DO NOT meet those conditions, then you had no permission to distribute the LGPLed code. And this has force because while the proprietary half of a combined work is not a derived work, you still need permission to distribute some else's copyrighted code and that permission was contingent on what you did with your application. The GPL defines a covered work to be, either the unmodified Program or a work based on the Program. Later in the license a distinction is drawn between that and mere aggregation. The intent is that distributing your program + the covered GPLed code it depends on creates a work and you need GPL permission to have distributed the covered GPLed code. (Whether a judge will agree with this interpretation is another question, but I'm pretty sure that the license drafters intended a judge to understand it this way.) With that said, the LGPL gives a lot of license flexibility for your part of the combined work but says you must allow reverse engineering. Which by default is allowed in many places, but is something that many proprietary licenses take away. By contrast the GPL offers no real alternative but to license the code you own under the GPL. Therefore LGPLed code keeps itself copylefted but does not encourage developers to GPL their own code. While GPLed code pushes people who want to use that code to have to GPL the code that they wrote. On Tue, Apr 7, 2015 at 10:23 AM, Lawrence Rosen lro...@rosenlaw.com wrote: Patrice-Emmanuel Schmitz referred me to this thought-provoking link: https://joinup.ec.europa.eu/community/eupl/news/meaning-%E2%80%9Ccopyleft%E2%80%9D-eupl Can anyone here precisely identify the language in the GPL licenses that makes it strong rather than weak copyleft? And can anyone here identify anything in copyright law or cases that allow this distinction in the meaning of derivative work? /Larry ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
I believe that the legal key is distribution of the licensed code, not linking to it. The LGPL defines a Combined Work and has requirements on what is required when you distribute a combined work together. The intent is clearly that if you distribute the combined work together and DO NOT meet those conditions, then you had no permission to distribute the LGPLed code. And this has force because while the proprietary half of a combined work is not a derived work, you still need permission to distribute some else's copyrighted code and that permission was contingent on what you did with your application. The GPL defines a covered work to be, either the unmodified Program or a work based on the Program. Later in the license a distinction is drawn between that and mere aggregation. The intent is that distributing your program + the covered GPLed code it depends on creates a work and you need GPL permission to have distributed the covered GPLed code. (Whether a judge will agree with this interpretation is another question, but I'm pretty sure that the license drafters intended a judge to understand it this way.) With that said, the LGPL gives a lot of license flexibility for your part of the combined work but says you must allow reverse engineering. Which by default is allowed in many places, but is something that many proprietary licenses take away. By contrast the GPL offers no real alternative but to license the code you own under the GPL. Therefore LGPLed code keeps itself copylefted but does not encourage developers to GPL their own code. While GPLed code pushes people who want to use that code to have to GPL the code that they wrote. On Tue, Apr 7, 2015 at 10:23 AM, Lawrence Rosen lro...@rosenlaw.com wrote: Patrice-Emmanuel Schmitz referred me to this thought-provoking link: https://joinup.ec.europa.eu/community/eupl/news/meaning-%E2%80%9Ccopyleft%E2%80%9D-eupl Can anyone here precisely identify the language in the GPL licenses that makes it strong rather than weak copyleft? And can anyone here identify anything in copyright law or cases that allow this distinction in the meaning of derivative work? /Larry ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Strong and weak copyleft
It looks like you may consider LGPL to be a weak copyleft license; my apologies if you don't! But if you do... I do not believe the LGPL to be a weak copyleft license. Strong copyleft implies that the scope of the required reciprocity is the source needed to create the distributed binary, while weak copyleft implies that scope to be the altered source file alone. The LGPL requirements, like those of the GPL, are scoped at the distributed binary, but there is a restriction to what constitutes the distributed binary. Thus I refer to LGPL as scope-limited strong copyleft and discourage clients from regarding it as weak copyleft. Treating LGPL as weak copyleft is a dangerous thing to do as, in the absence of conditions to make the limitation of scope apply, LGPL has all the same consequences as GPL. S. On Tue, Apr 7, 2015 at 7:29 PM, Ben Tilly bti...@gmail.com wrote: I believe that the legal key is distribution of the licensed code, not linking to it. The LGPL defines a Combined Work and has requirements on what is required when you distribute a combined work together. The intent is clearly that if you distribute the combined work together and DO NOT meet those conditions, then you had no permission to distribute the LGPLed code. And this has force because while the proprietary half of a combined work is not a derived work, you still need permission to distribute some else's copyrighted code and that permission was contingent on what you did with your application. The GPL defines a covered work to be, either the unmodified Program or a work based on the Program. Later in the license a distinction is drawn between that and mere aggregation. The intent is that distributing your program + the covered GPLed code it depends on creates a work and you need GPL permission to have distributed the covered GPLed code. (Whether a judge will agree with this interpretation is another question, but I'm pretty sure that the license drafters intended a judge to understand it this way.) With that said, the LGPL gives a lot of license flexibility for your part of the combined work but says you must allow reverse engineering. Which by default is allowed in many places, but is something that many proprietary licenses take away. By contrast the GPL offers no real alternative but to license the code you own under the GPL. Therefore LGPLed code keeps itself copylefted but does not encourage developers to GPL their own code. While GPLed code pushes people who want to use that code to have to GPL the code that they wrote. On Tue, Apr 7, 2015 at 10:23 AM, Lawrence Rosen lro...@rosenlaw.com wrote: Patrice-Emmanuel Schmitz referred me to this thought-provoking link: https://joinup.ec.europa.eu/community/eupl/news/meaning-%E2%80%9Ccopyleft%E2%80%9D-eupl Can anyone here precisely identify the language in the GPL licenses that makes it strong rather than weak copyleft? And can anyone here identify anything in copyright law or cases that allow this distinction in the meaning of derivative work? /Larry ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss -- Simon Phipps*, OSI President* +44 238 098 7027 or +1 415 683 7660 : www.opensource.org ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
