Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Lawrence Rosen scripsit: In any case, I am speaking here of literal copying only. In that case, what's the problem you're hypothesizing? Every FOSS license permits literal copying, and no FOSS license imposes a copyleft obligation on any *other* work just because of making literal copies of the FOSS work. Literal copying and adding material is still literal copying, as distinct from the kind of indirect copying for which the AFC test is relevant. Modified source code solely to accomplish interworking? No, not at all. I contend that the differences of the methods of interworking are largely irrelevant to the analysis. I agree, but again you are bringing up red herrings. I am not speaking of interworking at all, but of functional enhancement using expressive means. Modified source code to change the program and its expression? That sounds like a derivative work. The question is, when does mere addition of new and itself copyrightable material (not de minimis, no form/content merger) without deletion or replacement count as making a derivative work? To take your stapled vs. unstapled booklet hypo: if Charlie stapled the pages of two stories (written separately by Alice and Bob) alternately (and supposing that no sentences or paragraphs in either story ran over a page boundary), would that make Charlie's booklet a derivative work of Alice's story and Bob's story, or still merely a collective work? Every sentence is still traceable to either Bob or Alice. -- One Word to write them all, John Cowan co...@ccil.org One Access to find them, http://www.ccil.org/~cowan One Excel to count them all, And thus to Windows bind them.--Mike Champion ___ 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
Therefore, my understanding of the directive is that software, that is independently created and exchanges information with other software through an interface, is independent software and not a derivative work. This is also my own understanding. But it means that linking software for interoperability (= for exchanging information) makes no derivatives and that the way of linking (statically producing a single binary or dynamic at runtime) is just a technical modality without substantial importance regarding copyright. From the perspective of European copyright law: yes. From the perspective of GPLv2: probably not (because of the wording of sec. 2 GPLv2). Best, Till ___ 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
Lawrence Rosen scripsit: They will refer you to the confusing abstraction-filtration-comparison tests that are used in the U.S. courts to distinguish functional from expressive content. Some U.S. courts. What is more, the AFC test sounds good in theory, but is decidedly hard to apply in practice. In any case, I am speaking here of literal copying only. when talking about the principles of copyright law, your hypothesized examples ought to focus on the things that Bob and Alice do for *expressive* purposes What on earth do _purposes_ have to do with anything? If I write a cookbook, I don't do it to express myself, but to explain how to cook various dishes (and perhaps to make money). Nonetheless, my cookbook is copyrightable because there is more than one possible form for the content. Likewise, both Alice's code and Bob's code are expressive, for there is more than one way to write each of them. rather than the things they do merely to allow their software to function together through some technical (or bizarre) form of linking. Why bring up linking? My hypos have to do with source-code modification, not with linking. I'll apply copyright law only when Bob or Alice make their software prettier. Bah. -- Don't be so humble. You're not that great. John Cowan --Golda Meirco...@ccil.org ___ 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
John Cowan wrote: In any case, I am speaking here of literal copying only. In that case, what's the problem you're hypothesizing? Every FOSS license permits literal copying, and no FOSS license imposes a copyleft obligation on any *other* work just because of making literal copies of the FOSS work. Why bring up linking? My hypos have to do with source-code modification, not with linking. Modified source code solely to accomplish interworking? That's almost the same as creating a functional link between two separate programs but instead by patching one or the other for that functional purpose only. I contend that the differences of the methods of interworking are largely irrelevant to the analysis. Modified source code to change the program and its expression? That sounds like a derivative work. In any event, neither is literal copying. /Larry -Original Message- From: John Cowan [mailto:co...@mercury.ccil.org] Sent: Thursday, September 12, 2013 12:27 PM To: lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Lawrence Rosen scripsit: They will refer you to the confusing abstraction-filtration-comparison tests that are used in the U.S. courts to distinguish functional from expressive content. Some U.S. courts. What is more, the AFC test sounds good in theory, but is decidedly hard to apply in practice. In any case, I am speaking here of literal copying only. when talking about the principles of copyright law, your hypothesized examples ought to focus on the things that Bob and Alice do for *expressive* purposes What on earth do _purposes_ have to do with anything? If I write a cookbook, I don't do it to express myself, but to explain how to cook various dishes (and perhaps to make money). Nonetheless, my cookbook is copyrightable because there is more than one possible form for the content. Likewise, both Alice's code and Bob's code are expressive, for there is more than one way to write each of them. rather than the things they do merely to allow their software to function together through some technical (or bizarre) form of linking. Why bring up linking? My hypos have to do with source-code modification, not with linking. I'll apply copyright law only when Bob or Alice make their software prettier. Bah. -- Don't be so humble. You're not that great. John Cowan --Golda Meirco...@ccil.org ___ 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
Dear Till
Thank you for this - excellent - analysis.
You wrote:
The only hint you may find is Article 6 which says that decompilation is
allowed under certain circumstances to achieve the interoperability of an
independently created computer program with other programs.
Written in 1991, the Directive considered decompilation only, based on the
assumption that source code was not communicated to the licensee. The case
of free/open source software looks different because the licensee has
legitimately an access to the source code (no decompilation is needed).
However, this is indeed without importance in my understanding: the idea is
that the legitimate licensee of a software program (received as object code
only or as object + source in the case of FOSS) has the right to inspect
and reuse this code with the purpose “to achieve interoperability”
There is a definition of interoperability in recital 10: 'The parts of the
program
which provide for such interconnection and interaction between elements of
software and hardware are generally known as interfaces. This functional
interconnection and interaction is generally known as interoperability;
such interoperability can be defined as the ability to exchange information
and mutually to use the information which has been exchanged. '
Therefore, my understanding of the directive is that software, that is
independently created and exchanges information with other software through
an interface, is independent software and not a derivative work.
This is also my own understanding. But it means that linking software for
interoperability (= for exchanging information) makes no derivatives and
that the way of linking (statically producing a single binary or dynamic at
runtime) is just a technical modality without substantial importance
regarding copyright.
There is another hint in section 3 of Article 6: “the provisions of this
Article may not be interpreted in such a way as to allow its application to
be used in a manner which unreasonably prejudices the rightholder's
legitimate interests”.
If some litigation comes (hypothetically) to the Court (note: the right
name is now “Court of Justice of the European Union”) and if I was - by
impossible chance - involved as a lawyer, I guess that I would argue that
protecting free software is a legitimate interest and that statically
linking with proprietary software unreasonably prejudices this interest. At
the contrary, linking with FOSS software covered by another “similar”
copyleft licence would not prejudice this interest. Just my own
understanding of course...
Interesting debate...
Patrice-Emmanuel
2013/9/10 Till Jaeger jae...@jbb.de
Dear list,
Bradley and Larry have asked me to share my view as a European lawyer on
the
question if linking of software components (necessarily) results in a
derivative work as understood by the GPL. In a nutshell, my thoughts are
the following (a more comprehensive overview can be found at
http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German
only):
1.
As far as I know there is no relevant case law on the question of what may
be considered a derivative work under European copyright law for
software.
European software copyright law has been harmonized
(
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:111:0016:01:EN:HTML
)
since 1991.
In my opinion derivative work in software law should have a different
meaning than in other fields of copyright law.
Software is typically interacting with other software, and dependencies
(e.g. an application running on an operating system) do not necessarily
mean
that two components form a derivative work.
2.
GPLv3 refers to copyright law ('To “modify” a work means to copy from or
adapt all or part of the work in a fashion requiring copyright permission,
other than the making of an exact copy') whereas GPLv2 might be interpreted
in a way that the understanding of derivative work is broader. In this
regard the GPLv2 seems to be a bit contradictory to me. On the one hand it
defines 'a work based on the Program'as “either the Program or any
derivative work under copyright law, on the other hand sec. 2 contains a
more detailed explanation of what the term derivative work is supposed to
mean within the scope of the GPLv2 (If identifiable sections of that work
are not derived from the Program, and can be reasonably considered
independent and separate works in themselves, then this License, and its
terms, do not apply to those sections when you distribute them as separate
works.). Apparently, a computer program which is _not_ derived from GPL
code has nonetheless to be licensed under the GPLv2 when the original GPL
code and the program are not distributed as separate works.
If you do not want to ignore that language you have to find a meaningful
interpretation for this sentence in sec. 2 of the GPLv2. To me, it makes
sense to understand distribute them as separate work
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Thanks Till, this was a very useful summary of the situation in Europe! I believe you've begged the question, however, by saying this: Apparently, a computer program which is _not_ derived from GPL code has nonetheless to be licensed under the GPLv2 when the original GPL code and the program are not distributed as separate works. I'll take as your premise that we're talking about distributing a computer program which is _not_ derived from GPL code. That simplifies our analysis. Certainly in most of the collective works or compilations distributed by software companies under a variety of copyleft and non-copyleft licenses, the most interesting and useful parts of those applications software are NOT derived from GPL code. Those larger applications, comprised of many FOSS and non-FOSS components, evidence a great deal of independent creativity and development effort. Although we know that creativity and effort alone does not determine the copyright status of those applications, we can say that the reward system in software development is tied to such independent creative development efforts. It will take more than wishful thinking and static linking to subject those independent creative works to the GPL and thereby to reduce the rewards available to their authors. Does the distribution of a GPL-licensed work along with those separate works convert them into something not separate in the copyright sense? Does a staple or a paper clip or a book binding convert separate works to something not separate in the copyright sense? You refer to a binary blob. That is an interesting phrase which has no analogue in copyright law. How would a European lawyer define such a thing in a FOSS license so that, as long as even one blob-ette within it is GPL, binary blobs as a whole subject are to the GPL? You concluded that the situation is far from being clear. Maybe I'm being naive, but it is clear to me that the law in the US and Europe favors the free interoperability of legitimately acquired software and disfavors claims of infringement by mere linking. Best regards, and thanks again for stepping into this minefield. I'd much rather hear your thoughtful views and those of our colleagues than ambiguous threats of infringement from GPL enforcers without any legal analysis behind them. /Larry -Original Message- From: Till Jaeger [mailto:jae...@jbb.de] Sent: Tuesday, September 10, 2013 10:25 AM To: license-discuss@opensource.org Cc: Bradley M. Kuhn; Lawrence Rosen Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Dear list, Bradley and Larry have asked me to share my view as a European lawyer on the question if linking of software components (necessarily) results in a derivative work as understood by the GPL. In a nutshell, my thoughts are the following (a more comprehensive overview can be found at http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German only): snip ___ 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
On Tue, Sep 10, 2013 at 10:41 AM, Bradley M. Kuhn bk...@ebb.org wrote: As I mentioned in a private thread, I didn't really see the need to burn Till's time posting here, since the discussion was a side-issue on the main thread about license compatibility, and an OSI director had already said oh no, not again on the derivative works subthread. To be clear, I'm very glad for the high quality of response since then! As you speculated, Bradley, we have seen much of the same, tired analysis before, which is why I was unhappy; but since then, the thread has seen much new, useful writing that I think will be valuable for anyone thinking about this issue in the future, so I'm glad people have thoughtfully responded and continued the discussion. Luis ___ 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
Lawrence Rosen scripsit: Does the distribution of a GPL-licensed work along with those separate works convert them into something not separate in the copyright sense? Does a staple or a paper clip or a book binding convert separate works to something not separate in the copyright sense? Plainly not. But suppose Bob takes Alice's program under the GPL and and adds a bunch of calls to syslog() so that it logs what it is doing (and suppose further that this is not a de minimis or merely mechanical change). Do you then hold that this is not a derivative work either, and therefore need not be licensed by Bob under the GPL? After all, it is not as if you can't trace every single bit in the source code or resulting object code to Alice or Bob respectively, at least assuming the compiler is not over-clever. -- Well, I'm back. --SamJohn Cowan co...@ccil.org ___ 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
John Cowan asked: But suppose Bob takes Alice's program under the GPL and and adds a bunch of calls to syslog() so that it logs what it is doing (and suppose further that this is not a de minimis or merely mechanical change). Hypotheticals are so easy to answer without committing malpractice. :-) And so useless as authority for real cases! I would guess that Bob's adding a bunch of calls to syslog() into Alice's work might create a derivative work of Alice's work, but that wouldn't convert syslog() itself a derivative work owned by either Alice or Bob, even if Bob statically linked it with Alice's program. Why are you putting the burden on an over-clever source code compiler to detect derivative works? Alice better be able to prove that Bob created a derivative work by some reasonable legal standard relating to the expressive content of her work or she may be sanctioned by the court for filing a frivolous lawsuit. /Larry -Original Message- From: John Cowan [mailto:co...@mercury.ccil.org] Sent: Wednesday, September 11, 2013 2:05 PM To: lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Lawrence Rosen scripsit: Does the distribution of a GPL-licensed work along with those separate works convert them into something not separate in the copyright sense? Does a staple or a paper clip or a book binding convert separate works to something not separate in the copyright sense? Plainly not. But suppose Bob takes Alice's program under the GPL and and adds a bunch of calls to syslog() so that it logs what it is doing (and suppose further that this is not a de minimis or merely mechanical change). Do you then hold that this is not a derivative work either, and therefore need not be licensed by Bob under the GPL? After all, it is not as if you can't trace every single bit in the source code or resulting object code to Alice or Bob respectively, at least assuming the compiler is not over-clever. -- Well, I'm back. --SamJohn Cowan co...@ccil.org ___ 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
Lawrence Rosen scripsit: I would guess that Bob's adding a bunch of calls to syslog() into Alice's work might create a derivative work of Alice's work, but that wouldn't convert syslog() itself a derivative work owned by either Alice or Bob, even if Bob statically linked it with Alice's program. The GPL provides an exception for things like syslog() anyway; you can link to it without triggering even disputable obligations. Why are you putting the burden on an over-clever source code compiler to detect derivative works? Not what I meant. If Alice's code contains the string foobar and so does Bob's, a compiler might coalesce the two strings into one, in such a way that the 0x62 in the object file's initialized-data segment could not be unilaterally attributed to either Alice or Bob. But in any case my point is that there is no bright line between a derivative and a collective work. If Bob's work is a derivative of Alice's, then we can construct a sequence of alternate hypos by Bob that lead right up to two separate modules of code, such as this: Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module. In all cases, Bob's contributions can be separated from Alice's mechanically, even at the object level (absent coalescence as described above). Yet that fact is not determinative of collective work vs. derivative work. -- I Hope, Sir, that we are notJohn Cowan mutually Un-friended by thisco...@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) ___ 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
John Cowan wrote: But in any case my point is that there is no bright line between a derivative and a collective work. If you are looking for a bright line in copyright law, I'll agree that that isn't it. Here again is what you hypothesized: Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module. Consider that all the Bob v. Alice examples you described would be undertaken either for expressive or functional reasons. If for functional reasons, then copyright has nothing to do with it. Bob and Alice can *use* software that they lawfully acquire, and *interoperate* it for functional purposes with other software that they lawfully acquire, to their heart's content. It is my impression that the law in the US and Europe strongly favors such freedom to use and interoperate legally acquired computer software without copyright restraints. But if there is an expressive component to what Bob and Alice have done, that expressive aspect alone is protectable by copyright, and they can prevent the making of copies, derivative works, collective works, or compilations of their own expressions -- again to their heart's content. And they can choose to license those things. That is true regardless of whether what Bob and Alice create is a derivative or a collective work. Copyright law is the same for both. What is different is that some FOSS licenses (such as GPLv2) actually obfuscate even further by their sloppy language that fuzzy-line between derivative and collective works, and leave people confused about what they can and can't do with their legally-acquired software. There isn't a bright line between expressive and functional components either, as my lawyer friends will remind us. They will refer you to the confusing abstraction-filtration-comparison tests that are used in the U.S. courts to distinguish functional from expressive content. But at least, when talking about the principles of copyright law, your hypothesized examples ought to focus on the things that Bob and Alice do for *expressive* purposes rather than the things they do merely to allow their software to function together through some technical (or bizarre) form of linking. I'll apply copyright law only when Bob or Alice make their software prettier. /Larry -Original Message- From: John Cowan [mailto:co...@mercury.ccil.org] Sent: Wednesday, September 11, 2013 6:20 PM To: lro...@rosenlaw.com; license-discuss@opensource.org Subject: Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com Lawrence Rosen scripsit: I would guess that Bob's adding a bunch of calls to syslog() into Alice's work might create a derivative work of Alice's work, but that wouldn't convert syslog() itself a derivative work owned by either Alice or Bob, even if Bob statically linked it with Alice's program. The GPL provides an exception for things like syslog() anyway; you can link to it without triggering even disputable obligations. Why are you putting the burden on an over-clever source code compiler to detect derivative works? Not what I meant. If Alice's code contains the string foobar and so does Bob's, a compiler might coalesce the two strings into one, in such a way that the 0x62 in the object file's initialized-data segment could not be unilaterally attributed to either Alice or Bob. But in any case my point is that there is no bright line between a derivative and a collective work. If Bob's work is a derivative of Alice's, then we can construct a sequence of alternate hypos by Bob that lead right up to two separate modules of code, such as this: Bob interweaves his code into Alice's code (as in this hypo), Bob adds code to the end of Alice's procedure, Bob adds new procedures to the end of Alice's module, Bob adds a new module to Alice's module. In all cases, Bob's contributions can be separated from Alice's mechanically, even at the object level (absent coalescence as described above). Yet that fact is not determinative of collective work vs. derivative work. -- I Hope, Sir, that we are notJohn Cowan mutually Un-friended by thisco...@ccil.org Difference which hath happened http://www.ccil.org/~cowan betwixt us. --Thomas Fuller, Appeal of Injured Innocence (1659) ___ 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
Till Jaeger wrote: Bradley and Larry have asked me to share my view as a European lawyer on the To be abundantly clear, it was wholly Larry's request to Till, so Larry deserves all the credit here for eliciting this wonderful and informative contribution to this list from Till! As I mentioned in a private thread, I didn't really see the need to burn Till's time posting here, since the discussion was a side-issue on the main thread about license compatibility, and an OSI director had already said oh no, not again on the derivative works subthread. However, nevertheless, Till, thank you so much for providing such a detailed posting to the list, and it's a wonderful written supplement to what you covered in your FOSDEM 2013 talk! -- 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
Dear list,
Bradley and Larry have asked me to share my view as a European lawyer on the
question if linking of software components (necessarily) results in a
derivative work as understood by the GPL. In a nutshell, my thoughts are
the following (a more comprehensive overview can be found at
http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German
only):
1.
As far as I know there is no relevant case law on the question of what may
be considered a derivative work under European copyright law for software.
European software copyright law has been harmonized
(http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:111:0016:01:EN:HTML)
since 1991.
In my opinion derivative work in software law should have a different
meaning than in other fields of copyright law.
Software is typically interacting with other software, and dependencies
(e.g. an application running on an operating system) do not necessarily mean
that two components form a derivative work.
2.
GPLv3 refers to copyright law ('To “modify” a work means to copy from or
adapt all or part of the work in a fashion requiring copyright permission,
other than the making of an exact copy') whereas GPLv2 might be interpreted
in a way that the understanding of derivative work is broader. In this
regard the GPLv2 seems to be a bit contradictory to me. On the one hand it
defines 'a work based on the Program'as “either the Program or any
derivative work under copyright law, on the other hand sec. 2 contains a
more detailed explanation of what the term derivative work is supposed to
mean within the scope of the GPLv2 (If identifiable sections of that work
are not derived from the Program, and can be reasonably considered
independent and separate works in themselves, then this License, and its
terms, do not apply to those sections when you distribute them as separate
works.). Apparently, a computer program which is _not_ derived from GPL
code has nonetheless to be licensed under the GPLv2 when the original GPL
code and the program are not distributed as separate works.
If you do not want to ignore that language you have to find a meaningful
interpretation for this sentence in sec. 2 of the GPLv2. To me, it makes
sense to understand distribute them as separate work as a formal
criterion, i.e. distributing one binary blob makes it one work instead of
two or more separate works. Of course, other interpretations are possible.
3.
I think it is very difficult to predict how the European Court of Justice
(ECJ) would interpret the phrase adaptation, arrangement and any other
alteration of a computer program as used in Article 4.1 (b) of the
Directive 2009/24/EC.
The only hint you may find is Article 6 which says that decompilation is
allowed under certain circumstances to achieve the interoperability of an
independently created computer program with other programs. There is a
definition of interoperability in recital 10: 'The parts of the program
which provide for such interconnection and interaction between elements of
software and hardware are generally known as interfaces. This functional
interconnection and interaction is generally known as interoperability;
such interoperability can be defined as the ability to exchange information
and mutually to use the information which has been exchanged. '
Therefore, my understanding of the directive is that software, that is
independently created and exchanges information with other software through
an interface, is independent software and not a derivative work.
However, it is unclear which kinds of interfaces fall within the scope of
the directive. The text is from 1991 when Java and other object oriented
programming was not known at that time (or not as common as it is today).
4.
If linked software should be considered a derivative work (under the
GPLv2 and GPLv3) is truly difficult to judge. With regard to the
aforementioned criteria I come to the following conclusions:
a)
From the perspective of copyright law the way how two parts of a program
interact _technically_ with each other may provide an indication about the
derivative work question. However, the technical fact by itself that two
components are linked with each other does not necessarily lead to the
conclusion that the combination is or is not a derivative work.
b)
If a developer modifies an existing program and puts the added code in a
library instead of the existing files the code in the library would still be
a derivative work. A modified program is a modified program, and one might
not circumvent this legal effect just by moving code into a library.
However, the situation might be different if an independently created
application uses an existing standard library. You could argue
that the application uses the interface of the library, and linking is just
a matter of interoperability, which seems convincing to me. But you might
also consider that there is a widely accepted opinion that linking results
regularly in creating
Re: [License-discuss] License incompatibility (was Re: Open source license chooser choosealicense.com
Hi Til:
Thanks very much for this thoughtful analysis. Are you planning to post to the
ftf list as well?
G.
On Sep 10, 2013, at 10:24 AM, Till Jaeger jae...@jbb.de wrote:
Dear list,
Bradley and Larry have asked me to share my view as a European lawyer on the
question if linking of software components (necessarily) results in a
derivative work as understood by the GPL. In a nutshell, my thoughts are
the following (a more comprehensive overview can be found at
http://www.ifross.org/Druckfassung/Ziffer%202.pdf, unfortunately in German
only):
1.
As far as I know there is no relevant case law on the question of what may
be considered a derivative work under European copyright law for software.
European software copyright law has been harmonized
(http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:111:0016:01:EN:HTML)
since 1991.
In my opinion derivative work in software law should have a different
meaning than in other fields of copyright law.
Software is typically interacting with other software, and dependencies
(e.g. an application running on an operating system) do not necessarily mean
that two components form a derivative work.
2.
GPLv3 refers to copyright law ('To “modify” a work means to copy from or
adapt all or part of the work in a fashion requiring copyright permission,
other than the making of an exact copy') whereas GPLv2 might be interpreted
in a way that the understanding of derivative work is broader. In this
regard the GPLv2 seems to be a bit contradictory to me. On the one hand it
defines 'a work based on the Program'as “either the Program or any
derivative work under copyright law, on the other hand sec. 2 contains a
more detailed explanation of what the term derivative work is supposed to
mean within the scope of the GPLv2 (If identifiable sections of that work
are not derived from the Program, and can be reasonably considered
independent and separate works in themselves, then this License, and its
terms, do not apply to those sections when you distribute them as separate
works.). Apparently, a computer program which is _not_ derived from GPL
code has nonetheless to be licensed under the GPLv2 when the original GPL
code and the program are not distributed as separate works.
If you do not want to ignore that language you have to find a meaningful
interpretation for this sentence in sec. 2 of the GPLv2. To me, it makes
sense to understand distribute them as separate work as a formal
criterion, i.e. distributing one binary blob makes it one work instead of
two or more separate works. Of course, other interpretations are possible.
3.
I think it is very difficult to predict how the European Court of Justice
(ECJ) would interpret the phrase adaptation, arrangement and any other
alteration of a computer program as used in Article 4.1 (b) of the
Directive 2009/24/EC.
The only hint you may find is Article 6 which says that decompilation is
allowed under certain circumstances to achieve the interoperability of an
independently created computer program with other programs. There is a
definition of interoperability in recital 10: 'The parts of the program
which provide for such interconnection and interaction between elements of
software and hardware are generally known as interfaces. This functional
interconnection and interaction is generally known as interoperability;
such interoperability can be defined as the ability to exchange information
and mutually to use the information which has been exchanged. '
Therefore, my understanding of the directive is that software, that is
independently created and exchanges information with other software through
an interface, is independent software and not a derivative work.
However, it is unclear which kinds of interfaces fall within the scope of
the directive. The text is from 1991 when Java and other object oriented
programming was not known at that time (or not as common as it is today).
4.
If linked software should be considered a derivative work (under the
GPLv2 and GPLv3) is truly difficult to judge. With regard to the
aforementioned criteria I come to the following conclusions:
a)
From the perspective of copyright law the way how two parts of a program
interact _technically_ with each other may provide an indication about the
derivative work question. However, the technical fact by itself that two
components are linked with each other does not necessarily lead to the
conclusion that the combination is or is not a derivative work.
b)
If a developer modifies an existing program and puts the added code in a
library instead of the existing files the code in the library would still be
a derivative work. A modified program is a modified program, and one might
not circumvent this legal effect just by moving code into a library.
However, the situation might be different if an independently created
application uses an existing standard
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
