On Tue, Apr 18, 2017 at 10:26:39PM +0200, Daniel Vetter wrote:
> On Tue, Apr 18, 2017 at 7:55 PM, Andy Ritger <aritger@xxxxxxxxxx> wrote:
> > I explained:
> >
> > We intentionally chose MODULE_LICENSE("MIT") for nvidia-drm.ko, rather
> > than MODULE_LICENSE("Dual MIT/GPL"), to avoid any ambiguity:
> >
> > * nvidia-drm.ko depends on nvidia.ko, which is MODULE_LICENSE("NVIDIA").
> >
> > * nvidia-drm.ko is the portion of the NVIDIA dGPU driver that interfaces
> > with DRM in the kernel. We wouldn't want nvidia-drm.ko to
> > inadvertently function as, or even be perceived as, a path for
> > nvidia.ko to indirectly get access to EXPORT_SYMBOL_GPL symbols.
>
> So I'm a layman and all that, but I don't get why this is relevant at
> all. Speaking for myself, not my employer, not legal advice, yadayada,
> but I see two options:
>
> - the blob has become at least partially a derived work of the linux
> kernel work. You're fucked, whether you use gpl only symbols or not,
> because if there ever was some meaning to labelling stuff gpl-only it
> has long evaporated imo and become a pure political thing.
>
> - it is still a clearly independent work. There's no problem, because
> only the nvidia-drm impendence mismatch layer is a derived work (no on
> argues that I guess), and that along could easily ship as a part of
> the kernel with the overall GPL license. Of course upstream wont do
> that because it'd be pointless, but I don't see a problem.
>
> So either labelling it as dual MIT/GPL isn't really a problem, or
> labelling it as MIT-only isn't going to save your (legally speaking at
> least).
>
> Doing simple wrappers around gpl-only symbols otoh like you do here
> isn't any different from shipping it as part of nvidia-drm, at least I
> don't see how this factually changes anything.
>From my perspective, the distinction is:
* How drm functions are implemented is an implementation detail of drm.
The implementations of these functions use kref/refcount_t today because
they are well-proven primitives in the kernel. But, they could just
as easily have an entirely different implementation, and drm drivers
don't need to care.
* In contrast, if nvidia-drm directly accesses kref/refcount_t, we were
worried it would be perceived by some as an attempt to side-step the
intent of refcount_t being EXPORT_SYMBOL_GPL in the first place.
My goal was just for nvidia-drm to plug into the drm subsystem, not to
use any facilities that were deemed low-level implementation details
of the kernel.
Thanks,
- Andy
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
