Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
Quoting Bradley M. Kuhn (bk...@ebb.org): Rick, I've tried to reply at length below on the issue of license (in)compatibility. The below is probably the most I've ever written on the subject, but it's in some ways a summary of items that discussed regularly among various Free Software licensing theorist for the past decade, particularly Richard Fontana. Thank you for your very generous and thoughtful reply, Bradley. I'll have to spend some time reading it carefully. I appreciate your time and trouble. -- Cheers, I love stateless systems. Rick Moen Don't they have drawbacks? r...@linuxmafia.com Don't what have drawbacks? McQ! (4x80) -- Sam Hughes ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
On Mon, Sep 2, 2013 at 4:16 AM, John Cowan co...@mercury.ccil.org wrote:
Al Foxone scripsit:
I doubt that Red Hat’s own End User License Agreement is
'compatible' (according to you) with the GPL'd components in that
combined work as whole. Anyway, that combined work as a whole must be
full of proclaimed 'incompatibly' licensed components (once again
according to you). How come that this is possible?
See GPLv2 section 2, the penultimate paragraph:
# [M]ere aggregation of another work not based on the Program with the
# Program (or with a work based on the Program) on a volume of a storage
# or distribution medium does not bring the other work under the scope
# of this License.
Ultimately to me that just says that the intended scope of
quasi-automatic aggregation (pooling) of copyrights under the GPL
('compatibility' as somehow less strict requirement aside) is limited
to (non-private) derivative works only.
But Mr Kuhn seems to disagree and I don't understand his position.
The corresponding paragraph of the GPLv3 is the final one of Section 5:
# A compilation of a covered work with other separate and independent
# works, which are not by their nature extensions of the covered work,
# and which are not combined with it such as to form a larger program,
This is somewhat problematic because it uses undefined terms such as
by their nature extensions and a larger program***. But I've been
told that such ambiguities are interpreted against the drafter /
licensor and not against the licensee.
So once again it seems to it says that the scope of reciprocation is
limited to (non-private) derivative works only... but Mr Kuhn seems to
disagree (at least with respect to compatibility) and I don't
understand his position.
***) e.g.
http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zappldev/zappldev_91.htm
Program management model in Language Environment
Application programming on z/OS
...
Program management
Program management defines the program execution constructs of an
application, and the semantics associated with the integration of
various management components of such constructs.
Three entities, process, enclave, and thread, are at the core of the
Language Environment program management model.
Processes
The highest level component of the Language Environment program model
is the process. A process consists of at least one enclave and is
logically separate from other processes. Language Environment
generally does not allow language file sharing across enclaves nor
does it provide the ability to access collections of externally stored
data.
Enclaves
A key feature of the program management model is the enclave, a
collection of the routines that make up an application. The enclave is
the equivalent of any of the following:
A run unit, in COBOL
A program, consisting of a main C function and its sub-functions, in C and C++
A main procedure and all of its subroutines, in PL/I
A program and its subroutines, in Fortran.
In Language Environment, environment is normally a reference to the
runtime environment of HLLs at the enclave level. The enclave consists
of one main routine and zero or more subroutines. The main routine is
the first to execute in an enclave; all subsequent routines are named
as subroutines.
Threads
Each enclave consists of at least one thread, the basic instance of a
particular routine. ...
___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
On Thu, Aug 29, 2013 at 3:51 PM, Bradley M. Kuhn bk...@ebb.org wrote: I'd suspect everyone to agree that you must meet the redistribution requirements of all copyright licenses for a given work to have permission to redistribute. Thus, license compatibility *exists* as a concept because if you make a new work that combines two existing works under different licenses, you have to make sure you've complied with the terms of both licenses. Again, I'd be surprised if anyone disputes that as a necessary task and requirement. Well, http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf Copyright law protects the expression of an idea. When Red Hat develops new software, it owns the copyright in the software. Red Hat® Enterprise Linux® consists of hundreds of software modules, some developed by Red Hat and many developed by other members of the open source community. Those authors hold the copyrights in the modules or code they developed. At the same time, the combined body of work that constitutes Red Hat® Enterprise Linux® is a collective work which has been organized by Red Hat, and Red Hat holds the copyright in that collective work. Red Hat then permits others to copy, modify and redistribute the collective work. To grant this permission Red Hat usually uses the GNU General Public License (“GPL”) version 2 and Red Hat’s own End User License Agreement. I doubt that Red Hat’s own End User License Agreement is 'compatible' (according to you) with the GPL'd components in that combined work as whole. Anyway, that combined work as a whole must be full of proclaimed 'incompatibly' licensed components (once again according to you). How come that this is possible? ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
Al Foxone scripsit: I doubt that Red Hat’s own End User License Agreement is 'compatible' (according to you) with the GPL'd components in that combined work as whole. Anyway, that combined work as a whole must be full of proclaimed 'incompatibly' licensed components (once again according to you). How come that this is possible? See GPLv2 section 2, the penultimate paragraph: # [M]ere aggregation of another work not based on the Program with the # Program (or with a work based on the Program) on a volume of a storage # or distribution medium does not bring the other work under the scope # of this License. The corresponding paragraph of the GPLv3 is the final one of Section 5: # A compilation of a covered work with other separate and independent # works, which are not by their nature extensions of the covered work, # and which are not combined with it such as to form a larger program, # in or on a volume of a storage or distribution medium, is called an # “aggregate” if the compilation and its resulting copyright are not # used to limit the access or legal rights of the compilation's users # beyond what the individual works permit. Inclusion of a covered work # in an aggregate does not cause this License to apply to the other # parts of the aggregate. -- John Cowanco...@ccil.org I amar prestar aen, han mathon ne nen,http://www.ccil.org/~cowan han mathon ne chae, a han noston ne 'wilith. --Galadriel, LOTR:FOTR ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com) launched.
Rick, I've tried to reply at length below on the issue of license (in)compatibility. The below is probably the most I've ever written on the subject, but it's in some ways a summary of items that discussed regularly among various Free Software licensing theorist for the past decade, particularly Richard Fontana. Rick wrote yesterday: It's a fair, interesting, and relevant question, and I'd really like to know the answer. Most things in policy, unlike science, aren't a technical problem where we can provide a hypothesis and test the results. So, there probably isn't an answer. I've observed that many lawyers often build their careers on *pretending* that there are answers to questions like this. Then, they simply bluster their way through to convince everyone. Since IANAL (and, BTW, TINLA), I don't tend to think that way. I won't pretend license compatibility is a testable scientific fact like Einstein's theory of relativity; it's a policy analysis and conclusion, based on what those doing the analysis think is correct and likely to be permissible under copyright. I'd actually be interested in Bradley ... pointing to any caselaw that supports [his] view. So, most importantly, I don't think there has been any litigation anywhere in the world regarding license compatibility. Specifically, Jacobsen v. Katzer didn't consider it AFAICT. And, (speaking as someone who has either advised the Plaintiff and/or actually been the 30(b)(6) witness for Plaintiff in all of the GPL enforcement lawsuits in the USA), I'm not aware of the license compatibility ever coming up in USA litigation. Also, note that, no one else in this thread has put any license compatibility caselaw forward; it just doesn't exist, AFAIK. However, even if there were caselaw, I don't think looking at the caselaw record is somehow the only way to consider these questions. My primary point throughout this thread is that Free Software projects are regularly concerned about compatibility (and license proliferation too), for good policy and project health reasons; not because of what some Court said. I'd suspect everyone to agree that you must meet the redistribution requirements of all copyright licenses for a given work to have permission to redistribute. Thus, license compatibility *exists* as a concept because if you make a new work that combines two existing works under different licenses, you have to make sure you've complied with the terms of both licenses. Again, I'd be surprised if anyone disputes that as a necessary task and requirement. Where people disagree is about whether or not you actually need copyright permission at all to create that new work. Some have a theory that it's virtually impossible to ever need such permission. I'm pretty sure that can't be right, and there is a lot of caselaw on *this* subject, but the tests that courts have come up are *highly* dependent on the facts of a specific set of circumstances for a specific work. (Dan Ravicher's article the Software Derivative Work: A Circuit Dependent Determination is a seminal source on that subject about the USA situation. Till Jaeger's talk at FOSDEM, a recording of which I already linked to in this thread, covered the European side quite well IMO.) Of course, derivative works analysis has almost *nothing* to do with license compatibility. It's just that folks love to fall into derivative works debates because it's an interesting topic, and because those whose primary goal is to circumvent copyleft as much as possible (and I've found that's most people who work as Open Source legal experts) prefer to point to the derivative works issue as some sort of insurmountable problem that is therefore the base case of every discussion about Free Software licensing. And, as you saw, this thread descended into that debate too. I suspect that's what led Luis Villa to have his oh no, not again reaction. Meanwhile, license compatibility, as a concept, is a lex mercatoria. (Fontana and others have talked at length about how much in Free Software licensing are leges mercatorum; ironically, the derivative work question may be the only central issue that *isn't* a lex mercatoria.) Specifically, no court anywhere in the world, to my knowledge, has sat down and lined two Free Software licenses up next to each other and tried to determine if, upon creating a whole work based on two works under the two licenses, if the terms of any license was violated and thus the distributor of that whole work infringed copyright of one party or the other. Thus, people argue about what a court might say. Some lawyers bluster and claim they know the answer when they really don't. (This is why I love Till's first FOSDEM slide: he admits, as a first principle, the Socratic Epiphany inherent in this type of work.) In the meantime, though, we have to operate, share code, and (hopefully) uphold software freedom -- with the tools we have. That's what led me, back when I started working
[License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Lawrence Rosen wrote at 17:00 (EDT) on Tuesday: I asked for practical examples. You cited none. In the world of copyrights or most logical pursuits, absence of evidence isn't evidence. License compatibility issues come up regularly on lots of bug tickets and threads about licensing on lots of projects. I don't have a saved file of evidence to hand you, mostly because it's such an unremarkable occurrence that I don't note it down when it happens. I see it at least once a month somewhere. I suspect anyone who follows Free Software development regularly sees it just as much. I can tell you that I dealt with two issues of license incompatibility in my day job recently, but I can't disclose the specifics since it was confidential advice. Meanwhile, if you need evidence to satisfy your curiosity right away, I'd suggest debian-legal archives would be a good place to start your research on this, but... Awaiting your evidence to the contrary ... I can't spare the time to do this basic research for you. If anyone else here does agree with you that license incompatibility isn't a problem in the real world, then perhaps it's worth continuing this thread, but I suspect you may be alone on this one. :) Most FOSS licenses (including the GPL!) don't actually define the term derivative work with enough precision to make it meaningful for court interpretation. ... The court will therefore use the statutory and case law to determine that situation. That's as it should be. It's not the job (nor is it really appropriate) for a copyright license to define statutory terms, so the GPL doesn't do that. The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. all major FOSS licenses that I'm aware of *except the GPL* make it abundantly clear that the mere combination of that licensed software with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Indeed, weaker copylefts give guidelines for certain derivative works that can be proprietarized, and the rest are left under copyleft. BTW, if you are interested in how the European lawyers view this question, I refer you to an excellent talk by Till Jaeger at FOSDEM 2013: http://www.faif.us/cast/2013/mar/26/0x39/ So what's the worry about license incompatibility all about? Is it merely that so many licenses are deemed incompatible with the GPL, Many licenses are incompatible with the Eclipse Public License, too, since it's a stronger copyleft than, say, the MPL or LGPL. There aren't very many strong copylefts around. with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Finally, I'm unlikely to respond to this thread further as I think the use of slurs like infect (notwithstanding the quotes, and '?') to refer to copyleft are just unnecessarily inflammatory. I've asked you not to talk about copyleft using slur words so many times before in the thirteen years we've known each other, it's really hard for me to believe you aren't saying infect intentionally just to spread needless discord. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Till Jaeger answer to the question What is a derivative work? is (on slide 4): I dont know (and probably nobody else) ! I do agree with him as long there is no case law, but my personal feeling (which as no value as case law !) is that the Court of Justice of the European Union would *not* follow the assumption Linking makes derivative especially when 2 open source programs are linked (even statically). These doubts on the concept of strong copyleft are reported in comments on EUPL (see point 4.1. - pages 19-20 in http://www.europarl.europa.eu/document/activities/cont/201307/20130708ATT69346/20130708ATT69346EN.pdf ). Just another European lawyer opinion... Thank you also for considering multi-lingual and multicultural aspects in license (licence?) chooser :-) 2013/8/28 Bradley M. Kuhn bk...@ebb.org Lawrence Rosen wrote at 17:00 (EDT) on Tuesday: I asked for practical examples. You cited none. In the world of copyrights or most logical pursuits, absence of evidence isn't evidence. License compatibility issues come up regularly on lots of bug tickets and threads about licensing on lots of projects. I don't have a saved file of evidence to hand you, mostly because it's such an unremarkable occurrence that I don't note it down when it happens. I see it at least once a month somewhere. I suspect anyone who follows Free Software development regularly sees it just as much. I can tell you that I dealt with two issues of license incompatibility in my day job recently, but I can't disclose the specifics since it was confidential advice. Meanwhile, if you need evidence to satisfy your curiosity right away, I'd suggest debian-legal archives would be a good place to start your research on this, but... Awaiting your evidence to the contrary ... I can't spare the time to do this basic research for you. If anyone else here does agree with you that license incompatibility isn't a problem in the real world, then perhaps it's worth continuing this thread, but I suspect you may be alone on this one. :) Most FOSS licenses (including the GPL!) don't actually define the term derivative work with enough precision to make it meaningful for court interpretation. ... The court will therefore use the statutory and case law to determine that situation. That's as it should be. It's not the job (nor is it really appropriate) for a copyright license to define statutory terms, so the GPL doesn't do that. The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. all major FOSS licenses that I'm aware of *except the GPL* make it abundantly clear that the mere combination of that licensed software with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Indeed, weaker copylefts give guidelines for certain derivative works that can be proprietarized, and the rest are left under copyleft. BTW, if you are interested in how the European lawyers view this question, I refer you to an excellent talk by Till Jaeger at FOSDEM 2013: http://www.faif.us/cast/2013/mar/26/0x39/ So what's the worry about license incompatibility all about? Is it merely that so many licenses are deemed incompatible with the GPL, Many licenses are incompatible with the Eclipse Public License, too, since it's a stronger copyleft than, say, the MPL or LGPL. There aren't very many strong copylefts around. with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Finally, I'm unlikely to respond to this thread further as I think the use of slurs like infect (notwithstanding the quotes, and '?') to refer to copyleft are just unnecessarily inflammatory. I've asked you not to talk about copyleft using slur words so many times before in the thirteen years we've known each other, it's really hard for me to believe you aren't saying infect intentionally just to spread needless discord. -- -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss -- Patrice-Emmanuel Schmitz pe.schm...@googlemail.com tel. + 32 478 50 40 65 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
On Wed, Aug 28, 2013 at 10:59:43AM -0400, Bradley M. Kuhn wrote: The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. A few sources credit Richard Stallman with saying that the GPL is a form of intellectual jujitsu, using the legal system that software hoarders have set up against them in a _Byte_ interview in July 1986. However, I do not see any RMS interview in that issue of _Byte_ (which is now available at archive.org). The gnu.org site has republished what it says is a July 1986 _Byte_ interview of RMS, but this contains no jujitsu quote. It seems likely that RMS *did* originate this characterization of the GPL, and probably in a _Byte_ interview, but it would be nice to track down the precise date of publication. - RF ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Bradley Kuhn wrote: Finally, I'm unlikely to respond to this thread further as I think the use of slurs like infect (notwithstanding the quotes, and '?') to refer to copyleft are just unnecessarily inflammatory. I've asked you not to talk about copyleft using slur words so many times before in the thirteen years we've known each other, it's really hard for me to believe you aren't saying infect intentionally just to spread needless discord. Bradley, The fear that *you* sow is infectious, not the GPL. I do not slur that license and certainly not copyleft!!! Indeed, I have argued at length here and elsewhere [1] that fear of the GPL is unwarranted. It is instead the fear that companies will be challenged by aggressive folks suing on some bogus derivative work theory that infects our community. To revert to the subject of this thread: The GPL should clearly be on every FOSS license chooser. But don't leave licenses off those license choosers simply because they are deemed incompatible under those false derivative work enforcement theories or some generalized fear of license proliferation. Here's what I suggest for license choosers: (1) Ask first whether the developer is intending to integrate his or her software most with Eclipse, Apache, Linux, Mozilla or other specific current FOSS projects. (2) Recommend that FOSS project's license (with appropriate IANAL caveats!). (3) Otherwise, consult a lawyer before choosing a license on your own. (4) Invent a new license only as a very last resort and only when justified by something missing in all other approved licenses. /Larry [1] In 2005 I published this: http://rosenlaw.com/pdf-files/Rosen_Ch06.pdf. See also my antique 2001 article on the topic of GPL infection: http://www.rosenlaw.com/html/GPL.pdf -Original Message- From: Bradley M. Kuhn [mailto:bk...@ebb.org] Sent: Wednesday, August 28, 2013 8:00 AM To: license-discuss@opensource.org Subject: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.) Lawrence Rosen wrote at 17:00 (EDT) on Tuesday: I asked for practical examples. You cited none. In the world of copyrights or most logical pursuits, absence of evidence isn't evidence. License compatibility issues come up regularly on lots of bug tickets and threads about licensing on lots of projects. I don't have a saved file of evidence to hand you, mostly because it's such an unremarkable occurrence that I don't note it down when it happens. I see it at least once a month somewhere. I suspect anyone who follows Free Software development regularly sees it just as much. I can tell you that I dealt with two issues of license incompatibility in my day job recently, but I can't disclose the specifics since it was confidential advice. Meanwhile, if you need evidence to satisfy your curiosity right away, I'd suggest debian-legal archives would be a good place to start your research on this, but... Awaiting your evidence to the contrary ... I can't spare the time to do this basic research for you. If anyone else here does agree with you that license incompatibility isn't a problem in the real world, then perhaps it's worth continuing this thread, but I suspect you may be alone on this one. :) Most FOSS licenses (including the GPL!) don't actually define the term derivative work with enough precision to make it meaningful for court interpretation. ... The court will therefore use the statutory and case law to determine that situation. That's as it should be. It's not the job (nor is it really appropriate) for a copyright license to define statutory terms, so the GPL doesn't do that. The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. all major FOSS licenses that I'm aware of *except the GPL* make it abundantly clear that the mere combination of that licensed software with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Indeed, weaker copylefts give guidelines for certain derivative works that can be proprietarized, and the rest are left under copyleft. BTW, if you are interested in how the European lawyers view this question, I refer you to an excellent talk by Till Jaeger at FOSDEM 2013: http://www.faif.us/cast/2013/mar/26/0x39/ So what's the worry about license incompatibility all about? Is it merely that so many licenses are deemed incompatible with the GPL, Many licenses are incompatible with the Eclipse Public License, too, since it's a stronger copyleft than, say, the MPL or LGPL. There aren't very many strong copylefts around. with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Finally
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
I also believe that incompatibility is a myth. Here's excellent paper: http://www.btlj.org/data/articles/21_04_04.pdf DANGEROUS LIAISONS—SOFTWARE COMBINATIONS AS DERIVATIVE WORKS? DISTRIBUTION,INSTALLATION, AND EXECUTION OF LINKED PROGRAMS UNDER COPYRIGHT LAW, COMMERCIAL LICENSES, AND THE GPL By Lothar Determann† † Prof. Dr. Lothar Determann teaches courses on computer and internet law at the University of California, Berkeley School of Law (Boalt Hall), University of San Francisco School of Law, and Freie Universität Berlin (www.lothar.determann.name), and practices law as a partner in the technology practice group of Baker McKenzie LLP, San Francisco/Palo Alto office (www.bakernet.com). The author is grateful for assistance from his students, in particular Tal Lavian, Principal Scientist at Nortel Labs (valuable comments from computer science perspective), Steven B. Toeniskoetter, Lars F. Brauer, and Neda Shabahang (legal research and footnote editing). On Wed, Aug 28, 2013 at 4:59 PM, Bradley M. Kuhn bk...@ebb.org wrote: Lawrence Rosen wrote at 17:00 (EDT) on Tuesday: I asked for practical examples. You cited none. In the world of copyrights or most logical pursuits, absence of evidence isn't evidence. License compatibility issues come up regularly on lots of bug tickets and threads about licensing on lots of projects. I don't have a saved file of evidence to hand you, mostly because it's such an unremarkable occurrence that I don't note it down when it happens. I see it at least once a month somewhere. I suspect anyone who follows Free Software development regularly sees it just as much. I can tell you that I dealt with two issues of license incompatibility in my day job recently, but I can't disclose the specifics since it was confidential advice. Meanwhile, if you need evidence to satisfy your curiosity right away, I'd suggest debian-legal archives would be a good place to start your research on this, but... Awaiting your evidence to the contrary ... I can't spare the time to do this basic research for you. If anyone else here does agree with you that license incompatibility isn't a problem in the real world, then perhaps it's worth continuing this thread, but I suspect you may be alone on this one. :) Most FOSS licenses (including the GPL!) don't actually define the term derivative work with enough precision to make it meaningful for court interpretation. ... The court will therefore use the statutory and case law to determine that situation. That's as it should be. It's not the job (nor is it really appropriate) for a copyright license to define statutory terms, so the GPL doesn't do that. The GPL has always tried to go as far as copyright would allow to mandate software freedom. That's what Michael Meeks (and/or Jeremy Allison -- I heard them both use this phrase within a few weeks of each other and not sure who deserves credit) call copyleft's judo move on copyright. It's the essence of strong copyleft. all major FOSS licenses that I'm aware of *except the GPL* make it abundantly clear that the mere combination of that licensed software with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Indeed, weaker copylefts give guidelines for certain derivative works that can be proprietarized, and the rest are left under copyleft. BTW, if you are interested in how the European lawyers view this question, I refer you to an excellent talk by Till Jaeger at FOSDEM 2013: http://www.faif.us/cast/2013/mar/26/0x39/ So what's the worry about license incompatibility all about? Is it merely that so many licenses are deemed incompatible with the GPL, Many licenses are incompatible with the Eclipse Public License, too, since it's a stronger copyleft than, say, the MPL or LGPL. There aren't very many strong copylefts around. with other software (FOSS or non-FOSS) does not affect (infect?) the other software. Finally, I'm unlikely to respond to this thread further as I think the use of slurs like infect (notwithstanding the quotes, and '?') to refer to copyleft are just unnecessarily inflammatory. I've asked you not to talk about copyleft using slur words so many times before in the thirteen years we've known each other, it's really hard for me to believe you aren't saying infect intentionally just to spread needless discord. -- -- bkuhn ___ 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] License incompatibility (was Re: Open source license chooser choosealicense.com launched.)
Larry, it seems that you responded to my point that calling the GPL by the name 'infection' is a slur that spreads needless discord with (paraphrased) it's not the GPL; it's the work that *you*, Bradley, and others have done enforcing the GPL that's an infection on our community. This doesn't seem a very civil manner of debate. Recall that I recently defended you, Larry, on this very list, when someone was uncivil to you. Please don't be uncivil to me and the orgs that I work with / volunteer for. I have no objection to your policy disagreements and disputes with GPL enforcement or anything else I've worked. I do object to your insinuation that my and others' work in this regard is a virus plagued upon our community. -- bkuhn ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
