lkml.org 
[lkml]   [2019]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity
On Sat, Feb 09, 2019 at 10:37:17AM +0100, Philippe Ombredanne wrote:
> > + * states, that the module is licensed under one of the compatible BSD
> > + * license variants. The detailed and correct license information is again
> > + * to be found in the corresponding source files.
> > + *
> > * There are dual licensed components, but when running with Linux it is the
> > * GPL that is relevant so this is a non issue. Similarly LGPL linked with GPL
> > * is a GPL combined work.
>
> Just to add to your points, I have seen a few times folks create
> out-of-tree modules and use a MODULE_LICENSE "Proprietary" with a
> proper GPL license notice at the top just to ensure that the code
> would not be able to link with and use symbols exported with
> EXPORT_SYMBOL_GPL().

That's very odd, but oh well, people do strange things :)

> This further reinforces the relevance of your argument as
> MODULE_LICENSE can be used also as a pure technical solution that is
> not making any licensing statement. So much so that a rewrite could
> instead use something akin to EXPORT_SYMBOL_PRIVATE/INTERNAL/NON_API (
> as 0 or 1) and MODULE_CAN_USE_PRIVATE/INTERNAL/NON_API_SYMBOLS ( as 0
> or 1) and not deal with anything license-related? After all this is
> mostly a binary flag.

No, let's leave the export symbol stuff as-is for now please. Let's
just focus on cleaning up this odd string mess so that we can move on to
the larger goal of getting everything in-tree properly classified.

thanks,

greg k-h

\
 
 \ /
  Last update: 2019-02-09 13:13    [W:0.133 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site