[Fsfe-ie] Re: gpl and web scripting

Niall Douglas s_fsfeurope2 at nedprod.com
Mon Oct 27 06:22:09 CET 2003


On 27 Oct 2003 at 2:34, Jimmy O'Regan wrote:

> >You can't distribute GPLed code without making its source available. 
> >  
> That's not strictly true; you can add a note offering to provide the
> source for anyone who requests it.

Indeed, and it was an anachronism even in 1991. Software should 
always come with source.

> >That includes limited releases to your friends or a beta test group
> >or anything else. It would be interesting however if the diffs from
> >the public version were distributed alone - while it's against the
> >spirit of the GPL and likely that diffs are a legally derived work
> >under copyright, I don't know of a court case proving it one way or
> >another (however, IANAL).
> >
> Well, if you had a version of diff that included none of the original
> work in the .diff, you might be on to something.

Non-context diffs don't include the surrounding lines. However, it 
would be hard to prove a diff wasn't a derived work (not impossible, 
just hard).

> I doubt it will be tested; few companies would wish to bet their
> software on being proved right. Plug-ins are an unclear case; dlls in
> general though, I shouldn't think so - if a program can't function
> without a certain dll, I don't think any lawyer will have too much
> trouble in showing that the program is a derivative work. A lot of
> people try to toy with the definition of "derivative" to achieve their
> goals. If a program uses a library to perform a function, it, in other
> words, derives its ability to perform that function from the library,
> therefore the combined whole is a derivative of the library.

Ah, but you are thinking too much in design ie; programmer's terms. 
Remember that a judge isn't a programmer, and while usually 
intelligent will not see why a program explained in terms of code 
using libraries is any different than that of executables running 
other executables.

To test this, describe precisely how linking to a shared library is 
any different from running an executable from the point of view of 
steps taken by the computer's processor.

You will find them virtually identical - from mapping disc-backed 
data into memory to the processor entering and exiting that binary 
repeatedly using defined API points.

Linking to a static library is clear - the original work ends up in 
the derived work and in a customised form (from the linker) to boot. 
A shared library however is packaged like an executable (in ELF 
terms, they are identical except for reloc info) and is not altered 
or customised by being used by multiple clients any more than an 
application executable image is. Most importantly, none one jot of 
the shared library code ends up in the client image on either Linux 
or Windows.

Therefore, when explaining to a judge, how can you claim an 
executable should be treated differently from a DLL? Any half decent 
lawyer would rip the opposition to shreds on this.

Of course, RMS has fixed this by making all code on a computer a 
derived work of the operating system (hence the OS exemption). 
However as Linus quite rightly points out, if someone writes a filing 
system for some other OS and ports it to Linux, how could it possibly 
be derived from Linux?

Furthermore, I think it's decidedly unhealthy for the industry for 
derivability to be too loose - it gets like software patents - which 
I personally think GNU would like if circumstances were a little 
different. And while I've heard rants from the GPL cult about 
commercial software using a GPLed DLL being equal to theft, I 
personally cannot see how a binary designed for general-purpose multi-
client use is being stolen in this situation?

Cheers,
Niall




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 208 bytes
Desc: not available
Url : http://mail.fsfeurope.org/pipermail/fsfe-ie/attachments/20031027/3cfbffb4/attachment.pgp 


More information about the FSFE-IE mailing list