public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <landley@trommello.org>
To: David Schwartz <davids@webmaster.com>, <linux-kernel@vger.kernel.org>
Subject: Re: Input on the Non-GPL Modules - legal nonsense
Date: Thu, 25 Oct 2001 23:58:59 -0400	[thread overview]
Message-ID: <01102523585902.10384@localhost.localdomain> (raw)
In-Reply-To: <20011025062415.AAA15814@shell.webmaster.com@whenever>
In-Reply-To: <20011025062415.AAA15814@shell.webmaster.com@whenever>

On Thursday 25 October 2001 02:24, David Schwartz wrote:
> >I keep hearing this type of reasoning.  It flat-out doesn't work this way
> > in the legal system.  This is similar to arguing that you didn't really
> > stab someone if you threw the knife instead of holding it. ("But your
> > honor, once the knife left my hand it really wasn't under my control...")
>
> 	What amazes me is that these legal arguments about the control programmers
> have over their software, are coming from the free software community. If
> Microsoft argued that anybody who wanted to write a program to link with
> Windows system DLLs had to give them 2% of the profits, they'd be blasted
> by the press, yet the free software community wants to argue that
> programmers can't use their APIs if they don't have certain licensing
> terms?!
>
> 	The irony is killing me.

It's not a question of the published APIs.  Binary-only modules ARE allowed, 
and nobody's even questioned userspace applications.

It's aggregating yoru code with GPL code and distributing the result.  That 
violates the terms of the GPL, negating your right to distribute the GPL 
code, and by extension the aggregate work containing the GPL code.

And this isn't specific to free software.  Imagine if Microsoft put royalties 
on the distribution of some of their DLLs (like the big visual basic runtime) 
with your program, or Sun put restrictions on shipping their java runtime 
with one of your java programs.  (Which, in fact, they do.)  Neither 
currently ask for cash, but boy do they put restrictions!  Try distributing a 
modified version of either one of those sometime and see how long it takes 
their lawyers to come after you.  Distributing a patched vbrun.dll?  They'll 
go after you with bazookas.  You can't even unarchive jre.exe, last I 
checked.  The end user has to install it on their machine using Sun's 
installer.  (Maybe this has eased up in the past couple years, I stopped 
paying too much attention to Sun's java distributions shortly after 1.2...)

If your code doesn't include any GPL code, you're fine.  User space 
applications linking against glibc are fine, and binary-only kernel modules 
you wrote from scratch yourself are fine.  (Header files that define APIs but 
don't directly produce binary output code by themselves are a gray area; it's 
sloppy of us to have those as GPL instead of LGPL anyway, but compiling 
against header files probably falls under fair use since the programmer did 
make a distinction between .h and .c files, and being included in other 
programs to allow interoperability with this bit of code is what .h files are 
FOR...  I'd guess It's something that either side of could be successfully 
argued in front of a judge, depending on who had the better lawyer...)

Rob

  reply	other threads:[~2001-10-26  7:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-18 15:29 Input on the Non-GPL Modules Greg Boyce
2001-10-18 16:00 ` M. R. Brown
2001-10-18 16:32 ` Jan Niehusmann
2001-10-18 17:08   ` Tony Hoyle
2001-10-18 17:15     ` Jan Niehusmann
2001-10-18 19:01       ` Tim Bird
2001-10-18 19:38   ` Rik van Riel
2001-10-20 22:04   ` Alan Cox
2001-10-20 22:08     ` Ben Greear
2001-10-22 15:19       ` Input on the Non-GPL Modules - legal nonsense Tim Bird
2001-10-22 15:30         ` Ben Greear
2001-10-22 17:04           ` Jan Niehusmann
2001-10-25  6:24         ` David Schwartz
2001-10-26  3:58           ` Rob Landley [this message]
2001-10-20 22:20     ` Input on the Non-GPL Modules Anton Altaparmakov
2001-10-21 14:28       ` Alan Cox
2001-10-20 22:58     ` Craig Milo Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01102523585902.10384@localhost.localdomain \
    --to=landley@trommello.org \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox