"work based on" definition
Jean-Marc Lienher
I would like to know what's the definition of a "work based on"
according to the Copyright laws.
When I create and sell a program which use a dynamic
library is my program a "work based on" that library ?
Even if I don't redistribute that library ?
If yes, as the copyright holder of the dynamic library can I restrict
the definition of a "work based on" to "a work containing portion of
the original work".
For example by writing something like that in my license:
The term "work based on", below, refers to any derivative work
under copyright law: that is to say, a work containing a portion
of the original work.
(A program which uses a dynamic library doesn't contain any portion
of that library before it is runned by the end-user.)
Bruce E. Hayden
> I would like to know what's the definition of a "work based on"
> according to the Copyright laws.
Note that my comments below are based on U.S. copyright law.
Swiss copyright law is probably very different.
> When I create and sell a program which use a dynamic
> library is my program a "work based on" that library ?
> Even if I don't redistribute that library ?
Well, regardless of the definition of a derivative work,
your program would definitely impinge the copyright of
the library. That is why libraries almost always come
with a license that allows precisely what you did, and
indeed, usually allow you to also sell a product containing
the library.
That said, "based on" is more a function of someone borrowing
some sort of original expression from the underlying work,
and not that of utilizing the underlying work.
> If yes, as the copyright holder of the dynamic library can I restrict
> the definition of a "work based on" to "a work containing portion of
> the original work".
I am not sure what you have in mind here.
> For example by writing something like that in my license:
> The term "work based on", below, refers to any derivative work
> under copyright law: that is to say, a work containing a portion
> of the original work.
You cannot really redefine a derivative work through contract.
That said, you are in control of whatever license you may
provide for code that you wrote yourself.
> (A program which uses a dynamic library doesn't contain any portion
> of that library before it is runned by the end-user.)
Ok, I think that I have this figured out. Your program uses
a dynamic library which is provided by someone else. I would
think then that if you make sure that they get the library
from someone else, then you probably can draft a license
agreement for your own code that protects yourself against
the copyright owner for the dynamic library.
--
--------------------------------------------------------------------
The preceding was not a legal opinion, and is not my employer's.
Original portions Copyright 2003 Bruce E. Hayden,all rights reserved
My work may be copied in whole or part, with proper attribution,
as long as the copying is not for commercial gain.
--------------------------------------------------------------------
Bruce E. Hayden bha...@ieee.org
Dillon, Colorado bha...@highdown.com
Phoenix, Arizona bha...@copatlaw.com
Jean-Marc Lienher
>
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> > I would like to know what's the definition of a "work based on"
> > according to the Copyright laws.
>
> Note that my comments below are based on U.S. copyright law.
> Swiss copyright law is probably very different.
Certainly, but as my software are distributed on the internet,
US laws will rules in most cases.
>
> > When I create and sell a program which use a dynamic
> > library is my program a "work based on" that library ?
> > Even if I don't redistribute that library ?
>
> Well, regardless of the definition of a derivative work,
> your program would definitely impinge the copyright of
> the library. That is why libraries almost always come
> with a license that allows precisely what you did, and
> indeed, usually allow you to also sell a product containing
> the library.
>
> That said, "based on" is more a function of someone borrowing
> some sort of original expression from the underlying work,
> and not that of utilizing the underlying work.
>
> > If yes, as the copyright holder of the dynamic library can I restrict
> > the definition of a "work based on" to "a work containing portion of
> > the original work".
>
> I am not sure what you have in mind here.
That's because I'm splitting hair.
>
> > For example by writing something like that in my license:
> > The term "work based on", below, refers to any derivative work
> > under copyright law: that is to say, a work containing a portion
> > of the original work.
>
> You cannot really redefine a derivative work through contract.
> That said, you are in control of whatever license you may
> provide for code that you wrote yourself.
>
> > (A program which uses a dynamic library doesn't contain any portion
> > of that library before it is runned by the end-user.)
>
> Ok, I think that I have this figured out. Your program uses
> a dynamic library which is provided by someone else.
Yes and no.
> I would
> think then that if you make sure that they get the library
> from someone else, then you probably can draft a license
> agreement for your own code that protects yourself against
> the copyright owner for the dynamic library.
First thank you for your reply. It's so difficult to get fair
answer on this subject.
Now let me tell you the full story.
There is an holy war in the Open Source community about the
GPL (GNU GENERAL PUBLIC LICENSE).
( http://www.gnu.org/licenses/gpl.html#SEC3 )
A member of the OSI (Open Source Initiative) posted that article :
http://www.linuxjournal.com/article.php?sid=6366
But the FSF (Free Software Fundation) says :
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
And me, I'm a progammer who as developed some software and
placed them under the GPL.
Before reading the OSI member's article I was beleaving that
nobody can use my software to create a non-GPL software.
Since the GPL license explicitly allows anybody to
create (and redistribute) a dynamic GPL library with the code
of my software, that's why I'm asking if dynamically compiled
program is a derivative work of the dynamic library.
And I ask if I can redefine the meaning of derivative work,
because the GPL nearly does in the second sentance of section 0.
How I understand that section is that a dynamically linked
program is not a derivative work under the scope of the GPL.
There is no problem of where the end-user can get the dynamic
GPL library, since everybody is allowed to redistribute and/or sell
it. The author of the dynamically compiled program can even
create a non-profit web site to distribute the GPL library only,
if he is at the same time the author of the non-GPL program.
(He can even advertize that he is a great supporter of the
Open Source community because he has done a great library based on
work of someone else. :-()
Can I sue the author of the dynamically compiled program and
expect to have more than 2% of chances to win ?
Now I will understand If you don't want to say anything about
that particular case, because if you do then you will certainly
get flames from both the FSF and OSI's fanatics.
Arnoud Galactus Engelfriet
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>I would like to know what's the definition of a "work based on"
>according to the Copyright laws.
That depends on the copyright law you look for. But it's very
difficult to find court cases on this topic. Copyright law
calls it a "derivative work", but the main focus is on things
like translations, making plays from a book or incorporating
a photo in a magazine.
>When I create and sell a program which use a dynamic
>library is my program a "work based on" that library ?
>Even if I don't redistribute that library ?
That depends on how you "use" the dynamic library. In the
case of the GPL (which I suspect is what you're thinking of),
some people, including the author of the GPL, defend that
yes, this makes your work 'based on' the library.
However, again in the case of the GPL, this means that you
can only distribute the resulting work under the GPL. You
can keep the program to yourself.
>If yes, as the copyright holder of the dynamic library can I restrict
>the definition of a "work based on" to "a work containing portion of
>the original work".
This is a more difficult question, because it depends on how
far copyright law goes. You can't do things in a copyright
license that go beyond what copyright law regulates, unless
you enter in a contract with the licensee.
I suppose you could say "You can copy and distribute a work
containing a portion of the original work only under
condition X. All other combinations of the original work
with another work are permitted to be distributed
without restriction."
This would be a bit dangerous, since you've now given
blanket permission for all kinds of derivations other
than those that contain a portion of your program. And who
knows what will happen in five years?
>For example by writing something like that in my license:
>The term "work based on", below, refers to any derivative work
>under copyright law: that is to say, a work containing a portion
>of the original work.
The problem with that is it only works if the other party
agrees to that definition. And that requires you to have
a contract. With GPL-like licenses, it's not at all clear
there *is* a contract between you and the licensee, so
you should be careful here.
Arnoud
--
Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Jean-Marc Lienher
> >For example by writing something like that in my license:
> >The term "work based on", below, refers to any derivative work
> >under copyright law: that is to say, a work containing a portion
> >of the original work.
>
> The problem with that is it only works if the other party
> agrees to that definition. And that requires you to have
> a contract. With GPL-like licenses, it's not at all clear
> there *is* a contract between you and the licensee, so
> you should be careful here.
Can I fairly say that nobody can know before going in court ?
Arnoud Galactus Engelfriet
>> agrees to that definition. And that requires you to have
>> a contract. With GPL-like licenses, it's not at all clear
>> there *is* a contract between you and the licensee, so
>> you should be careful here.
>
>Can I fairly say that nobody can know before going in court ?
Sure, that's a real lawyer's answer. :-)
Nobody knows for sure whether the GPL will stand up in
court, and if so how far it can reach. The only
sensible thing to do (other than avoiding GPL-licensed
software altogether, which may be impractical) is to
study how it was intended, and to work with that as
an internal guideline. And then, if you don't like
the consequences of that guideline, you can't use
that software.
Stefaan A Eeckels
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
First, IANAL, but my uncle is one ;-)
> I would like to know what's the definition of a "work based on"
> according to the Copyright laws.
>
> When I create and sell a program which use a dynamic
> library is my program a "work based on" that library ?
> Even if I don't redistribute that library ?
In my understanding, the (USA) copyright statute does not
deal with this specific issue, as it predates the technology.
I would argue that making calls to a library is not enough
to make source code a derivative work of that library. If it
were so, then any program would be a derivative of the OS
on which it runs, something that would have nasty consequences
as it would allow the OS copyright holders to arbitrarily restrict
which programs can be written for their OS, and they would be able
to stop any third party from writing programs for their OS (as
one is not allowed to prepare derivative works without the
consent of the copyright holder).
It might even be argued that an OS is a derivative work of the
microcode in the processor, as it "calls" the routines in the
microcode. Clearly, the effects of considering a program in
source code a derivative work of the code it calls or references
would have so many nefarious consequences the statutes will have
to be amended if ever a court rules in this sense.
> If yes, as the copyright holder of the dynamic library can I restrict
> the definition of a "work based on" to "a work containing portion of
> the original work".
You can word your license as pleases you, but even a
lawyer will not give you any assurances as to its
effectiveness in a court of law.
> For example by writing something like that in my license:
> The term "work based on", below, refers to any derivative work
> under copyright law: that is to say, a work containing a portion
> of the original work.
I think that the GPL's use of "a work based on" is a reference
to the definition of a derivative work in the copyright statute.
> (A program which uses a dynamic library doesn't contain any portion
> of that library before it is runned by the end-user.)
>
Personally, I think that there is little doubt that the running program
in memory is a derivative work of both its source code, and the
libraries (and the OS) it uses. I also firmly believe that this
does _not_ make the source code a derivative work of any of these
libraries. Whether the compiled, dynamically linked program on
a medium (ie not loaded for execution, and containing only references
to the libraries and the OS, that will need to be resolved by the
linking loader before execution is possible) is a derivative work of
the OS and libraries it was designed to work with is not clear, and
has not been tested in court. The FSF argues it is.
Again, IANAL.
--
Stefaan
--
"One man alone can be pretty dumb sometimes, but for real bona fide
stupidity there ain't nothing can beat teamwork." -- Mark Twain
Jean-Marc Lienher
> In my understanding, the (USA) copyright statute does not
> deal with this specific issue, as it predates the technology.
> I would argue that making calls to a library is not enough
> to make source code a derivative work of that library. If it
Bay saying that you will not make new friends at the FSF.
(As I did not on their news group :-)
But I think that you're right.
Because when I create and distribute a program under Windows
using a free compiler I don't recieve any license from Microsoft to
do it.
If we follow the FSF's logic then Microsoft is a copyright holder
of my own programs...
Christopher C. Stacy
(that is, whether you are making a copy of the library), and of
course on what the license from the library (OS) vendor says.
Stefaan A Eeckels
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> "Bruce E. Hayden" a écrit :
> >
> > Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> > > I would like to know what's the definition of a "work based on"
> > > according to the Copyright laws.
> >
> > Note that my comments below are based on U.S. copyright law.
> > Swiss copyright law is probably very different.
>
> Certainly, but as my software are distributed on the internet,
> US laws will rules in most cases.
Not unless you're suying in the US.
> >
> > > When I create and sell a program which use a dynamic
> > > library is my program a "work based on" that library ?
> > > Even if I don't redistribute that library ?
> >
> > Well, regardless of the definition of a derivative work,
> > your program would definitely impinge the copyright of
> > the library. That is why libraries almost always come
> > with a license that allows precisely what you did, and
> > indeed, usually allow you to also sell a product containing
> > the library.
With all due respect Bruce, I think you're wrong here.
References to another work don't cause another work to
be a derivative, and the copyright statutes do not mention
with functionality as a criterion for a derivative work.
References to other works are specifically allowed under
the fair use clause. I admit that the analogy between a
program and printed matter is becoming weaker with the
day, but IMHO (and IANAL) opinion, the texts offer no support
for your interpretation.
<snippage>
> First thank you for your reply. It's so difficult to get fair
> answer on this subject.
>
> Now let me tell you the full story.
>
> There is an holy war in the Open Source community about the
> GPL (GNU GENERAL PUBLIC LICENSE).
> ( http://www.gnu.org/licenses/gpl.html#SEC3 )
>
> A member of the OSI (Open Source Initiative) posted that article :
> http://www.linuxjournal.com/article.php?sid=6366
>
> But the FSF (Free Software Fundation) says :
> http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
>
> And me, I'm a progammer who as developed some software and
> placed them under the GPL.
>
> Before reading the OSI member's article I was beleaving that
> nobody can use my software to create a non-GPL software.
That was naive, as people are using Linux on a daily basis
to create non-GPLed software.
> Since the GPL license explicitly allows anybody to
> create (and redistribute) a dynamic GPL library with the code
> of my software, that's why I'm asking if dynamically compiled
> program is a derivative work of the dynamic library.
When the GPL was written, there were no (or hardly any) OSes
that supported dynamic linking, and hence any program compiled
against a library had to include bits of it.
Technology has evolved, making it possible to have a binary
that uses a library, but contains only references to this
library. Because the copyright statutes were written to
define the protection of printed matter, a dynamically compiled
program is more like a book making references to other works
than a book containing significant portions of another book.
Requiring a dynamically compiled program to be a derivative
work of the library is IMHO the same as making a web page
a derivative work of the pages it links to (or at least, I
believe serious case could be made for this interpretation).
> And I ask if I can redefine the meaning of derivative work,
> because the GPL nearly does in the second sentance of section 0.
> How I understand that section is that a dynamically linked
> program is not a derivative work under the scope of the GPL.
If your program is turned into a shared library, and people
call functions from this shared library in a non-free program,
the only thing they can do is distribute their own program
under a closed license. The library derived from your program
continues to be under the GPL.
To all intents and purposes, this is the same as a non-free
program that uses, say, GNU Ghostscript to produce PDFs. In both
cases the resulting "system" has functionalities that would not
have been possible without the free programs. The fact is that the
free program contibutes to the value of the closed source program,
but this fact is not relevant to the latter being a derivative
work of the former.
> There is no problem of where the end-user can get the dynamic
> GPL library, since everybody is allowed to redistribute and/or sell
> it. The author of the dynamically compiled program can even
> create a non-profit web site to distribute the GPL library only,
> if he is at the same time the author of the non-GPL program.
> (He can even advertize that he is a great supporter of the
> Open Source community because he has done a great library based on
> work of someone else. :-()
If you don't want someone else to benefit economically from your
gratis programs, then you should not use the GPL, but a not-for
profit license. Trying to broaden the meaning of "derivative work"
is IMHO too dangerous as it contibutes to the efforts of the
large IP-owning companies to restrict the use people can make of
their legally acquired copies.
> Can I sue the author of the dynamically compiled program and
> expect to have more than 2% of chances to win ?
That would depend on the amount of money you can throw at
the case.
> Now I will understand If you don't want to say anything about
> that particular case, because if you do then you will certainly
> get flames from both the FSF and OSI's fanatics.
Oh, for those we have our asbestos suits.
Take care,
Jean-Marc Lienher
> > nobody can use my software to create a non-GPL software.
>
> That was naive, as people are using Linux on a daily basis
> to create non-GPLed software.
I was. But I have excuse to have been brain-washed by the
FSF's philosophy.
>
> > Since the GPL license explicitly allows anybody to
> > create (and redistribute) a dynamic GPL library with the code
> > of my software, that's why I'm asking if dynamically compiled
> > program is a derivative work of the dynamic library.
>
> When the GPL was written, there were no (or hardly any) OSes
> that supported dynamic linking, and hence any program compiled
> against a library had to include bits of it.
That's why I think that if they where really care about the
dynamic library problem then they would have written a new
version of the GPL.
> If your program is turned into a shared library, and people
> call functions from this shared library in a non-free program,
> the only thing they can do is distribute their own program
> under a closed license. The library derived from your program
> continues to be under the GPL.
That's how I understand things too.
>
> If you don't want someone else to benefit economically from your
> gratis programs, then you should not use the GPL, but a not-for
> profit license. Trying to broaden the meaning of "derivative work"
My problem is not profit. But fair profit.
I want that if somebody uses my code to create a software then
he must make its source available. At least for my own use.
But your right, GPL is definitly not the license that I want to use.
> > Can I sue the author of the dynamically compiled program and
> > expect to have more than 2% of chances to win ?
>
> That would depend on the amount of money you can throw at
> the case.
20'000$ is this enough ? ;-)
>
> > Now I will understand If you don't want to say anything about
> > that particular case, because if you do then you will certainly
> > get flames from both the FSF and OSI's fanatics.
>
> Oh, for those we have our asbestos suits.
:-) me too.
Thank you, you are confirming exactly what I was thinking.
Mike Brown
And whether or not in the course of using or linking to the library you
(or your compiler) copies any of the library code into your final
executable.
--
Michael F. Brown
Registered Patent Attorney No. 29,619
Stefaan A Eeckels
The _source_ code is not a derivative of the libraries it calls
or the OS it is designed to run on. The compiled object code
(the .o or .obj before it is linked into a runnable program)
is a derivative only of the source code. The runnable program
is in all likelihood a derivative work of both the source, and
the libraries it statically links with, and the startup code
that is linked in.
It is my opinion that the runnable program is not a derivative
of the libraries it dynamically links to. Assuming this is the
case because the program is useless without the library has no
foundation in copyright law (usefulness is not a criterion in
determining derivation). Assuming it is because the result is
functionally equivalent to a statically linked program also has
no foundation in copyright law.
The links in the runnable program are mere references to the
library, and hence do not make it a derivative work (they're
not even excerpts covered by the fair use clause).
What the license of the vendor says is only relevant for the
use you can make of the result of linking with their library
if that result is a derivative work. Otherwise, the license is
irrelevant, as it cannot modify the law. The real problem is
that the law was written for printed words, not for software.
Of course, all this is IMHO, and IANAL.
Christopher C. Stacy
Stefaan> When the GPL was written, there were no (or hardly any) OSes
Stefaan> that supported dynamic linking
Historical footnote: Actually, there were plenty of OSes that did
dynamic linking when the GPL was written, and the author of the GPL
was very familiar with them. You can draw your own conclusions as
to his motives for writing the GPL that way.
Arnoud Galactus Engelfriet
The motives appear to have more to do with keeping the GPL
a pure copyright license and not a contract, since it's
quite unclear whether it would be a valid contract given
the way you 'accept' it. Defining your own term for
'derivative work' or 'work based on' is apparently something
you can't do in a copyright license.
As I understand it, there won't be a definition in GPLv3 either.
Jean-Marc Lienher
The case of the FSF seems to be more and more dark.
I was thinking that it was a real alternative to systems
like Windows. I was realy realy naive.
But after having some discussion on GNU newsgroup and some
contact by e-mail with some members and reread the GPL FAQ, I'm
starting to believe that the FSF is working like a church or a sect.
It's impossible to have a descent talk with them.
(but that's only my own opinion. Maybe it's because I don't ask
the good questions...)
Isaac
<gala...@stack.nl> wrote:
> In article <uk7g2a...@dtpq.com>,
> Christopher C. Stacy <cst...@dtpq.com> wrote:
>>>>>>> On Fri, 14 Feb 2003 09:40:30 +0100, Stefaan A Eeckels ("Stefaan") writes:
>> Stefaan> When the GPL was written, there were no (or hardly any) OSes
>> Stefaan> that supported dynamic linking
>>
>>Historical footnote: Actually, there were plenty of OSes that did
>>dynamic linking when the GPL was written, and the author of the GPL
>>was very familiar with them. You can draw your own conclusions as
>>to his motives for writing the GPL that way.
>
> The motives appear to have more to do with keeping the GPL
> a pure copyright license and not a contract, since it's
> quite unclear whether it would be a valid contract given
> the way you 'accept' it. Defining your own term for
> 'derivative work' or 'work based on' is apparently something
> you can't do in a copyright license.
I think this is a pretty good explanation. I think the other part of
it is that the only real way to fix this part of the GPL would be to add
some kind of user restrictions. I think adding such restrictions would
be a major change in philosophy.
Isaac
Jean-Marc Lienher
> of the libraries it dynamically links to. Assuming this is the
> case because the program is useless without the library has no
> foundation in copyright law (usefulness is not a criterion in
> determining derivation). Assuming it is because the result is
> functionally equivalent to a statically linked program also has
> no foundation in copyright law.
So you are certainly wrong.
Because the FSF says strongly (without giving any legal argument) that :
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
And I had confirmation by e-mail from a FSF's member speeking
officialy that any kind of linking produice a derivative work.
I believe that the FSF knowns this kind of thing better than
anybody on this newsgroup, because they have (of course) many
time sued people in court about this particular case.
And I believe that (of course) they won. ;-)
But that's only what I believe. ;-)
Isaac
wrote:
>
> I believe that the FSF knowns this kind of thing better than
> anybody on this newsgroup, because they have (of course) many
> time sued people in court about this particular case.
> And I believe that (of course) they won. ;-)
I don't think they've sued anyone for GPL violations. I think
to date they've been very successful at protecting the FSF's code
without having to go to court.
Isaac
Stefaan A Eeckels
cst...@dtpq.com (Christopher C. Stacy) wrote:
> >>>>> On Fri, 14 Feb 2003 09:40:30 +0100, Stefaan A Eeckels ("Stefaan")
> >writes: Stefaan> When the GPL was written, there were no (or hardly
> >any) OSes Stefaan> that supported dynamic linking
>
> Historical footnote: Actually, there were plenty of OSes that did
> dynamic linking when the GPL was written, and the author of the GPL
> was very familiar with them.
Plenty? I'd be interested to know the OSes RMS was familiar with
that had dynamic linking. I'm not an OS historian, and there was
a proliferation of OSes in those days, but none of those I worked
with in those years had shared libraries. As a matter of fact, even
the fast machines were so slow that doing the link at load time
would have been a serious drag on resources.
Lee Hollaar
>> Historical footnote: Actually, there were plenty of OSes that did
>> dynamic linking when the GPL was written, and the author of the GPL
>> was very familiar with them.
>
>Plenty? I'd be interested to know the OSes RMS was familiar with
>that had dynamic linking. I'm not an OS historian, and there was
>a proliferation of OSes in those days, but none of those I worked
>with in those years had shared libraries. As a matter of fact, even
>the fast machines were so slow that doing the link at load time
>would have been a serious drag on resources.
Multics, if I remember correctly. (I'm away from my reference
material.) It was an operating system co-developed by Honeywell,
Bell Labs, and MIT. Library rountines could be stored in segments
that were dynamically-linked (largely through hardware) and could
be shared.
The Apollo workstations (early 1980's) also had dynamically-linked
libraries. On one project, I had to write a problem that unlinked
a library, so that a saved image of a running program could be
later run on an Apollo with a different version of the dynamic
library.
As to United States copyright law, when a program is statically-
linked with a library, what is produced is likely NOT a derivative
work of either the program or the library, but a "compilation" --
"a work formed by the collection and assembly of preexisting
materials or of data that are selected, coordinated, or arranged
in such a way that the resulting work as a whole constitutes an
original work of authorship."
Jean-Marc Lienher
Sorry if it was not clear. But it was a joke.
I said that I was brain-washed but now it's ok I'm feeling
really better.
Jean-Marc Lienher
> > The motives appear to have more to do with keeping the GPL
> > a pure copyright license and not a contract, since it's
> > quite unclear whether it would be a valid contract given
> > the way you 'accept' it. Defining your own term for
> > 'derivative work' or 'work based on' is apparently something
> > you can't do in a copyright license.
>
> I think this is a pretty good explanation.
I don't think so.
If it was true, then the FSF would have written that in its FAQ.
> I think the other part of
> it is that the only real way to fix this part of the GPL would be to add
> some kind of user restrictions. I think adding such restrictions would
> be a major change in philosophy.
Yes that's true. But what is the (real) FSF's philosophy ?
But that's Off Topic.
Isaac
> Isaac a écrit :
>> > The motives appear to have more to do with keeping the GPL
>> > a pure copyright license and not a contract, since it's
>> > quite unclear whether it would be a valid contract given
>> > the way you 'accept' it. Defining your own term for
>> > 'derivative work' or 'work based on' is apparently something
>> > you can't do in a copyright license.
>>
>> I think this is a pretty good explanation.
>
> I don't think so.
> If it was true, then the FSF would have written that in its FAQ.
Really? You seem to be saying that the FSF must always be
correct.
If so, why don't you take their statement that programs are derivative
works based on the libraries they call at face value?
IMO if the FSF wants to place restrictions on the use of FSF code
which are beyond that required by copyright, they have to find
a way to bind you legally to an agreement including such restrictions.
But if code that can link dynamically to GPLd code isn't a derivative
work, then under what theory would the developer be bound to care
what restrictions the FSF wants?
Isaac
Isaac
You were probably clear enough. I just missed the smiley and the
sarcasm.
In fact I think I missed it again in another message that I've
already responded to. Mea culpa.
Isaac
Arnoud Galactus Engelfriet
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>Isaac a écrit :
>> > The motives appear to have more to do with keeping the GPL
>> > a pure copyright license and not a contract, since it's
>> > quite unclear whether it would be a valid contract given
>> > the way you 'accept' it. Defining your own term for
>> > 'derivative work' or 'work based on' is apparently something
>> > you can't do in a copyright license.
>>
>> I think this is a pretty good explanation.
>
>I don't think so.
>If it was true, then the FSF would have written that in its FAQ.
Right now it is simply not clear what 'derivative work'
means for software, especially when dealing with dynamically
linked libraries and so on. It is thus theoretically possible
a court could give the term a very broad meaning, which would
be to the benefit of the FSF. It would not be wise for them to
take a narrow position right now, since the rest of the world
would then hold that against them if they ever sue.
>Yes that's true. But what is the (real) FSF's philosophy ?
It's documented fairly clearly at
http://www.gnu.org/philosophy/philosophy.html
"People should be free to use software in all the ways that are
socially useful."
This position would be helped more by a broad interpretation
of 'derivative work' than by a narrow one.
Roger Schlafly
> It's documented fairly clearly at
> http://www.gnu.org/philosophy/philosophy.html
> "People should be free to use software in all the ways that are
> socially useful."
Then you have to understand the Stallman concept of "free", and
"socially useful". He like to say free as in free speech, not free beer.
Somehow he decides that Linux is more free than BSD unix.
Go figure.
Stefaan A Eeckels
hol...@faith.cs.utah.edu (Lee Hollaar) wrote:
> In article <20030215123727.6...@ecc.lu> Stefaan A Eeckels
> <hoen...@ecc.lu> writes:
> >> Historical footnote: Actually, there were plenty of OSes that did
> >> dynamic linking when the GPL was written, and the author of the GPL
> >> was very familiar with them.
> >
> >Plenty? I'd be interested to know the OSes RMS was familiar with
> >that had dynamic linking. I'm not an OS historian, and there was
> >a proliferation of OSes in those days, but none of those I worked
> >with in those years had shared libraries. As a matter of fact, even
> >the fast machines were so slow that doing the link at load time
> >would have been a serious drag on resources.
>
> Multics, if I remember correctly. (I'm away from my reference
> material.) It was an operating system co-developed by Honeywell,
> Bell Labs, and MIT. Library rountines could be stored in segments
> that were dynamically-linked (largely through hardware) and could
> be shared.
But Multics was hardly mainstream - by the early 1980's is was
largely dead, even though it's likely RMS would have known it
as it was the direct reason for Ken writing the first version
of Unix. I'm pretty sure that the then version of Unix did not
have shared libraries though.
> The Apollo workstations (early 1980's) also had dynamically-linked
> libraries. On one project, I had to write a problem that unlinked
> a library, so that a saved image of a running program could be
> later run on an Apollo with a different version of the dynamic
> library.
Did Aegis already have shared libraries, or was that a feature
of Domain/OS?
> As to United States copyright law, when a program is statically-
> linked with a library, what is produced is likely NOT a derivative
> work of either the program or the library, but a "compilation" --
> "a work formed by the collection and assembly of preexisting
> materials or of data that are selected, coordinated, or arranged
> in such a way that the resulting work as a whole constitutes an
> original work of authorship."
Should one seek the permission of the copyright owners before
a compilation can be prepared, or are the rules less strict
than for the preparation of a derivative work?
In any case, I seem to have lost a decade somewhere, as I was
labouring under the misunderstanding that the GPL v2 dated from around
1982, whereas it's from 1991. Obviously, by that time shared libraries
were pretty much mainstream. And maybe one should wonder if the fact
that a reference to them, and their effect on distributing binaries
that use a GPLed shared libraries, was not included in v2 is an
indication that the FSF saw the loophole they create, and ignored
it on purpose.
Thanks!
Stefaan A Eeckels
cst...@dtpq.com (Christopher C. Stacy) wrote:
You are of course correct - I somehow lost a decade (wish
that was true for me personally, but alas) as I was convinced
that the GPL v2 was written in 1982/1983. Obviously, it's was
1991, and by that time shared libraries and dynamic linking
was widespread. Shucks, even Windows 3.0 had them.
1982 is another matter, and I think I'm correct in believing
that around that time, dynamic linking was the exception
rather than the rule.
Thanks for setting me straight.
Jean-Marc Lienher
> IMO if the FSF wants to place restrictions on the use of FSF code
> which are beyond that required by copyright, they have to find
> a way to bind you legally to an agreement including such restrictions.
> But if code that can link dynamically to GPLd code isn't a derivative
> work, then under what theory would the developer be bound to care
> what restrictions the FSF wants?
I think that I've found a solution.
I've modified the GPL to forbid distribution of dynamic library and
server program.
I agree that this solution can't be used everywhere.
But that's the only solution that I've found to protect
my own code.
The full text of my license is available here :
http://www.oksid.ch/license/ofsl.html
The main difference between GPL and my OFSL is Section 3 :
---------------------------------------------------------------------
3. You may copy and/or distribute the Program (or a work based on it,
under Section 2) in executable form under the terms of Sections 1
and 2 above provided that you also meet all of these conditions:
a) Accompany it with the complete corresponding machine-readable
source
code, which must be distributed under the terms of Sections 1 and
2 above on a medium customarily used for software interchange.
b) It is a standard executable that can't export its internal
functions
and that can only create valuable output in direct interaction
with the user's input by keyboard, touch panel, mouse, joystick
and/or digital pen. That is to say: it cannot be (but not limited
to)
a pipe, a server, a library, a shared object nor a shared
service.
c) You must offer the opportunity to all its copyright holders
to have immediate access by HTTP to its complete source code.
If this opportunity is not clearly advertized on a well known
web directory, then you must send an e-mail or a mail to all
its copyright holders.
As a special exception, you may copy the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above for your personal private use only, even if it
doesn't meet condition b) and/or c) of Section 3.
------------------------------------------------------------------
I did that because I've not found a license that fits to my needs.
But if somebody knows another good license then I will throw
away my OFSL and use that one.
Isaac
> Isaac a écrit :
>
>> IMO if the FSF wants to place restrictions on the use of FSF code
>> which are beyond that required by copyright, they have to find
>> a way to bind you legally to an agreement including such restrictions.
>> But if code that can link dynamically to GPLd code isn't a derivative
>> work, then under what theory would the developer be bound to care
>> what restrictions the FSF wants?
>
> I think that I've found a solution.
> I've modified the GPL to forbid distribution of dynamic library and
> server program.
> I agree that this solution can't be used everywhere.
> But that's the only solution that I've found to protect
> my own code.
Can your code be mixed with code under an unmodified GPL? I would
guess not.
It seems like a patch that begs someone to do a work around, but I
wish you the best.
Isaac
Jean-Marc Lienher
> Can your code be mixed with code under an unmodified GPL? I would
> guess not.
No, you can't mix GPL and OFSL code.
That's why I've only released a small program under the OFSL.
I must rewrite some portion of my main project, because
I've used some small GPL code that are not mine.
>
> It seems like a patch that begs someone to do a work around, but I
> wish you the best.
Yes, in fact I did that to give a kick in the ass to the FSF.
Lee Hollaar
>On 15 Feb 2003 15:21:08 GMT
>hol...@faith.cs.utah.edu (Lee Hollaar) wrote:
>> As to United States copyright law, when a program is statically-
>> linked with a library, what is produced is likely NOT a derivative
>> work of either the program or the library, but a "compilation" --
>> "a work formed by the collection and assembly of preexisting
>> materials or of data that are selected, coordinated, or arranged
>> in such a way that the resulting work as a whole constitutes an
>> original work of authorship."
>
>Should one seek the permission of the copyright owners before
>a compilation can be prepared, or are the rules less strict
>than for the preparation of a derivative work?
The person creating the compilation needs the permission of
the copyright owner for each work in the compilation. After
all, their works are being reproduced and distributed, and
just because it is in a compilation doesn't change those acts
into non-infringement.
The copyright owner of the compilation simply has a copyright
on any originality in the compilation, and gains no special
rights to the underlying works.
Christopher C. Stacy
Stefaan> On Fri, 14 Feb 2003 20:25:06 GMT
Stefaan> cst...@dtpq.com (Christopher C. Stacy) wrote:
>> >>>>> On Fri, 14 Feb 2003 09:40:30 +0100, Stefaan A Eeckels ("Stefaan")
>> >writes: Stefaan> When the GPL was written, there were no (or hardly
>> >any) OSes Stefaan> that supported dynamic linking
>>
>> Historical footnote: Actually, there were plenty of OSes that did
>> dynamic linking when the GPL was written, and the author of the GPL
>> was very familiar with them.
Stefaan> Plenty? I'd be interested to know the OSes RMS was familiar with
By that time, dynamic linking was available in several kinds of Unix
and Unix-looking systems. But RMS had been familiar with Multics for
more than 15 years before that, and he was one of the developers of an
operating system for The Lisp Machine. Moreover, just about all the
programming that he had personally done for the past 20 years was
based on dynamic linking.
Isaac
I think the FSF sincerely believes that there is no problem. They
may be right, although IMO, their position is probably wrong.
And as you've probably discovered there probably aren't any fixes
that don't have problems of their own. Your fix obviously wouldn't
work for code intended to be a library.
Isaac
Bruce E. Hayden
> In article <20030215123727.6...@ecc.lu> Stefaan A Eeckels <hoen...@ecc.lu> writes:
>
>>>Historical footnote: Actually, there were plenty of OSes that did
>>>dynamic linking when the GPL was written, and the author of the GPL
>>>was very familiar with them.
>>
>>Plenty? I'd be interested to know the OSes RMS was familiar with
>>that had dynamic linking. I'm not an OS historian, and there was
>>a proliferation of OSes in those days, but none of those I worked
>>with in those years had shared libraries. As a matter of fact, even
>>the fast machines were so slow that doing the link at load time
>>would have been a serious drag on resources.
>
> Multics, if I remember correctly. (I'm away from my reference
> material.) It was an operating system co-developed by Honeywell,
> Bell Labs, and MIT. Library rountines could be stored in segments
> that were dynamically-linked (largely through hardware) and could
> be shared.
I had forgotten the Bell Labs part. I had to go through the
original MULTICS contracts a couple of years ago when it was
being wound down (I think the last site went away right before
Y2K). Honeywell et al. ended up with ownership of it, and
created a couple of machines that would run it. There were
GCOS machines that were modified to run it for awhile. But
then the cost of new machines got high enough, compared
with the installed base, that it was put in maintenance mode
throughout the 1990s. At some point, the company had to
decide between GCOS and MULTICS, and for political reasons
picked the former - which was apparently very unpopular with
the rank and file developers. Twenty years later they were
still griping about the decision due to what they considered
the technical superiority of MULTICS over pretty much any other
mainframe operating system around then.
> The Apollo workstations (early 1980's) also had dynamically-linked
> libraries. On one project, I had to write a problem that unlinked
> a library, so that a saved image of a running program could be
> later run on an Apollo with a different version of the dynamic
> library.
By the early 1980s, I think you also had dynamically linked
libraries of some sort with Sperry, Burroughs, and GCOS
mainframe OSes. In the Sperry case, run time libraries were
shared starting around 1980 - even though bank and offset
addressing was static. Nevertheless, these shared libraries
could be and were continually modified through time without
the necessity of relinking the programs utilizing them.
--
--------------------------------------------------------------------
The preceding was not a legal opinion, and is not my employer's.
Original portions Copyright 2003 Bruce E. Hayden,all rights reserved
My work may be copied in whole or part, with proper attribution,
as long as the copying is not for commercial gain.
--------------------------------------------------------------------
Bruce E. Hayden bha...@ieee.org
Dillon, Colorado bha...@highdown.com
Phoenix, Arizona bha...@copatlaw.com
Jean-Marc Lienher
> >> It seems like a patch that begs someone to do a work around, but I
> >> wish you the best.
> >
> > Yes, in fact I did that to give a kick in the ass to the FSF.
>
> I think the FSF sincerely believes that there is no problem. They
> may be right, although IMO, their position is probably wrong.
The word "sincerely" is maybe not the good term.
I had never read the LGPL, but I took some time to do it.
See that :
---------------------------------------------------------
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
----------------------------------------------------------
In the LGPL they use the same definition for a derivative
work as in GPL. The LGPL was created in the same year as the latest
release of the GPL.
How can the FSF explain (sincerely) that in the GPL a dynamically
linked program is a derivative work and not in the LGPL ?
Don't tell me that they don't know about dynamic linking because
the use both "compiled" and "linked with" terms in the LGPL.
"sincerely" is definitely not the good word.
"Intentionally" is better.
Arnoud Galactus Engelfriet
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> 5. A program that contains no derivative of any portion of the
>Library, but is designed to work with the Library by being compiled or
>linked with it, is called a "work that uses the Library". Such a
>work, in isolation, is not a derivative work of the Library, and
>therefore falls outside the scope of this License.
>
> However, linking a "work that uses the Library" with the Library
>creates an executable that is a derivative of the Library (because it
>contains portions of the Library), rather than a "work that uses the
>library". The executable is therefore covered by this License.
>Section 6 states terms for distribution of such executables.
>----------------------------------------------------------
>In the LGPL they use the same definition for a derivative
>work as in GPL. The LGPL was created in the same year as the latest
>release of the GPL.
>
>How can the FSF explain (sincerely) that in the GPL a dynamically
>linked program is a derivative work and not in the LGPL ?
They say above that a dynamically linked work _IS_ a derivative
of the library. Second paragraph. You cannot distribute such a
linked work unless you comply with section 6 of the LGPL.
The distinction they make is that the work in isolation is not
a derivative work. So if you distribute it separate from the
library it's OK; if you link it together and distribute it
together, that distribution must be under LGPL section 6.
arnoud
Jean-Marc Lienher
>
> In article <3E539D0C...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> > 5. A program that contains no derivative of any portion of the
> >Library, but is designed to work with the Library by being compiled or
> >linked with it, is called a "work that uses the Library". Such a
> >work, in isolation, is not a derivative work of the Library, and
> >therefore falls outside the scope of this License.
> >
> > However, linking a "work that uses the Library" with the Library
> >creates an executable that is a derivative of the Library (because it
> >contains portions of the Library), rather than a "work that uses the
> >library". The executable is therefore covered by this License.
> >Section 6 states terms for distribution of such executables.
> >----------------------------------------------------------
> >In the LGPL they use the same definition for a derivative
> >work as in GPL. The LGPL was created in the same year as the latest
> >release of the GPL.
> >
> >How can the FSF explain (sincerely) that in the GPL a dynamically
> >linked program is a derivative work and not in the LGPL ?
>
> They say above that a dynamically linked work _IS_ a derivative
Yes when it is linked. But this is the end-user who makes the
linking. The creator of the program only compile it with
the library.
> of the library. Second paragraph. You cannot distribute such a
> linked work unless you comply with section 6 of the LGPL.
Yes when it is statically linked.
>
> The distinction they make is that the work in isolation is not
> a derivative work. So if you distribute it separate from the
> library it's OK;
That's exactly what we do with dynamically linked programs.
Arnoud Galactus Engelfriet
>> a derivative work. So if you distribute it separate from the
>> library it's OK;
>
>That's exactly what we do with dynamically linked programs.
You don't distribute necessary libraries together with
your executables? How do you then ensure the user can even
run the program?
Arnoud
Jean-Marc Lienher
>
> In article <3E53A420...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >Arnoud Galactus Engelfriet a écrit :
> >> The distinction they make is that the work in isolation is not
> >> a derivative work. So if you distribute it separate from the
> >> library it's OK;
> >
> >That's exactly what we do with dynamically linked programs.
>
> You don't distribute necessary libraries together with
> your executables? How do you then ensure the user can even
> run the program?
I distribute it on the same CDROM but in a separate package.
Arnoud Galactus Engelfriet
>> your executables? How do you then ensure the user can even
>> run the program?
>
>I distribute it on the same CDROM but in a separate package.
And then I suppose you have an installation script (or set of
rules for the system-wide installer like RPM or dpkg) which
installs both? That sounds like contributory infringement to
me. You're actively trying to get around a license restriction
by dividing up the program like that.
Jean-Marc Lienher
>
> In article <3E53CFA2...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >Arnoud Galactus Engelfriet a écrit :
> >> You don't distribute necessary libraries together with
> >> your executables? How do you then ensure the user can even
> >> run the program?
> >
> >I distribute it on the same CDROM but in a separate package.
>
> And then I suppose you have an installation script (or set of
> rules for the system-wide installer like RPM or dpkg) which
> installs both? That sounds like contributory infringement to
> me. You're actively trying to get around a license restriction
> by dividing up the program like that.
Absolutly not. I'm a great supporter of the Open Source Community
because I've created a nice GPL library (using code written by
somebody else) that anybody can use and re-use.
I'm selling a value added proprietary program which uses that
GPL library. There is nothing in the GPL that forbid it.
Isaac
<gala...@stack.nl> wrote:
> In article <3E53CFA2...@bluewin.ch>,
> Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>>Arnoud Galactus Engelfriet a écrit :
>>> You don't distribute necessary libraries together with
>>> your executables? How do you then ensure the user can even
>>> run the program?
>>
>>I distribute it on the same CDROM but in a separate package.
>
> And then I suppose you have an installation script (or set of
> rules for the system-wide installer like RPM or dpkg) which
> installs both? That sounds like contributory infringement to
> me. You're actively trying to get around a license restriction
> by dividing up the program like that.
The GPL doesn't place restrictions on how users run licensed software.
Given that, how can the developer be guilty of contributory
infringement?
I think the developer/distributor must be guilty of a direct
infringement if he is infringing at all.
Isaac
Arnoud Galactus Engelfriet
Isaac <is...@latveria.castledoom.org> wrote:
>On Wed, 19 Feb 2003 19:06:25 +0000 (UTC), Arnoud "Galactus" Engelfriet
><gala...@stack.nl> wrote:
>> And then I suppose you have an installation script (or set of
>> rules for the system-wide installer like RPM or dpkg) which
>> installs both? That sounds like contributory infringement to
>> me. You're actively trying to get around a license restriction
>> by dividing up the program like that.
>
>The GPL doesn't place restrictions on how users run licensed software.
>Given that, how can the developer be guilty of contributory
>infringement?
Good point; no contributory infringement without any direct
infringement. And the user is allowed to use the GPL library
without any restriction, so that would seem to include linking
it at run-time against 'proprietary' executables.
It still seems wrong somehow. If you were to combine two elements,
and distribute the combination, you'd be infringing, so you
distribute them separately and let the recipient combine them.
That sounds like a trick to circumvent the license.
>I think the developer/distributor must be guilty of a direct
>infringement if he is infringing at all.
Hm. Ok.
Jean-Marc Lienher
> and distribute the combination, you'd be infringing, so you
> distribute them separately and let the recipient combine them.
> That sounds like a trick to circumvent the license.
It's maybe a trick. But how do you make the difference between
a company that is a real Open Source contributor and a company
that is only an unfair Open Source user ?
You can't because both companies must sell proprietary
software to get money. See RedHat, SuSE, SUN... (I agree that their
proprietary software are not using GPL libraries.)
And both companies have made real Open Source contribution.
And the trick is not anymore a trick if the GPL library was made
by another company or a non-profit group. The bad company can
pay a consultant to create the GPL library.
I agree that this is philosophycally unfair. But buisness is
not a matter of philosophy.
The FSF agree in the LGPL that a program which is not
linked to a library is not a derivative work but a
"work that uses the Library".
And since the GPL definition of a derivative work is the
same as in the LGPL, I think that everybody will agree that
a dynamically compiled program is not a dervative work under
the scope of the GPL.
So the FSF can write all that it wants about its philosophy
it will not change the terms of its licenses.
Isaac
> In article <slrnb57tr3...@latveria.castledoom.org>,
> Isaac <is...@latveria.castledoom.org> wrote:
>>On Wed, 19 Feb 2003 19:06:25 +0000 (UTC), Arnoud "Galactus" Engelfriet
>><gala...@stack.nl> wrote:
>>> And then I suppose you have an installation script (or set of
>>> rules for the system-wide installer like RPM or dpkg) which
>>> installs both? That sounds like contributory infringement to
>>> me. You're actively trying to get around a license restriction
>>> by dividing up the program like that.
>>
>>The GPL doesn't place restrictions on how users run licensed software.
>>Given that, how can the developer be guilty of contributory
>>infringement?
>
> Good point; no contributory infringement without any direct
> infringement. And the user is allowed to use the GPL library
> without any restriction, so that would seem to include linking
> it at run-time against 'proprietary' executables.
>
> It still seems wrong somehow. If you were to combine two elements,
> and distribute the combination, you'd be infringing, so you
> distribute them separately and let the recipient combine them.
> That sounds like a trick to circumvent the license.
I agree that it seems wrong somehow, but I think the issue
here is how the law would work to prohibit the trick.
Another complicating issue is that in some situations, the
library would not be distributed, but the user would go out
and grab his own copies from one of the ubiquitous online
archives.
Isaac
Arnoud Galactus Engelfriet
Jean-Marc Lienher <ok...@bluewin.ch> wrote:
>Arnoud Galactus Engelfriet a écrit :
>> It still seems wrong somehow. If you were to combine two elements,
>> and distribute the combination, you'd be infringing, so you
>> distribute them separately and let the recipient combine them.
>> That sounds like a trick to circumvent the license.
>
>It's maybe a trick. But how do you make the difference between
>a company that is a real Open Source contributor and a company
>that is only an unfair Open Source user ?
Is that relevant? The question is, can you legally distribute
a program that relies at run-time on a library under GPL
without licensing the program under the GPL itself?
>You can't because both companies must sell proprietary
>software to get money. See RedHat, SuSE, SUN... (I agree that their
>proprietary software are not using GPL libraries.)
>And both companies have made real Open Source contribution.
It's fine to distribute 'proprietary' software on the same
medium as GPL software. That's a "mere aggregation" and it
is explicitly permitted by the GPL. But that software does
not use GPL'ed libraries (maybe LGPL'ed ones, but those
permit linking from proprietary executables).
>And the trick is not anymore a trick if the GPL library was made
>by another company or a non-profit group. The bad company can
>pay a consultant to create the GPL library.
I do not understand this. Why does it matter who wrote the
library? The license is what counts.
>I agree that this is philosophycally unfair. But buisness is
>not a matter of philosophy.
To a certain extent, especially when dealing with the open
source community and in particular the FSF. You don't want
to be posted on slashdot as a parasite because you are
abusing the letter of the GPL.
>The FSF agree in the LGPL that a program which is not
>linked to a library is not a derivative work but a
>"work that uses the Library".
True, but in the next sentence they go on to say that if
you distribute both together the result _is_ a work based
on the library.
>And since the GPL definition of a derivative work is the
>same as in the LGPL, I think that everybody will agree that
>a dynamically compiled program is not a dervative work under
>the scope of the GPL.
The LGPL definition is not part of the GPL's text, so it
does not follow that the same definition applies.
>So the FSF can write all that it wants about its philosophy
>it will not change the terms of its licenses.
Intent of the licensor is one of the things you use to
determine the scope of a license.
Arnoud Galactus Engelfriet
Isaac <is...@latveria.castledoom.org> wrote:
>On Thu, 20 Feb 2003 11:30:04 +0000 (UTC), Arnoud "Galactus" Engelfriet
><gala...@stack.nl> wrote:
>> It still seems wrong somehow. If you were to combine two elements,
>> and distribute the combination, you'd be infringing, so you
>> distribute them separately and let the recipient combine them.
>> That sounds like a trick to circumvent the license.
>
>I agree that it seems wrong somehow, but I think the issue
>here is how the law would work to prohibit the trick.
Right. And I must admit I don't know. I don't think 'violating
the spirit of a license' is a well-established doctrine.
>Another complicating issue is that in some situations, the
>library would not be distributed, but the user would go out
>and grab his own copies from one of the ubiquitous online
>archives.
Or the library is distributed with the target platform. Even
more interesting, suppose I replace the LGPL'ed standard glibc
with my own, GPL-licensed libc library? Now every program links
against my library, as every program needs libc. Hm.
Roger Schlafly
> a program that relies at run-time on a library under GPL
> without licensing the program under the GPL itself?
And the answer must be YES, or else Linux would have been
dead in the water. Every single application program that runs
under Linux makes OS calls into GPL-licensed Linux code.
They all rely on GPL code at run-time.
If IBM thought that every Linux program must be licensed
under the GPL, then IBM would not be pushing Linux as
it is.
Jean-Marc Lienher
> >linked to a library is not a derivative work but a
> >"work that uses the Library".
>
> True, but in the next sentence they go on to say that if
> you distribute both together the result _is_ a work based
> on the library.
Distribute ? I read "linking".
>
> >And since the GPL definition of a derivative work is the
> >same as in the LGPL, I think that everybody will agree that
> >a dynamically compiled program is not a dervative work under
> >the scope of the GPL.
>
> The LGPL definition is not part of the GPL's text, so it
> does not follow that the same definition applies.
Yes GPL and LGPL are independent. Except that they have been made
at the same moment by the same author.
Here is the LGPL definition of derivative work:
------------------------------------------------------
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language.
------------------------------------------------------
And now the GPL one :
------------------------------------------------------------
The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language.
------------------------------------------------------------
The definitions are exactly the same with different words.
And now the LGPL part which allows dynamic linking of non-LGPL prog :
-----------------------------------------------
5. A program that contains no derivative of any portion of the
^^^^^^^^^^^^^^
Library, but is designed to work with the Library by being compiled or
^^^^^^^
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
--------------------------------------------------
If we assume that a dynamically compiled program is a derivative
work of its library then you CAN'T distribute proprietary programs
which uses LGPL libraries.
Or can the meaning of "derivative" change as we want ?
One time dynamic linking is "derivative" and the other time
it is not ?
Is "derivative" a magic word that changes its definition when
you add a "L" to the name of the license ?
Isaac
>
> Is "derivative" a magic word that changes its definition when
> you add a "L" to the name of the license ?
>
I think the copyright holder can get away with changing the definition
if you are bound by the license.
The problem is that you may be able to create a work that can be
dynamically linked to a library without treading on any rights
under copyright law. If so, you can create that work without
becoming bound by the terms of the GPL or the LGPL.
So no matter what the definition of derivative work is in the license,
the definition under copyright law is still relevant.
Isaac
Jean-Marc Lienher
>
> On Thu, 20 Feb 2003 23:00:51 +0100, Jean-Marc Lienher <ok...@bluewin.ch> wrote:
> >
> > Is "derivative" a magic word that changes its definition when
> > you add a "L" to the name of the license ?
> >
>
> I think the copyright holder can get away with changing the definition
> if you are bound by the license.
Yes. But the problem is that the FSF uses the same definition
in both the GPL and LGPL, and they say that it has different
meaning... Is the FSF credible ?
>
> The problem is that you may be able to create a work that can be
> dynamically linked to a library without treading on any rights
> under copyright law. If so, you can create that work without
> becoming bound by the terms of the GPL or the LGPL.
That's what everybody think. But that's not what the FSF says.
>
> So no matter what the definition of derivative work is in the license,
> the definition under copyright law is still relevant.
I agree.
Arnoud Galactus Engelfriet
Roger Schlafly <rog...@mindspring.com> wrote:
>"Arnoud "Galactus" Engelfriet" <gala...@stack.nl> wrote
>> Is that relevant? The question is, can you legally distribute
>> a program that relies at run-time on a library under GPL
>> without licensing the program under the GPL itself?
>
>And the answer must be YES, or else Linux would have been
>dead in the water. Every single application program that runs
>under Linux makes OS calls into GPL-licensed Linux code.
You mean the operating system for which the copyright holder
has said that system calls do not count as 'linking'?
Linus said that explicitly to take away fears like this.