|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsBen Tilly wrote:
> 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. Usually, you're not displaying parts of the codebase that are under the GPL. 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? If you are really distributing GPLed content. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn 1/25/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> Ben Tilly wrote: > > 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. > > Usually, you're not displaying parts of the codebase that are under the GPL. No, I'm not displaying parts of the codebase. But I'm displaying documents that are derivatives of that codebase. For instance n a typical web page I'm going to include some graphics images, a CSS file verbatim, possibly include some JavaScript files, and the content of the page is going to include large sections of templates that were in the codebase. Much if not all of this is copyrightable information. All that the GPL says on this topic is that "the output from the Program is covered only if its contents constitute a work based on the Program". I'm claiming that the output that is delivered constitutes a work based on the Program. Note that similar issues have come up in the case of gcc, and I have heard that there are optimizations that have not been made because if they were, then the compiled output from gcc would have to be GPLed. > 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? > > If you are really distributing GPLed content. Exactly. Cheers, Ben |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsBen Tilly wrote:
> On 1/25/07, Matthew Flaschen <matthew.flaschen@...> wrote: >> Ben Tilly wrote: >> > 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. >> >> Usually, you're not displaying parts of the codebase that are under >> the GPL. > > No, I'm not displaying parts of the codebase. But I'm displaying > documents that are derivatives of that codebase. For instance n a > typical web page I'm going to include some graphics images, a CSS file > verbatim, possibly include some JavaScript files, and the content of > the page is going to include large sections of templates that were in > the codebase. Much if not all of this is copyrightable information. either don't include this content, or put it into the public domain (or at least a very permissive license). > > Note that similar issues have come up in the case of gcc, and I have > heard that there are optimizations that have not been made because if > they were, then the compiled output from gcc would have to be GPLed. That sounds unlikely to me. glibc already has an exception for linking to proprietary software, and Bison can be used to create proprietary programs, even though both include parts of their code base into derivative works. I think they would make the same exception for gcc if it made practical sense. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions> Always???? So if I write a program to work only on Windows Vista and no
> other system, is my code a derivative work of Windows? That's a non-sequitur in the case of the GPL, because there is a specific exemption in that case. Also, in general, I think one needs to consider what the purpose of the linking restrictions are in trying to determine the meaning of the licence. It is fairly clear that the purpose of the linking requirements are to prevent someone from creating software that can only realistically be used in combination with GPLed code, but isn't, itself, free software. The borderline case occurs when they provide a non-GPLed stub of a GPLed library. I think you then have to consider intention. If the intention is that most users will use that stub, and all functions of the non-free code are still accessible without excessive contortions, it would seem to me that it is legitimate to conform to the API of the GPLed library. If they actually use the machine readable GPLed shared library or header files in building their program, or if their intention is that most users would replace the stub library with the GPLed one, I would suggest that they are trying to defeat the intentions of the GPL. |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsLawrence Rosen wrote:
> Arnoud Engelfriet wrote: > > 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. > > Always???? So if I write a program to work only on Windows Vista and no > other system, is my code a derivative work of Windows? Specifically written to work only with one particular other program. Then it's a derivative. It is based on one pre-existing work and cannot function without that specific pre-existing work. That makes it a derivative in my book. A Windows Vista application normally uses the API that Microsoft so helpfully (cough) provides. Such an application is not a derivative of the Vista program itself. I'd be happy to argue that Microsoft Office, with its internal backdoors to the XP kernel, is a derivative of Windows XP. > > If you write to an API that happens to be implemented by GNU readline > > as well as others, I don't see how you can be a derivative of one > > particular implementation. > > What if those "others" implemented their API in order to be functionally > compatible with GNU readline? Which came first and who copied who? I think > that we also have to carefully distinguish between copyrightable subject > matter and other forms of IP. I'd like to focus on copyright here. As always, it depends on the circumstances of the case. If I'm given an API and I write a program that uses that API, it's not derivative of any particular implementation of the library behind the API. If I write a program that relies on a specific library for certain functionality, my program is a derivative of that library. I'm assuming this involves copying of creative expression of course. > It is perhaps simpler to say that, to the extent that you write a program > that supports a particular API *without basing your expressive coding on > someone else's original copyrightable work*, there is no derivative work > problem. That's the inverse case of what I wrote at the top, yes. I agree with that. > Dynamic *or* static. I'm beginning to question why people developed this fixation on linking as being the Holy Grail of determining derivative work status. Is it because it's easier to understand this mechanism than, say, object-oriented inheritance? Arnoud -- Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud Engelfriet wrote:
> I'm beginning to question why people developed this fixation on > linking as being the Holy Grail of determining derivative work > status. Is it because it's easier to understand this mechanism > than, say, object-oriented inheritance? Static linking is a special case, because the two codebases are permanently (not dynamically) combined into one executable file. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud Engelfriet scripsit:
> Specifically written to work only with one particular other program. > Then it's a derivative. It is based on one pre-existing work and > cannot function without that specific pre-existing work. That makes > it a derivative in my book. That comes awfully close to saying that if you write an article arguing for some position, and I write another article arguing against yours, that my work is a derivative of yours, even if I don't quote you (or at least not beyond fair use/fair dealing). That seems to me a socially dangerous position (it would make life hard for lawyers!). In particular, there exists the C Answer Book (Tondo & Gimpel), which gives answers to the study questions in The C Programming Language (Kernighan & Ritchie). I can't see that it is a derivative work, even though it is hardly usable without K&R. -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime cowan@... for which he stands, one world under http://www.ccil.org/~cowan Linux, with free music and open source software for all. --Julian Dibbell on Brazil, edited |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn Jan 25, 2007, at 5:52 PM, Ben Tilly wrote:
> On 1/25/07, Lawrence Rosen <lrosen@...> wrote: [ ... ] >> Would someone here please explain how the mere act of statically >> linking, >> which may automatically and without my interference take some >> bytes from >> program A and some bytes from program B and combine them in a >> memory image, >> result--without more--in a creative work suitable for independent >> copyright? If you include all of someone else's copyrighted work into a new work, can the new work be considered "independent"? Note that statically linking a program is not an "automatic" action, at least as far as the developer is concerned; a developer explicitly commands the compiler toolchain (perhaps via make, ant, or a fancy IDE) to produce an executable program by combining the program's compiled object modules with libraries to resolve all published global symbols found from any object being linked into the final result. If there are unresolved symbols, the resulting output is not executable without additional linking (whether dynamic or static). Systems which support dynamic linking permit an executable to run so long as any unresolved global symbols can be resolved by dynamically linking in, at runtime, the necessary additional dynamic shared libraries (called .dll's [Dynamic Link Libraries] or .so's [Shared Objects]). Dynamic linking happens automatically as far as the end-user running the program is concerned; however, the developer must still explicitly perform a linking stage which leaves dynamic relocation entries and shared library load commands even when creating a dynamically linked program. [ ... ] > However the complete compiled result is a single program. You could > try to argue that this is "mere aggregation", but I think you'd have a > hard time of it. (For one thing it isn't straightforward to determine > what parts of the final result belong to the GPLed piece and what > parts do not. With mere aggregation that should be easy.) 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 would agree that the information is not readily accessible to a normal user, but the information is present and interpretable within certain limits (such as whether the executable has been stripped). Without the right tools, even a normal filesystem is just a big collection of bits; the level of complexity required to understand a foreign filesystem's directory hierarchy is not significantly different from understanding a foreign binary executable format (ie, examining Dwarf or a.out or PE-COFF on a ELF-based system)... >> I can't find any principled distinction in a copyright sense >> between static >> and dynamic linking, although either kind of linking might be an >> indicator >> of an intention to create a derivative work. You don't create a >> derivative >> work unless you base one creative and expressive work on another, >> which you >> can do equally easily (and equally hard) with static and dynamic >> linking. > > In an abstract copyright sense I agree with you, but I believe that > the GPL's terms draw a practical distinction. However (and this will > be interesting to watch going forward) when you throw in various > virtualization technologies, the GPL may have some unexpected > consequences. For instance suppose that I snapshot an image of a > running system and copy that snapshot elsewhere. If that snapshot > included GPLed programs, does the whole snapshot have to be GPLed? My first take would be no-- a disk image or snapshot falls under GPL clause 2: "In addition, mere 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." > 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?)" Care to pick the thread up from Message-Id: <8A1B049B-8C04-4857-A301-98FB1FD6B0E0@...> or shall I excerpt the end of that message...? :-) -Chuck |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsJohn Cowan wrote:
> Arnoud Engelfriet scripsit: > > Specifically written to work only with one particular other program. > > Then it's a derivative. It is based on one pre-existing work and > > cannot function without that specific pre-existing work. That makes > > it a derivative in my book. > > That comes awfully close to saying that if you write an article arguing > for some position, and I write another article arguing against yours, > that my work is a derivative of yours, even if I don't quote you (or at > least not beyond fair use/fair dealing). That seems to me a socially > dangerous position (it would make life hard for lawyers!). I'm not sure I follow that. A program cannot *function* without the pre-existing library. It has no purpose. It does not work. You can't make such a program without access to the library. The same can be said for an article. Although in that case you could probably rely on fair use or citation rights as an excuse for your derivation, so you would not be infringing. > In particular, there exists the C Answer Book (Tondo & Gimpel), which > gives answers to the study questions in The C Programming Language > (Kernighan & Ritchie). I can't see that it is a derivative work, even > though it is hardly usable without K&R. Well, personally I don't see why such an answer book is *not* a derivative work of K&R. It builds upon K&R and could not have been written without access to K&R. In a somewhat similar case, a US 2nd Circuit Case decided a trivia book for the TV show Seinfeld was a copyright infringement. http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=2nd&navby=case&no=977992 (I don't see much difference between taking notes from Seinfeld and turning those into multiple-choice questions on the one hand and reading questions in K&R and writing down answers. Both involve copying of creative elements from the originals) I agree that it would be useful if people create such books. But given things like this I'm pretty sure it would be regarded as a derivative work under most copyright laws. Arnoud -- Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud Engelfriet wrote:
> John Cowan wrote: >> Arnoud Engelfriet scripsit: >>> Specifically written to work only with one particular other program. >>> Then it's a derivative. It is based on one pre-existing work and >>> cannot function without that specific pre-existing work. That makes >>> it a derivative in my book. >> That comes awfully close to saying that if you write an article arguing >> for some position, and I write another article arguing against yours, >> that my work is a derivative of yours, even if I don't quote you (or at >> least not beyond fair use/fair dealing). That seems to me a socially >> dangerous position (it would make life hard for lawyers!). > > I'm not sure I follow that. A program cannot *function* without > the pre-existing library. It has no purpose. It does not work. > You can't make such a program without access to the library. > > The same can be said for an article. Although in that case you could > probably rely on fair use or citation rights as an excuse for your > derivation, so you would not be infringing. allowed by fair use) if no text was quoted? I highly doubt that. >> In particular, there exists the C Answer Book (Tondo & Gimpel), which >> gives answers to the study questions in The C Programming Language >> (Kernighan & Ritchie). I can't see that it is a derivative work, even >> though it is hardly usable without K&R. > > Well, personally I don't see why such an answer book is *not* > a derivative work of K&R. It builds upon K&R and could not have > been written without access to K&R. I think this is a copyright infringement, because it uses the same form (questions) as K&R. In a somewhat similar case, > a US 2nd Circuit Case decided a trivia book for the TV show Seinfeld > was a copyright infringement. > http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=2nd&navby=case&no=977992 I disagree here, unless the Seinfeld book was using large amounts of exact quotation. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsMatthew Flaschen wrote:
> Arnoud Engelfriet wrote: > > The same can be said for an article. Although in that case you could > > probably rely on fair use or citation rights as an excuse for your > > derivation, so you would not be infringing. > > Do you still think it would be a copyright infringement (though possibly > allowed by fair use) if no text was quoted? I highly doubt that. If no creative elements have been copied, then there can be no infringement. But it doesn't have to be a literal quote (like my quote of you above). The article can paraphrase the point it's responding to. That can still be copying, although it's almost certainly a fair use. > In a somewhat similar case, > > a US 2nd Circuit Case decided a trivia book for the TV show Seinfeld > > was a copyright infringement. > > http://caselaw.lp.findlaw.com/scripts/getcase.pl?court=2nd&navby=case&no=977992 > > I disagree here, unless the Seinfeld book was using large amounts of > exact quotation. According to one source, the book "contained 643 questions regarding characters, dialogue and plot details of virtually every episode of the hit television comedy series "Seinfeld." Forty-one of those questions included verbatim quotes of the show's dialogue, comprising roughly 3-5% of the total script of the quoted episodes." The court considered the book to be a derivative work of the show and rejected the fair use defense. I found the court's response to the argument that only facts were copied to be interesting: "The facts depicted in a Seinfeld episode are quite unlike the facts depicted in a biography, historical text or compilation. Seinfeld is fiction; both the `facts' in the various episodes, and the expression of those facts, are plaintiff's creation." http://cll.inherent.com/articles/article.cfm?articleid=22 Arnoud -- Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud Engelfriet wrote:
> According to one source, the book "contained 643 questions regarding > characters, dialogue and plot details of virtually every episode of the > hit television comedy series "Seinfeld." Forty-one of those questions > included verbatim quotes of the show's dialogue, comprising roughly > 3-5% of the total script of the quoted episodes." Well, given that and that it was commercial, I think their decision was probably correct. > I found the court's response to the argument that only facts were > copied to be interesting: "The facts depicted in a Seinfeld episode are > quite unlike the facts depicted in a biography, historical text or > compilation. Seinfeld is fiction; both the `facts' in the various > episodes, and the expression of those facts, are plaintiff's creation." I find this part dubious. Wouldn't that mean that for instance it's impssible to write a non-infringing review without using a fair use defense? That disturbs me. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud 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. 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. 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. -- --my blog is at http://blog.russnelson.com | You can do any damn thing Crynwr sells support for free software | PGPok | you want, as long as you 521 Pleasant Valley Rd. | +1 315-323-1241 | don't expect somebody else Potsdam, NY 13676-3213 | Sheepdog | to pick up the pieces. |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsRuss 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. Your library would probably only copy the functional elements, i.e. the function calls that GNU readline supports. If you don't copy implementation, your library is not derivative of GNU readline. A program originally written to work only with GNU readline is and remains a derivative of GNU readline. A later compatible alternative does not change that. > 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. I am not relying on the static/dynamic linking situation at all. What I'm saying is that if you write something that needs GNU readline to work, you have a derivative of GNU readline. That's (in my eyes) a useful criterion. If you don't need GNU readline but just any library that implements a char *readline() function, you are not creating a derivative of GNU readline. I still am unsure as to whether a Windows or Linux program would be seen as a derivative work of Windows/Linux. Those programs are written according to a more-or-less standard API, but there is only one implementation of that API available. Fortunately this isn't a problem in practice. Arnoud -- Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsArnoud Engelfriet wrote:
> I still am unsure as to whether a Windows or Linux program would > be seen as a derivative work of Windows/Linux. Those programs are > written according to a more-or-less standard API, but there is only > one implementation of that API available. Not exactly. Wine has implemented most of the Win32 API. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsThe question of derivative work sounds really tricky to me, and I am a
bit surprised that you seem to be so sure that just linking is making a derivative work. By the way, the question arises often, and until now, I have never read a satisfying answer. And if such an answer was easy to produce, why the term "derivative" has been replaced by the "whole work"? My feeling is that the question will not be solved until a judgement, following a trial, would have been made. But still the answer would then be country-specific, and probably quite artificial. And what if a library linking produce a derivative work in a country and not in another country. Would it not be a discrimation between users, so a violation of the open-source definiton? We can also consider a different situation. Often, GPLd library are created as replacements to non-GPLd libraries (to my best knowledge, it is for instance the case of TLS, whose goal is to replace SSL), so programs designed to work with these libraries are only using in practice previously designed functionalities, so if we later just consider the function definitions to recreate equivalent functionalities, why should we still have to consider the work as a derivative of the GPLd library? And by the way, how can we now with certainty that the original author has written is code in order to only allow the use of the GPLd library? It could be only a transitional development phase, a "better-than-nothing" solution. I become more and more uncomfortable with the "all-GPL" (GNU project) vision behind this licence, and I cannot accept to see for instance the GPL copyright notice in the beginning of the BLAS header in the GSL library. How can I think that using the GSL blas is producing a GPL derivative, while I could compile with ATLAS without changing a single line of code? The rationale of GPL 3 is well designed on this point, since the "whole work" do not include such standardized API... if you can define what is standard and what is not... The licence GPL 3 becomes less and less clear, and it could produce a lot of law problems, especially in Europe where trials are not as expensive as in North America, and law is different. For instance, GPL is a contract in view of European law, even if Moglen does not agree. But first of all, remind that United Stated is not the only country on earth, so you should try to avoid and location-specific consideration... Fabian P.S.: while I am writing, I would like to make an off-topic, and gently ask all to stop discussion about "delete me"? Even if Russ Nelson's words could have been better, I can understand him because it becomes really frustrating to receive such emails, especially the spam one. I do not subscribe to list to get reminders, but to learn and discuss about the topic, which is not what it is done on this other thread. Arnoud Engelfriet a écrit : > Russ 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. >> > > Your library would probably only copy the functional elements, i.e. > the function calls that GNU readline supports. If you don't copy > implementation, your library is not derivative of GNU readline. > > A program originally written to work only with GNU readline is and > remains a derivative of GNU readline. A later compatible alternative > does not change that. > > >> 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. >> > > I am not relying on the static/dynamic linking situation at all. > > What I'm saying is that if you write something that needs GNU > readline to work, you have a derivative of GNU readline. That's > (in my eyes) a useful criterion. If you don't need GNU readline > but just any library that implements a char *readline() function, > you are not creating a derivative of GNU readline. > > I still am unsure as to whether a Windows or Linux program would > be seen as a derivative work of Windows/Linux. Those programs are > written according to a more-or-less standard API, but there is only > one implementation of that API available. Fortunately this isn't > a problem in practice. > > Arnoud > > |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsFabian Bastin wrote:
> My feeling is that the question will not be solved until a > judgement, following a trial, would have been made. But still the answer > would then be country-specific, and probably quite artificial. That's certainly right. > And what if a library linking produce a derivative work in a country and not in > another country. Would it not be a discrimation between users, so a > violation of the open-source definiton? No, as long as the license didn't discriminate. However, copyright holders might be able/have to discriminate in enforcement. > We can also consider a different situation. Often, GPLd library are > created as replacements to non-GPLd libraries (to my best knowledge, it > is for instance the case of TLS, whose goal is to replace SSL) These are protocols, not programs. Free and unfree software exists for both. > why should we still have to consider the work as a > derivative of the GPLd library? IANAL, but in my opinion, it would only be a derivative of the GPL if it were built to specifically use GPL code. > And by the way, how can we now with > certainty that the original author has written is code in order to only > allow the use of the GPLd library? It could be only a transitional > development phase, a "better-than-nothing" solution. I think that if the code wasn't written specifically for GPL code, it probably isn't a derivative work > > I become more and more uncomfortable with the "all-GPL" (GNU project) > vision behind this licence The GNU Project is not all-GPL in any sense. The GNU project itself uses other licenses for its code, including LGPL and MIT. They have also "adopted" external code under other licenses, such as X11. Their criterion is simply whether they believe the license is free; in practice these licenses overlap almost completely with OSI-approved licenses , and I cannot accept to see for instance the > GPL copyright notice in the beginning of the BLAS header in the GSL > library. How can I think that using the GSL blas is producing a GPL > derivative, while I could compile with ATLAS without changing a single > line of code? I don't know anything about this. It would probably depend on what was written when, designed for what. The rationale of GPL 3 is well designed on this point, > since the "whole work" do not include such standardized API... Are you trying to note some difference between GPL v2 and v3 here? I'm not understanding your point. GPL v2 says (referring the requirements for new code), "These requirements apply to the modified work as a whole." and GPL v3 says, "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy." I don't see a big distinction here. > The licence GPL 3 becomes less and less clear, and it could produce a lot of law problems, > especially in Europe where trials are not as expensive as in North > America, and law is different. For instance, GPL is a contract in view > of European law, even if Moglen does not agree. But first of all, remind > that United Stated is not the only country on earth, so you should try > to avoid and location-specific consideration... I'm really losing your point here, but GPL 3 is specifically written to minimize such local variations in interpretations. That's why it uses custom terminology like "propagation" and "conveying"; the idea is that these words don't have existing meaning in any legal systems. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsMatthew Flaschen a écrit :
> Fabian Bastin wrote: > >> My feeling is that the question will not be solved until a >> judgement, following a trial, would have been made. But still the answer >> would then be country-specific, and probably quite artificial. >> > > That's certainly right. > > >> And what if a library linking produce a derivative work in a country and not in >> another country. Would it not be a discrimation between users, so a >> violation of the open-source definiton? >> > > > No, as long as the license didn't discriminate. However, copyright > holders might be able/have to discriminate in enforcement. > > >> We can also consider a different situation. Often, GPLd library are >> created as replacements to non-GPLd libraries (to my best knowledge, it >> is for instance the case of TLS, whose goal is to replace SSL) >> > > These are protocols, not programs. Free and unfree software exists for > both. > > Ok. Badly expressed. The point that I would raise is just that GPL library, and more specific GNU codes, are sometimes produced juste to replaced preexisting things. TLS and SSL are protocols, indeed, but in practice, GNU TLS can be seen as an attempt to OpenSSL for instance. The example is probably not the best. I have to think a bit more in order to produce a better one. >> why should we still have to consider the work as a >> derivative of the GPLd library? >> > > IANAL, but in my opinion, it would only be a derivative of the GPL if it > were built to specifically use GPL code. > > >> And by the way, how can we now with >> certainty that the original author has written is code in order to only >> allow the use of the GPLd library? It could be only a transitional >> development phase, a "better-than-nothing" solution. >> > > I think that if the code wasn't written specifically for GPL code, it > probably isn't a derivative work > > first author? And what about the co-authors? The question of intention can be very tricky to determine. >> I become more and more uncomfortable with the "all-GPL" (GNU project) >> vision behind this licence >> > > The GNU Project is not all-GPL in any sense. The GNU project itself > uses other licenses for its code, including LGPL and MIT. They have > also "adopted" external code under other licenses, such as X11. Their > criterion is simply whether they believe the license is free; in > practice these licenses overlap almost completely with OSI-approved licenses > > (http://www.gnu.org/licenses/), and the other licences are sometimes used for convenience, but not recommanded for the GNU project. Stallman position about LGPL for istance is quite clear, since he explicitely recommands to avoid LGPL when possible in order to force people to switch to GPL. > , and I cannot accept to see for instance the > >> GPL copyright notice in the beginning of the BLAS header in the GSL >> library. How can I think that using the GSL blas is producing a GPL >> derivative, while I could compile with ATLAS without changing a single >> line of code? >> > > I don't know anything about this. It would probably depend on what was > written when, designed for what. > > The rationale of GPL 3 is well designed on this point, > >> since the "whole work" do not include such standardized API... >> > > Are you trying to note some difference between GPL v2 and v3 here? I'm > not understanding your point. GPL v2 says (referring the requirements > for new code), "These requirements apply to the modified work as a > whole." and GPL v3 says, "You must license the entire work, as a whole, > under this License to anyone who comes into possession of a copy." I > don't see a big distinction here. > > in GPL v2 in Point 0, which defines the licence extent. GPL v3 differs by speaking only about the whole work, and in Point 0, the "covered work". The definitions have to be found in the rationale. It seems (also from other discussion) that the GPL v3 has been cautious with the use of the word derivative, because of the interpretation problem. >> The licence GPL 3 becomes less and less clear, and it could produce a >> > lot of law problems, > >> especially in Europe where trials are not as expensive as in North >> America, and law is different. For instance, GPL is a contract in view >> of European law, even if Moglen does not agree. But first of all, remind >> that United Stated is not the only country on earth, so you should try >> to avoid and location-specific consideration... >> > > I'm really losing your point here, but GPL 3 is specifically written to > minimize such local variations in interpretations. That's why it uses > custom terminology like "propagation" and "conveying"; the idea is that > these words don't have existing meaning in any legal systems. > > imply that the licence will be subjet to a lot of interpretations if contested, and the interpretation could be dependent on the location. The fact is that until now, disputes (with one or two exception) have been mainly resolved without trials. What I want to say is that trials could so much money in US that it is really the best way to proceed, and I think that Moglen have taken this fact into account. The European situation is different, with for instance the Munich trial, which has been well publicized because it has recognized the validity of the GPL. Local terms are not too difficult to interpret if the law system is precised, so I think that it is an acceptable solution, but the problem is then that it could conflit with local laws, and again we face an interpretation problem about how to take the author willingness and local regulations. I find all of this far from be simple... Fabian |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsFabian Bastin wrote:
>> No, as long as the license didn't discriminate. However, copyright >> holders might be able/have to discriminate in enforcement. >> >> > You are right. But it would still be a bad situtation in my eyes. Definitely. > >>> We can also consider a different situation. Often, GPLd library are >>> created as replacements to non-GPLd libraries (to my best knowledge, it >>> is for instance the case of TLS, whose goal is to replace SSL) >>> >> >> These are protocols, not programs. Free and unfree software exists for >> both. >> >> > Ok. Badly expressed. The point that I would raise is just that GPL > library, and more specific GNU codes, are sometimes produced juste to > replaced preexisting things. TLS and SSL are protocols, indeed, but in > practice, GNU TLS can be seen as an attempt to OpenSSL for instance. The > example is probably not the best. I have to think a bit more in order to > produce a better one. compatible implementation of UNIX. However, the GNU project focuses on replacing only code that is unfree. That's why they kept X Windows, Tex, etc., even though these weren't under the GPL. See http://www.gnu.org/licenses/license-list.html#SoftwareLicenses for a list of licenses the FSF considers free. >> I think that if the code wasn't written specifically for GPL code, it >> probably isn't a derivative work >> >> > So the question is than how to determine the initial opinion of the > first author? And what about the co-authors? The question of intention > can be very tricky to determine. Right. I agree this whole thing isn't simple. >>> I become more and more uncomfortable with the "all-GPL" (GNU project) >>> vision behind this licence >>> >> >> The GNU Project is not all-GPL in any sense. The GNU project itself >> uses other licenses for its code, including LGPL and MIT. They have >> also "adopted" external code under other licenses, such as X11. Their >> criterion is simply whether they believe the license is free; in >> practice these licenses overlap almost completely with OSI-approved >> licenses >> >> > Well, the GPL licence is the licence promoted and recommanded by the FSF > (http://www.gnu.org/licenses/), and the other licences are sometimes > used for convenience, but not recommanded for the GNU project. copyleft, and already widespread. Stallman > position about LGPL for istance is quite clear, since he explicitely > recommands to avoid LGPL when possible in order to force people to > switch to GPL. Yes. The FSF's position is code should remain free for all end-users, and GPL is the best way to accomplish this; personally, I also support the GPL for this reason. > If you take the whole licences, you could observe the word "derivative" > in GPL v2 in Point 0, which defines the licence extent. GPL v3 differs > by speaking only about the whole work, and in Point 0, the "covered > work". The definitions have to be found in the rationale. This is incorrect. The phrase "whole work" is not used, and "covered work" is defined in Section 0. >> I'm really losing your point here, but GPL 3 is specifically written to >> minimize such local variations in interpretations. That's why it uses >> custom terminology like "propagation" and "conveying"; the idea is that >> these words don't have existing meaning in any legal systems. >> >> > Sorry that my point is not clear. The lack of existing meaning could > imply that the licence will be subjet to a lot of interpretations if > contested, and the interpretation could be dependent on the location. The interpretation of terms of art like "derivative work" are certainly dependent on location. Part of GPL 3 is to construct new, clear meaning from words with no existing legal meaning. I think this will result in less location-specific interpretation, since courts will hopefully look more to the license itself. However, IANAL and this could be the wrong approach. > The fact is that until now, disputes (with one or two exception) have > been mainly resolved without trials. What I want to say is that trials > could so much money in US that it is really the best way to proceed, and > I think that Moglen have taken this fact into account. The European > situation is different, with for instance the Munich trial, which has > been well publicized because it has recognized the validity of the GPL. Right, but there haven't been a flurry of GPL v2 trials anywhere; I don't think that will change with GPL v3. > Local terms are not too difficult to interpret if the law system is > precised, so I think that it is an acceptable solution What? If they wanted to use local terms, they'd have to create a hundred versions of the license; this is very undesirable. > > I find all of this far from be simple... I agree. Matthew Flaschen |
|
|
Re: Dynamic linking, was: Re: Dispelling BSD License MisconceptionsOn 1/26/07, Chuck Swiger <chuck@...> wrote:
> On Jan 25, 2007, at 5:52 PM, Ben Tilly wrote: > > On 1/25/07, Lawrence Rosen <lrosen@...> wrote: [...] > > However the complete compiled result is a single program. You could > > try to argue that this is "mere aggregation", but I think you'd have a > > hard time of it. (For one thing it isn't straightforward to determine > > what parts of the final result belong to the GPLed piece and what > > parts do not. With mere aggregation that should be easy.) > > 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 would > agree that the information is not readily accessible to a normal > user, but the information is present and interpretable within certain > limits (such as whether the executable has been stripped). 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". 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. > Without the right tools, even a normal filesystem is just a big > collection of bits; the level of complexity required to understand a > foreign filesystem's directory hierarchy is not significantly > different from understanding a foreign binary executable format (ie, > examining Dwarf or a.out or PE-COFF on a ELF-based system)... Without the right tools, a CD is just a shiny disk. :-) [...] > > In an abstract copyright sense I agree with you, but I believe that > > the GPL's terms draw a practical distinction. However (and this will > > be interesting to watch going forward) when you throw in various > > virtualization technologies, the GPL may have some unexpected > > consequences. For instance suppose that I snapshot an image of a > > running system and copy that snapshot elsewhere. If that snapshot > > included GPLed programs, does the whole snapshot have to be GPLed? > > My first take would be no-- a disk image or snapshot falls under GPL > clause 2: > > "In addition, mere 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." Again the question is whether this case is mere aggregation. I can make arguments both ways. > > 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?)" Care to pick the thread up from Message-Id: > <8A1B049B-8C04-4857-A301-98FB1FD6B0E0@...> or shall I excerpt > the end of that message...? :-) I'm not aware of an easy way within gmail to look up messages by message ID. Going to the archive, I think you are referring to your response at http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11975:200612:pkdkohikcmmfeklkbdhe which I didn't respond to. (In large part because I was going on vacation right then and so didn't have time.) 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.) Cheers, Ben |
| < Prev | 1 - 2 - 3 - 4 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |