Dispelling BSD License Misconceptions (fwd)

[Ben Tilly]

On 1/18/07, Matthew Flaschen <matthew.flaschen@...> wrote:

> Ben Tilly wrote:
> > On 1/18/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> >> Chuck Swiger wrote:
> >>
> >> Sticking to the example of readline and Python, part of the code is
> >> still specifically written to depend on readline.  I think under Eben's
> >> argument, this part would then be a derivative work.  Thus, that part at
> >> least should be licensed under the GPL.
> >
> > I can't speak to Python, but I can to Perl.  The situation is nowhere
> > near as simple as you describe.
>
> To clarify, I wrote that text, not Chuck.

I did not intend to confuse.

> > There is a module, Term::ReadLine, that is distributed with the Perl
> > core.  This module is a stub, it allows people to interface to one of
> > (currently) three implementations of readline.  The first will load a
> > module (available on CPAN) that provides a Perl interface to the GNU
> > application.
>
> IANAL, but I think this is most likely to be a derivative work of readline.

Agreed.

> > Here is my opinion as a non-lawyer who can't give legal advice.  It is
> > obvious to me that no part of Perl outside of Term::ReadLine depends
> > on or is derivative from the GNU implementation of readline.  I
> > strongly doubt that Term::ReadLine can be said to be derivative of
> > readline.  I suspect that the author of Term::ReadLine::Gnu may be
> > overstepping when he licenses his module  under a dual Artistic/GPL
> > license.  (See the README file at
> > http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.16/ for details.)
>
> I don't follow.  If you say his code is not derivative of anything,
> shouldn't he be able to choose whatever license he wants?

I didn't say that.  Or rather, I said that about another piece of
code.  Here are the pieces of code of interest:

1. Perl minus Term::ReadLine
2. Term::ReadLine
3. Term::ReadLine::Gnu
4. Code written in Perl

I think the first is obviously not derivative, the second I strongly
doubt is derivative, the third I'm inclined to think would be (but
don't feel qualified to judge), and the last is generally not but in
some cases could be.  There is no contradiction between my opinions on
item 2 and 3 because they are about different pieces of code with
different histories.

> >> This isn't quite the same thing.  Readline wasn't written to an existing
> >> Python plugin API.  Part of Python was written to interact specifically
> >> with readline.
> >
> > I suspect that Python did what Perl does.  (Possibly with less
> > pieces.)  In which case Python is written with a general plugin API,
> > and someone wrote a Python plugin around readline.  I suspect that
> > what is actually distributed with Python is a stub like the Perl one
> > so the situation is completely parallel, but the Python stub may be
> > more filled in than the Perl one is.
>
> I think this hypothetical plugin/stub is most likely to be a derivative
> work.

