RE: Request for comments - Microwindows
The item you swapped, in the original license, would have gone to Shaun. In the new license, your "gift" of code would go to the Allegro Source Base. -- "It's not about the money...It's about the rules. Without rules, we might as well be tree climbers flinging crap at each other." - Red Foreman of That '70s Show On Wed, 6 Oct 1999, Scott Lanning wrote: > Alex Holden wrote [regarding Allegro graphics lib]: > >As I said, it is now. Get the latest version (3.12), read the > >license. I believe Shawn decided to abandon the original "swapware" > >license as it was needlessly preventing Allegro's use in some > >situations. > > Also because he no longer is the only one writing the code; i.e., > who would you give the "gift" to? --Scott > >
RE: Request for comments - Microwindows
Alex Holden wrote [regarding Allegro graphics lib]: >As I said, it is now. Get the latest version (3.12), read the >license. I believe Shawn decided to abandon the original "swapware" >license as it was needlessly preventing Allegro's use in some >situations. Also because he no longer is the only one writing the code; i.e., who would you give the "gift" to? --Scott
RE: Request for comments - Microwindows
On Tue, 5 Oct 1999, Louis P. Santillan wrote: > The restrictions of not being able to produce a binary w/o code/obj files > has already been mentioned as a restriction. BSD is an attractive way of > getting around it. As far as I know, Allegro has never been truly PD. > Formally Swapware or at least give me a copy of your autoexec.bat and now > Giftware or add something to the code base if you use it and if you can. > In a sense, Allegro is PD...but not completely free. As I said, it is now. Get the latest version (3.12), read the license. I believe Shawn decided to abandon the original "swapware" license as it was needlessly preventing Allegro's use in some situations. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Tue, 5 Oct 1999, Alan Cox wrote: > This is going on far too long and round in circles. Greg and Alex - pick > something, stick a license on it all , say so publically and be done. It > does more harm now than whichever is picked Right, I vote for MPL with a "convert to GPL/LGPL" option, with David's original code retaining it's current Public Domain license. Vidar has already said he's happy with that. Greg? --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
RE: Request for comments - Microwindows
The restrictions of not being able to produce a binary w/o code/obj files has already been mentioned as a restriction. BSD is an attractive way of getting around it. As far as I know, Allegro has never been truly PD. Formally Swapware or at least give me a copy of your autoexec.bat and now Giftware or add something to the code base if you use it and if you can. In a sense, Allegro is PD...but not completely free. -- "It's not about the money...It's about the rules. Without rules, we might as well be tree climbers flinging crap at each other." - Red Foreman of That '70s Show On Tue, 5 Oct 1999, Alex Holden wrote: > On Mon, 4 Oct 1999, Louis P. Santillan wrote: > > A few more logs for the flame (err...thread), BSD and Dave's original > > license? Maybe even a NASM type license, short and sweet, with > > restrictions against those who would like to use the code for commercial > > purposes. IMHO, the GPL and LGPL are too detailed and too restrictive. > > What kind of restrictions? > > > People who enjoy the code should use the code. Maybe those who have evil > > commercial purposes should be punished, but they should not be completely > > prejudiced against. I think the intent is to make the Nano/Micro series > > a standard for small systems. I also like Allegro's gift society type > > license though it may not be restrictive enough for some. > > The latest version of Allegro is now fully Public Domain. >
Re: Request for comments - Microwindows
> Actually, the BSD and X licenses best reflect the needs of embedded > developers. The X one does. The BSD original format doesnt. The advertising clause got a netbsd router project by a very large networking company canned
Re: Request for comments - Microwindows
On Tue, 5 Oct 1999, Alan Cox wrote: > The MPL is also the only one that sanely reflects embedded system licensing Actually, the BSD and X licenses best reflect the needs of embedded developers. Jamie
RE: Request for comments - Microwindows
On Mon, 4 Oct 1999, Louis P. Santillan wrote: > A few more logs for the flame (err...thread), BSD and Dave's original > license? Maybe even a NASM type license, short and sweet, with > restrictions against those who would like to use the code for commercial > purposes. IMHO, the GPL and LGPL are too detailed and too restrictive. What kind of restrictions? > People who enjoy the code should use the code. Maybe those who have evil > commercial purposes should be punished, but they should not be completely > prejudiced against. I think the intent is to make the Nano/Micro series > a standard for small systems. I also like Allegro's gift society type > license though it may not be restrictive enough for some. The latest version of Allegro is now fully Public Domain. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > Why give up your right to release source code? Why not tell that vendor > "I'll sign and NDA, but only with the condition that I can release my work > open-source." I have. That's what we usually try. If you're only a small company making less than a few thousand units, it often doesn't work. There's also the situation of large closed source software systems too- for example you can license the code to decent voice recognition software... You can't easily reverse engineer something like that- it's easier to spend a few months or years writing it again. In the case of a company, it's much cheaper to spend say $2 licensing some closed source code than it is to have a team of developers spend a year or so rewriting it from scratch. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
> So - we don't _have_ to separate any code. David's original > code is available on Alex's and my ftp server. Correct? Correct
Re: Request for comments - Microwindows
This is going on far too long and round in circles. Greg and Alex - pick something, stick a license on it all , say so publically and be done. It does more harm now than whichever is picked I've been through the licenses with respect to embedded system issues o GPL Means people can't provide nonfree apps of any kind using nanogui without writing a nonfree library clone. The only one that stops users writing binary only extensions/modules. o LGPLMeans people can build apps and servers with some non free components and programs. This still causes big problems for some standard embedded uses - DVD is the big one. The rules on protecting the DVD crypto are draconic and not the vendors fault. Only when the DVD cracking is finished would they go away. o MPL Easier than (L)GPL to add private extensions. Doesn't require relinkable object modules and the like. Does require source is made available to MPL'd modules The MPL is also the only one that sanely reflects embedded system licensing because it doesn't require written offers of media which are difficult to manage but instead requires the source is somewhere publically available - eg for FTP. Alan
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > However, it does appear to kill the static model, but ONLY FOR NON-FREE > ROGRAMS. Free programs could still use the static model just fine, and > non-free programs could still use the client/server model, since the client > side is LGPL. But the static model is probably targeted the most at embedded projects. These tend to be non-free, often for practical reasons. I think it is better to get a shoe through the embedded door, rather than not at all. Just my SKR 0.05 Jakob
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 19:52:51 -0400 you wrote: >> At the very least >> the server needs to be LGPL'd, preferrably MPL'd, or as Alex suggested >> MPL'd with an added provision for users to do a one way conversion to >> GPL/LGPL. > >The server needs? I don't need it. Who here needs it? Or are we trying >to accomodate hypothetical users? My hope would be that we'd try to accomodate the typical embedded systems developers. If you believe you can get people to use NanoGUI for that type of projects without being able to link proprietary code, fine. But I wouldn't count on it - I know of more than enough of people considering NanoGUI for platforms that doesn't support dynamic linking or networking, and that require third party code that they'd never be allowed to link to GPL'd or LGPL'd code by the companies they've licensed code from. >> In that case I'll have to start evaluating other systems for my work, >> since it was a hard enough sell to go for the MPL for some of our >partners. > >The only thing is you can't use proprietary drivers in the server. Does >that mean that you have to stop contributing to the LGPL client side, or >abandon Micro* completely? You could (I imagine very easily) derive a new >server for the proprietary hardware from the same original sources, but >still use the LGPL Micro* client side non-statically linked. As I've said time and time again, we have partners that would make it problematic enough that, yes, it would likely make economic sense for us to stop contributing to NanoGUI/MicroWindows completely, and abandon it completely in favor of a less restricted system. Also, it seems that maybe you are confusing the client and server side in the above paragraph. It is the server that contain all of the logic. The client side is only a small set of functions to connect to the server via Unix domain sockets, and send request and read responses. Which makes it even more silly to use a restrictive license on it. Also remember that not all systems people might want to use it under may even support dynamic linking. If the server is under the LGPL it will still be usable for us. However I'd still prefer a less restrictive license for the server as well, or dual licensing, since it might attract a larger audience in the embedded/ small systems world, which i currently _very_ tied up in proprietary systems. >Are we going to cater to proprietary interests or create a completely >open-source system? And if we don't create it open-source, how long will >it be before MicroFree* comes along? We're hopefully creating a completely open source system. But that doesn't require a license that precludes people to link proprietary code to it. I would hope that we would cater to the interest of those most likely to use NanoGUI in embedded and small systems projects: embedded and small systems developers. In that case, you'll meet countless problems with a restrictive license. Vidar.
RE: Request for comments - Microwindows
On Monday, October 04, 1999 4:55 PM, Louis P. Santillan [SMTP:[EMAIL PROTECTED]] wrote: : Maybe those who have evil : commercial purposes should be punished, but they should not be completely : prejudiced against. I think the intent is to make the Nano/Micro series : a standard for small systems. nano/micro will never be a standard with an attitude against commercial interests. I'm certainly not against commercial interests. I'm very much into commercial interests. However, I'm not necessarily doing microwindows for money. I'm doing it for fun, to give back what I've taken from the community over the past 20 years, and I want to build a graphics system! Greg
RE: Request for comments - Microwindows
: > We'd have to seperate the code which requires David's public domain : > license into seperate files to the code which is under MPL though. : : That is good practice. David wanted his original code to be totally : free. Lets make it easy for people to use it that way Alan, I thought you said that nano-X/microwindows was a derivative work, and thus another license can be put upon it. David's code has no restrictions on derivative works, as long as his copyright remains intact. Alex, your and my revisions are completely new work. We are debating a [L][GM]PL license for the derivative work. So - we don't _have_ to separate any code. David's original code is available on Alex's and my ftp server. Correct?
Re: Request for comments - Microwindows
- Original Message - From: Vidar Hokstad <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 6:59 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999 17:32:09 -0400 you wrote: > >I think that GPL is the answer for the server part. > > Then you've killed the static linking potential for a lot of developers, > who will then likely look to other projects instead. I haven't yet heard anyone here say that they need to link proprietary code to the static model. > At the very least > the server needs to be LGPL'd, preferrably MPL'd, or as Alex suggested > MPL'd with an added provision for users to do a one way conversion to > GPL/LGPL. The server needs? I don't need it. Who here needs it? Or are we trying to accomodate hypothetical users? > >Do we believe in this thing or not? I do. > > > >Are we willing to reverse engineer a few devices? Are we willing to have > >to > >write some extra code now and then? I am. > > > >So let's just take a deep breath, GPL the server part, go forward, and not > >look back. > > > >As for the client part, same thing execpt add an L before the GPL. > > In that case I'll have to start evaluating other systems for my work, > since it was a hard enough sell to go for the MPL for some of our partners. The only thing is you can't use proprietary drivers in the server. Does that mean that you have to stop contributing to the LGPL client side, or abandon Micro* completely? You could (I imagine very easily) derive a new server for the proprietary hardware from the same original sources, but still use the LGPL Micro* client side non-statically linked. Are we going to cater to proprietary interests or create a completely open-source system? And if we don't create it open-source, how long will it be before MicroFree* comes along? Regards, Brad
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 17:32:09 -0400 you wrote: >I think that GPL is the answer for the server part. Then you've killed the static linking potential for a lot of developers, who will then likely look to other projects instead. At the very least the server needs to be LGPL'd, preferrably MPL'd, or as Alex suggested MPL'd with an added provision for users to do a one way conversion to GPL/LGPL. >Do we believe in this thing or not? I do. > >Are we willing to reverse engineer a few devices? Are we willing to have >to >write some extra code now and then? I am. > >So let's just take a deep breath, GPL the server part, go forward, and not >look back. > >As for the client part, same thing execpt add an L before the GPL. In that case I'll have to start evaluating other systems for my work, since it was a hard enough sell to go for the MPL for some of our partners. Vidar.
RE: Request for comments - Microwindows
A few more logs for the flame (err...thread), BSD and Dave's original license? Maybe even a NASM type license, short and sweet, with restrictions against those who would like to use the code for commercial purposes. IMHO, the GPL and LGPL are too detailed and too restrictive. People who enjoy the code should use the code. Maybe those who have evil commercial purposes should be punished, but they should not be completely prejudiced against. I think the intent is to make the Nano/Micro series a standard for small systems. I also like Allegro's gift society type license though it may not be restrictive enough for some. -- "It's not about the money...It's about the rules. Without rules, we might as well be tree climbers flinging crap at each other." - Red Foreman of That '70s Show On Mon, 4 Oct 1999, Gregory Leblanc wrote: > I've been kind of following this thread, since it's fascinating. Anyway, I > know the GPL, and I've read the LGPL a couple of times, but I can't find > this other one, MPL. Any pointers? > > > -Original Message- > > From: Bradley D. LaRonde [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 04, 1999 2:32 PM > > To: Alex Holden > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: Request for comments - Microwindows > > > > > > > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > > > So if I'm understanding you right, you are saying that we > > might have an > > > > opportunity with Micro* to do something similar, but only > > if we GPL the > > > > server part (or maybe LGPL?), but definately not MPL it. > > Is that right? > > > > > > Because of the restrictive nature of the GPL, you can't legally link > > > proprietory code into it. The Linux kernel on Intel PCs, > > with millions of > > > potential users, is just starting to become popular enough > > that we can > > > actually force some hardware vendors to release specs to > > allow a GPLed > > > driver to be written, or to even write a GPLed driver > > themselves. Up till > > > fairly recently, and with less common hardware, this didn't > > usually work, > > > and a lot of hardware had to be reverse engineered. > > > > I don't mind reverse engineering something. The tempting > > thing is when a > > vender says they'll give you the specs but you can't release > > anything but a > > binary. That is something to avoid IMO. Maybe it is better > > to reverse > > engineer it than to cave to the vendor's desires. > > > > Why give up your right to release source code? Why not tell > > that vendor > > "I'll sign and NDA, but only with the condition that I can > > release my work > > open-source." I have. > > Agreed. If we have to reverse engineer some drivers, so be it. But we > should demand that our work can be released GPL'd. > > > > > > How long do you think > > > it'll be before Nano-X on Foo obscure Palmtop or embedded system has > > > enough millions of users for a hardware manufacturer to be > > forced into > > > releasing a GPLed driver or specs for somebody to write a > > GPLed driver for > > > it? Roughly never? > > > > If Linux was guided from the start by that thinking, it may > > never have made > > it to that point either. > > > > I think that GPL is the answer for the server part. > > > > Do we believe in this thing or not? I do. > > > > Are we willing to reverse engineer a few devices? Are we > > willing to have to > > write some extra code now and then? I am. > > > > So let's just take a deep breath, GPL the server part, go > > forward, and not > > look back. > > > > As for the client part, same thing execpt add an L before the GPL. > > > > Regards, > > Brad > > >
RE: Request for comments - Microwindows
I've been kind of following this thread, since it's fascinating. Anyway, I know the GPL, and I've read the LGPL a couple of times, but I can't find this other one, MPL. Any pointers? > -Original Message- > From: Bradley D. LaRonde [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 04, 1999 2:32 PM > To: Alex Holden > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Request for comments - Microwindows > > > > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > > So if I'm understanding you right, you are saying that we > might have an > > > opportunity with Micro* to do something similar, but only > if we GPL the > > > server part (or maybe LGPL?), but definately not MPL it. > Is that right? > > > > Because of the restrictive nature of the GPL, you can't legally link > > proprietory code into it. The Linux kernel on Intel PCs, > with millions of > > potential users, is just starting to become popular enough > that we can > > actually force some hardware vendors to release specs to > allow a GPLed > > driver to be written, or to even write a GPLed driver > themselves. Up till > > fairly recently, and with less common hardware, this didn't > usually work, > > and a lot of hardware had to be reverse engineered. > > I don't mind reverse engineering something. The tempting > thing is when a > vender says they'll give you the specs but you can't release > anything but a > binary. That is something to avoid IMO. Maybe it is better > to reverse > engineer it than to cave to the vendor's desires. > > Why give up your right to release source code? Why not tell > that vendor > "I'll sign and NDA, but only with the condition that I can > release my work > open-source." I have. Agreed. If we have to reverse engineer some drivers, so be it. But we should demand that our work can be released GPL'd. > > > How long do you think > > it'll be before Nano-X on Foo obscure Palmtop or embedded system has > > enough millions of users for a hardware manufacturer to be > forced into > > releasing a GPLed driver or specs for somebody to write a > GPLed driver for > > it? Roughly never? > > If Linux was guided from the start by that thinking, it may > never have made > it to that point either. > > I think that GPL is the answer for the server part. > > Do we believe in this thing or not? I do. > > Are we willing to reverse engineer a few devices? Are we > willing to have to > write some extra code now and then? I am. > > So let's just take a deep breath, GPL the server part, go > forward, and not > look back. > > As for the client part, same thing execpt add an L before the GPL. > > Regards, > Brad >
Re: Request for comments - Microwindows
- Original Message - From: Alex Holden <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 5:01 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > So if I'm understanding you right, you are saying that we might have an > > opportunity with Micro* to do something similar, but only if we GPL the > > server part (or maybe LGPL?), but definately not MPL it. Is that right? > > Because of the restrictive nature of the GPL, you can't legally link > proprietory code into it. The Linux kernel on Intel PCs, with millions of > potential users, is just starting to become popular enough that we can > actually force some hardware vendors to release specs to allow a GPLed > driver to be written, or to even write a GPLed driver themselves. Up till > fairly recently, and with less common hardware, this didn't usually work, > and a lot of hardware had to be reverse engineered. I don't mind reverse engineering something. The tempting thing is when a vender says they'll give you the specs but you can't release anything but a binary. That is something to avoid IMO. Maybe it is better to reverse engineer it than to cave to the vendor's desires. Why give up your right to release source code? Why not tell that vendor "I'll sign and NDA, but only with the condition that I can release my work open-source." I have. > How long do you think > it'll be before Nano-X on Foo obscure Palmtop or embedded system has > enough millions of users for a hardware manufacturer to be forced into > releasing a GPLed driver or specs for somebody to write a GPLed driver for > it? Roughly never? If Linux was guided from the start by that thinking, it may never have made it to that point either. I think that GPL is the answer for the server part. Do we believe in this thing or not? I do. Are we willing to reverse engineer a few devices? Are we willing to have to write some extra code now and then? I am. So let's just take a deep breath, GPL the server part, go forward, and not look back. As for the client part, same thing execpt add an L before the GPL. Regards, Brad
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > So if I'm understanding you right, you are saying that we might have an > opportunity with Micro* to do something similar, but only if we GPL the > server part (or maybe LGPL?), but definately not MPL it. Is that right? Because of the restrictive nature of the GPL, you can't legally link proprietory code into it. The Linux kernel on Intel PCs, with millions of potential users, is just starting to become popular enough that we can actually force some hardware vendors to release specs to allow a GPLed driver to be written, or to even write a GPLed driver themselves. Up till fairly recently, and with less common hardware, this didn't usually work, and a lot of hardware had to be reverse engineered. How long do you think it'll be before Nano-X on Foo obscure Palmtop or embedded system has enough millions of users for a hardware manufacturer to be forced into releasing a GPLed driver or specs for somebody to write a GPLed driver for it? Roughly never? --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > It's both less restrictive and designed to apply to anything; not just a > > library with a well defined interface API. > This is a library we are talking about here, right? No, a graphics server application. > So I get to grant who, Greg, you, who? the right to use my improvements in > their own proprietary Micro*. Doesn't sound good to me. And I get to have Proprietory in what way? Because they can sell it? You can sell GPLed programs too, and the GPLed code and any changes made to it remain available in the same way that MPLed code and any changes made to it remain available. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
- Original Message - From: Alan Cox <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 4:30 PM Subject: Re: Request for comments - Microwindows > > > In the longer term XFree86 has gained by the fact vendors wont ship binary > > > only kit. Its now at the point that 'Linux' is a question big vendors ask > > > and that 'no' costs you bulk sales > > > > I don't understand. What do you mean? > > "I want to make Linux support an XYZ card" > "Im sorry we only allow binary drivers" > "oh goodbye" > > [nowdays] > > "Hi majorvendor foo purchasing here we want to source 50,000 XYZ cards" > "Oh great yes, expenses paid lunch coming right up" > "We do want Linux support as we may be certifying our stuff for Linux" > "Oh.. umm. I need to talk to the boss" > > And vendors are changing policy for these kind of reasons So if I'm understanding you right, you are saying that we might have an opportunity with Micro* to do something similar, but only if we GPL the server part (or maybe LGPL?), but definately not MPL it. Is that right? Regards, Brad
Re: Request for comments - Microwindows
> > In the longer term XFree86 has gained by the fact vendors wont ship binary > > only kit. Its now at the point that 'Linux' is a question big vendors ask > > and that 'no' costs you bulk sales > > I don't understand. What do you mean? "I want to make Linux support an XYZ card" "Im sorry we only allow binary drivers" "oh goodbye" [nowdays] "Hi majorvendor foo purchasing here we want to source 50,000 XYZ cards" "Oh great yes, expenses paid lunch coming right up" "We do want Linux support as we may be certifying our stuff for Linux" "Oh.. umm. I need to talk to the boss" And vendors are changing policy for these kind of reasons
Re: Request for comments - Microwindows
- Original Message - From: Alan Cox <[EMAIL PROTECTED]> To: Vidar Hokstad <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 4:13 PM Subject: Re: Request for comments - Microwindows > > >people will be able to hide drivers from us, as I think this has the > > >potential to seriously injure Micro*'s open-source value. > > > > So has the lack of support for on devices where specs simply aren't openly > > available. > > In the longer term XFree86 has gained by the fact vendors wont ship binary > only kit. Its now at the point that 'Linux' is a question big vendors ask > and that 'no' costs you bulk sales I don't understand. What do you mean? Regards, Brad
Re: Request for comments - Microwindows
- Original Message - From: Vidar Hokstad <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 4:08 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999 15:55:50 -0400 you wrote: > >- Original Message - > >From: Alex Holden <[EMAIL PROTECTED]> > >To: Bradley D. LaRonde <[EMAIL PROTECTED]> > >Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > >Sent: Monday, October 04, 1999 3:40 PM > >Subject: Re: Request for comments - Microwindows > > > > > >> On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > >> > This is an idea, but why? Doesn't MPL completely kill any GPL benefit? > >Why > >> > would someone choose to use it under GPL when they can use it under MPL? > >> > >> Because they want to borrow some of our code, but are stuck with code > >> which is GPLed (you can't mix MPLed code in with GPLed code because of the > >> restrictive nature of the GPL). > > > >So why not use LGPL? IOW, why use MPL instead of LGPL? > > Because, as I've said multiple times now, the LGPL is too restrictive > for a potentially large part of the people who would otherwise be > interested in contributing and using this code. But you have never said HOW LGPL is too restrictive. How is LGPL more restrictive than MPL, and why is that significant to you? > In an ideal world everyone would be able to accept open source code, > but the world isn't ideal. It would limit our interest in this project > dramatically if we would be limited from using third party code which > we can't control licensing of because of license issues. How is LGPL a problem with that? > It would probably > mean I'd be redirected to do my widget set development for another system > for instance, or it might mean we'd have to fork the tree and keep working > on a less restricted version. Of course we don't want that to happen. But how will LGPL make that happen and MPL prevent it? Regards, Brad
Re: Request for comments - Microwindows
> >people will be able to hide drivers from us, as I think this has the > >potential to seriously injure Micro*'s open-source value. > > So has the lack of support for on devices where specs simply aren't openly > available. In the longer term XFree86 has gained by the fact vendors wont ship binary only kit. Its now at the point that 'Linux' is a question big vendors ask and that 'no' costs you bulk sales
Re: Request for comments - Microwindows
>> That depends on what you consider the benefit of the GPL in this case. >> It would allow people to write GPL'd programs with it, and to user GPL'd >> code in their applications, *OR* to link it to non-free programs (using >> the server under the MPL). > >I don't think that I understand what you mean. The licensing of a library >does never prevent me from licesing my code under GPL. Then I suggest you reread the GPL. The GPL requires that any code you link with GPL'd code be either licensed under the GPL or under a license that add no restrictions beyond what the GPL adds. The MPL is incompatible with the GPL, and if you link GPL'd and MPL'd code, you are violating the GPL. >> The MPL allow static linking without releasing object code. It >> also allows non-free additions to the project (read: drivers for hardware >> where specs are only available under NDA), as long as they are in separate >files. > >Wouldn't an LGPL'ed server part allow proprietary drivers too? I don't see >the benefit of MPL here. Yes, that's true, as long as it's available in object form. However, not everyone wants to make their code available in object form, but might be willing to release a server binary with the driver compiled in. >And I can see your business reason for the client being LGPL (so that you >can link it from proprietary programs). > >I still do not understand your need for MPL at all. As mentioned time after time: The LGPL is *NOT ENOUGH* for some of the third parties we might license code from, since they *won't* allow their code to be released even in object form, which is a requirement if the client libraries are LGPL'd (you are required to make your code available in a form that let anyone relink the non-LGPL'd and LGPL'd parts). >I do not at all like the fact that if the server side is under LGPL then >people will be able to hide drivers from us, as I think this has the >potential to seriously injure Micro*'s open-source value. So has the lack of support for on devices where specs simply aren't openly available. Regards, Vidar
Re: Request for comments - Microwindows
- Original Message - From: Alex Holden <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 3:57 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > So why not use LGPL? IOW, why use MPL instead of LGPL? > > It's both less restrictive and designed to apply to anything; not just a > library with a well defined interface API. This is a library we are talking about here, right? > It's also more sensibly > designed (try reading them both and comparing them side by side- I did), > and has passed a review by qualified solicitors (at Netscape). The FSF > really seem to have the opinion that all code should be available under > the GPL or not at all, and the LGPL is intentionally awkward to apply to > anything other than a straight "link it in and it provides these > functions" library to encourage people not to use it for anything else. > The MPL is a much more elegant solution to the problem where you want to > be able to link proprietory code to free code, and keep the free code free > (and contribute improvements to it back) without having to release the > proprietory code under the same license. So I get to grant who, Greg, you, who? the right to use my improvements in their own proprietary Micro*. Doesn't sound good to me. And I get to have this priveledge for what? A more readable license and a conjecture that it may be more legally sound? I'm not convinced that MPL is better than LGPL for those reasons. Regards, Brad
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > So why not use LGPL? IOW, why use MPL instead of LGPL? It's both less restrictive and designed to apply to anything; not just a library with a well defined interface API. It's also more sensibly designed (try reading them both and comparing them side by side- I did), and has passed a review by qualified solicitors (at Netscape). The FSF really seem to have the opinion that all code should be available under the GPL or not at all, and the LGPL is intentionally awkward to apply to anything other than a straight "link it in and it provides these functions" library to encourage people not to use it for anything else. The MPL is a much more elegant solution to the problem where you want to be able to link proprietory code to free code, and keep the free code free (and contribute improvements to it back) without having to release the proprietory code under the same license. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 15:55:50 -0400 you wrote: >- Original Message - >From: Alex Holden <[EMAIL PROTECTED]> >To: Bradley D. LaRonde <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> >Sent: Monday, October 04, 1999 3:40 PM >Subject: Re: Request for comments - Microwindows > > >> On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: >> > This is an idea, but why? Doesn't MPL completely kill any GPL benefit? >Why >> > would someone choose to use it under GPL when they can use it under MPL? >> >> Because they want to borrow some of our code, but are stuck with code >> which is GPLed (you can't mix MPLed code in with GPLed code because of the >> restrictive nature of the GPL). > >So why not use LGPL? IOW, why use MPL instead of LGPL? Because, as I've said multiple times now, the LGPL is too restrictive for a potentially large part of the people who would otherwise be interested in contributing and using this code. In an ideal world everyone would be able to accept open source code, but the world isn't ideal. It would limit our interest in this project dramatically if we would be limited from using third party code which we can't control licensing of because of license issues. It would probably mean I'd be redirected to do my widget set development for another system for instance, or it might mean we'd have to fork the tree and keep working on a less restricted version. I absolutely symphatize with those who want to use GPL'd code with it too, and that's why I suggested dual licensing as an option. Regards, Vidar
Re: Request for comments - Microwindows
> * As David's code is gradually rewritten and replaced by new code, license > the new code under MPL. > > We'd have to seperate the code which requires David's public domain > license into seperate files to the code which is under MPL though. That is good practice. David wanted his original code to be totally free. Lets make it easy for people to use it that way
Re: Request for comments - Microwindows
- Original Message - From: Alex Holden <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 3:40 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > > This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why > > would someone choose to use it under GPL when they can use it under MPL? > > Because they want to borrow some of our code, but are stuck with code > which is GPLed (you can't mix MPLed code in with GPLed code because of the > restrictive nature of the GPL). So why not use LGPL? IOW, why use MPL instead of LGPL? Regards, Brad
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why > would someone choose to use it under GPL when they can use it under MPL? Because they want to borrow some of our code, but are stuck with code which is GPLed (you can't mix MPLed code in with GPLed code because of the restrictive nature of the GPL). --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On 4 Oct 1999, Vidar Hokstad wrote: > I thought we'd already agreed on the MPL as a decent common denominator, > but I'd have no problems with dual licensing the code under both *GPL > and MPL. Seconded. What would probably be the best compromise would be something along the lines of the license I placed on the LinuxHacker.org code- basically it's MPL, but you can at your option convert it one-way to a *GPL license. I've just realised that David's original license is compatible with the MPL (even though the GPL isn't), so there's no reason why we can't: * License our new code under MPL. * Keep David's original, public domain, license on his code. * Provide an option to convert the code to GPL (David has said his code can be relicensed under GPL, so that's okay). * As David's code is gradually rewritten and replaced by new code, license the new code under MPL. We'd have to seperate the code which requires David's public domain license into seperate files to the code which is under MPL though. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Greg Haerr wrote: > License under LGPL. All of the code I've written, > which includes all of microwindows and all the enhancements > to mini-X, can be easily licensed this way. But the nano-X > project has a large core of GrXXX routines that were originally > written by David Bell, and his license is completely unrestrictive, > except that his copyright notice must still be included. So > we can't downgrade his license to LGPL. This means that > his code can't be used if this project goes strictly MPL or LGPL. > One idea is to contact David, another is to rewrite it as Xlib. As has already been discussed (at great length) at least twice before, David has already agreed to let us license his code under either the LGPL or the GPL, but not the MPL (he wouldn't say why he didn't like the MPL). I would prefer the MPL myself (with a convert-one-way-to-GPL option) so that commercial applications in linked in mode and drivers for hardware that the specs for had to be obtained under NDA could be used. > In this way, the MicroWindows project goal could become "A > micro-reimplementation of the Xlib and Win32 api's, catering to small > size and speed of porting, on Linux[CE,86] platforms." Only Linux86 and LinuxCE? What about the thousands of other embedded systems, palmtops, etc. it is useful for... --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
- Original Message - From: Vidar Hokstad <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 3:15 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999 you wrote: > > >> I thought we'd already agreed on the MPL as a decent common denominator, > >> but I'd have no problems with dual licensing the code under both *GPL > >> and MPL. > > > >This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why > >would someone choose to use it under GPL when they can use it under MPL? > > That depends on what you consider the benefit of the GPL in this case. > It would allow people to write GPL'd programs with it, and to user GPL'd > code in their applications, *OR* to link it to non-free programs (using > the server under the MPL). I don't think that I understand what you mean. The licensing of a library does never prevent me from licesing my code under GPL. > The main downside I see is that we'd increase the risc for splitting the > tree again, if someone wants to contribute code, but only under the GPL > or only under the MPL. Dual-licensing practically encourages splitting. > The MPL allow static linking without releasing object code. It > also allows non-free additions to the project (read: drivers for hardware > where specs are only available under NDA), as long as they are in separate files. Wouldn't an LGPL'ed server part allow proprietary drivers too? I don't see the benefit of MPL here. > I don't think we would be able to live with the whole code licensed under > the LGPL, but if the client code for the networked version is dual > licensed LGPL/MPL, and the rest is under LGPL, then that would be something > we could live with. OK, I can see your business reason for the server being LGPL vs. GPL (so that you can link in proprietary hardware drivers). And I can see your business reason for the client being LGPL (so that you can link it from proprietary programs). I still do not understand your need for MPL at all. Plus... I do not at all like the fact that if the server side is under LGPL then people will be able to hide drivers from us, as I think this has the potential to seriously injure Micro*'s open-source value. I can live with the fact that people need to link in proprietary applications and can accept the client side being LGPL. Regards, Brad
RE: Request for comments - Microwindows
On Mon, 4 Oct 1999 13:03:01 -0600 you wrote: >: Can you say what it is in *GPL that would make it unworkable for Screen >: Media? >: >:: This is an idea, but why? Doesn't MPL completely kill any GPL benefit? >Why >: would someone choose to use it under GPL when they can use it under MPL? >: > >I think it's clear that we can't go with just GPL. So the issue >now is whether we should go with MPL or LGPL. Both permit proprietary >code to be linked with the project. Is there a significant benefit to MPL >that LGPL doesn't have? The MPL allow static linking without releasing object code. It also allows non-free additions to the project (read: drivers for hardware where specs are only available under NDA), as long as they are in separate files. The embedded and small systems market is special enough that both of those issues can be fairly important. I don't think we would be able to live with the whole code licensed under the LGPL, but if the client code for the networked version is dual licensed LGPL/MPL, and the rest is under LGPL, then that would be something we could live with. Regards, Vidar
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 14:52:39 -0400 you wrote: >> The problem, as you've noted, is that many would want to link the server >> into their applications. I know that we (Screen Media) can't continue to >> work on it if the code isn't available under another license (apart from >> the *GPL's) as well, and the result would be yet another code split. > >Can you say what it is in *GPL that would make it unworkable for Screen >Media? I did in another message. To reiterate: We might be licensing third party code which we have no control on the license for, and where they are willing to port if they won't have to give us access to binary. Not being able to do that would kill a key benefit of using NanoGUI for us. >> I thought we'd already agreed on the MPL as a decent common denominator, >> but I'd have no problems with dual licensing the code under both *GPL >> and MPL. > >This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why >would someone choose to use it under GPL when they can use it under MPL? That depends on what you consider the benefit of the GPL in this case. It would allow people to write GPL'd programs with it, and to user GPL'd code in their applications, *OR* to link it to non-free programs (using the server under the MPL). The main downside I see is that we'd increase the risc for splitting the tree again, if someone wants to contribute code, but only under the GPL or only under the MPL. Regards, Vidar
RE: Request for comments - Microwindows
On Mon, 4 Oct 1999 12:51:13 -0600 you wrote: > >: However, it does appear to kill the static model, but ONLY FOR NON-FREE >: ROGRAMS. Free programs could still use the static model just fine, and >: non-free programs could still use the client/server model, since the client >: side is LGPL. >: > >Well, we could always have LGPL for static model, otherwise >GPL for server and LGPL for applications. If someone wants to develop >a non-free program, and link it statically, we still let them Yes, but it may still be too restrictive for some cases. We for instance specifically have one case where we might end up licensing software from a third party that they won't be willing to deliver object code for relinking for, and that thus means that we can't use it with LGPL'd code either. So for us the LGPL might end up being to restrictive. In my case though, I don't expect us to statically link anything, so for us it might be enough to dual license the client side library, but I'd expect the above to be the case for a rather large part of the potential user base for NanoGUI, and I'd prefer to support it. Regards, Vidar
RE: Request for comments - Microwindows
: Can you say what it is in *GPL that would make it unworkable for Screen : Media? : :: This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why : would someone choose to use it under GPL when they can use it under MPL? : I think it's clear that we can't go with just GPL. So the issue now is whether we should go with MPL or LGPL. Both permit proprietary code to be linked with the project. Is there a significant benefit to MPL that LGPL doesn't have?
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 19:49:11 +0100 (BST) you wrote: >> I thought we'd already agreed on the MPL as a decent common denominator, >> but I'd have no problems with dual licensing the code under both *GPL >> and MPL. > >I still personally think the MPL is the only standard license that fits >the linked in case at all I agree, but on the other hand I'd gladly support licensing the code under both the GPL and the MPL, so that those who wants to develop free software can do so and still use other GPL'd software in their programs. Regards, Vidar
Re: Request for comments - Microwindows
- Original Message - From: Vidar Hokstad <[EMAIL PROTECTED]> To: Bradley D. LaRonde <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 2:46 PM Subject: Re: Request for comments - Microwindows > On Mon, 4 Oct 1999 14:38:00 -0400 you wrote: > >What you suggest is brilliant IMO. I recommend to go ahead with your ideas. > > > >Only two comments, both about the licensing: > > > >1) I would prefer *GPL over MPL. > > > >2) I'm fine with LGPL, but I would like to see GPL in here somewhere if > >feasable. > > I'd suggest dual licensing. *GPL is completely unworkable for many people, > for a variety of reasons. > > >I was thinking, how about using GPL for server layer(s), and LGPL for client > >layer(s)? I think that as long the client and server are separated by a > >messaging protocol it will work. > > The problem, as you've noted, is that many would want to link the server > into their applications. I know that we (Screen Media) can't continue to > work on it if the code isn't available under another license (apart from > the *GPL's) as well, and the result would be yet another code split. Can you say what it is in *GPL that would make it unworkable for Screen Media? > I thought we'd already agreed on the MPL as a decent common denominator, > but I'd have no problems with dual licensing the code under both *GPL > and MPL. This is an idea, but why? Doesn't MPL completely kill any GPL benefit? Why would someone choose to use it under GPL when they can use it under MPL? Regards, Brad
Re: Request for comments - Microwindows
> The problem, as you've noted, is that many would want to link the server > into their applications. I know that we (Screen Media) can't continue to > work on it if the code isn't available under another license (apart from > the *GPL's) as well, and the result would be yet another code split. Nod. > I thought we'd already agreed on the MPL as a decent common denominator, > but I'd have no problems with dual licensing the code under both *GPL > and MPL. I still personally think the MPL is the only standard license that fits the linked in case at all
RE: Request for comments - Microwindows
: I support having a partial Xlib implementation, but *not* if it affects : size and efficiency. : I completely agree. For instance, none of the Xrm* stuff would come in. OTOH, why not just call XOpenDisplay and XDrawString, rather than GrOpen and GrText? It would involve one more (usually NULL) parameter, the Display *. But most of the api would port easily. : I suspect it would be hard to implement a full featured API and maintain : a small size without deviating quite a bit from the Xlib API. It might : be worth a try to add at least partial compatibility. I think it's a good try. Just like when I reimplemented win32, I'm only going for the graphics stuff, not the whole damned world. Heaven's knows we don't want to create Gate's whole idiotic pig-big system all over again. On a more rational note, yes, the Xlib api may differ on certain items. Like color. We could use a much simpler color model than X. So the api isn't exactly Xlib, but it's as close. We try to keep the parameters the same, but don't have to match the internal Xlib data structures for the parameters. This is a trick I used in microwindows, if anyone's noticed. Greg
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 14:38:00 -0400 you wrote: >What you suggest is brilliant IMO. I recommend to go ahead with your ideas. > >Only two comments, both about the licensing: > >1) I would prefer *GPL over MPL. > >2) I'm fine with LGPL, but I would like to see GPL in here somewhere if >feasable. I'd suggest dual licensing. *GPL is completely unworkable for many people, for a variety of reasons. >I was thinking, how about using GPL for server layer(s), and LGPL for client >layer(s)? I think that as long the client and server are separated by a >messaging protocol it will work. The problem, as you've noted, is that many would want to link the server into their applications. I know that we (Screen Media) can't continue to work on it if the code isn't available under another license (apart from the *GPL's) as well, and the result would be yet another code split. I thought we'd already agreed on the MPL as a decent common denominator, but I'd have no problems with dual licensing the code under both *GPL and MPL. Vidar Hokstad.
Re: Request for comments - Microwindows
- Original Message - From: Greg Haerr <[EMAIL PROTECTED]> To: 'Bradley D. LaRonde' <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 2:51 PM Subject: RE: Request for comments - Microwindows > > : However, it does appear to kill the static model, but ONLY FOR NON-FREE > : ROGRAMS. Free programs could still use the static model just fine, and > : non-free programs could still use the client/server model, since the client > : side is LGPL. > : > Well, we could always have LGPL for static model, otherwise > GPL for server and LGPL for applications. If someone wants to develop > a non-free program, and link it statically, we still let them Wow, I never thought of that possibility. One thought, though, is that it might convolute things too much to #ifdef the licensing. Regards, Brad
RE: Request for comments - Microwindows
: However, it does appear to kill the static model, but ONLY FOR NON-FREE : ROGRAMS. Free programs could still use the static model just fine, and : non-free programs could still use the client/server model, since the client : side is LGPL. : Well, we could always have LGPL for static model, otherwise GPL for server and LGPL for applications. If someone wants to develop a non-free program, and link it statically, we still let them
Re: Request for comments - Microwindows
> So even though David Bell said "Permission is granted to use, distribute, > or modify this source, provided that this copyright notice remain intact" we > can say that now his code is subject to another agreement, the LGPL? > Doesn't the LGPL restrict more than the above? Yes. But that is allowed. You can take his work and use it as allowed by his license to create a derivative work - his license allows this. What you cannot do is stop someone taking David Bell's original work and using it under David Bell's license alone. The derivative work (the combination) is differently licensed to the original code he wrote. > Also, can we have a GPL license on the server and an LGPL license > on the applications? Can we have both even if we allow linked-in > apps and client/server apps? It gets complicated in the linked in case. Alan
RE: Request for comments - Microwindows
On Monday, October 04, 1999 12:13 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: : > which includes all of microwindows and all the enhancements : > to mini-X, can be easily licensed this way. But the nano-X : > project has a large core of GrXXX routines that were originally : > written by David Bell, and his license is completely unrestrictive, : > except that his copyright notice must still be included. So : : His license doesnt clash with the LGPL. The LGPL doesnt allow you to : remove other peoples copyright notices either : So even though David Bell said "Permission is granted to use, distribute, or modify this source, provided that this copyright notice remain intact" we can say that now his code is subject to another agreement, the LGPL? Doesn't the LGPL restrict more than the above? Also, can we have a GPL license on the server and an LGPL license on the applications? Can we have both even if we allow linked-in apps and client/server apps?
Re: Request for comments - Microwindows
What you suggest is brilliant IMO. I recommend to go ahead with your ideas. Only two comments, both about the licensing: 1) I would prefer *GPL over MPL. 2) I'm fine with LGPL, but I would like to see GPL in here somewhere if feasable. I was thinking, how about using GPL for server layer(s), and LGPL for client layer(s)? I think that as long the client and server are separated by a messaging protocol it will work. The nice thing about this is that it provides that all server code (e.g. drivers) will be free (open-source) - which seems like a Good Thing to me. However, it does appear to kill the static model, but ONLY FOR NON-FREE ROGRAMS. Free programs could still use the static model just fine, and non-free programs could still use the client/server model, since the client side is LGPL. Comments? Regards, Brad - Original Message - From: Greg Haerr <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 2:16 PM Subject: Request for comments - Microwindows > Move to Xlib reimplementation. I've been thinking that the > proper way to go with the microwindows project is to build a close > resemblance to Xlib, much like I've done with the win32 api portion. > This would allow, for instance, with little effort, the graphics applications > that currently use Gtk on top of Gdk on top of Xlib to be ported to > all the systems that microwindows supports with very little effort. > Also, the Xlib reference manual could be used for most instances > to learn about the micro-X api. > > License under LGPL. All of the code I've written, > which includes all of microwindows and all the enhancements > to mini-X, can be easily licensed this way. But the nano-X > project has a large core of GrXXX routines that were originally > written by David Bell, and his license is completely unrestrictive, > except that his copyright notice must still be included. So > we can't downgrade his license to LGPL. This means that > his code can't be used if this project goes strictly MPL or LGPL. > One idea is to contact David, another is to rewrite it as Xlib. > > Reorganize source code so that micro-Win32 and micro-X > can both be worked on simultaneously. Currently, the source > is organized with win32 getting the "upper hand". The win32 reimplementation > would be placed in a subdirectory from the engine code. The > Xlib reimplementation would be placed in a subdirectory under the engine > code. Thus, Xlib development could proceed much more quickly, > without having to know anything about win32. > In this way, the MicroWindows project goal > could become "A micro-reimplementation of the Xlib and Win32 > api's, catering to small size and speed of porting, on Linux[CE,86] platforms."
Re: Request for comments - Microwindows
- Original Message - From: Greg Haerr <[EMAIL PROTECTED]> To: 'Alan Cox' <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 2:37 PM Subject: RE: Request for comments - Microwindows > On Monday, October 04, 1999 12:13 PM, Alan Cox [SMTP:[EMAIL PROTECTED]] wrote: > : > which includes all of microwindows and all the enhancements > : > to mini-X, can be easily licensed this way. But the nano-X > : > project has a large core of GrXXX routines that were originally > : > written by David Bell, and his license is completely unrestrictive, > : > except that his copyright notice must still be included. So > : > : His license doesnt clash with the LGPL. The LGPL doesnt allow you to > : remove other peoples copyright notices either > : > So even though David Bell said "Permission is granted to use, distribute, > or modify this source, provided that this copyright notice remain intact" we > can say that now his code is subject to another agreement, the LGPL? > Doesn't the LGPL restrict more than the above? Yes, it does, but he doesn't restrict placing new restrictions on derived works with his copyright, which is the main reason for using GPL vs. his license. GPL prevents ppl from making proprietary works based on your free work. > Also, can we have a GPL license on the server and an LGPL license > on the applications? Can we have both even if we allow linked-in > apps and client/server apps? Wow, seems like we are thinking along the same lines. :-) I commented on that already in my previous message. Regards, Brad
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999 12:16:10 -0600 you wrote: >I am considering some bigger changes to the graphics engine >project I've been working on the last six months. I'd like to get >your comments before I go headlong into this. Following are >some of the changes being considered: > > >Move to Xlib reimplementation. I've been thinking that the >proper way to go with the microwindows project is to build a close >resemblance to Xlib, much like I've done with the win32 api portion. >This would allow, for instance, with little effort, the graphics applications >that currently use Gtk on top of Gdk on top of Xlib to be ported to >all the systems that microwindows supports with very little effort. >Also, the Xlib reference manual could be used for most instances >to learn about the micro-X api. I support having a partial Xlib implementation, but *not* if it affects size and efficiency. I suspect it would be hard to implement a full featured API and maintain a small size without deviating quite a bit from the Xlib API. It might be worth a try to add at least partial compatibility. Vidar.
