Dispelling BSD License Misconceptions (fwd)

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 - 4 | Next >

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

  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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Ben Tilly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben 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.
Yes, the question is whether it's under the GPL.  Normally, developers
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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by David Woolley :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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 Misconceptions

by Arnoud Engelfriet-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Lawrence 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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Arnoud 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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by John Cowan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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!).

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 Misconceptions

by Chuck Swiger :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 Misconceptions

by Arnoud Engelfriet-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

> 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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Arnoud 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.
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.

>> 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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Arnoud Engelfriet-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matthew 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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Arnoud 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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Russ Nelson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

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 Misconceptions

by Arnoud Engelfriet-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

--
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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Arnoud 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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Fabian Bastin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The 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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

> 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




signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Fabian Bastin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Matthew 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.
>
>  
You are right. But it would still be a bad situtation in my eyes.

>> 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
>
>  
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.

>> 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. 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.
>
>  
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. 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.
>
>  
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 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 Misconceptions

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Fabian 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.
Yes, this is obviously true.  After all, GNU is meant to be a free,
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.
That's true.  GPL is recommended simply because it's free, strong
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



signature.asc (260 bytes) Download Attachment

Re: Dynamic linking, was: Re: Dispelling BSD License Misconceptions

by Ben Tilly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 >