Re: [Ksummit-discuss] [MAINTAINER SUMMIT] EXPORT_SYMBOL_GPL

[Guenter Roeck <linux@roeck-us.net>]

On Thu, Sep 13, 2018 at 12:43:15PM -0700, Dan Williams wrote:
> Currently the only guidance we have about EXPORT_SYMBOL_GPL usage in
> Documentation/ is:
> 
> "It implies that the function is considered an internal implementation
> issue, and not really an interface."
> 
> The topics for a Maintainer Summit discussion are:
> 
> 1/ The criteria "is considered an internal implementation issue" is
> sufficiently vague and seems to lead to arbitrary and subjective
> decisions by individual developers. Are there some objective technical
> criteria we can apply? For example, the symbol consumes other
> EXPORT_SYMBOL_GPL functionality, the symbol can effect kernel-wide
> state / policy, or the symbol leaks internal implementation details
> that are more unstable than typical EXPORT_SYMBOL apis. Any additional
> subjective criteria to consider? For example, it would be better for
> long term health of Linux if the consumers of a given API had the
> EXPORT_SYMBOL_GPL-related encouragement to get their code upstream.
> 
> 2/ With expanded criteria in hand the question then becomes what are
> the considerations for changing an existing symbol between
> EXPORT_SYMBOL or EXPORT_SYMBOL_GPL? I expect it would be awkward and
> unwanted to set down hard rules, but a list of considerations that a
> change proposal needs to address would at least help guide such
> discussions.
> 
> Not being a lawyer, I'm less interested in legal concerns, and more
> the technical, code maintenance, and health of the kernel aspects of
> what EXPORT_SYMBOL_GPL influences.
> 
> Note, I am not available to travel to Edinburgh to lead this discussion.

FWIW, I personally like to have a means to say "This code shall only
be used by GPL code" for any code I contribute to the Linux kernel.
I understand that this is completely non-technical.

Guenter