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, 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
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 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: Licensing summary
- Original Message - From: Greg Haerr [EMAIL PROTECTED] To: 'Vidar Hokstad' [EMAIL PROTECTED]; Bradley D. LaRonde [EMAIL PROTECTED]; 'Alan Cox' [EMAIL PROTECTED]; 'Alex Holden' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 04, 1999 8:39 PM Subject: 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) I disagree. If a vendor can take the proprietary route, he probably will. But if he likes Micro* and wants to use it, and the server part of Micro* is GPLed (not MPLed) he might be swayed to release his driver, which benefits our community. Consider this: "Yes, you can use this cool, free Micro* thingy for your project, but you have to, uh..., er..., buy our driver to get it to work." For embedded, it's not like you can just swap out the graphics card to a supported one like you can in a PC. Granted, we could reverse engineer the driver, but what I'm saying is that vendors, if given the ($PL) route, will probably take it, but if we don't give them that route, they might decide to release their driver, benefitting everyone. 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) This is simply solved by using LGPL on the client side. Take GNOME for an example. 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. Yes, we would like to have them back, so let's require it for the server side. Linux does. 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. If a vendor is on the fence, which way do you think they will go? I think that they will probably go $PL if given that option. If not given that option, then I think that they will be more likely to contribute back. BTW, the MPL has a serious flaw in that you can avoid contributing stuff back to the project just by putting it in a separate file. 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] Let everyone use it as they please, only require that they release their improvements back to the community. Is that too much to ask? Please, let's not fall into the trap of thinking that the success or failure of Micro* depends on how many embedded vendors pick it up. I think that for it to truly succeed means that it becomes the best FREE graphics system available for small devices, and that for it to remain free it needs the protection that the GNU GPL affords - protection that is certainly NOT present in (and would be effectively nullified by) the MPL. It really comes down do this: are we committed to free software, or are we just trying to please everyone? I hope that we decide that free software is more important than being popular. Where would we be today if others before us who were faced with this decision chose the popular way? Would we have GNU? Would we have Linux? I don't think so, and the same might be said about Micro* someday... or not. Regards, Brad
Re: Licensing summary
I disagree. If a vendor can take the proprietary route, he probably will. That doesnt back up experience. The only vendor who wants to take a proprietary route is one for whom this is 'core technology'. To everyone else its overhead and overheads want reducing so you make more profit on the product. BTW, the MPL has a serious flaw in that you can avoid contributing stuff back to the project just by putting it in a separate file. Same with the LGPL, you just put it inside or outside the library.
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
At last - Microwindows/Nano-X Screenshots!!!
OK, Thank you everyone for the licensing input, I learned alot. Sitting in frustration at home last night, I finally wrote a little program that reads the framebuffer and generates bitmap files. So, I ran through all the cool demos that I've got going, and we now have screenshot gif files for microwindows, as well as nano-X landmine, world, and widget sets running... There still on ftp, but have fun! ftp://microwindows.censoft.com/pub/microwindows/ScreenShots Note: the next release will include the makebmp conversion program, as well as support for screen dumping... Greg
RE: new version of nano-X/microwindows
: Speaking of projects .. I have few questions regarding 0.84 release of : mwin. : : 1: nano-x won't compile here with -O switch. It has to be some sort of : copt error (it does compile actually but doesn't assemble/link). This : can be solved by calling bcc without -O for nanox/srvfunc.c to be : compiled. I'll look into this. It works on my system... ;-) : : 2: where is Al's "terminal emulator" ? nterm ? did you manage to get it : woring ? : It's in there, but you must unset the client/server switch, and link in nterm.o. See the Makefile and INSTALL files. : 3: does world.c and/or nclock.c actually work on any ELKS system ? All the demos run on ELKS, including the nterm. If running world, you must supply the .dat file in the current directory. See world.c for details. Greg
RE: At last - Microwindows/Nano-X Screenshots!!!
It's cool, simply cool ! /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: Tuesday, October 05, 1999 1:30 PM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: At last - Microwindows/Nano-X Screenshots!!! OK, Thank you everyone for the licensing input, I learned alot. Sitting in frustration at home last night, I finally wrote a little program that reads the framebuffer and generates bitmap files. So, I ran through all the cool demos that I've got going, and we now have screenshot gif files for microwindows, as well as nano-X landmine, world, and widget sets running... There still on ftp, but have fun! ftp://microwindows.censoft.com/pub/microwindows/ScreenShots Note: the next release will include the makebmp conversion program, as well as support for screen dumping... Greg
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/
Licensing summary
On Tuesday, October 05, 1999 12:50 PM, Alex Holden [SMTP:[EMAIL PROTECTED]] wrote: : 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? Yes. I think I agree. But I want to be completely clear on David's code. His original code retains his original PDL license. The code that's included in nano-X and/or MicroWindows is a derivative work, and is not subject to any terms other than his original terms: leave the copyright notice intact. In addition, the "convert to" would be strictly GPL, not LGPL. What are the semantics of a "conversion", anyway? Greg
Re: Licensing summary
On Tue, 5 Oct 1999, Greg Haerr wrote: Yes. I think I agree. But I want to be completely clear on David's code. His original code retains his original PDL license. The code that's included in nano-X and/or MicroWindows is a derivative work, and is not subject to any terms other than his original terms: leave the copyright notice intact. That's the reason I thought we'd have to move David's code into seperate files- because his code wants to go into files with his Public Domain license on them, and the new code wants to go into files with the MPL on them. What are the semantics of a "conversion", anyway? You just redistribute everything under the new license. It would have to be a total conversion though, because the GPL wouldn't allow some GPL parts and some MPL parts, and I don't think it, or any improvements made to the GPLed version could be converted back to MPL without explicit permission of the author of the changes. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Licensing summary
- Original Message - From: Alex Holden [EMAIL PROTECTED] To: Greg Haerr [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, October 05, 1999 3:31 PM Subject: Re: Licensing summary On Tue, 5 Oct 1999, Greg Haerr wrote: Yes. I think I agree. But I want to be completely clear on David's code. His original code retains his original PDL license. The code that's included in nano-X and/or MicroWindows is a derivative work, and is not subject to any terms other than his original terms: leave the copyright notice intact. That's the reason I thought we'd have to move David's code into seperate files- because his code wants to go into files with his Public Domain license on them, and the new code wants to go into files with the MPL on them. No, I don't think we need to do that. We can do *whatever* we want as long as the copyright message remains intact, and that includes MPLing, GPLing, or ThisThatAndTheOtherPLing it. What are the semantics of a "conversion", anyway? You just redistribute everything under the new license. It would have to be a total conversion though, because the GPL wouldn't allow some GPL parts and some MPL parts, and I don't think it, or any improvements made to the GPLed version could be converted back to MPL without explicit permission of the author of the changes. The whole dual/conversion license scheme is confusing to me. Regards, Brad
RE: Licensing summary
On Tue, 5 Oct 1999, Greg Haerr wrote: No - this is specifically what we _dont_ want to do. David's license allows us to create derivative works and do what we want with it, providing that we leave his copyright notice intact. Ok. Does this mean that the tree would split at this point? I plan Only if the person who converted his copy to GPL decided to maintain a seperate, GPLed tree. The tree could also split for technical rather than license issues. Basically we only really want the GPL clause so that people who want to use parts of Nano-X in a GPLed project can convert those parts to GPL, but there's nothing stopping somebody who really hated the MPL for some reason from maintaining a seperate, GPL only tree of their own. This isn't likely to happen if the main MPLed tree continues to develop at a decent pace (the GPL tree maintainer would have to spend a lot of his time back-porting changes from the MPL tree to his GPL tree rather than working on new code). --- 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 (not silly licence thing)
On Mon, 4 Oct 1999, Greg Haerr wrote: The major changes in this release are: * wrote asm version of VGA driver for ELKS How much faster is this thing? Useable? Luke(Boo) Farrar.
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: new version of nano-X/microwindows (not silly licence thing)
* wrote asm version of VGA driver for ELKS : : How much faster is this thing? Useable? It's definitely faster, and it works. I use it for the ELKS port, which runs on _slow_ systems. Greg
