Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2021-09-11 at 08:51 -0600, Jonathan Corbet wrote:
> James Bottomley <James.Bottomley@HansenPartnership.com> writes:
> 
> > On Fri, 2021-09-10 at 23:59 +0200, Alexandre Belloni wrote:
> > > I think the question is not whether we want to forbid proprietary
> > > user space using an API but whether we want to merge said API so
> > > the license on the kernel doesn't matter much.
> > 
> > I thought that *was* the statement I made in the last paragraph: we
> > can choose whether or not to merge the enabling API into the
> > kernel. However, if we merge it we can't choose whether a
> > proprietary user space takes advantage of the API.  My original
> > reply was to the notion of EXPORT_USERSPACE_GPL, which I think we
> > have no legal basis for enforcing without modifying the system
> > exception.
> 
> That wasn't thinking when I pulled the idea of EXPORT_USERSPACE_GPL
> out of whatever dark place it was lurking in.

OK, but you can see how that thought is arrived at since
EXPORT_SYMBOL_GPL is a technically enforced licensing permission tag. 
However, I was seriously pushing back against the *idea* of such a tag
because once it crosses the kernel to user boundary it would cause huge
confusion of our current licensing positions ... regardless of what it
actually means.

>   The idea was, instead, to document that if your driver is using
> that interface, it won't be considered for merging into the kernel in
> the absence of a working, free, user-space implementation -- should
> we choose to adopt such a policy, of course.

Right, and if you have a driver with an internal API that's used for
communication with a userspace blob, we can evaluate that, as we have
done before, on a case by case basis.  It's not a new thing, because
we're both old enough to remember "my wireless driver has to have a
proprietary component for regulatory reasons".

We've made decisions both for and against such drivers in the past, but
I think the issues are too nuanced to make a general rule.  If you do
have a general rule, what other things, like firmware, would get caught
by it and so on ...

> Nobody is trying to prohibit proprietary user space, that's not the
> point.

I didn't think you were in general, but requiring a free userspace
driver implementation is prohibiting a proprietary one and so then you
get into questions of how wide the reach is and what the knock on
effects are if you try to craft a general policy around this ...
especially if it has technical enforcement measures.

James