Re: Licensing summary
This was a reasonable summary. Below I've commented on _my_ needs only, related to your suggestions. What I need, and what I want are two different things, though. I'd like a more liberal use of licenses than what we need, for the reasons of more easily growing mindshare in the embedded systems community. (When I talk about we/us below, I talk about Screen Media) On Mon, 4 Oct 1999 18:39:11 -0600 you wrote: >Let me try to summarize what we need in a graphics system license: > > >1. We _must_ have: > >a. The ability to have private, proprietary drivers to be used (NDA's, >and other commercial non-control issues) > >b. The ability to work with, communicate with, and be linked with, >private, proprietary applications. (commercial software shops use our engine >with >their application; they'll never go open source, but still want/choose our >engine) These are really one and the same: Being able to link proprietary code into the server side. I still believe some people will have problem with LGPL here, but for _me_ it doesn't matter. Even the GPL would be acceptable for _our_ use. But then we will only be using it with network support. >2. We _would_like_to_have: > >a. All modifications to original files, whether they're enhancements >or bug fixes. It'd be nice to have them back, but not required. The MPL allow this, but also allows people to "cheat" in some cases, by adding enhancements in separate files. For me, I'd consider the MPL as protection enough, but I won't object to the LGPL for the server side. >b. A community desiring to better the project as a whole, >by sending contributions to be included in the whole, whether they're original >work, new drivers, or whatever. > >3. We _must_not_have: > >a. The ability to use the graphics engine, lock stock and barrel, >for whatever purposes are desired [It is this 3a that I can't quite come >to >grips with] I gather that you mean that we don't want someone to take the code, and run with it, not contributing anything back. But I'm not sure if this would be a huge problem. Unless you add a lot of stuff that you are very afraid of releasing, it will always be an advantage to using an unchanged "official" version over having to backport your changes every time you upgrade. The MPL provide some (but not as much as the LGPL or GPL) protection against this kind of use, though. My main concern is the client side, though. The client side is a very small part of the code, but a liberal license on the client side code will be a "bail out" for people that _can't_ (for contractual or other reasons) use LGPL'd code, and thus don't want to link to a LGPL'd server, but won't let them take the server code and run with it. Regards, Vidar
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: Stupid licensing thread (Was: Request for comments - Microwindows)
On Mon, 4 Oct 1999 18:28:03 -0600 you wrote: >On Monday, October 04, 1999 4:51 PM, Vidar Hokstad [SMTP:[EMAIL PROTECTED]] >wrote: >: the near future I and another developer will be working >: nearly full time on it, and we also sponsor another company to port a major >: software product to NanoGUI. >: >: This is code that we contribute back. > > >Correct me if I'm wrong: If we license LGPL _or_ MPL, >it is not required to contribute any code back. Depends on how the code is organized - with MPL you still have to contribute back changes to the existing code, but it is easier to add proprietary code outside the existing code. We will contribute back no matter what license - if we'd been afraid of releasing code we wouldn't have considered NanoGUI in the first place. My concern is being able to use proprietary code for which we have no control over the license terms, and were we in some cases may explicitly not be allowed to release anything but stripped binaries. In our case we won't link directly to the server, though, so as long as the client library has a liberal enough license (such as the MPL), that's enough for us. > If the _contributors_ to NanoGUI >: regards prefer a restrictive licensing scheme over those contributions, >: then fine. In that case we'll spend our time and money improving >: another product instead, or license a closed source product instead of >: spending or time and money on supporting an open source project. > > >So we need a license that: > >1) must > >or >2) should > >cause contributors to contribute code back. Which? For the server side I don't really have a preference. I know that _we_ (as in Screen Media) can live with pretty much any open source license on the server without problem, including the GPL. I'm concerned about what others would want for it too, though. For the client library I would certainly prefer a much more liberal license. But since all the logic will be on the server side anyway, I can't see the point with a restrictive license for the client library. But as we've been through before: Many people might prefer to link directly with the server (doesn't apply to us), for instance when running on systems without networking support. And the more restrictive license on the server, the fewer of that kinds of projects will be able to use NanoGUI. For that reason I'd prefer a not too restrictive license for the server side too, because it might help with developer mindshare. Regards, Vidar
Licensing summary
Let me try to summarize what we need in a graphics system license: 1. We _must_ have: a. The ability to have private, proprietary drivers to be used (NDA's, and other commercial non-control issues) b. The ability to work with, communicate with, and be linked with, private, proprietary applications. (commercial software shops use our engine with their application; they'll never go open source, but still want/choose our engine) 2. We _would_like_to_have: a. All modifications to original files, whether they're enhancements or bug fixes. It'd be nice to have them back, but not required. b. A community desiring to better the project as a whole, by sending contributions to be included in the whole, whether they're original work, new drivers, or whatever. 3. We _must_not_have: a. The ability to use the graphics engine, lock stock and barrel, for whatever purposes are desired [It is this 3a that I can't quite come to grips with] please debate Greg
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: Stupid licensing thread (Was: Request for comments - Microwindows)
On Monday, October 04, 1999 4:51 PM, Vidar Hokstad [SMTP:[EMAIL PROTECTED]] wrote: : the near future I and another developer will be working : nearly full time on it, and we also sponsor another company to port a major : software product to NanoGUI. : : This is code that we contribute back. Correct me if I'm wrong: If we license LGPL _or_ MPL, it is not required to contribute any code back. If the _contributors_ to NanoGUI : regards prefer a restrictive licensing scheme over those contributions, : then fine. In that case we'll spend our time and money improving : another product instead, or license a closed source product instead of : spending or time and money on supporting an open source project. So we need a license that: 1) must or 2) should cause contributors to contribute code back. Which?
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: Stupid licensing thread (Was: Request for comments - Microwindows)
I totally agree with Alan... -- "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, Alan Cox wrote: > > >As long as the API and/or messaging protocol are open spec, then anyone > > >can write their own library. X is an example, XFree uses opensource > > >license, metrox and accelx used closed. Same function, same result, but > > >they had to write their own library. > > [Equally a server] > > > Actually they wouldn't have had to if they didn't want to. The XFree license > > permits closed source use. > > Indeed. And while LGPL might be better in some ways than the BSD license X > wouldnt be where it is today had it had a GPL library > >
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: Stupid licensing thread (Was: Request for comments - Microwindows)
> >As long as the API and/or messaging protocol are open spec, then anyone > >can write their own library. X is an example, XFree uses opensource > >license, metrox and accelx used closed. Same function, same result, but > >they had to write their own library. [Equally a server] > Actually they wouldn't have had to if they didn't want to. The XFree license > permits closed source use. Indeed. And while LGPL might be better in some ways than the BSD license X wouldnt be where it is today had it had a GPL library
Re: Stupid licensing thread (Was: Request for comments - Microwindows)
On Tue, 5 Oct 1999 06:44:43 +1000 (EST) you wrote: >On 4 Oct 1999, Vidar Hokstad wrote: > >> >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. > >IMHO, the simple/obvious answer is GPL. If someone wants to write >commercial/closedsource programs, there's nothing at all stopping them >from writing their own library, under their own license. I very much >dislike the thought of someone making money off any code I've written, >without giving something back to the opensource community, and I'm sure >quite a few people would agree. In our case, our alternative is to write our own library, yes, or choose one under a less restrictive license. Currently I work part time on a widget set for NanoGUI. In the near future I and another developer will be working nearly full time on it, and we also sponsor another company to port a major software product to NanoGUI. This is code that we contribute back. If the _contributors_ to NanoGUI regards prefer a restrictive licensing scheme over those contributions, then fine. In that case we'll spend our time and money improving another product instead, or license a closed source product instead of spending or time and money on supporting an open source project. >As long as the API and/or messaging protocol are open spec, then anyone >can write their own library. X is an example, XFree uses opensource >license, metrox and accelx used closed. Same function, same result, but >they had to write their own library. Actually they wouldn't have had to if they didn't want to. The XFree license permits closed source use. Vidar Hokstad
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: new version of nano-X/microwindows
On Mon, 4 Oct 1999, Greg Haerr wrote: > On Monday, October 04, 1999 1:32 PM, Araujo, Isaque G. >[SMTP:[EMAIL PROTECTED]] wrote: > : Would be nice if you had some screenshots of nano-X/microwindows running ! > : > Yes, it would be. Sometime ago this was discussed on this list, > and IIRC, all that had to be done was that /dev/fb0 was read to get the > bits, and then they need to be written out in some bitmap format... Heck, even easier than that, just run it under dosemu, or vmware, and get an X snapshot. Davey
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: Stupid licensing thread (Was: Request for comments - Microwindows)
On 4 Oct 1999, Vidar Hokstad wrote: > >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. IMHO, the simple/obvious answer is GPL. If someone wants to write commercial/closedsource programs, there's nothing at all stopping them from writing their own library, under their own license. I very much dislike the thought of someone making money off any code I've written, without giving something back to the opensource community, and I'm sure quite a few people would agree. As long as the API and/or messaging protocol are open spec, then anyone can write their own library. X is an example, XFree uses opensource license, metrox and accelx used closed. Same function, same result, but they had to write their own library. Davey
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/
as86 .o file runtime loader completed
Al, I've completed the runtime dynamic linking loader produced by the 8086-based bcc, as86 and ld86 tools. This code allows the relocatable images produced by as86 to be loaded as shared libraries if desired. All export and import symbols are matched, and offsets relocated. Currently, it also allows for libc.a and other archive files to be searched, and modules loaded as well. The relocating loader also works for 32-bit object modules produced with the bcc -3 option. However, there remains a very serious problem relating to getting this to work in 16-bit mode. (I finally realized this damn near after completing the whole thing) Although I have it working for both 16 and 32 bit files now, I can't actually execute the code loaded for 16 bit modules. This is because I malloc() the data space for the code segment, but the code has to actually execute relative to the CS segment. Thus, we would need an additional system call, or the ability to write into a new process space in order to allocate code segment space and have it relative to the CS register. So, I'm not sure what's next. (It's been a very informative project, however... I can still run .o files created from bcc -3 in my native linux elf programs...) If we wanted to add some very _new_ design to the ELKS kernel, we could add the abililty for ELKS to load/unload modules, and the same loader code could be used for user processes as well. The reason we'd use the current .o file format is because we'd not have to write new tools. The ELKS kernel could load/unload drivers using the same mechanism that user programs use, which is cooler than the Linux kernel's implementation. Unloading modules is easy if there's a single import, but with multiple imports, it gets harder. Greg
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: new version of nano-X/microwindows
On Monday, October 04, 1999 1:32 PM, Araujo, Isaque G. [SMTP:[EMAIL PROTECTED]] wrote: : Would be nice if you had some screenshots of nano-X/microwindows running ! : Yes, it would be. Sometime ago this was discussed on this list, and IIRC, all that had to be done was that /dev/fb0 was read to get the bits, and then they need to be written out in some bitmap format... Perhaps that should be tonight's project... Or are there any volunteers? Greg
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: new version of nano-X/microwindows
Would be nice if you had some screenshots of nano-X/microwindows running ! /H\j HPLX SG70900338[EMAIL PROTECTED] (=U=) [EMAIL PROTECTED] 55-11-3741-3510 '-' C/C++ PL/SQL Sistema Empresa / SIAL 2000 > -Original Message- > From: Greg Haerr [SMTP:[EMAIL PROTECTED]] > Sent: Monday, October 04, 1999 2:26 PM > To: '[EMAIL PROTECTED]' > Cc: '[EMAIL PROTECTED]' > Subject: new version of nano-X/microwindows > > I've completed another version of nano-X/microwindows that takes > care of most of the last two week's concerns on this list. > > Version 0.84 is now available at > > ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.84.tar.gz > > Thanks to Brad LaRonde and Vidar Hokstad for input and changes for this > release. > > The major changes in this release are: > > o completely support client/server model for nano-X programs. > o integration of truecolor support (thanks Brad) > o integration of nanoWidgets (thanks Vidar) > o support cross-compilation for MIPS linuxCE project (thanks Brad) > o integrated bug fixes from nano-X-0.5pre3 > > For those with truecolor systems, it would be nice to check this version > out, since I still can't run with truecolor. This version also compiles > and runs > the complete nanoWidget set from Vidar with a single toplevel make, so > you all can check out what's new there. There are quite a few bug fixes > with the client/server networking code, many calls didn't previously work. > The make defaults to client/server builds now, although the linked > application > model can be built with a switch for debugging. > > Attached is the ChangeLog for this release > > Version 0.84 - 3rd October 1999 - [EMAIL PROTECTED] > * integrated Vidar's nanoWidgets 0.1, changed color constants > * integrated Brad LaRonde's MIPS LinuxCE port cross-compile changes > * integrated Alex's nano-X-0.5pre3 changes except dir/filename > changes > * added support for 8 to 32 bit truecolor systems > * reorganized Makefile for nanoX and linked/non-linked nano-X > servers > * reorganized Makefiles for gcc, bcc and other compilers > * reorganized nano-X.h header file for client programs > * fixed GrSetGCFont,GrGetGCTextSize,ReadArea,Area client/server bugs > * fix bug in nanoX network select code for client attach > * workaround for GrGetNextEvent in nanoX client lib > * wrote asm version of VGA driver for ELKS > * added optimized herc hline routine from > [EMAIL PROTECTED] > * added contributed terminal emulator demo for nano-X, > (from Alistair Riddoch, requires linked server) > > Greg >
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.
Request for comments - Microwindows
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. 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." Comments? Greg
Re: new version of nano-X/microwindows
Excellent! I will look at it right away. Thanks Greg. Regards, Brad - Original Message - From: Greg Haerr <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, October 04, 1999 1:26 PM Subject: new version of nano-X/microwindows > I've completed another version of nano-X/microwindows that takes > care of most of the last two week's concerns on this list. > > Version 0.84 is now available at > ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.84.tar.gz > > Thanks to Brad LaRonde and Vidar Hokstad for input and changes for this release. > > The major changes in this release are: > > o completely support client/server model for nano-X programs. > o integration of truecolor support (thanks Brad) > o integration of nanoWidgets (thanks Vidar) > o support cross-compilation for MIPS linuxCE project (thanks Brad) > o integrated bug fixes from nano-X-0.5pre3 > > For those with truecolor systems, it would be nice to check this version > out, since I still can't run with truecolor. This version also compiles and runs > the complete nanoWidget set from Vidar with a single toplevel make, so > you all can check out what's new there. There are quite a few bug fixes > with the client/server networking code, many calls didn't previously work. > The make defaults to client/server builds now, although the linked application > model can be built with a switch for debugging. > > Attached is the ChangeLog for this release > > Version 0.84 - 3rd October 1999 - [EMAIL PROTECTED] > * integrated Vidar's nanoWidgets 0.1, changed color constants > * integrated Brad LaRonde's MIPS LinuxCE port cross-compile changes > * integrated Alex's nano-X-0.5pre3 changes except dir/filename changes > * added support for 8 to 32 bit truecolor systems > * reorganized Makefile for nanoX and linked/non-linked nano-X servers > * reorganized Makefiles for gcc, bcc and other compilers > * reorganized nano-X.h header file for client programs > * fixed GrSetGCFont,GrGetGCTextSize,ReadArea,Area client/server bugs > * fix bug in nanoX network select code for client attach > * workaround for GrGetNextEvent in nanoX client lib > * wrote asm version of VGA driver for ELKS > * added optimized herc hline routine from [EMAIL PROTECTED] > * added contributed terminal emulator demo for nano-X, > (from Alistair Riddoch, requires linked server) > > Greg > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
new version of nano-X/microwindows
I've completed another version of nano-X/microwindows that takes care of most of the last two week's concerns on this list. Version 0.84 is now available at ftp://microwindows.censoft.com/pub/microwindows/microwindows-0.84.tar.gz Thanks to Brad LaRonde and Vidar Hokstad for input and changes for this release. The major changes in this release are: o completely support client/server model for nano-X programs. o integration of truecolor support (thanks Brad) o integration of nanoWidgets (thanks Vidar) o support cross-compilation for MIPS linuxCE project (thanks Brad) o integrated bug fixes from nano-X-0.5pre3 For those with truecolor systems, it would be nice to check this version out, since I still can't run with truecolor. This version also compiles and runs the complete nanoWidget set from Vidar with a single toplevel make, so you all can check out what's new there. There are quite a few bug fixes with the client/server networking code, many calls didn't previously work. The make defaults to client/server builds now, although the linked application model can be built with a switch for debugging. Attached is the ChangeLog for this release Version 0.84 - 3rd October 1999 - [EMAIL PROTECTED] * integrated Vidar's nanoWidgets 0.1, changed color constants * integrated Brad LaRonde's MIPS LinuxCE port cross-compile changes * integrated Alex's nano-X-0.5pre3 changes except dir/filename changes * added support for 8 to 32 bit truecolor systems * reorganized Makefile for nanoX and linked/non-linked nano-X servers * reorganized Makefiles for gcc, bcc and other compilers * reorganized nano-X.h header file for client programs * fixed GrSetGCFont,GrGetGCTextSize,ReadArea,Area client/server bugs * fix bug in nanoX network select code for client attach * workaround for GrGetNextEvent in nanoX client lib * wrote asm version of VGA driver for ELKS * added optimized herc hline routine from [EMAIL PROTECTED] * added contributed terminal emulator demo for nano-X, (from Alistair Riddoch, requires linked server) Greg
RE: Anybody using this list?
: As this is an exe file, a windows based disassembler may be the best way to : work on it. If you would rather work on it under Linux, try ndisasm which : comes as part of the NASM package. It is a very powerful disassembler, but : some knowledge of the format of the file you are trying to disassemble. I : am not sure what the format of a .exe file is. Any pointers anyone? : The format of setup1.exe for the toshiba 1200 is an MZ header DOS executable. This is the original DOS format for .exe files, the other being .com files, raw binary images. Any DOS disassembler will work for MZ header files. The 16 bit windows file format is known as NE (new executable). This format uses a real-mode MZ header with a special value at offset 18h to indicate the location of the new header. Meanwhile, the windows 32 bit exe file is known as PE format, which is a modified COFF file. Following is the format of an MZ header .exe file: MZ EXE Format Intel byte order The old EXE files are the EXE files executed directly by MS-DOS. They were a major improvement over the old 64K COM files, since EXE files can span multiple segments. An EXE file consists of three different parts, the header, the relocation table and the binary code. The header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below. The format of the header is as follows : OFFSET Count TYPE Description h 2 char ID='MZ' ID='ZM' 0002h 1 word Number of bytes in last 512-byte page of executable 0004h 1 word Total number of 512-byte pages in executable (including the last page) 0006h 1 word Number of relocation entries 0008h 1 word Header size in paragraphs 000Ah 1 word Minimum paragraphs of memory allocated in addition to the code size 000Ch 1 word Maximum number of paragraphs allocated in addition to the code size 000Eh 1 word Initial SS relative to start of executable 0010h 1 word Initial SP 0012h 1 word Checksum (or 0) of executable 0014h 1 dword CS:IP relative to start of executable (entry point) 0018h 1 word Offset of relocation table; 40h for new-(NE,LE,LX,W3,PE etc.) executable 001Ah 1 word Overlay number (0h = main program) Greg
Apropos Z80 elks
UZI sources, GPL:ed http://www.psyber.com/~tcj/uzi180.html Jakob
.exe formats [was RE: Anybody using this list?]
> I > am not sure what the format of a .exe file is. Any pointers anyone? The old EXE files are the EXE files executed directly by MS-DOS. They were a major improvement over the old 64K COM files, since EXE files can span multiple segments. An EXE file consists of three different parts, the header, the relocation table and the binary code. The header is expanded by a lot of programs to store their copyright information in the executable, some extensions are documented below. The format of the header is as follows : OFFSET Count TYPE Description h 2 char ID='MZ' ID='ZM' 0002h 1 word Number of bytes in last 512-byte page of executable 0004h 1 word Total number of 512-byte pages in executable (including the last page) 0006h 1 word Number of relocation entries 0008h 1 word Header size in paragraphs 000Ah 1 word Minimum paragraphs of memory allocated in addition to the code size 000Ch 1 word Maximum number of paragraphs allocated in addition to the code size 000Eh 1 word Initial SS relative to start of executable 0010h 1 word Initial SP 0012h 1 word Checksum (or 0) of executable 0014h 1 dword CS:IP relative to start of executable (entry point) 0018h 1 word Offset of relocation table; 40h for new-(NE,LE,LX,W3,PE etc.) executable 001Ah 1 word Overlay number (0h = main program) Following are the header expansions by some other prorams like TLink, LZExe and other linkers, encryptors and compressors; all offsets are relative to the start of the whole header : ---new executable OFFSET Count TYPE Description 001Ch 4 byte 0020h 1 word Behaviour bits ?? 0022h 26 byte reserved (0) 003Ch 1 dword Offset of new executable header from start of file (or 0 if plain MZ executable) ---Borland TLINK OFFSET Count TYPE Description 001Ch 2 byte ?? (apparently always 01h 00h) 001Eh 1 byte ID=0FBh 001Fh 1 byte TLink version, major in high nybble 0020h 2 byte ?? ---old ARJ self-extracting archive OFFSET Count TYPE Description 001Ch 4 char ID='RJSX' (older versions) new signature is 'aRJsf'" in the first 1000 bytes of the file) ---LZEXE compressed executable OFFSET Count TYPE Description 001Ch 2 char ID='LZ' 001Eh 2 char Version number : '09' - LZExe 0.90 '91' - LZExe 0.91 ---PKLITE compressed executable OFFSET Count TYPE Description 001Ch 1 byte Minor version number 001Dh 1 byte Bit mapped : 0-3 - major version 4 - Extra compression 5 - Multi-segment file 001Eh 6 char ID='PKLITE' ---LHarc 1.x self-extracting archive OFFSET Count TYPE Description 001Ch 4 byte unused??? 0020h 3 byte Jump to start of extraction code 0023h 2 byte ??? 0025h 12 char ID='LHarc's SFX ' --LHA 2.x self-extracting archive OFFSET Count TYPE Description 001Ch 8 byte ??? 0024h 10 char ID='LHa's SFX ' For version 2.10 ID='LHA's SFX ' (v2.13) For version 2.13 ---LH self-extracting archive OFFSET Count TYPE Description 001Ch 8 byte ??? 0024h 8 byte ID='LH's SFX ' ---TopSpeed C 3.0 CRUNCH compressed file OFFSET Count TYPE Description 001Ch 1 dword ID=018A0001h 0020h 1 word ID=1565h ---PKARC 3.5 self-extracting archive OFFSET Count TYPE Description 001Ch 1 dword ID=00020001h 0020h 1 word ID=0700h ---BSA (Soviet archiver) self-extracting archive OFFSET Count TYPE Description 001Ch 1 word ID=000Fh 001Eh 1 byte ID=A7h ---LARC self-extracting archive OFFSET Count TYPE Description 001Ch 4 byte ??
Re: Anybody using this list?
Gregory Leblanc writes: > > I'm perfectly willing to put in the time to do this (expect it to take a > while), and teach myself assembler at the same time, but I need some help > going about it. A friend of mine loaned me his disassembler program, but > it's designed to run under win95 and winnt. Can I (should I even try) to > figure it out this way, or does it need to be on the t1200 to have it be > acurate and useful? Thanks, > Greg As this is an exe file, a windows based disassembler may be the best way to work on it. If you would rather work on it under Linux, try ndisasm which comes as part of the NASM package. It is a very powerful disassembler, but some knowledge of the format of the file you are trying to disassemble. I am not sure what the format of a .exe file is. Any pointers anyone? Al
