Re: DRM radeon i2c support and GPL
On Mer, 2004-09-22 at 06:09, Eric Anholt wrote: > lines are GPLed of a file otherwise MIT-licensed). I was very bothered > by Jon's suggestion that a lot of the code could be GPLed by accident or > something, as if that license would have infected the entire DRM > (including shared bits) while nobody was looking. If someone feels that > there is GPLed code in there, it should be looked into and documented > immediately, or that vague stick should stop being waved. The GPL is intentionally very explicit about this situation "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. " ["the Program" being the GPL code] --- 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
Re: DRM radeon i2c support and GPL
On Tue, 2004-09-21 at 02:48, Alan Cox wrote: > 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. Ugh. Of course that wouldn't happen. Not even implementing internal kernel interfaces, which is all that could apply for Kean's suggestion. > > 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 ? I'll stick my two cents in here, as a BSD DRI maintainer. I don't think it matters if Linux-only DRM bits are GPLed, as long as they're clearly licensed appropriately (copyright header at the top, or describing which lines are GPLed of a file otherwise MIT-licensed). I was very bothered by Jon's suggestion that a lot of the code could be GPLed by accident or something, as if that license would have infected the entire DRM (including shared bits) while nobody was looking. If someone feels that there is GPLed code in there, it should be looked into and documented immediately, or that vague stick should stop being waved. IMO, X.Org should care about the DRM for its purposes as the kernel part of the DRI -- the 3d bits, not the i2c bits or whatever other linux bits, as long as X.Org and the DRI/DRM (drm/shared) remains portable to other platforms without depending on the GPLed bits, which I don't think is on the horizon at all. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- 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
Re: DRM radeon i2c support and GPL
On Maw, 2004-09-21 at 16:19, Jim Gettys wrote: > Please read, understand and comment on the license policy strawman I > posted both to dri-devel and the xorg list. Oh I did, don't take my response as anything but throwing up the logical conclusion to that policy. I'm not in favour of that approach. > Such policy can only be set by the community of course, > and that requires discussion. Historically X core code which is (L)GPL has been rejected. That has always made sense as the effects are often bizarre like probably not being able to use the vnc driver and trident driver together even though they share an author. I don't believe X should change on that issue. The question is one of additional programs that come with X - that is what the Linux DRI kernel module really is. Currently almost everyone in the X world is using some GPL software with their X server, it just happens to be in a different tarball/rpm/dpkg/... > I also expect that as the releases become more modular, this situation > also becomes more modular and less of an issue in any case. Agreed --- 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
Re: DRM radeon i2c support and GPL
On Tuesday 21 September 2004 10:24, Alex Deucher wrote: > On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson <[EMAIL PROTECTED]> wrote: > > 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. I don't see why it can't either, besides that we've never formally stated that that's okay. If you're not going to link the GPL-licensed bits with a non-GPL kernel, then having GPL bits in the tree isn't a big deal. My strong preference is to minimize GPL code in the tree, for the usual contamination reasons. But either way, we need a formally stated policy. - ajax pgpVG6CNrXMr1.pgp Description: PGP signature
Re: DRM radeon i2c support and GPL
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 fil
Re: DRM radeon i2c support and GPL
On Tuesday 21 September 2004 05:48, Alan Cox wrote: >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 ? And can you define what the effect of that would be on how well it runs? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.26% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved. --- 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
Re: DRM radeon i2c support and GPL
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 > > > > > --- 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
Re: DRM radeon i2c support and GPL
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 ? --- 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
Re: DRM radeon i2c support and GPL
Le mar 21/09/2004 Ã 09:58, Kean Johnston a Ãcrit : > > I picked a very simple piece of code to start out with as a test case. > > The I2C code is only a hundred lines and could be rewritten. But > > what's the point, BSD doesn't have Linux's I2C driver system. This > > code has no value anywhere but on Linux. > 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 > Solaris or whatever. Maybe now that code that is currently only > of value on Linux is of value on a broad range of systems. My understanding is that if/when BSDs (and others) implement an I2C system, it'll probably be compatible with the Linux one from the userspace side (i.e. the syscalls will have the same semantics) but certainly not from the kernel side: there's not point for them to be compatible with the Linux architecture as they can't import its drivers. I don't the DRM drivers, but if they use I2C from the kernel side there's not point in licensing that code for multiplatform. Xav --- 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
Re: DRM radeon i2c support and GPL
Le mardi 21 septembre 2004 Ã 00:58 -0700, Kean Johnston a Ãcrit : > > I picked a very simple piece of code to start out with as a test case. > > The I2C code is only a hundred lines and could be rewritten. But > > what's the point, BSD doesn't have Linux's I2C driver system. This > > code has no value anywhere but on Linux. > 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 > Solaris or whatever. Maybe now that code that is currently only > of value on Linux is of value on a broad range of systems. Then the xorg code will be rewritten in a platform-agnostic way with a more permissive license. Or do you believe you can write now some code that will work as-is with yet unwritten platform implementations? Since the code *will* need to be adapted then, the licensing can be reviewed at that time too. That's the point people tried to make, I think. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: DRM radeon i2c support and GPL
I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. 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 Solaris or whatever. Maybe now that code that is currently only of value on Linux is of value on a broad range of systems. Now you have the potential for a broad range of non-GPL systems to be dependent on GPL code, which is, after all, the point I think the original strawman paper was addressing. 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. Kean --- 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
Re: DRM radeon i2c support and GPL
On Tue, 21 Sep 2004 00:10:31 +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > On Llu, 2004-09-20 at 18:38, Adam Jackson wrote: > > 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. > > Some of the pure Linux code is clearly derivative of existing GPL code. > I personally don't see the issue for platform specific code that isn't > meant to be and won't be portable. Providing that code is also clearly > marked. Is there a reason however for not starting from the X code for > doing this management ? I picked a very simple piece of code to start out with as a test case. The I2C code is only a hundred lines and could be rewritten. But what's the point, BSD doesn't have Linux's I2C driver system. This code has no value anywhere but on Linux. There are more complicated files that I am looking at. For example sysfs support, it is much easier to just copy class_simple.c into the project and start editing on it that it is to write it all over again. GregKH even recommends doing this when you need a class that is more complex than simple. -- Jon Smirl [EMAIL PROTECTED] --- 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
Re: DRM radeon i2c support and GPL
On Llu, 2004-09-20 at 18:38, Adam Jackson wrote: > 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. Some of the pure Linux code is clearly derivative of existing GPL code. I personally don't see the issue for platform specific code that isn't meant to be and won't be portable. Providing that code is also clearly marked. Is there a reason however for not starting from the X code for doing this management ? --- 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
Re: DRM radeon i2c support and GPL
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'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 pgpyxgKSdXzjn.pgp Description: PGP signature
Re: Strawman licensing policy (was: DRM radeon i2c support and GPL)
Also note the embedded issue raised during the Cairo relicencing discussion, however. We have a lot of embedded X use both historically and going forward; I know that hasn't occurred much in the DRI part of the world, but it is commonplace for X itself, and can be expected to be common in the future for DRI as well. We need to understand that issue better, as my strawman states. - Jim On Mon, 2004-09-20 at 13:25, Jon Smirl wrote: > This policy prevents code reuse from other parts of Linux. It is > counter productive to take working GPL code that is specific to Linux, > rewrite it for the MIT license, and then resubmit it to Linux under > the GPL again. The policy is fine for the cross platform code but it > doesn't make sense for the platform specific code. --- 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
Re: Strawman licensing policy (was: DRM radeon i2c support and GPL)
I think if you read it again more carefully, it doesn't say that. Of course, it is a strawman I just put together, so I may not have said what I meant - Jim On Mon, 2004-09-20 at 13:25, Jon Smirl wrote: > This policy prevents code reuse from other parts of Linux. It is > counter productive to take working GPL code that is specific to Linux, > rewrite it for the MIT license, and then resubmit it to Linux under > the GPL again. The policy is fine for the cross platform code but it > doesn't make sense for the platform specific code. --- 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
Re: Strawman licensing policy (was: DRM radeon i2c support and GPL)
This policy prevents code reuse from other parts of Linux. It is counter productive to take working GPL code that is specific to Linux, rewrite it for the MIT license, and then resubmit it to Linux under the GPL again. The policy is fine for the cross platform code but it doesn't make sense for the platform specific code. -- Jon Smirl [EMAIL PROTECTED] --- 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
Strawman licensing policy (was: DRM radeon i2c support and GPL)
Keith, We haven't managed to write such a policy down yet, and demonstrate full consensus of the community. So far, I'd describe the policy today as "first, do no harm". It is certainly on the board's radar screen to try help the community generate a policy with full feedback from the membership. Also note that with the intention of modularizing the distribution, new parts of the system may in the future be available under different terms than has been true under the past. I'll take a crack at enunciating a policy now, however, to help get the discussion going. I've stated this position informally in a number of forums and have had encouraging feedback, but as there has not been public review and comment and it has not been written down and accepted, it must be regarded as a strawman. Strawman policy on X.org licensing == Jim Gettys 9/20/2004 version .1 Preamble Many people, organizations and companies, have contributed to the corpus of code distributed by X.org, which has been built over 20 years. An *implicit* unwritten understanding of their contributions to the X Window System code base has been that the code would remain available to them under the same terms that it was made available to the community into the future, though, in fact, there has been no legal terms in the licenses used in X code to enforce this. Violating this trust would be to the long term detriment of X.org, the contributors and organizations that have funded X development. The current body of code is primarily under the "MIT License", which is considered fully acceptable software by the entire community, whether they call themselves open source or free.(*) A description of what it means to be free software may have best been stated by the Debian project, in the Debian Free Software Guidelines (which can be found at: http://www.debian.org/social_contract). Certainly licenses that qualify by these guidelines are the only licenses the full community finds acceptable. Detailed Consequences - a) adding more restrictive copyrights on modifications to existing code bases is not allowed. For example, if a patch or file is added to a library, it may not have copyrights any more restrictive than that of the module which it is a part of, and the usual expectation will be that it be the MIT license or the license used by that module. The most complicated situations come up as software is "aggregated" into larger programs or systems. Interactions among copyrights easily become very complicated, and in fact, contradictions among licenses can occur that prevent aggregates being distributed at all. "Compatibility" between common licenses is a real issue we must continue to be sensitive to, and licenses cannot be arbitrarily mixed *in a system as a result. b) The consequences of a new module that becomes part of a larger program (e.g. a graphics driver in the X server) must be very carefully analyzed before they can be accepted (there can be situations that would make it illegal for the aggregate to be shipped), or it could be that previous contributors contributions might become effectively useless to them, violating the implicit trust given by previous contributors that the terms would not change in the future. c) Similarly, requiring a new dependency on a module may present serious issues. An example might be the required dependency on a GPL only library (note GPL rather than LGPL) for which there is no BSD/MIT licensed equivalent that is required generally for the software to be useful, which might disenfranchise those who may be unwilling to accept such libraries on other platforms. Note that dependencies that are specific to a single platform might or might not generate problems of this class, depending upon the precise circumstances. Note that during the recent Cairo licensing discussion that even the LGPL by itself could be problematic, due to concerns of use in embedded systems, in which X has been and continues to be used. Further understanding of the issues raised during that discussion are needed to understand if those concerns are valid, even though a solution for that particular situation has been found. d) consequences b) and c) argue toward simplicity of licensing; X.org desires to keep the overall aggregate licensing simple and may discourage/forbid the use of licenses that complicate licensing or make aggregate programs or systems difficult or impossible. The board of directors will decide on whether a license not already in use in the module or program in the system is allowed after full public discussion, if consensus during that discussion is not reached. e) new contributions under other DFSG compliant licenses will be considered, so long as conditions a-d are met. I hope this strawman starts a productive discussion.
Re: DRM radeon i2c support and GPL
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'd feel a whole lot better about the licensing if BSD and Linux DRM were split into two repositories. > 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. > > Yes, I think it's silly too. > > - ajax > > > > -- Jon Smirl [EMAIL PROTECTED] --- 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
Re: DRM radeon i2c support and GPL
On Monday 20 September 2004 12:08, Jon Smirl wrote: > 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. 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 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. Yes, I think it's silly too. - ajax pgpU4ErFqDpAz.pgp Description: PGP signature
Re: DRM radeon i2c support and GPL
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 <[EMAIL PROTECTED]> 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 > licences)." > > 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: > http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/Attic/COPYRIGHT > > 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 > past. > > - ajax > -- Jon Smirl [EMAIL PROTECTED] --- 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
Re: DRM radeon i2c support and GPL
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 licences)." 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: http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/doc/Attic/COPYRIGHT 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 past. - ajax --- 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
Re: DRM radeon i2c support and GPL
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? Keith --- 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
Re: DRM radeon i2c support and GPL
The patch is also an example of using permanent maps and enabling MMIO from the driver. -- Jon Smirl [EMAIL PROTECTED] --- 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
Re: DRM radeon i2c support and GPL
You need i2c and eeprom kernel modules loaded in order to see the EDID data. [EMAIL PROTECTED] 3-0050]$ hexdump -C /sys/class/drm/card0/device/i2c-3/3-0050/eeprom 00 ff ff ff ff ff ff 00 5a 63 47 55 01 01 01 01 |ZcGU| 0010 18 0b 01 03 08 1e 17 50 ea 6d 8c 98 59 50 93 26 |...P.m..YP.&| 0020 20 4c 52 2f ce 00 01 01 01 01 01 01 01 01 01 01 | LR/| 0030 01 01 01 01 01 01 64 19 00 40 41 00 26 30 18 88 |[EMAIL PROTECTED]&0..| 0040 36 00 30 e4 10 00 00 18 00 00 00 ff 00 47 55 31 |6.0..GU1| 0050 32 34 30 31 30 37 38 0a 20 20 00 00 00 fd 00 32 |2401078. .2| 0060 4b 1e 3c 08 00 0a 20 20 20 20 20 20 00 00 00 fc |K.<... | 0070 00 56 45 31 35 30 0a 20 20 20 20 20 20 20 00 ae |.VE150. ..| 0080 00 ff ff ff ff ff ff 00 5a 63 47 55 01 01 01 01 |ZcGU| 0090 18 0b 01 03 08 1e 17 50 ea 6d 8c 98 59 50 93 26 |...P.m..YP.&| 00a0 20 4c 52 2f ce 00 01 01 01 01 01 01 01 01 01 01 | LR/| 00b0 01 01 01 01 01 01 64 19 00 40 41 00 26 30 18 88 |[EMAIL PROTECTED]&0..| 00c0 36 00 30 e4 10 00 00 18 00 00 00 ff 00 47 55 31 |6.0..GU1| 00d0 32 34 30 31 30 37 38 0a 20 20 00 00 00 fd 00 32 |2401078. .2| 00e0 4b 1e 3c 08 00 0a 20 20 20 20 20 20 00 00 00 fc |K.<... | 00f0 00 56 45 31 35 30 0a 20 20 20 20 20 20 20 00 ae |.VE150. ..| 0100 -- Jon Smirl [EMAIL PROTECTED] --- 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
DRM radeon i2c support and GPL
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. -- Jon Smirl [EMAIL PROTECTED] --- 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
