|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn 1/27/07, Russ Nelson <nelson@...> wrote:
> Arnoud Engelfriet writes: > > If, as Matthew writes, part of the code is _specifically_ written to > > work only with GNU readline and no other library, then the code is > > a derivative work of GNU readline at the moment of creation. > > And if I later write a library compatible with GNU readline, that > makes the code NOT a derivative work? How can that be? It's either > derived in the sense that I incoporated parts of GNU readline into my > code, or else it's NOT derivative because no part of GNU readline was > incorporated. In my opinion it should be a judgement call based on how closely connected your code is with the design of GNU readline. Remember that copyright is not just intended to apply to literal copying. For instance if I write a short story and Mickey Mouse appears in it, I'm going to hear from Disney's lawyers. Even though I have not copied anything exact, I can still be derivative of it. Likewise if my code makes liberal use of ideas and memes created by GNU readline, there is an argument that I'm derivative of realine regardless of whether I link. Of course my opinion is influenced by having read http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in detail and then having thought about how the changing richness of the Linux kernel module API has changed Linus' opinions about when a binary module is a derived work of the Linux kernel. (And why.) > The standard interpretation of linking forming a derivative work has > no basis in copyright law. A staticly linked program is a collective > work, perhaps, but not derivative. A derivative work is where I take > an existing library and add my own calls to it. A dynamically linked > program which includes no portion of the library is neither derivative > nor collective. The dynamic linking information is just a set of > names; it's not the code itself. See my reply to Larry Rosen. The key issue is that the GPL offers no permission to distribute a collective work with some pieces GPLed and others not that is not formed by "mere aggregation". Therefore if you wish to distribute a collective work that has a more complex relationship, you must GPL the whole thing. I think there is a good argument to be made that static linking is not mere aggregation. > The dynamic linking argument has no legs unless you can claim > copyright on a list of names. If somebody else produces a similar but > different list, does that infringe your copyright? Not obvious. But in fact you *can* claim copyright on a list of names. (Not always, but often.) But you are completely right that it is not obvious when a similar but different list infringes on your copyright. Cheers, Ben |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsBen Tilly wrote:
> In my opinion it should be a judgement call based on how closely > connected your code is with the design of GNU readline. Remember that > copyright is not just intended to apply to literal copying. For > instance if I write a short story and Mickey Mouse appears in it, I'm > going to hear from Disney's lawyers. Yes, but probably on trademark grounds. Even though I have not copied > anything exact, I can still be derivative of it. Likewise if my code > makes liberal use of ideas and memes created by GNU readline, there is > an argument that I'm derivative of realine regardless of whether I > link. Ideas and memes alone shouldn't be enough to create a derivative work under copyright law. > > Of course my opinion is influenced by having read > http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in > detail and then having thought about how the changing richness of the > Linux kernel module API has changed Linus' opinions about when a > binary module is a derived work of the Linux kernel. (And why.) That is a quite interesting compilation. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn 1/28/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> Ben Tilly wrote: > > In my opinion it should be a judgement call based on how closely > > connected your code is with the design of GNU readline. Remember that > > copyright is not just intended to apply to literal copying. For > > instance if I write a short story and Mickey Mouse appears in it, I'm > > going to hear from Disney's lawyers. > > Yes, but probably on trademark grounds. On every grounds they can get, *including* copyright. In fact I chose that example specifically for good reason. Disney is famous for caring about the copyright that they have on Mickey Mouse. So much so that on multiple occasions they have successfully lobbied for copyright law to be changed so that they can continue to maintain that copyright. > Even though I have not copied > > anything exact, I can still be derivative of it. Likewise if my code > > makes liberal use of ideas and memes created by GNU readline, there is > > an argument that I'm derivative of realine regardless of whether I > > link. > > Ideas and memes alone shouldn't be enough to create a derivative work > under copyright law. My understanding (as a non-lawyer) is that copyright law protects my creative expression. Thus while the concepts that I used to write my code are not copyrighted, the various variable names, function names, arrangements, etc that I used might be copyrightable material. Therefore someone who makes extensive use of the creative framework that I created can find that their work is derivative of mine under copyright. Nothing stops them from creating an equivalent framework from scratch. It is only when they use my creative arrangement that they have a possibility of running into trouble. > > Of course my opinion is influenced by having read > > http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in > > detail and then having thought about how the changing richness of the > > Linux kernel module API has changed Linus' opinions about when a > > binary module is a derived work of the Linux kernel. (And why.) > > That is a quite interesting compilation. It is. And it gives a lot of insight into how Linus thinks about this issue. Of course I have no idea of what a lawyer would think about his thinking... Cheers, Ben |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn Jan 28, 2007, at 12:21 PM, Ben Tilly wrote:
>> With the appropriate parts of the compiler toolchain (ar, nm, >> objdump, etc), you can actually examine the contents, symbol headers, >> and timestamps of libraries, object files, and executables. > > I think that intent enters into it. Sure, it frequently is possible > to divide it back up into pieces, but nobody intends for such a > division to ever happen. Therefore the file is not just a "mere > aggregation". A reasonable position-- I would generally agree that statically linking resources into an executable implies an intent to create a compilation or derivative work that goes beyond "mere aggregation". On the other hand, it is possible to include (link in) a library from which no symbols are being referenced (via GNU ld's --whole-archive option, for example)...and this can be done at any time, including after an executable has been created. Let's suppose someone who holds the perspective that "any linking against a GPL'ed library means that the associated binary must be distributed under the terms of the GPL, even if the executable does not depend on that GPL'ed library"-- such a person could relink any given proprietary binary against GNU readline and then demand that the vendor of the proprietary program release their sources, even though the binary does not know about, use, or depend on GNU readline in any fashion when originally distributed. [ I don't think the vendor of the proprietary binary would have any obligation or responsibility for actions which lie completely outside of their control; it would be the responsibility of the person doing this linking to either obtain the sources or to refrain from redistributing their modified version if the result was not in compliance with the GPL's requirements. ] > And sometimes such a division is not possible. The > difference between those two cases takes more skill to determine than > the vast majority of computer users possess. Oh, certainly. But courts may well pay attention to facts which may not be significant or discernible to a layman but are evident to expert examination. >> > Another case of interest is the web. Suppose that I write GPLed >> > software that produces a website. There is no question that the >> web >> > pages that I display include lots of stuff that is part of my >> > codebase. I think they should therefore be GPLed. And every >> time you >> > fetch a page, a derivative work has been distributed. Does every >> > page, therefore, need to include a copy of the GPL? >> >> We'd discussed this back in the thread "GPL for JS libraries (Was: >> Re: Redefining GPL?)" [ ...Msg-Id's snipped as you've found the right message... ] > In any case you raised a number of interesting points in that email. > A key one is that in your opinion distributing a hyperlink to the GPL > along with a GPLed file should count as distribution of the GPL > license. While this seems like a reasonable practice, it doesn't > match my understanding of the GPL that one can merely offer the > license text in place of giving the license text to the recipient. > (The license says that one must give the recipient the license.) Yes, it does. If you've redistributed GPL'ed software such as JavaScript code, CSS, etc, then you need to provide the text of the GNU General Public License to the recipients. To me, that means you need to make the text downloadable as a normal .txt or HTML file from the site which offers the GPL'ed software, not that you need the whole text of the GPL on every single page of the site, or included with every single resource files which comprises the site. After all, you can GPL image resources like PNG/ GIF/JPG/etc files, but the image file formats do not lend themselves to including the GPL text with these image files... -- -Chuck |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn 1/29/07, Chuck Swiger <chuck@...> wrote:
> On Jan 28, 2007, at 12:21 PM, Ben Tilly wrote: > >> With the appropriate parts of the compiler toolchain (ar, nm, > >> objdump, etc), you can actually examine the contents, symbol headers, > >> and timestamps of libraries, object files, and executables. > > > > I think that intent enters into it. Sure, it frequently is possible > > to divide it back up into pieces, but nobody intends for such a > > division to ever happen. Therefore the file is not just a "mere > > aggregation". > > A reasonable position-- I would generally agree that statically > linking resources into an executable implies an intent to create a > compilation or derivative work that goes beyond "mere aggregation". :-) > On the other hand, it is possible to include (link in) a library from > which no symbols are being referenced (via GNU ld's --whole-archive > option, for example)...and this can be done at any time, including > after an executable has been created. > > Let's suppose someone who holds the perspective that "any linking > against a GPL'ed library means that the associated binary must be > distributed under the terms of the GPL, even if the executable does > not depend on that GPL'ed library"-- such a person could relink any > given proprietary binary against GNU readline and then demand that > the vendor of the proprietary program release their sources, even > though the binary does not know about, use, or depend on GNU readline > in any fashion when originally distributed. Not so fast. In this case "must" is a requirement on the person who wishes to redistribute, not a requirement on third parties who may have copyrights involved. Therefore there is no basis for a demand. What I mean by that is that the person who did the relinking has no permission to distribute the result unless it can be GPLed, but relinking in no way obligates the proprietary vendor to give permission to GPL that binary. Since the vendor is unlikely to give their permission or source code, the relinked binary is unlikely to be legally redistributable. > [ I don't think the vendor of the proprietary binary would have any > obligation or responsibility for actions which lie completely outside > of their control; it would be the responsibility of the person doing > this linking to either obtain the sources or to refrain from > redistributing their modified version if the result was not in > compliance with the GPL's requirements. ] Exactly. > > And sometimes such a division is not possible. The > > difference between those two cases takes more skill to determine than > > the vast majority of computer users possess. > > Oh, certainly. But courts may well pay attention to facts which may > not be significant or discernible to a layman but are evident to > expert examination. True. However it all rests on what is considered "mere aggregation". I'd be surprised to see a court rule that linking was mere aggreation. Particularly given the fact that the FSF has made it very clear that they *don't* think that linking is mere aggregation, and nobody has challenged them on that. [...] > > In any case you raised a number of interesting points in that email. > > A key one is that in your opinion distributing a hyperlink to the GPL > > along with a GPLed file should count as distribution of the GPL > > license. While this seems like a reasonable practice, it doesn't > > match my understanding of the GPL that one can merely offer the > > license text in place of giving the license text to the recipient. > > (The license says that one must give the recipient the license.) > > Yes, it does. If you've redistributed GPL'ed software such as > JavaScript code, CSS, etc, then you need to provide the text of the > GNU General Public License to the recipients. Excuse me? When I said that it doesn't match my understanding, I meant what I said. It doesn't match my understanding. > To me, that means you need to make the text downloadable as a > normal .txt or HTML file from the site which offers the GPL'ed > software, not that you need the whole text of the GPL on every single > page of the site, or included with every single resource files which > comprises the site. After all, you can GPL image resources like PNG/ > GIF/JPG/etc files, but the image file formats do not lend themselves > to including the GPL text with these image files... You've just repeated your understanding. However you haven't changed mine. I don't think that telling someone where they can find the text to the license is equivalent to actually giving them the license. Cheers, Ben |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsBen Tilly wrote:
> On 1/28/07, Matthew Flaschen <matthew.flaschen@...> wrote: >> Ben Tilly wrote: >> > In my opinion it should be a judgement call based on how closely >> > connected your code is with the design of GNU readline. Remember that >> > copyright is not just intended to apply to literal copying. For >> > instance if I write a short story and Mickey Mouse appears in it, I'm >> > going to hear from Disney's lawyers. >> >> Yes, but probably on trademark grounds. > > On every grounds they can get, *including* copyright. would (if you did nothing more then mention Mickey in the story) > In fact I chose that example specifically for good reason. Disney is > famous for caring about the copyright that they have on Mickey Mouse. > So much so that on multiple occasions they have successfully lobbied > for copyright law to be changed so that they can continue to maintain > that copyright. True, but that's mainly to prevent full-scale copying of the original (now quite valuable) cartoons. > >> Even though I have not copied >> > anything exact, I can still be derivative of it. Likewise if my code >> > makes liberal use of ideas and memes created by GNU readline, there is >> > an argument that I'm derivative of realine regardless of whether I >> > link. >> >> Ideas and memes alone shouldn't be enough to create a derivative work >> under copyright law. > > My understanding (as a non-lawyer) is that copyright law protects my > creative expression. copyright, as long as I ignore your expression. > Nothing stops them from creating an equivalent framework from scratch. Unless it happens to be patented. > >> > Of course my opinion is influenced by having read >> > http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in >> > detail and then having thought about how the changing richness of the >> > Linux kernel module API has changed Linus' opinions about when a >> > binary module is a derived work of the Linux kernel. (And why.) >> >> That is a quite interesting compilation. > > It is. And it gives a lot of insight into how Linus thinks about this > issue. Of course I have no idea of what a lawyer would think about > his thinking... asserts that the LGPL applies de facto...simply because he considers some kernel routines libraries. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn Jan 29, 2007, at 2:37 PM, Ben Tilly wrote:
> True. However it all rests on what is considered "mere aggregation". > I'd be surprised to see a court rule that linking was mere aggreation. > Particularly given the fact that the FSF has made it very clear that > they *don't* think that linking is mere aggregation, and nobody has > challenged them on that. Hmm-- what about people like nVidia providing proprietary Linux kernel modules for their video cards...? > [ ... ] >> > In any case you raised a number of interesting points in that >> email. >> > A key one is that in your opinion distributing a hyperlink to >> the GPL >> > along with a GPLed file should count as distribution of the GPL >> > license. While this seems like a reasonable practice, it doesn't >> > match my understanding of the GPL that one can merely offer the >> > license text in place of giving the license text to the recipient. >> > (The license says that one must give the recipient the license.) >> >> Yes, it does. If you've redistributed GPL'ed software such as >> JavaScript code, CSS, etc, then you need to provide the text of the >> GNU General Public License to the recipients. > > Excuse me? You said "(The license says that one must give the recipient the license.)"; I agree with this, that is a reasonable paraphrase of what GPL clause 1 says. > When I said that it doesn't match my understanding, I meant what I > said. It doesn't match my understanding. Apparently true; I doubt your understanding matches that of the GNU project or almost anyone else such as a Linux vendor redistributing GPL'ed software via the WWW. >> To me, that means you need to make the text downloadable as a >> normal .txt or HTML file from the site which offers the GPL'ed >> software, not that you need the whole text of the GPL on every single >> page of the site, or included with every single resource files which >> comprises the site. After all, you can GPL image resources like PNG/ >> GIF/JPG/etc files, but the image file formats do not lend themselves >> to including the GPL text with these image files... > > You've just repeated your understanding. However you haven't changed > mine. I don't think that telling someone where they can find the text > to the license is equivalent to actually giving them the license. Yes, that's right-- the two are not equivalent. If you browse to a website which redistributes GPLed software via Javascript or whatever, the site should "print or display an announcement ... telling the user how to view a copy of this License." per GPL clause 2c. If you provide a link which lets them view a copy of the license from your site, you've satisfied this requirement. A single source file, .js file, etc does not normally constitute an entire Program; you need to distribute a copy of the GPL with the Program, not with each individual subcomponent. And, as an example to support this interpretation, go visit: http://cvs.savannah.gnu.org/viewcvs/make/?root=make ...or any other GNU project available there via CVSweb and observe for yourself that gnu.org does not provide the full GPL text with every file nor even provide a link to the GPL on each and every page. Neither do third-parties who redistribute GPL source code such as RedHat, Novell, the various BSDs, Darwin from Apple, etc. If your position is that gnu.org, RedHat, and everyone else providing HTTP or FTP access to GPL'ed software in such a fashion nevertheless are violating GPL clause 1, even though it is simply not possible to provide the GPL text with each and every GPL'ed subcomponent due to (eg) binary image formats, please review "reductio ad absurdum": http://en.wikipedia.org/wiki/Reductio_ad_absurdum ...and re-evaluate your position until it does not require the impossible to occur. -- -Chuck |
| < Prev | 1 - 2 - 3 - 4 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |