I have been shutting up of late and just going heads down and
cranking code and work and staying out of politics, but I feel
compelled to address this issue with my understanding of IP law
and our system of equity. I've had a few off line discussions
with some folks, attorneys, and tech folks on this list, and as
near as I can tell, all you guys are out in the weeds (me included).
Here's what I discovered in researching the legal basis for
the GPL and kernel code development.
There is a belief that the GPL can contaminate upward and
downward any driver or kernel module written that runs on Linux.
This statement, irregardless of what language is in the GPL, is
total bullsh_t, **EXCEPT** in those states who have adopted
UCITA. UCITA is an evil body of legislation approved by
representatives of various state legislatures that in essence
makes anything written into a software license (like the GPL)
enforceable and potentially criminal in those states who adopt
UCITA for any use of a particular software program. By way of
example, UCITA makes reverse engineering an illegal act if
the software owner writes into the license that reverse engineering
is not allowed. UCITA will also give the GPL enormous "teeth"
to actually enforce this up/down contamination of code written
on the Linux kernel.
However, UCITA was lobbied for and pushed by Microsoft, Novell, and
the big software companies. It was supported and promoted to
interfere with development efforts just like Linux, and to oppress
software freedom, reversse engineering, competittion, etc.. So
UCITA is not the friend of Linux, and long term, it's designed to
strangle us and as Bill Gates likes to state, "cut off our air
supply" by preventing Linux and other open source efforts which
pose a competitive threat to the big players from being able to
replicate features/functionality and keep up. It's ironic that
this GPL up/down contamination benefits from something that could
in time kill Linux or make all of us wanted fugitives.
Now to the arguments in favor of balancing the equities. If someone
pays an engineer to develop code independent of Linux code which
does not incorporate Linux GPL code, irregardless of any knowledge
which may have been gained from access to Linux, guess what -- they
own this code, and they also own any "negative knowledge" created
as a result of this code being written. Negative knowledge is
knowing what does not work which results from the trial and error
process we all go through when we write new code. Established
law and precedence based on years of IP litigation has established
this through numerous lawsuits. I do not believe a sitting judge would
rule in favor of the GPL and compell someone to open source code they
developed independent of Linux, whether it's a kernel module or not,
simply because someone chose to compile and run it as a kernel module.
It comes down to balancing the equities. If a company invested
money developing something, it's their property, and those sections
of the GPL I would expect to be held invalid and unenforceable.
Enter UCITA which provides a statutory basis to require a sitting judge
to rule in favor of the GPL. Based upon my analysis, upon application
of a compelling interest test, rational basis test, and a balancing test
(procedures judges employ using logic to determine whether laws such
as UCITA can stand based on established Federal and Supreme Court
Opinions), I firmly believe UCITA would fail these tests, and a sitting
judge would rule against the GPL. The overall affect of the GPL in such
a case would be to perform compulsary conversion of IP into open source
merely by virtue of the fact that someone ran it on Linux in kernel
mode -- a ridiculous reality. A legal brief applying these tests
would be lengthy, so I will not post it here (unless someone
asks me to), but based upon discussions with folks who do
IP litigation, the outcome would be that this section of the GPL
would be held invalid and unenforceable.
Application of the GPL as described in this post would be equivalent
to Microsoft writing a license agreement stating that anything that
runs on Windows entitles them to a non-compete of the technology on
other platforms, and states a compulsary conversion of ownership to
them for all apllications written for windows.
You can write code independent of Linux which does not incoroporate
Linux code directly and run it in kernel, and despite what the GPL
says, I do not believe anyone would succeed in getting an order
to compell it being open sourced. If you incorporate GPL source
code into program by lifting it "whole cloth" from someone else's
code and it's GPL, then you have to open source it, and I believe
someone could obtain an order compelling it to be open sourced.
UCITA would provide a statutory basis for enforcement of this provision,
and chaces are good at least one or more lower courts would rubber
stamp UCITA (particularly in states like California, where the legal
systems or more statute based), but I believe UCITA and the GPL
enforcement wold fail on appeal ni the circuit courts or in any
state which has not adopted UCITA.
Jeff
On Wed, Feb 27, 2002 at 09:59:46PM -0600, Richard Thrapp wrote:
> On Wed, 2002-02-27 at 18:51, Erik Mouw wrote:
> > On Wed, Feb 27, 2002 at 05:23:41PM -0500, Richard B. Johnson wrote:
> > > So, enter the compromise. Make your proprietary stuff in separate file(s)
> > > known only to your company. This keeps them trade secret. Compile them
> > > into a library. Provide that library with your module. The functions
> > > contained within that library should be documented as well as the
> > > calling parameters (a header file). This helps GPL maintainers
> > > determine if your library is broken.
> >
> > Brilliant, this violates section 2b from the GPLv2. If that's OK with
> > you, see a lawyer first.
>
> Hasn't it been said (by people in control) that binary only modules are
> okay to link into the kernel, or do I remember incorrectly? How is this
> different from a binary only module? Release an open-source component
> under a BSD license, or even a commercial license if you like, along
> with a closed source component. Link the two together, and finally
> insmod your non-GPL amalgamation into the kernel.
>
> Anyway, you're not distributing your kernel with your module linked in,
> so you're not distributing a derivative of a GPLed program, so by my
> understanding section 2b doesn't apply. Comments?
>
> --
> Richard Thrapp
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:42 EST