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
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)
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: 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: Licensing summary
: 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 - 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. If we have to rewrite _any_ of Dave's code, I need to know now. This will greatly affect the Xlib project. It doesn't affect MicroWindows so much. : : > 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. Does this mean that the tree would split at this point? I plan on remaining the maintainer of the project, and don't want two trees. Greg
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: > 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/
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: Request for comments - Microwindows
On Tue, 5 Oct 1999, Alan Cox wrote: > This is going on far too long and round in circles. Greg and Alex - pick > something, stick a license on it all , say so publically and be done. It > does more harm now than whichever is picked Right, I vote for MPL with a "convert to GPL/LGPL" option, with David's original code retaining it's current Public Domain license. Vidar has already said he's happy with that. Greg? --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
RE: 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: 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
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
The restrictions of not being able to produce a binary w/o code/obj files has already been mentioned as a restriction. BSD is an attractive way of getting around it. As far as I know, Allegro has never been truly PD. Formally Swapware or at least give me a copy of your autoexec.bat and now Giftware or add something to the code base if you use it and if you can. In a sense, Allegro is PD...but not completely free. -- "It's not about the money...It's about the rules. Without rules, we might as well be tree climbers flinging crap at each other." - Red Foreman of That '70s Show On Tue, 5 Oct 1999, Alex Holden wrote: > On Mon, 4 Oct 1999, Louis P. Santillan wrote: > > A few more logs for the flame (err...thread), BSD and Dave's original > > license? Maybe even a NASM type license, short and sweet, with > > restrictions against those who would like to use the code for commercial > > purposes. IMHO, the GPL and LGPL are too detailed and too restrictive. > > What kind of restrictions? > > > People who enjoy the code should use the code. Maybe those who have evil > > commercial purposes should be punished, but they should not be completely > > prejudiced against. I think the intent is to make the Nano/Micro series > > a standard for small systems. I also like Allegro's gift society type > > license though it may not be restrictive enough for some. > > The latest version of Allegro is now fully Public Domain. >
Re: Request for comments - Microwindows
> Actually, the BSD and X licenses best reflect the needs of embedded > developers. The X one does. The BSD original format doesnt. The advertising clause got a netbsd router project by a very large networking company canned
Re: 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: Licensing summary
On Tue, 5 Oct 1999 09:59:51 -0400 you wrote: >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. Consider this: I go to a company, because I _need_ their hardware for my project, and I want to use NanoGUI. They say: Fine, but you can't release the source or object code. The result? I choose something other than NanoGUI. Hardware is what drives our cost, and if I'd have to choose more expensive, or inferior hardware to be able to use NanoGUI, then NanoGUI - *not* the hardware - would be what I would consider my problem. >> 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. It's a completely different market. Gnome doesn't run on any systems that doesn't support networking or dynamic linking. It also isn't used primarily in an environment where many companies have policies that prevent you from licensing your software for use with LGPL'd or similar licenses no matter how you do it. >> 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. An FreeBSD etc. doesn't. That Linux does isn't an argument for or against requiring it for NanoGUI. >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. You see it as a flaw, some see it as a feature. It hasn't stopped Mozilla for instance from getting massive amounts of new contributed code, even outside the standard code base, and at the same time it has attracted lots of companies that wouldn't have considered it had it been under the GPL or LGPL, but that nevertheless contribute at least parts of their code back. >> 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? No, but if you use GPL or LGPL, you don't let everyone use it as they please. In fact, you exclude a rather large part of the embedded and small devices community. >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. How come XFree has been so successful, then, if a license as restrictive as the GPL is required? >It really comes down do this: are we committed to free software, or are we >just trying to please everyone? I am comitted to whatever give me a good platform to develop embedded and small systems solutions on with the minimum hassle. If the NanoGUI license gets to restrictive, I will simply go and find some more suitable project. >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. Would there be X? X is a lot more widespread than GNU or Linux, so according to your argument, maybe we should accept the XFree or X consortium license. The reality is that comparing to X or Linux or GNU is meaningless. This is a completely different area, and a type of devices where most users will never even install any software themselves. Regards, Vidar
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: Request for comments - Microwindows
On Tue, 5 Oct 1999, Alan Cox wrote: > The MPL is also the only one that sanely reflects embedded system licensing Actually, the BSD and X licenses best reflect the needs of embedded developers. Jamie
RE: Request for comments - Microwindows
On Mon, 4 Oct 1999, Louis P. Santillan wrote: > A few more logs for the flame (err...thread), BSD and Dave's original > license? Maybe even a NASM type license, short and sweet, with > restrictions against those who would like to use the code for commercial > purposes. IMHO, the GPL and LGPL are too detailed and too restrictive. What kind of restrictions? > People who enjoy the code should use the code. Maybe those who have evil > commercial purposes should be punished, but they should not be completely > prejudiced against. I think the intent is to make the Nano/Micro series > a standard for small systems. I also like Allegro's gift society type > license though it may not be restrictive enough for some. The latest version of Allegro is now fully Public Domain. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
On Mon, 4 Oct 1999, Bradley D. LaRonde wrote: > Why give up your right to release source code? Why not tell that vendor > "I'll sign and NDA, but only with the condition that I can release my work > open-source." I have. That's what we usually try. If you're only a small company making less than a few thousand units, it often doesn't work. There's also the situation of large closed source software systems too- for example you can license the code to decent voice recognition software... You can't easily reverse engineer something like that- it's easier to spend a few months or years writing it again. In the case of a company, it's much cheaper to spend say $2 licensing some closed source code than it is to have a team of developers spend a year or so rewriting it from scratch. --- Linux- the choice of a GNU generation. -- : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham : http://www.linuxhacker.org/
Re: Request for comments - Microwindows
> So - we don't _have_ to separate any code. David's original > code is available on Alex's and my ftp server. Correct? Correct
Re: Request for comments - Microwindows
This is going on far too long and round in circles. Greg and Alex - pick something, stick a license on it all , say so publically and be done. It does more harm now than whichever is picked I've been through the licenses with respect to embedded system issues o GPL Means people can't provide nonfree apps of any kind using nanogui without writing a nonfree library clone. The only one that stops users writing binary only extensions/modules. o LGPLMeans people can build apps and servers with some non free components and programs. This still causes big problems for some standard embedded uses - DVD is the big one. The rules on protecting the DVD crypto are draconic and not the vendors fault. Only when the DVD cracking is finished would they go away. o MPL Easier than (L)GPL to add private extensions. Doesn't require relinkable object modules and the like. Does require source is made available to MPL'd modules The MPL is also the only one that sanely reflects embedded system licensing because it doesn't require written offers of media which are difficult to manage but instead requires the source is somewhere publically available - eg for FTP. Alan
Re: as86 .o file runtime loader completed
Greg Haerr writes:
>
> 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.
Sounds cool.
>
> 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.
There are several reasons why this is not a serious obstacle. Firstly
if the program, take as an example microwindows, wants to be able to
load a device driver for the type of graphics card it is going to use.
The maximum size of the largest driver can be measured at compile time
at statically allocated in the code segment as follows:-
int module_init(arg)
int arg;
{
#asm
ret
.blkb TEXTSIZE-1
#endasm
}
This is not very flexible, but it would work, and was the way space was
allocated in a very primitive module system I build for ELKS with Rob's
help a while back. The system itself was basically useless, but making it
was educational. In the case of using your code to load kernel modules, the
kernel loader can be modified to leave the full 64K of the kernel code
segment allocated so there is room at the top for modules. Space would
also have to made available at the top of the ds. Actually writing the
code to the code segment is a case of writing a simple memcpy_tocs()
function.
>
> 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.
>
I assume by single import you mean that the module has a single linked
entry point? This would be no problem for driver modules for most things.
I would really love to see your code if I may.
Al
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
