On Sat, Dec 02, 2000 at 06:46:59PM -0500, Theodore Y. Ts'o wrote:
> Date: Sat, 2 Dec 2000 17:18:43 +0000 (GMT)
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>
> Well, it's not up to just me, given that Linus also has his copyright on
> the code (although I doubt there's more than a few lines which are
> originally his). There are some other people who have contributed code
> to the serial driver in the past, although most have probably not given
> me more than a dozen lines of code or so, which seems to be the
> (completely untested in court) standard which the FSF uses to decide
> whether or not they need to get formal legal papers signed.
>
> The legal issues are also incredibly murky,
that's "Merkey"
> since the customers create
> the derived work, and issues of intent aside, you can't necessarily use
> intent to change the legal definition of "derived work". (Be glad;
> although it can be used to create a loophole in GPL, just meditate a
> while on what the MPAA could do with such an "intent" argument before
> you decide whether or not it's a good thing. Or think what Microsoft
> could do if they could make their EULA's as infectious as the GPL with
> the "intent" argument.) The whole dynamic linking argument is a very
> slippery slope; where do you draw the line? Does a shell script which
> calls a GPL program get infected? What about a propietary C program
> which makes a system() call to invoke a GPL'ed bash? What about an RPC
> call across the network? What about a GNOME Corba interface? Is it OK
> if it's on separate machines, but are they considered a single program
> if the CORBA client and server are on the same machine, since now they
> share the same VM?
Under the "Doctrine of Inevitable Disclosure" even looking at GPL code
and using techniques it contains would contaminate anything someone
works on. This doctrine put forward two concepts that have been
used in trade secret cases to justify injunctions and non-competes
in areas of IP pollution -- negative knowledge and inevitable
misappropriation.
The argument goes something like this. Negative knowledge is defined as
knowing what techniques do not work (as opposed to what techniques
do work). In the course of development of a piece of software,
there are many "blind alleys" and "false starts" that are encountered
as an individual uses trial and error to perfect whatever piece
of software he is writing. Over time, the person learns what
approaches are blind alleys and which work. This knowledge becomes
imprinted into the actual thinking processes of this person.
Source code can also contain notes and comments about what does not
work, and what does work. Someone reading this source code would
then incorporate these ideas and knowledge into their thinking
processes. Companies spend lots of money paying engineers to
develop software, and this "negative knowledge", under the
doctrine of inevitable disclosure is legally the property
of an employer since they paid an engineer to experiment and
learn it. This is how companies are able to get non-compete
court orders against employees in trade secret lawsuits -- they
argue that noone is going to go down a development path using ideas
or approaches they know do not work. This argument goes on
to state that if two engineers, one who had access to a piece of
code vs. one who did not were to start at the same time working
on the same problem, the person who had access to the code would
finish first because he would "inevitably use" the knowledge gained
from access to the source code.
Let's say for example two engineers wanted to write a new Linux-like
replacement. One of them had access to ftp.kernel.org and the other
did not. Which one of the engineers would finish first? Obviously
the one with access to ftp.kernel.org would finish first and
would not have had to use trial and error to get all the IOCTL calls
working, etc. The engineer without source code access would take
longer, perhaps by a factor of years, to complete the same project.
Under this argument, it is argued that the engineer who had source
code access "inevitably used" negative knowledge he gained from
his study of the Linux sources. Absent the vague descriptions of
what a "derivative work" is in the GPL, it could be argued that
conversion of any knowledge contained in GPL code is a "derivative
work".
There are a lot of big software companies who believe this and
fear application of the doctrine of inevitable disclosure relative
to GPL code. Novell and Microsoft both do not even allow employees
to bring GPL code into the building -- period -- for fear that someone
will attempt to file a claim that they have "converted" GPL code
and created derivative works that may have contaminated non-GPL
code projects. Novell has an official standing policy barring employees
from using GPL code. That's why all the Linux work for NetWare is
done in the India development center, and not the US, out of fear
of IP pollution in the Provo facility. When I officed at the Microsoft
campus in 1999, they had similiar policies, and were even more strict
than Novell.
Now, in reality, these folks have employees in both companies who
download stuff at home, and putz around with it, GPL code included,
but that's a lot different from these companies having official policies
allowing projects to use GPL code in their normal course of business.
In short, under the doctrine of inevitable disclosure, a GPL copyright
holder could succeed with a claim of conversion from someone simply
looking at a piece of GPL code, then using whatever it contained
to build either interface modules or a module with similiar functionality.
It would be a hard call for a sitting judge to make, but I have seen
actual cases where a judge does just that with the help of a special
master.
Personally, I think the doctrine is one of the most evil fucking things
in existence, legal opponents call it "the doctrine of intellectual
slavery" because it has the affect under the law to be able to convert
simple NDA agreements into non-compete agreements, and I've seen it
used this way. Novell has blocked all internal access to the NWFS
ftp server TRG, BTW, because they are afraid I would attempt to
apply the doctrine to force them to open source NetWare projects if
they download NWFS and used it internally with eDirectory. They've
told us so.
This may help you understand just how complicated this whole IP stuff
is relative to derived works. It's undefined under current case law
and precednt relative to the GPL, but these big companies are taking
no chances....
:-)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Dec 07 2000 - 21:00:09 EST