linux-kernel - Re: [PATCH] Documentation: extend use case for EXPORT_SYMBOL

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]

Message-ID: <20150528215618.GE7232@ZenIV.linux.org.uk>
Date:	Thu, 28 May 2015 22:56:19 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>, corbet@....net,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	mingo@...e.hu, gnomes@...rguk.ukuu.org.uk,
	gregkh@...uxfoundation.org, jkosina@...e.cz, bhelgaas@...gle.com,
	linux-pci@...r.kernel.org, xen-devel@...ts.xenproject.org,
	bp@...e.de
Subject: Re: [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()

On Thu, May 28, 2015 at 11:17:36PM +0200, Luis R. Rodriguez wrote:
> > ... while some of us consider that as pointless posturing and will refuse
> > to merge such exports regardless.
> 
> Can you elaborate why, for those maintainers not aware of such positions?

*shrug*

Either one states that all modules are derivative works of the kernel,
period (in which case attaching _GPL to specific exports is completely
pointless), or it's a claim that this specific export is something
special on its own, which is a fairly strong claim, completely unfounded
more often than not.  In the worst cases it's the former being misrepresented
as the latter.  That only serves to weaken our position in case of copyright
violations, IMO.  When obviously BS claims like "encoding and decoding
of UIDs between the numeric values as seen by userland and stored on
filesystem and opaque pointers as used by the userns stuff is so special
that its use alone is sufficient to change whether the code is derivative
of the kernel or not" are thrown around, we end up with weaker protection,
not stronger one.  If something like _that_ makes the difference between
derived and non-derived, the former can't be worth much...
--
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/