Re: [License-discuss] Red Hat compilation copyright RHEL contract
From http://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf 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. Bradley Kuhn wrote at 15:46 on Monday: … It's admittedly a strange behavior, and I've been asking Red Hat Legal for many years now to explain better why they're doing this and what they believe it's accomplishing. Larry Rosen wrote at 23:28 on Thursday: I often recommend that licensing method to those of my clients who combine various FOSS works into a single software package. It isn't odd at all. Even if GPL applies to one or more of those internal components, there is no need to license the entire collective work under the GPL. We've even distributed GPL software as part of collective works under the OSL. I too am curious what this compilation licenseing is and what its benefits are. Mr Kuhn asked, and Larry responded saying basically 'its not so odd - I use it often' and Larry did not state *why* he advises use of this licensing strategy from a business, social or other standpoint. 1) Why larry? 2) What is the standard way of doing this? How do most other org's license many works together? Full disclosure: I work for Red Hat, though am writing this from my personal account and perspective. I am a beginner on my knowledge into OSS license details, so please realize that I am attempting to learn. I could go and ask around in my company about this, yet I would rather engage with the community on this for now. -Nick Yeates ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Al Re: Red Hat compilation copyright RHEL contract
On Tue, Sep 10, 2013 at 6:42 AM, Bradley M. Kuhn bk...@ebb.org wrote: Quoting Luis Villa (l...@lu.is): We have dropped Al from the list, as we believe he is Alexander Terekhov, and he refused to deny it when asked. Rick Moen wrote at 18:28 (EDT) on Monday: The authorial 'voice' matches. Even so, I wasn't completely convinced that Al Foxtone was Terekhov myself, but I leave it to the listadmins to decide who's who. :) On Mon, Sep 9, 2013 at 10:32 AM, Bradley M. Kuhn bk...@ebb.org wrote: [0] And, to be clear to those who seem to have missed this point: I *don't* agree with Al's accusations/insinuations. In fact, I'm arguing against them, in case you missed it. Anyway, my footnote comment that Luis quoted above wasn't intended toward Al anyway, FWIW. :) My apologies for making assumptions, but it seemed as good a time as any to point out the problem and solution :) Luis ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Red Hat compilation copyright RHEL contract
Quoting Nick Yeates (nyeat...@umbc.edu): I too am curious what this compilation licenseing is... Copyright law recognises the possiblity of an abstract property called a 'compilation copyright', that being the ownership interest gained by someone who _creatively_ collects and assembles other people's works in such a way that the collective set can be legitimately seen as _itself_ constituting an original work of authorship. An example would be the editor of a short-story anthology collecting and arranging other people's stories to create a themed book. Copyright law recognises that the act of picking stories and arranging them and presenting them in a particular way is an act of creation deserving of recognition as an abstract property, completely aside from the copyright title existing in the constituent works. When I operated a dial-up BBS from (if memory serves) 1988 to 1993, my Policies bulletin asserted that I owned compilation copyright over the design and implementation of the BBS as a whole. Your term 'compilation licence', or whatever it was that people said upstream seems to refer to Red Hat's published policy asserting a compilation copyright over RHEL as a whole. By the way, when the whole 'Red Hat is violating other people's copyrights' drumbeat started in the early 2000s, I did my best to FAQ the extant situation. (I make no apologies if things have changed since then, but I doubt they have changed much.) http://linuxmafia.com/faq/RedHat/rhel-isos.html (If memory serves, the situation was then new enough that I merely speculated that RH asserts compilation copyright. It does, and grants GPLv2 redistribution permission to its rights over the collective work, while clarifying at the same time that their conveyance does not include any right to transgress Red Hat's trademark rights.) ...and what its benefits are. Mu. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] Al Re: Red Hat compilation copyright RHEL contract
Quoting Luis Villa (l...@lu.is): We have dropped Al from the list, as we believe he is Alexander Terekhov, and he refused to deny it when asked. Rick Moen wrote at 18:28 (EDT) on Monday: The authorial 'voice' matches. Even so, I wasn't completely convinced that Al Foxtone was Terekhov myself, but I leave it to the listadmins to decide who's who. :) On Mon, Sep 9, 2013 at 10:32 AM, Bradley M. Kuhn bk...@ebb.org wrote: [0] And, to be clear to those who seem to have missed this point: I *don't* agree with Al's accusations/insinuations. In fact, I'm arguing against them, in case you missed it. Anyway, my footnote comment that Luis quoted above wasn't intended toward Al anyway, FWIW. :) -- -- 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
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-review] Licence AGPL-3.0 Approval for Teampass
bcc: license-discuss to: license-review On Tue, Sep 3, 2013 at 3:55 AM, Nils Laumaillé n...@teampass.net wrote: Hello, I'm the developer of an open web tool (called Teampass) and would like to make it an official open-source tool. That's why I'm doing this request to the OSI board in order to check if the license is adequate. The AGPL is already considered OSI approved Open Source (http://opensource.org/licenses/alphabetical) It is also FSF Free Software (https://www.gnu.org/licenses/license-list.html) It is *not* considered copyfree (http://copyfree.org/rejected/) There is no need for you to get special approval just for your project. Do I understand what you are asking correctly? -- Eitan Adler ___ 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
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
