From: Dieter <Die...@ha...> - 2004-03-01 13:43:23
|
Someone preparing a merge? Thanks, Dieter |
From: Alan H. <al...@fa...> - 2004-03-01 14:27:33
|
On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter N=FCtzel wrote: > Someone preparing a merge? Possibly, for the binary packages we need to include the LICENSE documents. Alan. |
From: David D. <dawes@XFree86.Org> - 2004-03-01 18:55:45
|
On Mon, Mar 01, 2004 at 02:15:13PM +0000, Alan Hourihane wrote: >On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter N=FCtzel wrote: >> Someone preparing a merge? > >Possibly, > >for the binary packages we need to include the LICENSE documents. Including the LICENSE documents is, strictly speaking, required by many of the other licenses too. Even the old style MIT licence that you use for your trident driver says: "... and that both that copyright notice and this permission notice appear in supporting documentation." David |
From: Alan H. <al...@fa...> - 2004-03-01 19:42:16
|
On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote: > On Mon, Mar 01, 2004 at 02:15:13PM +0000, Alan Hourihane wrote: > >On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter N=FCtzel wrote: > >> Someone preparing a merge? > > > >Possibly, > > > >for the binary packages we need to include the LICENSE documents. >=20 > Including the LICENSE documents is, strictly speaking, required by > many of the other licenses too. Even the old style MIT licence > that you use for your trident driver says: >=20 > "... and that both that copyright notice and this permission notice > appear in supporting documentation." Right, and so we need to fix these things up. Felix, Can you add the LICENSE file to the binary packages ? Alan. |
From: Felix <fx...@gm...> - 2004-03-01 21:39:18
|
On Mon, 1 Mar 2004 19:29:45 +0000 Alan Hourihane <al...@fa...> wrote: > On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote: > > On Mon, Mar 01, 2004 at 02:15:13PM +0000, Alan Hourihane wrote: > > >On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter N=FCtzel wrote: > > >> Someone preparing a merge? > > > > > >Possibly, > > > > > >for the binary packages we need to include the LICENSE documents. > >=20 > > Including the LICENSE documents is, strictly speaking, required by > > many of the other licenses too. Even the old style MIT licence > > that you use for your trident driver says: > >=20 > > "... and that both that copyright notice and this permission notice > > appear in supporting documentation." >=20 > Right, and so we need to fix these things up. >=20 > Felix, >=20 > Can you add the LICENSE file to the binary packages ? Sure. I assume you mean programs/Xserver/hw/xfree86/doc/LICENSE? >=20 > Alan. >=20 Felix |
From: Alan H. <al...@fa...> - 2004-03-01 22:15:03
|
On Mon, Mar 01, 2004 at 10:26:58PM +0100, Felix K=FChling wrote: > On Mon, 1 Mar 2004 19:29:45 +0000 > Alan Hourihane <al...@fa...> wrote: >=20 > > On Mon, Mar 01, 2004 at 01:19:39PM -0500, David Dawes wrote: > > > On Mon, Mar 01, 2004 at 02:15:13PM +0000, Alan Hourihane wrote: > > > >On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter N=FCtzel wrote: > > > >> Someone preparing a merge? > > > > > > > >Possibly, > > > > > > > >for the binary packages we need to include the LICENSE documents. > > >=20 > > > Including the LICENSE documents is, strictly speaking, required by > > > many of the other licenses too. Even the old style MIT licence > > > that you use for your trident driver says: > > >=20 > > > "... and that both that copyright notice and this permission not= ice > > > appear in supporting documentation." > >=20 > > Right, and so we need to fix these things up. > >=20 > > Felix, > >=20 > > Can you add the LICENSE file to the binary packages ? >=20 > Sure. I assume you mean programs/Xserver/hw/xfree86/doc/LICENSE? Yup. Thanks. Alan. |
From: Alan S. <sw...@uk...> - 2004-03-01 14:40:11
|
On Mon, 2004-03-01 at 13:37, Dieter N=FCtzel wrote: > Someone preparing a merge? To which release? The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo and most other distributions are not touching with a barge pole? Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? --=20 Alan. "One must never be purposelessnessnesslessness." |
From: Adam K K. <ad...@vo...> - 2004-03-01 14:47:20
|
On Mon, 1 Mar 2004, Alan Swanson wrote: > On Mon, 2004-03-01 at 13:37, Dieter N=FCtzel wrote: > > Someone preparing a merge? > > To which release? > > The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo > and most other distributions are not touching with a barge pole? The client libraries are still distributed under the old license, so there is no problem linking GPLed libraries or apps to the 4.4 libraries. Which means there is no longer a reason for those distributions not to include 4.4 any more. > Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? And, as I understand it, is so significantly different from the XFree86 codebase to make a merge rather, shall we say, pointless? Adam |
From: Alan S. <sw...@uk...> - 2004-03-01 15:52:09
|
On Mon, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: > On Mon, 1 Mar 2004, Alan Swanson wrote: > > The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo > > and most other distributions are not touching with a barge pole? >=20 > The client libraries are still distributed under the old license, so ther= e > is no problem linking GPLed libraries or apps to the 4.4 libraries. Whic= h > means there is no longer a reason for those distributions not to include > 4.4 any more. Unless there has been a new development, they're still not touching it. The DRI list has been free of any flame bait regarding X licensing, but I'm concerned with what happened and what multitude of projects/forks the DRI may have to support. > > Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? >=20 > And, as I understand it, is so significantly different from the XFree86 > codebase to make a merge rather, shall we say, pointless? I wasn't referring to the X Server project. --=20 Alan. "One must never be purposelessnessnesslessness." |
From: David D. <dawes@XFree86.Org> - 2004-03-01 18:27:48
|
On Mon, Mar 01, 2004 at 09:34:57AM -0500, Adam K Kirchhoff wrote: > >On Mon, 1 Mar 2004, Alan Swanson wrote: > >> On Mon, 2004-03-01 at 13:37, Dieter N=FCtzel wrote: >> > Someone preparing a merge? >> >> To which release? >> >> The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo >> and most other distributions are not touching with a barge pole? > >The client libraries are still distributed under the old license, so the= re >is no problem linking GPLed libraries or apps to the 4.4 libraries. Whi= ch >means there is no longer a reason for those distributions not to include >4.4 any more. If GPL compatibility is a concern for the DRI project, you will need to take a careful look at the SGI "Free Software B" licence that applies to the GLX code. It is not GPL compatible. The FSF doesn't even consider it Free Software (in spite of its name). Personally I think that the GLX licence not qualifying as Free Software (as defined by the FSF) is a serious problem, and one that needs to be addressed. If my recollection is correct, and Brian can probably correct me if I'm wrong, the GLX licence was understood at the time it was hammered out to be compatible with the Open Source Definition. However, I don't see any specific mention of it at www.opensource.org. David |
From: Alan C. <al...@lx...> - 2004-03-01 19:00:38
|
On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: > The client libraries are still distributed under the old license, so there > is no problem linking GPLed libraries or apps to the 4.4 libraries. Which > means there is no longer a reason for those distributions not to include > 4.4 any more. There are several reasons, including for example the X Vnc servers which also use GPL code in the server > > > Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? > > And, as I understand it, is so significantly different from the XFree86 > codebase to make a merge rather, shall we say, pointless? If someone plans to merge with 4.4 can you please tag the codebase just before so that everyone else can fork it too 8) |
From: David D. <dawes@XFree86.Org> - 2004-03-02 01:56:41
|
On Mon, Mar 01, 2004 at 06:44:38PM +0000, Alan Cox wrote: >On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: >> The client libraries are still distributed under the old license, so there >> is no problem linking GPLed libraries or apps to the 4.4 libraries. Which >> means there is no longer a reason for those distributions not to include >> 4.4 any more. > >There are several reasons, including for example the X Vnc servers which >also use GPL code in the server The GLX licence is problematic for this also, given that it is used in the server. Both the freedesktop.org and x.org trees also included this problematic GLX code last I checked. I think it would be good all around if each of these projects, including the DRI project, made a clear licensing policy statement. As everyone should know by now, you can't be a little bit GPL-incompatible. Either you are or you aren't. David |
From: <ke...@tu...> - 2004-03-02 02:58:10
|
> On Mon, Mar 01, 2004 at 06:44:38PM +0000, Alan Cox wrote: >>On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: >>> The client libraries are still distributed under the old license, so >>> there is no problem linking GPLed libraries or apps to the 4.4 >>> libraries. Which means there is no longer a reason for those >>> distributions not to include 4.4 any more. >> >>There are several reasons, including for example the X Vnc servers >> which also use GPL code in the server > > The GLX licence is problematic for this also, given that it is used in > the server. Both the freedesktop.org and x.org trees also > included this problematic GLX code last I checked. I think it > would be good all around if each of these projects, including the > DRI project, made a clear licensing policy statement. As everyone > should know by now, you can't be a little bit GPL-incompatible. > Either you are or you aren't. > It's certainly a can of worms. I'm not particularly interested in the subtle differences between licenses, but I can say that the GLX-licenced code doesn't have much to do with the DRI project in particular - I believe it came directly from SGI and their license has been maintained since then. All the changes from this project (to my knowledge) have been intended to fall under a license comparable to the older, previous, uncontentious XFree86 one. If there are issues with the continued use of the GLX code, the first step would be to approach SGI and request a change of license. I've no idea if this would be succesful or not. I've also no idea if it is necessary or not. I'll leave this up to others with more interest in licenses than I have. There was an independently-developed GLX implementation (Utah-GLX). If worst came to worst, that could be revived. I'm not at all convinced this is the case or will become the case. I'd like someone to convince me there was a problem before any actual steps are taken. Keith |
From: David D. <dawes@XFree86.Org> - 2004-03-02 03:34:18
|
On Mon, Mar 01, 2004 at 07:43:51PM -0700, ke...@tu... wrote: >> On Mon, Mar 01, 2004 at 06:44:38PM +0000, Alan Cox wrote: >>>On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote: >>>> The client libraries are still distributed under the old license, so >>>> there is no problem linking GPLed libraries or apps to the 4.4 >>>> libraries. Which means there is no longer a reason for those >>>> distributions not to include 4.4 any more. >>> >>>There are several reasons, including for example the X Vnc servers >>> which also use GPL code in the server >> >> The GLX licence is problematic for this also, given that it is used in >> the server. Both the freedesktop.org and x.org trees also >> included this problematic GLX code last I checked. I think it >> would be good all around if each of these projects, including the >> DRI project, made a clear licensing policy statement. As everyone >> should know by now, you can't be a little bit GPL-incompatible. >> Either you are or you aren't. >> > >It's certainly a can of worms. I'm not particularly interested in the >subtle differences between licenses, but I can say that the GLX-licenced >code doesn't have much to do with the DRI project in particular - I >believe it came directly from SGI and their license has been maintained >since then. All the changes from this project (to my knowledge) have >been intended to fall under a license comparable to the older, previous, >uncontentious XFree86 one. If there are issues with the continued use of >the GLX code, the first step would be to approach SGI and request a change >of license. I've no idea if this would be succesful or not. I've also no >idea if it is necessary or not. I'll leave this up to others with more >interest in licenses than I have. > >There was an independently-developed GLX implementation (Utah-GLX). If >worst came to worst, that could be revived. I'm not at all convinced this >is the case or will become the case. > >I'd like someone to convince me there was a problem before any actual >steps are taken. It matters mostly if GPL-compatibility of the X server code is a concern. Given how the strict interpretation of the GPL works, you only need one piece of non-compatible code in a program for the whole to be non-compatible. Also with the strict interpretation, no GPL'd application could link with a libGL that included GPL-incompatible code. I happen to disagree with the ideas behind the GPL's definition of derivative works, but that's neither here nor there. I would expect all of this to be a non-issue for the DRI Project, particularly given that binary-only drivers or driver components from vendors present exactly the same issues when it comes to the X server and GL apps. Obviously GPL-compatibility of the X server code is also a non-issue as far as I am concerned. I'm just pointing out that if the new XFree86 licence is considered problematic because it makes the X server GPL-incompatible, then SGI's GLX licence is also problematic for the same reason. I'm personally more concerned that SGI's GLX licence doesn't meet the FSF's Free Software definition, but that is something that I intend to follow up elsewhere. If all of this licence stuff makes you feel nauseous, then I know how you feel... David |
From: Michel <mi...@da...> - 2004-03-01 16:41:07
|
On Mon, 2004-03-01 at 15:27, Alan Swanson wrote: > On Mon, 2004-03-01 at 13:37, Dieter Nützel wrote: > > Someone preparing a merge? > > To which release? > > The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo > and most other distributions are not touching with a barge pole? > > Or the old license with 4.4 RC2 fork that is somewhere on freedesktop? For my part, I'd certainly prefer staying clear of the silly new license. In the long run, I'd vote for moving the DRI X server code to a freedesktop.org X server tree and the libGL code to Mesa or its own xlibs module. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Michel <mi...@da...> - 2004-03-01 17:41:22
|
On Mon, 2004-03-01 at 17:28, Michel Dänzer wrote: > > For my part, I'd certainly prefer staying clear of the silly new > license. In the long run, I'd vote for moving the DRI X server code to a > freedesktop.org X server tree and the libGL code to Mesa or its own > xlibs module. I should probably clarify that I would have voted for that even without the license change. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Alan C. <al...@lx...> - 2004-03-01 19:01:53
|
On Llu, 2004-03-01 at 16:28, Michel D=C3=A4nzer wrote: > For my part, I'd certainly prefer staying clear of the silly new > license. In the long run, I'd vote for moving the DRI X server code to a > freedesktop.org X server tree and the libGL code to Mesa or its own > xlibs module. I'd definitely like to see this, and perhaps closer CVS integration so that DRI work can be done as a branch on the x.org tree not in a seperate tree. Assuming all the relevant powers that be can make it happen anyway Alan |
From: Mike A. H. <mh...@ww...> - 2004-03-02 08:16:48
|
On Mon, 1 Mar 2004, Alan Cox wrote: >On Llu, 2004-03-01 at 16:28, Michel D=C3=A4nzer wrote: >> For my part, I'd certainly prefer staying clear of the silly new >> license. In the long run, I'd vote for moving the DRI X server code to a >> freedesktop.org X server tree and the libGL code to Mesa or its own >> xlibs module. > >I'd definitely like to see this, and perhaps closer CVS integration so >that DRI work can be done as a branch on the x.org tree not in a >seperate tree. Assuming all the relevant powers that be can make it >happen anyway Yeah, I agree with that also. The X.org tree aims to be a much=20 more open community project. The recent reformation of X.org=20 into "The X.org Foundation" has brought with it a change in the=20 governance structure, and there are new intirim board members=20 present which make up a good cross section of the community=20 projects which use X technology as a base to build upon. The current plan is to have the tree develop in a way that is=20 rather very similar to the DRI project's tree. In fact, I am=20 proposing that we adopt the DRI CVS guidelines in the X.org tree,=20 and the rather liberal CVS access. There's more to it than that=20 as well, but all things aren't all worked out quite yet. I believe that once the X.org tree is "off the ground" so to=20 speak, that it would make sense to discuss the possibilities of=20 merging the trees at some point. I think it would be infinitely=20 beneficial for both projects to have closer integration for=20 numerous reasons, and would foster closer collaboration,=20 between the DRI and the core, since the two owuld essentially=20 become one and the same. It is probably a bit premature for now to make any solid=20 decisions though, but in the next few weeks/months things should=20 take shape. --=20 Mike A. Harris |
From: Keith W. <ke...@tu...> - 2004-03-08 19:47:30
|
Mike A. Harris wrote: > On Mon, 1 Mar 2004, Alan Cox wrote: > > >>On Llu, 2004-03-01 at 16:28, Michel Dänzer wrote: >> >>>For my part, I'd certainly prefer staying clear of the silly new >>>license. In the long run, I'd vote for moving the DRI X server code to a >>>freedesktop.org X server tree and the libGL code to Mesa or its own >>>xlibs module. >> >>I'd definitely like to see this, and perhaps closer CVS integration so >>that DRI work can be done as a branch on the x.org tree not in a >>seperate tree. Assuming all the relevant powers that be can make it >>happen anyway > > > Yeah, I agree with that also. The X.org tree aims to be a much > more open community project. The recent reformation of X.org > into "The X.org Foundation" has brought with it a change in the > governance structure, and there are new intirim board members > present which make up a good cross section of the community > projects which use X technology as a base to build upon. > > The current plan is to have the tree develop in a way that is > rather very similar to the DRI project's tree. In fact, I am > proposing that we adopt the DRI CVS guidelines in the X.org tree, > and the rather liberal CVS access. There's more to it than that > as well, but all things aren't all worked out quite yet. > > I believe that once the X.org tree is "off the ground" so to > speak, that it would make sense to discuss the possibilities of > merging the trees at some point. I think it would be infinitely > beneficial for both projects to have closer integration for > numerous reasons, and would foster closer collaboration, > between the DRI and the core, since the two owuld essentially > become one and the same. > > It is probably a bit premature for now to make any solid > decisions though, but in the next few weeks/months things should > take shape. I don't have any in-principle objections to this, though I'd like to get more of a feel for the "new X.org" before committing to anything... Will the X.org tree include all the XFree86 DDX code - we obviously rely on that as well as the core DRI protocol stuff. Keith |
From: Keith P. <ke...@ke...> - 2004-03-08 20:46:36
|
Around 19 o'clock on Mar 8, Keith Whitwell wrote: > I don't have any in-principle objections to this, though I'd like to get > more of a feel for the "new X.org" before committing to anything. That seems sensible. I don't think there's any particular urgency here, nothing related to DRI will likely change radically anytime soon. > Will the X.org tree include all the XFree86 DDX code - we obviously rely on > that as well as the core DRI protocol stuff. Yes. Right now, the X.org tree is serving as a place for developers and distributors to collaboratively support an X tree that is essentially identical to XFree86 4.4, but without the new license and the (very small) amount of code published only under that license. Stablizing the tree and getting something shipping that people can distribute is the first priority. I'm sure lots of people would like to see Mesa/DRI development more closely tied to X driver development so that there wasn't this 'big merge' problem to face every few months. Precisely how that should work is something we can figure out in time. One key is to split responsibilities across stable interfaces so that we can ship modern drivers into existing distributions. Of course, my own hope is that X turns into a simple GL application and all of the hardware management becomes someone else's problem... -keith |
From: Andy I. <ad...@bi...> - 2004-03-09 20:00:31
|
On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote: > Stablizing the tree and getting something shipping that people can > distribute is the first priority. I'm sure lots of people would like to > see Mesa/DRI development more closely tied to X driver development so that > there wasn't this 'big merge' problem to face every few months. > > Precisely how that should work is something we can figure out in time. One > key is to split responsibilities across stable interfaces so that we can > ship modern drivers into existing distributions. I feel a little bit like a shill here, but I figure I should throw out my two cents. First, a disclaimer: I work for BitMover but I do not set company policy; if you need to get The Official Word on things regarding BitMover or BK, you should talk to <sa...@bi...>. The Big Merge Problem is one of the places where BK is really excellent. It's best if everybody (or at least the central repositories) use BK directly, but even if BK is only used by users on the periphery or by just one of two centers of development, it can make merges exponentially easier compared to CVS. (Of course it's the BK users who reap the benefits, for the most part...) If DRI and X.Org both maintained BK repositories, it would be *really* easy to handle merges back and forth. Even if just one of them maintains a BK repository and the other remains on CVS, BK can allow merges to be done much more easily than CVS (although there can be some black magic there). It seems to me that using BK could really improve the state of X development. The downside, of course, is that the BKL (the license under which BitKeeper is available to Open Source contributors) is unacceptable to some developers. It's possible for a "gatekeeper" team of BK users to accept patches by email, and it's possible to make a BK repository available as CVS, so if a majority of developers were willing to agree to the BKL, I don't think that a small number of BKL-objecting developers would necessarily be a showstopper -- so long as the community as a whole can agree, and no contributors feel excluded. -andy |
From: Keith W. <ke...@tu...> - 2004-03-09 22:58:38
|
Andy Isaacson wrote: > On Mon, Mar 08, 2004 at 12:29:05PM -0800, Keith Packard wrote: > >>Stablizing the tree and getting something shipping that people can >>distribute is the first priority. I'm sure lots of people would like to >>see Mesa/DRI development more closely tied to X driver development so that >>there wasn't this 'big merge' problem to face every few months. >> >>Precisely how that should work is something we can figure out in time. One >>key is to split responsibilities across stable interfaces so that we can >>ship modern drivers into existing distributions. > > > I feel a little bit like a shill here, but I figure I should throw out > my two cents. First, a disclaimer: I work for BitMover but I do not set > company policy; if you need to get The Official Word on things regarding > BitMover or BK, you should talk to <sa...@bi...>. For DRI at least, it's been discussed & rejected. Keith |
From: Michel <mi...@da...> - 2004-03-09 23:27:39
|
On Tue, 2004-03-09 at 23:40, Keith Whitwell wrote: > Andy Isaacson wrote: > > > > I feel a little bit like a shill here, but I figure I should throw out > > my two cents. First, a disclaimer: I work for BitMover but I do not set > > company policy; if you need to get The Official Word on things regarding > > BitMover or BK, you should talk to <sa...@bi...>. > > For DRI at least, it's been discussed & rejected. And in the meantime, several free alternatives have become viable, should we ever decide that CVS no longer suits our needs. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer |
From: Andy I. <ad...@he...> - 2004-03-10 00:09:47
|
[responding from my personal account to avoid the subscriber-only filter] On Tue, Mar 09, 2004 at 10:40:28PM +0000, Keith Whitwell wrote: > Andy Isaacson wrote: > > [perhaps DRI / fd.o should consider BitKeeper] > > For DRI at least, it's been discussed & rejected. My apologies for bringing up a topic that's been hashed out already. I did search the archives, but obviously didn't use the right search key... and now that I found it, I do recall the discussion. -andy |