Alan,
Please read, understand and comment on the license policy strawman I
posted both to dri-devel and the xorg list.
It is a strawman, a first draft, and as I understand my intent,
is specifically intended to make it possible to permit such
situations. Whether it actually says that clearly, is, of course
possibly questionable ;-).
Such policy can only be set by the community of course,
and that requires discussion.
I also expect that as the releases become more modular, this situation
also becomes more modular and less of an issue in any case.
I personally prefer that kernel stuff be integrated in the kernel,
but that is because I always find having more than one version is
usually error prone (the same reasons we're trying to get things
like freetype, xterm, fontconfig/xft all from upstream modular
sources, rather than the current integration of stale bits).
- Jim
> Subject: Re: DRM radeon i2c support and GPL
> From: Alan Cox <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Jon Smirl <[EMAIL PROTECTED]>,
> Discuss issues related to the xorg tree <[EMAIL PROTECTED]>,
> DRI Devel <[EMAIL PROTECTED]>
> Date: Tue, 21 Sep 2004 10:48:05 +0100
>
> On Maw, 2004-09-21 at 08:58, Kean Johnston wrote:
> > That's not a statement thats safe to make. BSD (or any other OS
> > that XOrg supports) may not have Linux's I2C driver system. TODAY.
> > What if, next week, BSD gets such a beast, or HP-UX does, or
>
> Well they can't use the low level Linux code anyway, because its GPL
> licensed and likely to stay that way.
>
> > If XOrg is trying to be "license agnostic", it is going to need
> > to stay away from the GPL. The current MIT style license seems to
> > be quite acceptable to GPL-centric projects. However, the reverse
> > is not (always) true.
>
> Thats a shame. I guess its time to take DRI back out of the Xorg tree if
> this kind of extremist view is the preferred one, or just keep the
> kernel code in the Linux kernel and remove it from X.org ?
>
>
>
>
>
> --__--__--
>
> Message: 10
> Subject: XComposite and GLX
> From: Amir Bukhari <[EMAIL PROTECTED]>
> To: dri-devel <[EMAIL PROTECTED]>, Xorg <[EMAIL PROTECTED]>
> Date: Tue, 21 Sep 2004 15:54:25 +0200
>
> I have began to study the GLX code, to see the best way of getting
> Composite extension to support redirection of GLX. I will concentrate at
> first on server side code (software rendering). this will be a key to go
> afterwards to support DRI.
>
> I would like to know if there is someone has began this before or plan
> to work in it, so that we could share ideas!
>
> please use this thread to discuss this issue.
>
> --
> Amir Bukhari <[EMAIL PROTECTED]>
>
>
>
> --__--__--
>
> Message: 11
> Date: Tue, 21 Sep 2004 10:24:11 -0400
> From: Alex Deucher <[EMAIL PROTECTED]>
> Reply-To: Alex Deucher <[EMAIL PROTECTED]>
> To: Discuss issues related to the xorg tree <[EMAIL PROTECTED]>
> Subject: Re: DRM radeon i2c support and GPL
> Cc: Jon Smirl <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>
> On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > On Monday 20 September 2004 12:59, Jon Smirl wrote:
> > > On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > > License compatibility != OS compatibility, please don't conflate the two.
> > > > X runs on more than just Linux, and source is distributed as an
> > > > aggregate. If
> > >
> > > The Linux DRM driver does not run anywhere but on Linux. The GPL code
> > > is isolated to the Linux DRM driver.
> > >
> > > I wonder if DRM isn't GPL already by accident. DRM has been included
> > > in the Linux kernel under the GPL license. DRM has also accepted many
> > > bug patches back from the kernel people. If a fork had occurred
> > > between kernel and DRM it would be clear than one fork is GPL and one
> > > BSD. But the code never forked. Since there is only one code base and
> > > that code base has been released GPL via the kernel, so we may have
> > > inadvertently made DRM GPL.
> >
> > I would read it as "since the code never forked, we're still BSD".
> >
> > Inclusion is not conversion, in this case. All the copyright statements in
> > the DRM source (excluding your recent commit) specify BSD licenses. If the
> > bug-fixers wanted their changes to apply under the GPL they should have
> > indicated that by changing the copyright statement at the top of the file.
> >
> > The aggregate kernel is GPL, yes, but that doesn't mean all the components
> > are. ppp_deflate.c has gotten fixes from kernel people too, but it's still
> > BSD-licensed.
>
>
> I've never understood why the aggregate X (which includes some non MIT
> licensed code) can't have multiple licenses. The linux kernel does;
> other projects do. as long as it's properly labled in the code.
> People use X on linux. people run gnome on BSD. technically X and BSD
> have slightly different licenes too.
>
> Alex
>
> >
> > > I'd feel a whole lot better about the licensing if BSD and Linux DRM
> > > were split into two repositories.
> >
> > That still wouldn't address the issue of inclusion in Xorg, unless Xorg were
> > to only ship with the BSD DRM. And it would probably demote the BSD OSes to
> > fifth-class citizen status. Can't say as I'm a fan of that idea.
> >
> > > > it's really that big of a deal, ask the author of the GPL code to allow
> > > > you to add it to DRM under an X-friendly license.
> > >
> > > This is a waste of time. I know that some of the authors have a GPL or
> > > die attitude towards device driver code.
> >
> > Reimplementing code that the original author doesn't want to relicense is
> > nothing new under the sun (freeglut). I believe that splintering the code
> > base into universal and GPL versions is a bad idea, because it means any code
> > in the GPL version that someone wants to use in the universal version has to
> > be written twice - inevitably diverging the two trees and creating the sort
> > of cross-merge hell we're trying to get away from.
> >
> > If we're going to "waste time" like this, we might as well do it once, up
> > front, and be done with it.
> >
> > - ajax
> >
> >
> >
> > _______________________________________________
> > xorg mailing list
> > [EMAIL PROTECTED]
> > http://freedesktop.org/mailman/listinfo/xorg
> >
> >
> >
> >
> >
>
>
> --__--__--
>
> Message: 12
> Date: Tue, 21 Sep 2004 14:45:07 +0200
> From: Pavel Machek <[EMAIL PROTECTED]>
> To: Jon Smirl <[EMAIL PROTECTED]>
> Cc: dri-devel <[EMAIL PROTECTED]>,
> lkml <[EMAIL PROTECTED]>
> Subject: Re: Design for setting video modes, ownership of sysfs attributes
>
> Hi!
>
> > 1) user owns graphics devices
> > 2) user sets mode with string (or similar) format using ioctl common to
> > all drivers.
> > 3) driver is locked to prevent multiple mode sets
> > 4) common code takes this string and does a hotplug event with it.
>
> I though this was
>
> "Driver decides to either do it itself in kernel, or call userspace
> helper if that would be too complex".
>
> > How are errors going to be communicated in this scheme? I can cat the
> > sysfs mode variable to get a status. Is there a good way to do this
> > without polling?
>
> I'd say that write() to that sysfs file can simply return error. See
> echo disk > /sys/power/state, it returns error if transition failed.
>
>
> Pavel
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
