Dispelling BSD License Misconceptions (fwd)

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

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/27/07, Russ Nelson <nelson@...> wrote:

> Arnoud Engelfriet writes:
>  > If, as Matthew writes, part of the code is _specifically_ written to
>  > work only with GNU readline and no other library, then the code is
>  > a derivative work of GNU readline at the moment of creation.
>
> And if I later write a library compatible with GNU readline, that
> makes the code NOT a derivative work?  How can that be?  It's either
> derived in the sense that I incoporated parts of GNU readline into my
> code, or else it's NOT derivative because no part of GNU readline was
> incorporated.

In my opinion it should be a judgement call based on how closely
connected your code is with the design of GNU readline.  Remember that
copyright is not just intended to apply to literal copying.  For
instance if I write a short story and Mickey Mouse appears in it, I'm
going to hear from Disney's lawyers.  Even though I have not copied
anything exact, I can still be derivative of it.  Likewise if my code
makes liberal use of ideas and memes created by GNU readline, there is
an argument that I'm derivative of realine regardless of whether I
link.

Of course my opinion is influenced by having read
http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in
detail and then having thought about how the changing richness of the
Linux kernel module API has changed Linus' opinions about when a
binary module is a derived work of the Linux kernel.  (And why.)

> The standard interpretation of linking forming a derivative work has
> no basis in copyright law.  A staticly linked program is a collective
> work, perhaps, but not derivative.  A derivative work is where I take
> an existing library and add my own calls to it.  A dynamically linked
> program which includes no portion of the library is neither derivative
> nor collective.  The dynamic linking information is just a set of
> names; it's not the code itself.

See my reply to Larry Rosen.  The key issue is that the GPL offers no
permission to distribute a collective work with some pieces GPLed and
others not that is not formed by "mere aggregation".  Therefore if you
wish to distribute a collective work that has a more complex
relationship, you must GPL the whole thing.

I think there is a good argument to be made that static linking is not
mere aggregation.

> The dynamic linking argument has no legs unless you can claim
> copyright on a list of names.  If somebody else produces a similar but
> different list, does that infringe your copyright?  Not obvious.

But in fact you *can* claim copyright on a list of names.  (Not
always, but often.)  But you are completely right that it is not
obvious when a similar but different list infringes on your copyright.

Cheers,
Ben

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

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben Tilly wrote:
> In my opinion it should be a judgement call based on how closely
> connected your code is with the design of GNU readline.  Remember that
> copyright is not just intended to apply to literal copying.  For
> instance if I write a short story and Mickey Mouse appears in it, I'm
> going to hear from Disney's lawyers.

Yes, but probably on trademark grounds.

  Even though I have not copied
> anything exact, I can still be derivative of it.  Likewise if my code
> makes liberal use of ideas and memes created by GNU readline, there is
> an argument that I'm derivative of realine regardless of whether I
> link.

Ideas and memes alone shouldn't be enough to create a derivative work
under copyright law.

>
> Of course my opinion is influenced by having read
> http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in
> detail and then having thought about how the changing richness of the
> Linux kernel module API has changed Linus' opinions about when a
> binary module is a derived work of the Linux kernel.  (And why.)

That is a quite interesting compilation.

Matthew Flaschen



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/28/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> Ben Tilly wrote:
> > In my opinion it should be a judgement call based on how closely
> > connected your code is with the design of GNU readline.  Remember that
> > copyright is not just intended to apply to literal copying.  For
> > instance if I write a short story and Mickey Mouse appears in it, I'm
> > going to hear from Disney's lawyers.
>
> Yes, but probably on trademark grounds.

On every grounds they can get, *including* copyright.

In fact I chose that example specifically for good reason.  Disney is
famous for caring about the copyright that they have on Mickey Mouse.
So much so that on multiple occasions they have successfully lobbied
for copyright law to be changed so that they can continue to maintain
that copyright.

>   Even though I have not copied
> > anything exact, I can still be derivative of it.  Likewise if my code
> > makes liberal use of ideas and memes created by GNU readline, there is
> > an argument that I'm derivative of realine regardless of whether I
> > link.
>
> Ideas and memes alone shouldn't be enough to create a derivative work
> under copyright law.

My understanding (as a non-lawyer) is that copyright law protects my
creative expression.  Thus while the concepts that I used to write my
code are not copyrighted, the various variable names, function names,
arrangements, etc that I used might be copyrightable material.
Therefore someone who makes extensive use of the creative framework
that I created can find that their work is derivative of mine under
copyright.

Nothing stops them from creating an equivalent framework from scratch.
 It is only when they use my creative arrangement that they have a
possibility of running into trouble.

> > Of course my opinion is influenced by having read
> > http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in
> > detail and then having thought about how the changing richness of the
> > Linux kernel module API has changed Linus' opinions about when a
> > binary module is a derived work of the Linux kernel.  (And why.)
>
> That is a quite interesting compilation.

It is.  And it gives a lot of insight into how Linus thinks about this
issue.  Of course I have no idea of what a lawyer would think about
his thinking...

Cheers,
Ben

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

by Chuck Swiger :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Jan 28, 2007, at 12:21 PM, Ben Tilly wrote:
>> With the appropriate parts of the compiler toolchain (ar, nm,
>> objdump, etc), you can actually examine the contents, symbol headers,
>> and timestamps of libraries, object files, and executables.
>
> I think that intent enters into it.  Sure, it frequently is possible
> to divide it back up into pieces, but nobody intends for such a
> division to ever happen.  Therefore the file is not just a "mere
> aggregation".

A reasonable position-- I would generally agree that statically  
linking resources into an executable implies an intent to create a  
compilation or derivative work that goes beyond "mere aggregation".

On the other hand, it is possible to include (link in) a library from  
which no symbols are being referenced (via GNU ld's --whole-archive  
option, for example)...and this can be done at any time, including  
after an executable has been created.

Let's suppose someone who holds the perspective that "any linking  
against a GPL'ed library means that the associated binary must be  
distributed under the terms of the GPL, even if the executable does  
not depend on that GPL'ed library"-- such a person could relink any  
given proprietary binary against GNU readline and then demand that  
the vendor of the proprietary program release their sources, even  
though the binary does not know about, use, or depend on GNU readline  
in any fashion when originally distributed.

[ I don't think the vendor of the proprietary binary would have any  
obligation or responsibility for actions which lie completely outside  
of their control; it would be the responsibility of the person doing  
this linking to either obtain the sources or to refrain from  
redistributing their modified version if the result was not in  
compliance with the GPL's requirements. ]

> And sometimes such a division is not possible.  The
> difference between those two cases takes more skill to determine than
> the vast majority of computer users possess.

Oh, certainly.  But courts may well pay attention to facts which may  
not be significant or discernible to a layman but are evident to  
expert examination.

>> > Another case of interest is the web.  Suppose that I write GPLed
>> > software that produces a website.  There is no question that the  
>> web
>> > pages that I display include lots of stuff that is part of my
>> > codebase.  I think they should therefore be GPLed.  And every  
>> time you
>> > fetch a page, a derivative work has been distributed.  Does every
>> > page, therefore, need to include a copy of the GPL?
>>
>> We'd discussed this back in the thread "GPL for JS libraries (Was:
>> Re: Redefining GPL?)"

[ ...Msg-Id's snipped as you've found the right message... ]

> In any case you raised a number of interesting points in that email.
> A key one is that in your opinion distributing a hyperlink to the GPL
> along with a GPLed file should count as distribution of the GPL
> license.  While this seems like a reasonable practice, it doesn't
> match my understanding of the GPL that one can merely offer the
> license text in place of giving the license text to the recipient.
> (The license says that one must give the recipient the license.)

Yes, it does.  If you've redistributed GPL'ed software such as  
JavaScript code, CSS, etc, then you need to provide the text of the  
GNU General Public License to the recipients.

To me, that means you need to make the text downloadable as a  
normal .txt or HTML file from the site which offers the GPL'ed  
software, not that you need the whole text of the GPL on every single  
page of the site, or included with every single resource files which  
comprises the site.  After all, you can GPL image resources like PNG/
GIF/JPG/etc files, but the image file formats do not lend themselves  
to including the GPL text with these image files...

--
-Chuck


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

by Ben Tilly :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 1/29/07, Chuck Swiger <chuck@...> wrote:

> On Jan 28, 2007, at 12:21 PM, Ben Tilly wrote:
> >> With the appropriate parts of the compiler toolchain (ar, nm,
> >> objdump, etc), you can actually examine the contents, symbol headers,
> >> and timestamps of libraries, object files, and executables.
> >
> > I think that intent enters into it.  Sure, it frequently is possible
> > to divide it back up into pieces, but nobody intends for such a
> > division to ever happen.  Therefore the file is not just a "mere
> > aggregation".
>
> A reasonable position-- I would generally agree that statically
> linking resources into an executable implies an intent to create a
> compilation or derivative work that goes beyond "mere aggregation".

:-)

> On the other hand, it is possible to include (link in) a library from
> which no symbols are being referenced (via GNU ld's --whole-archive
> option, for example)...and this can be done at any time, including
> after an executable has been created.
>
> Let's suppose someone who holds the perspective that "any linking
> against a GPL'ed library means that the associated binary must be
> distributed under the terms of the GPL, even if the executable does
> not depend on that GPL'ed library"-- such a person could relink any
> given proprietary binary against GNU readline and then demand that
> the vendor of the proprietary program release their sources, even
> though the binary does not know about, use, or depend on GNU readline
> in any fashion when originally distributed.

Not so fast.

In this case "must" is a requirement on the person who wishes to
redistribute, not a requirement on third parties who may have
copyrights involved.  Therefore there is no basis for a demand.

What I mean by that is that the person who did the relinking has no
permission to distribute the result unless it can be GPLed, but
relinking in no way obligates the proprietary vendor to give
permission to GPL that binary.  Since the vendor is unlikely to give
their permission or source code, the relinked binary is unlikely to be
legally redistributable.

> [ I don't think the vendor of the proprietary binary would have any
> obligation or responsibility for actions which lie completely outside
> of their control; it would be the responsibility of the person doing
> this linking to either obtain the sources or to refrain from
> redistributing their modified version if the result was not in
> compliance with the GPL's requirements. ]

Exactly.

> > And sometimes such a division is not possible.  The
> > difference between those two cases takes more skill to determine than
> > the vast majority of computer users possess.
>
> Oh, certainly.  But courts may well pay attention to facts which may
> not be significant or discernible to a layman but are evident to
> expert examination.

True.  However it all rests on what is considered "mere aggregation".
I'd be surprised to see a court rule that linking was mere aggreation.
 Particularly given the fact that the FSF has made it very clear that
they *don't* think that linking is mere aggregation, and nobody has
challenged them on that.

[...]

> > In any case you raised a number of interesting points in that email.
> > A key one is that in your opinion distributing a hyperlink to the GPL
> > along with a GPLed file should count as distribution of the GPL
> > license.  While this seems like a reasonable practice, it doesn't
> > match my understanding of the GPL that one can merely offer the
> > license text in place of giving the license text to the recipient.
> > (The license says that one must give the recipient the license.)
>
> Yes, it does.  If you've redistributed GPL'ed software such as
> JavaScript code, CSS, etc, then you need to provide the text of the
> GNU General Public License to the recipients.

Excuse me?

When I said that it doesn't match my understanding, I meant what I
said.  It doesn't match my understanding.

> To me, that means you need to make the text downloadable as a
> normal .txt or HTML file from the site which offers the GPL'ed
> software, not that you need the whole text of the GPL on every single
> page of the site, or included with every single resource files which
> comprises the site.  After all, you can GPL image resources like PNG/
> GIF/JPG/etc files, but the image file formats do not lend themselves
> to including the GPL text with these image files...

You've just repeated your understanding.  However you haven't changed
mine.  I don't think that telling someone where they can find the text
to the license is equivalent to actually giving them the license.

Cheers,
Ben

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

by Matthew Flaschen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ben Tilly wrote:

> On 1/28/07, Matthew Flaschen <matthew.flaschen@...> wrote:
>> Ben Tilly wrote:
>> > In my opinion it should be a judgement call based on how closely
>> > connected your code is with the design of GNU readline.  Remember that
>> > copyright is not just intended to apply to literal copying.  For
>> > instance if I write a short story and Mickey Mouse appears in it, I'm
>> > going to hear from Disney's lawyers.
>>
>> Yes, but probably on trademark grounds.
>
> On every grounds they can get, *including* copyright.
They might consider it copyright infringement, but I don't think a judge
would (if you did nothing more then mention Mickey in the story)

> In fact I chose that example specifically for good reason.  Disney is
> famous for caring about the copyright that they have on Mickey Mouse.
> So much so that on multiple occasions they have successfully lobbied
> for copyright law to be changed so that they can continue to maintain
> that copyright.

True, but that's mainly to prevent full-scale copying of the original
(now quite valuable) cartoons.

>
>>   Even though I have not copied
>> > anything exact, I can still be derivative of it.  Likewise if my code
>> > makes liberal use of ideas and memes created by GNU readline, there is
>> > an argument that I'm derivative of realine regardless of whether I
>> > link.
>>
>> Ideas and memes alone shouldn't be enough to create a derivative work
>> under copyright law.
>
> My understanding (as a non-lawyer) is that copyright law protects my
> creative expression.
That's exactly my point.  I can take your ideas without infringing your
copyright, as long as I ignore your expression.

> Nothing stops them from creating an equivalent framework from scratch.

Unless it happens to be patented.

>
>> > Of course my opinion is influenced by having read
>> > http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html in
>> > detail and then having thought about how the changing richness of the
>> > Linux kernel module API has changed Linus' opinions about when a
>> > binary module is a derived work of the Linux kernel.  (And why.)
>>
>> That is a quite interesting compilation.
>
> It is.  And it gives a lot of insight into how Linus thinks about this
> issue.  Of course I have no idea of what a lawyer would think about
> his thinking...
Yes, and in some cases he's clearly wrong.  In the beginning when he
asserts that the LGPL applies de facto...simply because he considers
some kernel routines libraries.

Matthew Flaschen



signature.asc (260 bytes) Download Attachment

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 29, 2007, at 2:37 PM, Ben Tilly wrote:
> True.  However it all rests on what is considered "mere aggregation".
> I'd be surprised to see a court rule that linking was mere aggreation.
> Particularly given the fact that the FSF has made it very clear that
> they *don't* think that linking is mere aggregation, and nobody has
> challenged them on that.

Hmm-- what about people like nVidia providing proprietary Linux  
kernel modules for their video cards...?

> [ ... ]
>> > In any case you raised a number of interesting points in that  
>> email.
>> > A key one is that in your opinion distributing a hyperlink to  
>> the GPL
>> > along with a GPLed file should count as distribution of the GPL
>> > license.  While this seems like a reasonable practice, it doesn't
>> > match my understanding of the GPL that one can merely offer the
>> > license text in place of giving the license text to the recipient.
>> > (The license says that one must give the recipient the license.)
>>
>> Yes, it does.  If you've redistributed GPL'ed software such as
>> JavaScript code, CSS, etc, then you need to provide the text of the
>> GNU General Public License to the recipients.
>
> Excuse me?

You said "(The license says that one must give the recipient the  
license.)"; I agree with this, that is a reasonable paraphrase of  
what GPL clause 1 says.

> When I said that it doesn't match my understanding, I meant what I
> said.  It doesn't match my understanding.

Apparently true; I doubt your understanding matches that of the GNU  
project or almost anyone else such as a Linux vendor redistributing  
GPL'ed software via the WWW.

>> To me, that means you need to make the text downloadable as a
>> normal .txt or HTML file from the site which offers the GPL'ed
>> software, not that you need the whole text of the GPL on every single
>> page of the site, or included with every single resource files which
>> comprises the site.  After all, you can GPL image resources like PNG/
>> GIF/JPG/etc files, but the image file formats do not lend themselves
>> to including the GPL text with these image files...
>
> You've just repeated your understanding.  However you haven't changed
> mine.  I don't think that telling someone where they can find the text
> to the license is equivalent to actually giving them the license.

Yes, that's right-- the two are not equivalent.

If you browse to a website which redistributes GPLed software via  
Javascript or whatever, the site should "print or display an  
announcement ... telling the user how to view a copy of this  
License." per GPL clause 2c.  If you provide a link which lets them  
view a copy of the license from your site, you've satisfied this  
requirement.

A single source file, .js file, etc does not normally constitute an  
entire Program; you need to distribute a copy of the GPL with the  
Program, not with each individual subcomponent.  And, as an example  
to support this interpretation, go visit:

   http://cvs.savannah.gnu.org/viewcvs/make/?root=make

...or any other GNU project available there via CVSweb and observe  
for yourself that gnu.org does not provide the full GPL text with  
every file nor even provide a link to the GPL on each and every  
page.  Neither do third-parties who redistribute GPL source code such  
as RedHat, Novell, the various BSDs, Darwin from Apple, etc.

If your position is that gnu.org, RedHat, and everyone else providing  
HTTP or FTP access to GPL'ed software in such a fashion nevertheless  
are violating GPL clause 1, even though it is simply not possible to  
provide the GPL text with each and every GPL'ed subcomponent due to  
(eg) binary image formats, please review "reductio ad absurdum":

    http://en.wikipedia.org/wiki/Reductio_ad_absurdum

...and re-evaluate your position until it does not require the  
impossible to occur.

--
-Chuck

< Prev | 1 - 2 - 3 - 4 | Next >