I'd agree, but of the two the plugin is more likely to be derivative
than the stub.  Without seeing that stub I won't even venture my
unqualified opinion about whether I think it is derivative.  (I've
seen the Perl stub and I scrolled through the source-code.  It is so
minimal and generic that I don't think it is derivative of anything.)

Cheers,
Ben

[Matthew Flaschen]

Ben Tilly wrote:

>> > Here is my opinion as a non-lawyer who can't give legal advice.  It is
>> > obvious to me that no part of Perl outside of Term::ReadLine depends
>> > on or is derivative from the GNU implementation of readline.  I
>> > strongly doubt that Term::ReadLine can be said to be derivative of
>> > readline.  I suspect that the author of Term::ReadLine::Gnu may be
>> > overstepping when he licenses his module  under a dual Artistic/GPL
>> > license.  (See the README file at
>> > http://search.cpan.org/~hayashi/Term-ReadLine-Gnu-1.16/ for details.)
>>
>> I don't follow.  If you say his code is not derivative of anything,
>> shouldn't he be able to choose whatever license he wants?
>
> I didn't say that.  Or rather, I said that about another piece of
> code.  Here are the pieces of code of interest:
>
> 1. Perl minus Term::ReadLine
> 2. Term::ReadLine
> 3. Term::ReadLine::Gnu
> 4. Code written in Perl
>
> I think the first is obviously not derivative

I agree here.

, the second I strongly
> doubt is derivative

Still with you.

, the third I'm inclined to think would be (but
> don't feel qualified to judge)

Same.

, and the last is generally not but in
> some cases could be.

I'm not sure about this one.  I'm also still confused what you mean by
"the author of Term::ReadLine::Gnu may be overstepping".  Who is
overstepping, and why?

>> > I suspect that Python did what Perl does.  (Possibly with less
>> > pieces.)  In which case Python is written with a general plugin API,
>> > and someone wrote a Python plugin around readline.  I suspect that
>> > what is actually distributed with Python is a stub like the Perl one
>> > so the situation is completely parallel, but the Python stub may be
>> > more filled in than the Perl one is.
>>
>> I think this hypothetical plugin/stub is most likely to be a derivative
>> work.
>
> I'd agree, but of the two the plugin is more likely to be derivative
> than the stub.  Without seeing that stub I won't even venture my
> unqualified opinion about whether I think it is derivative.  (I've
> seen the Perl stub and I scrolled through the source-code.  It is so
> minimal and generic that I don't think it is derivative of anything.)

Right, I was hypothesizing a well-written plugin that fully and tightly
utilizes the readline library.

Matthew Flaschen

[Ben Tilly]

On 1/18/07, Matthew Flaschen <matthew.flaschen@...> wrote:
> Ben Tilly wrote:
[..]

> > I didn't say that.  Or rather, I said that about another piece of
> > code.  Here are the pieces of code of interest:
> >
> > 1. Perl minus Term::ReadLine
> > 2. Term::ReadLine
> > 3. Term::ReadLine::Gnu
> > 4. Code written in Perl
> >
> > I think the first is obviously not derivative
>
> I agree here.
>
> , the second I strongly
> > doubt is derivative
>
> Still with you.
>
> , the third I'm inclined to think would be (but
> > don't feel qualified to judge)
>
> Same.
>
> , and the last is generally not but in
> > some cases could be.
>
> I'm not sure about this one.  I'm also still confused what you mean by
> "the author of Term::ReadLine::Gnu may be overstepping".  Who is
> overstepping, and why?

Well I think the third is probably derivative.  But the author of that
code thinks he can dual license it Artistic and GPL.  Which means that
he either hasn't paid enough attention to readline's copyright
license, or doesn't think that his work is derivative.

Hence he may be overstepping - asserting that he has a right to apply
a license that he may not.

About the one you're not sure of, most Perl code does not even *load*
Term::ReadLine.  That's not going to be derivative.  Of code that does
load it, most uses only the Term::ReadLine API.  I think we're agreed
that that is unlikely to be derivative.  But the tiny portion of
fraction that specifically loads Term::ReadLine::Gnu and then heavily
uses parts of the API that are specific to readline - there probably
is some code that might be argued to be derivative of readline.

So general Perl code is generally not derivative of readline, but
there are probably some examples out there that could be.

Cheers,
Ben

[Matthew Flaschen]

Ben Tilly wrote:
>> I'm not sure about this one.  I'm also still confused what you mean by
>> "the author of Term::ReadLine::Gnu may be overstepping".  Who is
>> overstepping, and why?
>
> Well I think the third is probably derivative.  But the author of that
> code thinks he can dual license it Artistic and GPL.  Which means that
> he either hasn't paid enough attention to readline's copyright
> license, or doesn't think that his work is derivative.

Right, I see what you mean now.  Of course he simply may not know what
the License of Perl really is.

> Hence he may be overstepping - asserting that he has a right to apply
> a license that he may not.
>
> About the one you're not sure of, most Perl code does not even *load*
> Term::ReadLine.  That's not going to be derivative.  

I agree.

> Of code that does
> load it, most uses only the Term::ReadLine API.  I think we're agreed
> that that is unlikely to be derivative.  But the tiny portion of
> fraction that specifically loads Term::ReadLine::Gnu and then heavily
> uses parts of the API that are specific to readline - there probably
> is some code that might be argued to be derivative of readline.

I think code that uses Term::ReadLine::Gnu , directly or indirectly,
will probably be a derivative work.

Matthew Flaschen

[Dalibor Topic]

Matthew Flaschen <matthew.flaschen <at> gatech.edu> writes:

>
> Chuck Swiger wrote:
> >>> Absolutely not; this isn't a matter where you have to guess, go to:
> >>>
> >>>   http://www.microsoft.com/about/legal/useterms/default.aspx
> >>>
> >>> ...and choose your favorite version of Visual Studio.  One version of
> >>> the EULA states:
> > [ ...Microsoft EULA snipped for brevity... ]
> >>> You can't mix this EULA with the GPL under any circumstances, including
> >>> the exception mentioned in GPL #3.
> >>
> >> Why not?  I think this exception ensures the DLLs wouldn't fall under
> >> the GPL; thus neither i or ii should be violated.
> >
> > Microsoft EULA's not only impose many additional constraints which are
> > not GPL-miscible, the M$ EULA explicitly forbid one to create a
> > derivative work of "Redistributable Code - Visual C++: Microsoft
> > Foundation Classes (MFC), Active Template Libraries (ATL), and C
> > runtimes (CRTs)" in conjunction with an "Excluded License", which the
> > GPL obviously is.
>
> I'm fairly certain the GPL would allow the DLLs to be excluded from
> Corresponding Source due to the system library exception.  However, I
> now see you're right that that doesn't address the problem of the GPLed
> binary being a derivative work.  I don't know the answer to this
> question.  It's quite possible that Microsoft isn't fully enforcing
> their EULA here.
>

Microsoft's Visual Studio EULA is not particularly relevant for Cygwin, since it
uses gcc to build, rather than Visual Studio.

On the other hand, if Microsoft's goal with this licensing clause is to prevent
the creation of competing GPLd software using it's market-dominant Windows
compiler technology on their platform, then that should raise a concern with
EU's trade regulation bodies.

How does one go about launching a complaint there?

cheers,
dalibor topic

[Chuck Swiger]

On Jan 19, 2007, at 5:11 AM, Dalibor Topic wrote:
[ ...about Cygwin dynamically linking against Win32 DLL's... ]
> Microsoft's Visual Studio EULA is not particularly relevant for  
> Cygwin, since it
> uses gcc to build, rather than Visual Studio.

It doesn't matter which compiler the Cygwin folks use; Cygwin's  
setup.exe dynamically links against:

> <dependency>
>     <dependentAssembly>
>         <assemblyIdentity
>             type="win32"
>             name="Microsoft.Windows.Common-Controls"
>             version="6.0.0.0"
>             processorArchitecture="X86"
>             publicKeyToken="6595b64144ccf1df"
>             language="*"
>         />
>     </dependentAssembly>
> </dependency>
> </assembly>
> KERNEL32.DLL
> ADVAPI32.DLL
> COMCTL32.DLL
> GDI32.dll
> msvcrt.dll
> OLE32.dll
> SHELL32.DLL
> USER32.dll
> WSOCK32.DLL

See that "msvcrt.dll"?  That's the Microsoft Visual C runtime....

--
-Chuck

[John Cowan]

Chuck Swiger scripsit:

> It doesn't matter which compiler the Cygwin folks use; Cygwin's  
> setup.exe dynamically links against:

Fortunately, setup.exe is not a Cygwin program and is fully replaceable
should the need arise.

--
Her he asked if O'Hare Doctor tidings sent from far     John Cowan
coast and she with grameful sigh him answered that      http://ccil.org/~cowan
O'Hare Doctor in heaven was. Sad was the man that word  cowan@...
to hear that him so heavied in bowels ruthful. All
she there told him, ruing death for friend so young,    James Joyce, Ulysses
algate sore unwilling God's rightwiseness to withsay.   "Oxen of the Sun"

[Matthew Flaschen]

John Cowan wrote:
> Chuck Swiger scripsit:
>
>> It doesn't matter which compiler the Cygwin folks use; Cygwin's  
>> setup.exe dynamically links against:
>
> Fortunately, setup.exe is not a Cygwin program and is fully replaceable
> should the need arise.
>

Of course it's a Cygwin program.  I think you mean it's not a GNU program.

Matthew Flaschen

[John Cowan]

Matthew Flaschen scripsit:

> Of course it's a Cygwin program.  I think you mean it's not a GNU program.

What I mean is that it doesn't depend on anything Cygwin, specifically not
cygwin1.dll (since it has to work before that is even downloaded).
> Matthew Flaschen
>



--
John Cowan  cowan@...   http://ccil.org/~cowan
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.

[Andrew C. Oliver-2]

 
>
> See that "msvcrt.dll"?  That's the Microsoft Visual C runtime....
>
Doesn't an alternative version come with WINE?
> ---Chuck
>
>
>


--
No PST Files Ever Again
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

[Chuck Swiger]

On Jan 19, 2007, at 1:22 PM, John Cowan wrote:
> Chuck Swiger scripsit:
>> It doesn't matter which compiler the Cygwin folks use; Cygwin's
>> setup.exe dynamically links against:
>
> Fortunately, setup.exe is not a Cygwin program and is fully  
> replaceable
> should the need arise.

http://www.cygwin.com/setup.exe isn't a Cygwin program...?
Run "strings" against it and look at the tail of that output:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"  
manifestVersion="1.0">
<assemblyIdentity
     version="1.0.0.0"
     processorArchitecture="X86"
     name="RedHat.Cygwin.Setup"
     type="win32"
<description>Cygwin installation tool</description>

...followed by the dependency output and .DLLs I'd previous quoted.

It's probably true that normal UNIX binaries might only need link  
against the version of GNU libc that Cygwin comes with to work, but  
things like the Cygwin terminal program, things which install  
themselves as Windows services in order to do networking, things  
which eventually end up calling Win32 APIs to allocate new tasks,  
draw on the screen, access file or network resources, are eventually  
invoking Win32 APIs.

They appear to be doing so via a shim layer called winsup/w32api:

   http://cygwin.com/packages/cygwin/cygwin-1.5.23-2-src

...which includes a GPL "COPYING" file, yet if you actually download  
the Cygwin or MINGW version of this w32api shim and check the  
libraries or source code (I was looking at prdownloads.sf.net/mingw/
w32api-2.4.tar.gz), you'll find the following:

ADVAPI32.DLL
CAP.DLL
COMCTL32.DLL
COMDLG32.DLL
CRYPT32.DLL
CTL3D32.DLL
Control_FillCache_RunDLL
Control_RunDLL
DDRAW.dll
DINPUT.dll
DLCAPI.DLL
DPLAYX.dll
DSETUP.dll
DSOUND.dll
GDI32.dll
GLAUX.DLL
GLU32.DLL
IMAGEHLP.DLL
IMM32.DLL
IPHLPAPI.DLL
InitializeDll
InternetInitializeAutoProxyDll
Kernel32.dll
LZ32.DLL
LdrDisableThreadCalloutsForDll
LdrGetDllHandle
LdrLoadDll
LdrUnloadDll
MAPI32.DLL
MFCUIA32.DLL
MGMTAPI.DLL
MPR.DLL
MSACM32.DLL
MSIMG32.DLL
MSVCP60.DLL
MSVFW32.DLL
MSWSOCK.DLL
NDDEAPI.DLL
NETAPI32.DLL
[ ... ]

--
-Chuck

[Dalibor Topic]

Chuck Swiger <chuck <at> codefab.com> writes:

>
> On Jan 19, 2007, at 5:11 AM, Dalibor Topic wrote:
> [ ...about Cygwin dynamically linking against Win32 DLL's... ]
> > Microsoft's Visual Studio EULA is not particularly relevant for  
> > Cygwin, since it
> > uses gcc to build, rather than Visual Studio.
>
> It doesn't matter which compiler the Cygwin folks use; Cygwin's  
> setup.exe dynamically links against:

[snip]
>
> See that "msvcrt.dll"?  That's the Microsoft Visual C runtime....
>

MSVCRT.DLL is part of the Microsoft Windows OS, though, and as such covered by
the special exception in the GPLv2, i.e. it's not required to be licensed under
the GPL, be open source at all, etc., etc., etc., so the anti-open-source clause
of the Visual Studio EULA does not apply, afaict, both because the component in
question is not licensed via Visual Studio, in the first place, and because the
component's license is not implied by the GPL.

While I'd instantly buy a book a la "No Poetic License: Microsoft's End User
License Agreements As Contemporary Legalistic Dadaism", unfortunately, I don't
think Microsoft is going to write it. A shame, I think, and a huge loss to
literature criticism. :)

cheers,
dalibor topic

[Philippe Verdy]

There's no way to avoid linking with Msvcrt.dll at run-time given that this dll is part of the OS itself, and linked from Win32 API DLLs. It is also preinstalled with Windows, and that's why you can't delete or overwrite it as long as windows is running (it requires rebooting to update it with Windows update).

Of course third-party programs can use another version, but this won't forbid the OS to use its own version too for its internal use...

----- Original Message -----
From: "Andrew C. Oliver" <acoliver@...>
To: <license-discuss@...>
Sent: Friday, January 19, 2007 11:23 PM
Subject: Re: Cygwin & Microsoft's EULA, was: Re: Dispelling BSD License Misconceptions (fwd)


>
>>
>> See that "msvcrt.dll"?  That's the Microsoft Visual C runtime....
>>
> Doesn't an alternative version come with WINE?

[Russ Nelson]

Matthew Flaschen writes:
 > Sticking to the example of readline and Python, part of the code is
 > still specifically written to depend on readline.  I think under Eben's
 > argument, this part would then be a derivative work.  Thus, that part at
 > least should be licensed under the GPL.

Should it be licensed under the GPL before or after it's linked to
readline?  After all, the authors of Python have no control over what
code I actually link it to.  I might link it to readline; I might link
it to lineread, a 100% compatible implementation of readline which is
in the public domain, and which imposes no licensing obligation
whatsoever.

The question here is "Can you copyright an API"?  You can obviously
copyright the description of an API, but can you copyright the API
itself?  Or is it a listing of facts?

--
--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. | [phone]       | don't expect somebody else
Potsdam, NY 13676-3213  |     Sheepdog          | to pick up the pieces.

[Arnoud Engelfriet-2]

Russ Nelson wrote:

> Matthew Flaschen writes:
>  > Sticking to the example of readline and Python, part of the code is
>  > still specifically written to depend on readline.  I think under Eben's
>  > argument, this part would then be a derivative work.  Thus, that part at
>  > least should be licensed under the GPL.
>
> Should it be licensed under the GPL before or after it's linked to
> readline?  After all, the authors of Python have no control over what
> code I actually link it to.  I might link it to readline; I might link
> it to lineread, a 100% compatible implementation of readline which is
> in the public domain, and which imposes no licensing obligation
> whatsoever.

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.

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.

Arnoud

--
Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for myself
Patents, copyright and IPR explained for techies: http://www.iusmentis.com/

[Lawrence Rosen]

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?

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

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.

Dynamic *or* static.

/Larry

> -----Original Message-----
> From: Arnoud Engelfriet [mailto:arnoud@...]
> Sent: Thursday, January 25, 2007 1:59 PM
> To: License Discuss
> Subject: Re: Dynamic linking, was: Re: Dispelling BSD License
> Misconceptions
>
> Russ Nelson wrote:
> > Matthew Flaschen writes:
> >  > Sticking to the example of readline and Python, part of the code is
> >  > still specifically written to depend on readline.  I think under
> Eben's
> >  > argument, this part would then be a derivative work.  Thus, that part
> at
> >  > least should be licensed under the GPL.
> >
> > Should it be licensed under the GPL before or after it's linked to
> > readline?  After all, the authors of Python have no control over what
> > code I actually link it to.  I might link it to readline; I might link
> > it to lineread, a 100% compatible implementation of readline which is
> > in the public domain, and which imposes no licensing obligation
> > whatsoever.
>
> 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.
>
> 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.
>
> Arnoud
>
> --
> Arnoud Engelfriet, Dutch & European patent attorney - Speaking only for
> myself
> Patents, copyright and IPR explained for techies:
> http://www.iusmentis.com/

[Matthew Flaschen]

Russ Nelson wrote:

> Matthew Flaschen writes:
>  > Sticking to the example of readline and Python, part of the code is
>  > still specifically written to depend on readline.  I think under Eben's
>  > argument, this part would then be a derivative work.  Thus, that part at
>  > least should be licensed under the GPL.
>
> Should it be licensed under the GPL before or after it's linked to
> readline?  After all, the authors of Python have no control over what
> code I actually link it to.  I might link it to readline; I might link
> it to lineread, a 100% compatible implementation of readline which is
> in the public domain, and which imposes no licensing obligation
> whatsoever.

This isn't a simple issue.  Again, IANAL and these are just my thoughts.
 However, I think it would depend whether the code is designed to use
GNU readline, the PD version, or just the API.  If no one can prove it
was meant for GNU readline, it probably isn't a copyright infrigement.

Matthew Flaschen

[Matthew Flaschen]

Lawrence Rosen wrote:
> 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.

Well, if you're statically linking the executable will actually include
code from the library; this is definitely a derivative work.  If you're
dynamically linking, it will be designed to load code from the library;
if only one library implements the API, the code is probably a
derivative work of that library.

Matthew Flaschen

[Lawrence Rosen]

> Lawrence Rosen wrote:
> > 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.
>

Matthew Flaschen responded
> Well, if you're statically linking the executable will actually include
> code from the library; this is definitely a derivative work.  If you're
> dynamically linking, it will be designed to load code from the library;
> if only one library implements the API, the code is probably a
> derivative work of that library.

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?
Why shouldn't this be treated as "making a copy," which usually carries far
fewer obligations under reciprocal/copyleft licenses.

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.

/Larry

> -----Original Message-----
> From: Matthew Flaschen [mailto:matthew.flaschen@...]
> Sent: Thursday, January 25, 2007 3:30 PM
> To: lrosen@...
> Cc: 'License Discuss'
> Subject: Re: Dynamic linking, was: Re: Dispelling BSD License
> Misconceptions
>
> Lawrence Rosen wrote:
> > 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.
>
> Well, if you're statically linking the executable will actually include
> code from the library; this is definitely a derivative work.  If you're
> dynamically linking, it will be designed to load code from the library;
> if only one library implements the API, the code is probably a
> derivative work of that library.
>
> Matthew Flaschen

[Ben Tilly]

On 1/25/07, Lawrence Rosen <lrosen@...> wrote:

> > Lawrence Rosen wrote:
> > > 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.
> >
>
> Matthew Flaschen responded
> > Well, if you're statically linking the executable will actually include
> > code from the library; this is definitely a derivative work.  If you're
> > dynamically linking, it will be designed to load code from the library;
> > if only one library implements the API, the code is probably a
> > derivative work of that library.
>
> 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?
> Why shouldn't this be treated as "making a copy," which usually carries far
> fewer obligations under reciprocal/copyleft licenses.

Non-sequitor.  The question isn't whether the result is suitable for
an independent copyright, the question is what permissions the
copyright licenses for included copyrighted pieces gives you.

Let's suppose that one of those pieces is under the GPL.

The GPL gives you permission to copy 2 kinds of things.  The first is
the right to copy GPLed works.  The second is permission to copy GPLed
works which have been combined by "mere aggregation" with non-GPLed
works.  There is no permission to copy a single thing produced out of
GPLed and non-GPLed works.

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

Therefore the only way to find permission in the GPL to distribute a
program which has statically linked a GPLed library is to make the
entire program is GPLed.  Otherwise no permission is given.

> 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?
IANAL, but I find it interesting.

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?

Cheers,
Ben