Re: [PATCH 0/2] Do not call kref utility functions from static inline code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. So I don't see any
benefit for you folks. And if you are already infringing it's a pretty
obvious circumvention trick, so definitely not something I can nor
will get involved with or even look like I'm approving. Imo
drm_prime.c was already borderline, but could be justified with code
sharing on technical grounds post-factum (or post-merging).

Overall I still don't get why you do this, and how this can help
exactly. You seem to already have the architecture that I think is the
only option which might be possible to be shipped without angering
someone somewhere too much to give you (legal) heat. And it's also the
only architecture that make sense technically.

/me confused
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux