The nvidia framebuffer code added recently is marked as
MODULE_LICENSE(GPL), but some things seem a little odd to me..
1. The boilerplate at the top of drivers/video/nvidia/nv_dma.h,
drivers/video/nvidia/nv_local.h, and drivers/video/nvidia/nv_hw.c
doesn't seem to be a GPL-compatible license. It seems to be an nvidia
specific license with an advertising clause, and something that
adds restrictions on rights of U.S. Govt end users.
2. Some of these files clearly came from XFree86 judging from
the CVS idents in the source. Was this XFree86 code
dual-licensed by its original authors ? If so, it isn't clear.
Dave
Dave Jones <[email protected]> wrote:
>
> The nvidia framebuffer code added recently is marked as
> MODULE_LICENSE(GPL), but some things seem a little odd to me..
>
> 1. The boilerplate at the top of drivers/video/nvidia/nv_dma.h,
> drivers/video/nvidia/nv_local.h, and drivers/video/nvidia/nv_hw.c
> doesn't seem to be a GPL-compatible license. It seems to be an nvidia
> specific license with an advertising clause, and something that
> adds restrictions on rights of U.S. Govt end users.
>
> 2. Some of these files clearly came from XFree86 judging from
> the CVS idents in the source. Was this XFree86 code
> dual-licensed by its original authors ? If so, it isn't clear.
Does
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm3/broken-out/fbdev-nvidia-licensing-clarification.patch
clear things up?
On Sat, 2005-03-12 at 21:59 -0800, Andrew Morton wrote:
> Dave Jones <[email protected]> wrote:
> >
> > The nvidia framebuffer code added recently is marked as
> > MODULE_LICENSE(GPL), but some things seem a little odd to me..
> >
> > 1. The boilerplate at the top of drivers/video/nvidia/nv_dma.h,
> > drivers/video/nvidia/nv_local.h, and drivers/video/nvidia/nv_hw.c
> > doesn't seem to be a GPL-compatible license. It seems to be an nvidia
> > specific license with an advertising clause, and something that
> > adds restrictions on rights of U.S. Govt end users.
> >
> > 2. Some of these files clearly came from XFree86 judging from
> > the CVS idents in the source. Was this XFree86 code
> > dual-licensed by its original authors ? If so, it isn't clear.
>
> Does
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm3/broken-out/fbdev-nvidia-licensing-clarification.patch
>
> clear things up?
somewhat; it would even make sense to consider dual licensing that thing
(like most other not-originally-gpl code in the kernel) to clarify the
legal status for real. Otherwise if you merge it with GPL it sort of
becomes GPL only.. (due to the freedom of MIT and the viral nature of
GPL) and I suspect the intention of the author was to keep allowing MIT
use...
All of the files in drivers/char/drm really should have an explicit
dual MIT/GPL license on them too. The DRM project has been taking
patches back into DRM from LKML without making it clear that DRM is
MIT licensed. It might be construed that doing this has made DRM GPL
without that being the intention.
--
Jon Smirl
[email protected]
On Sun, 2005-03-13 at 21:03 -0500, Jon Smirl wrote:
> All of the files in drivers/char/drm really should have an explicit
> dual MIT/GPL license on them too. The DRM project has been taking
> patches back into DRM from LKML without making it clear that DRM is
> MIT licensed. It might be construed that doing this has made DRM GPL
> without that being the intention.
without explicit dual licensing this is a trap yeah... it's far far
nicer to just make it explicit that it's dual licensed and that you
expect all patches are also dual licensed unless they also remove one of
the licenses (several dual licensed parts of the kernel have such
language if you're looking for example text). Otherwise its very much an
unclear situation and with licenses it's just better to be very explicit
and clear.
On Sun, 13 Mar 2005, Jon Smirl wrote:
> All of the files in drivers/char/drm really should have an explicit
> dual MIT/GPL license on them too. The DRM project has been taking
> patches back into DRM from LKML without making it clear that DRM is
> MIT licensed. It might be construed that doing this has made DRM GPL
> without that being the intention.
They all have explicit MIT licenses on them, these files are only
dual-licensed by the fact that they are shipped with the kernel, but they
are MIT licensed and I would consider any changes to them to be MIT
licensed unless someone explicitly states it..
Similiar to the reiser notice on top of those files.. I think MIT license
is explicit enough...
Some files are GPL licensed like drm_sysfs as it is obivously derived from
GPL code,
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG
On Tue, 2005-03-15 at 10:32 +0000, Dave Airlie wrote:
> On Sun, 13 Mar 2005, Jon Smirl wrote:
>
> > All of the files in drivers/char/drm really should have an explicit
> > dual MIT/GPL license on them too. The DRM project has been taking
> > patches back into DRM from LKML without making it clear that DRM is
> > MIT licensed. It might be construed that doing this has made DRM GPL
> > without that being the intention.
>
> They all have explicit MIT licenses on them, these files are only
> dual-licensed by the fact that they are shipped with the kernel, but they
> are MIT licensed and I would consider any changes to them to be MIT
> licensed unless someone explicitly states it..
this is actually a bit of a legal iffy point here. People submit patches
to the kernel (which is GPL). In addition, while patches to gpl code are
gpl (by the gpl "derived works" clause), the MIT license has no such
requirement or even assumption on derived works so it's all quite iffy.
I strongly suggest you put the dual license header in those files to get
rid of the ambiguity.. as you said it's not really a big deal in that
the code already is dual licensed in effect; please consider making it
explicit, it solves a lot of ambiguity.