DRM radeon i2c support and GPL
jonsmirl at gmail.com
Mon Sep 20 09:08:28 PDT 2004
No GPL code doesn't make sense for the Linux drivers. The only place
Linux drivers can be used is in a GPL environment. For example there
is a 600 line sysfs support skeleton file I want to include. This file
is intended to be brought into a driver and then edited. It is a
complete waste of time recoding and redebugging that file just to make
it BSD compatible when the code won't even run on BSD.
On Mon, 20 Sep 2004 10:26:45 -0400, Adam Jackson <ajax at nwnk.net> wrote:
> On Monday 20 September 2004 05:57, Keith Whitwell wrote:
> > Jon Smirl wrote:
> > > I just checked a small change into DRM CVS that adds sysfs i2c support
> > > to the linux radeon driver. The patch includes some GPL licensed code
> > > extracted from the Linux kernel. The GPL files are only in the
> > > drm/linux directory. No GPL code was added to drm/shared or drm/bsd so
> > > the BSD build does not include the GPL code. The two GPL licensed
> > > files are clearly marked including warnings not to copy them into the
> > > BSD build.
> > The issue with GPL and drm is as I have stated several times now that we've
> > wanted XFree, and now Xorg, to be able to distribute this code as part of
> > their tree.
> > XFree86 had a strong policy against allowing GPL into their tree, I don't
> > know what Xorg's stand is. Maybe someone can comment from there?
> I've not heard any discussion to the contrary, so I would assume this is still
> the case.
> xc/extras/README claims:
> "Packages included here must be redistributable under conditions compatible
> with the XFree86 redistribution conditions (see
> xc/programs/Xserver/hw/xfree86/doc/COPYRIGHT for examples of compatible
> Of course that file no longer exists, and hasn't since before XFree86 4.0.
> When it did exist, it only made reference to BSD-style licenses:
> So this may be an open policy question still, but I suspect the answer is
> still "No GPL code".
> To be honest, I'd just as soon see Mesa removed from extras/ entirely, but -
> besides libGLcore - we can't do that until one of Mesa's build targets
> (linux-dri probably) is capable of generating a libGL that acts as a GLX
> client. This would involve moving the GLX client code from xc/lib/GL/glx
> into Mesa; I understand there's been some resistance to that idea in the
> - ajax
jonsmirl at gmail.com
More information about the xorg