Hi all, I partially agree with Steve (-uso): Lets get back to work. But not to write a new kernel. Better option is to keep UPX as default exepacker and let everybody have their own decision whether they compile their own aPack-ed kernel. At most spreading an aPacked kernel could conceivably trouble GPL. On the other hand: The stub for aPack decompression is built by software, not by an human... probably a special case. And feels a lot like "aPack stubs are similar to compiler stuff and therefore okay to have inside the binary". By the way, I UPXed my Linux mplayer binary yesterday - with the open source variant of UPX ;-).
And yes: Of course you can release your code under SEVERAL licenses if you want to do so. There are even examples on the GNU.org site: Some licenses are "you can use either license X or Y at your option". For example if you think GPL limits you, release your code under Public Domain non-license, too. I myself prefer not to do so for bigger projects because GPL encourages people to add their own OPEN code to create other open projects. You cannot really keep code away from "bad guys": Compare MS DOS 6.xx, where they first had a compressed filesystem with license troubles and later replaced it by a freshly written clone of the same IDEA. Still I like the "virus" effect of GPL somehow :-). By the way, about 386 stuff: When in doubt, protect all registers or revert to 286 optimizations until compilers become smarter. How much difference in speed and kernel size does 386 optimization make anyway? Eric. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
