lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 Dec 2006 09:03:57 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Greg KH <gregkh@...e.de>, Jonathan Corbet <corbet@....net>,
	Andrew Morton <akpm@...l.org>,
	Martin Bligh <mbligh@...igh.org>,
	"Michael K. Edwards" <medwards.linux@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: GPL only modules [was Re: [GIT PATCH] more Driver core patches
 for 2.6.19]



On Thu, 14 Dec 2006, Jeff Garzik wrote:
> 
> For the record, I also disagree with the sneaky backdoor way people want to
> add EXPORT_SYMBOL_GPL() to key subsystems that drivers will need.

I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if done 
properly (and I think we use it fairly well).

I think we _can_ do things where we give clear hints to people that "we 
think this is such an internal Linux thing that you simply cannot use this 
without being considered a derived work".

It's really just a strong hint about what we consider to be internal. The 
fact is, "intent" actually does matter, and as such our _intent_ in saying 
"these are very deep and internal interfaces" is actually meaningful - 
even in a court of law.

So I personally don't see EXPORT_SYMBOL_GPL() to be a "technical measure", 
I see it as being "documentation".

That said, I think that some people seem to be a bit over-eager to use it. 
And I actually think that weakens the rest of them too (imagine a lawyer 
saying in front of a judge:

  "Look, they marked 'strcpy()' as a symbol that requires us to be GPL'd, 
   but look, it's a standard function available everywhere else too, and 
   you can implement it as one line of code, so a module that uses it 
   clearly is NOT a derived work, so EXPORT_SYMBOL_GPL is obviously not 
   something that means anything"

So this is why I've actually argued in the past for some 
EXPORT_SYMBOL_GPL's to be demoted to "normal" EXPORT_SYMBOL's. Exactly 
because over-using them actually _weakens_ them, and makes them pointless 
both from a documentation _and_ from a legal standpoint.

Btw, I've actually had a lawyer tell me that EXPORT_SYMBOL_GPL makes legal 
sense and has actually made people happier, for what its worth. Of course, 
you can get <n*2> different opinions from <n> lawyers, so that may not be 
all that meaningful ;)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