[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Documentation: extend use case for EXPORT_SYMBOL_GPL()

On Thu, May 28, 2015 at 10:56:19PM +0100, Al Viro wrote:
> 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...

Great, thanks. This seems to be in alignment with those who have all along said
they've used EXPORT_SYMBOL() to mean what EXPORT_SYMBOL_GPL() users now use it
for. Nevertheless -- maintainers should know that some stubborn developers use
EXPORT_SYMBOL_GPL() for its technical merit should violators abuse those


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.