RE: Linux GPL and binary module exception clause?

[Andre Hedrick]

Linus,

How can the additional words alter the mean of GPL itself?
I am not baiting this time.  Does the simple addition of your meaning
imposed create an effective restriction?  Does that applied meaning make
the kernel license invalid for all?  I am sure there were no changes in
the text of the COPYING file, but the additions to the "coyrighted" file
appears to alter intent.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Wed, 10 Dec 2003, Linus Torvalds wrote:

> 
> 
> On Wed, 10 Dec 2003, Hua Zhong wrote:
> >
> > > What has meaning for "derived work" is whether it stands on its own or
> > > not, and how tightly integrated it is. If something works
> > > with just one particular version of the kernel - or depends on things like
> > > whether the kernel was compiled with certain options etc - then it pretty
> > > clearly is very tightly integrated.
> >
> > Many userspace programs fall into this category too.
> 
> Absolutely.
> 
> Trust me, REAL LAWYERS WERE WORRIED about this. It wasn't just random tech
> people discussing issues on a technical (or, right now, not-so-technical)
> mailing list.
> 
> There's a reason for those lines at the top of the COPYING file saying
> that user space is not covered, and there are literally lawyers who say it
> would hold up in a court of law.
> 
> Exactly because you _can_ argue that user-space might be covered. It's an
> argument that almost certainly would fail very quickly due to "documented
> interfaces" and ABI issues, but it is an argument that lawyers have made,
> and it's that argument that makes the disclaimer in COPYING be worth it.
> 
> In other words: even without that disclaimer of derivation, user space
> would almost certainly (with a very high probability indeed) be safe from
> a copyright infringement suit. Such a suit would most likely be thrown out
> very early, exactly because the UNIX system call interface is clearly
> extensively documented, and the Linux implementation of it has strived to
> be a stable ABI for a long time.
> 
> In fact, a user program written in 1991 is actually still likely to run,
> if it doesn't do a lot of special things. So user programs really are a
> hell of a lot more insulated than kernel modules, which have been known to
> break weekly.
> 
> Similarly, things like /proc etc are clearly intended to be ways to
> interface to the kernel in user space, so there's a clear intent there
> that nobody can reasonably deny (again, that intent is made _clearer_ by
> the COPYING disclaimer, but it would be hard to argue against even in the
> absense of that).
> 
> But even DESPITE these strong arguments that user-space clearly isn't a
> derived work, and real lawyers worried, and felt much happier with the
> explicit disclaimer in the COPYING file.
> 
> That should tell you something. In particular, it should tell you to be
> careful: some courts have made so broad "derivative work" judgements that
> it's scary - think about the "Gone With the Wind" parody (I think the
> ruling was eventually overturned on First Amendment grounds, but the
> point is that you should be very careful, and while source code has
> the potential for First Amendment protection, binary modules sure as hell
> do not).
> 
> And please note that I am _not_ arguing for those overly broad judgements:
> I'm just pointing out that you should not assume that "derivative" is
> something simple. If an author claims your work is derivative, you should
> step very very lightly.
> 
> And I claim that binary-only kernel modules ARE derivative "by default",
> by virtue of having no meaning without the kernel.
> 
> 		Linus
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/