lkml.org 
[lkml]   [2015]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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
symbols.

Luis


\
 
 \ /
  Last update: 2015-05-29 01:21    [W:0.067 / U:30.724 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site