Re: Writing the Apple AGX GPU driver in Rust?

[Asahi Lina <lina@asahilina.net>]

On 14/08/2022 00.30, Greg KH wrote:
> On Sun, Aug 14, 2022 at 12:06:08AM +0900, Asahi Lina wrote:
>>> From what I have been told, dual-licensing in the kernel quickly makes
>>> things trickier. Whether your case would be an issue or not depends on
>>> the tree that will pick up your patches, whether they accept
>>> dual-licensed stuff, whether the thing being abstracted is GPL-only or
>>> not, etc.
>>
>> That's odd, I've never heard of dual-licensing being an issue in the
>> kernel. Lots of drivers are dual licensed, as is the DRM core as I
>> mentioned... I did a quick search for SPDX lines and about 10% of them
>> are some kind of dual license in the entire kernel.
> 
> Most of those are legacy drivers and/or for the few Linux subsystems
> that do allow this, like DRM.

I see a lot of dual-licensed drivers in drivers/net/ and sound/soc/...
and nobody mentioned the license being an issue with drivers/soc/apple/
either (the Asahi drivers there are dual-licensed).

Of course, if a driver is based on another driver, then it should follow
the same license (or at least those portions should - if the driver has
several large and independent parts in different files, they could have
different licenses).

> For some subsystems that did dual-licensing, like IB, they regret doing
> that as it has caused nothing but pain and suffering over time and there
> was no benefit in the end at all..  Other subsystems can handle this
> properly but it is a lot of extra work that usually isn't worth it
> (again, DRM is the exception, they know what they are doing here.)

Right, but then the DRM bindings should also be dual-licensed, right?
I'm writing a DRM driver here, that's why I'm bringing this up...

> One of the biggest issue is having dual-licensed code use code from
> gpl-only subsystems.  What happens then is ripe for lots and lots of
> arguing by lots of lawyers.  For core interface code, like the Rust core
> is, avoiding all of that nightmare is a good idea by just keeping it
> simple as a single license (GPL) to remove any arguing at all.

I'm talking about bespoke scaffolding, especially proc macros. Those by
definition do not link with the rest of the kernel, since they run
inside the compiler. I'm not talking about kernel core abstractions...
those should be GPL-only if what they abstract over is GPL-only.

Really, I'm just saying I think it makes sense for Rust abstractions to
follow the license of whatever they abstract, and it might make sense
for shared, scaffolding-type stuff like proc macros to be more
permissive to encourage other OS projects to also adopt Rust without
having to reinvent those wheels.

~~ Lina