Date: Fri, 13 Nov 1998 10:03:59 +0100 From: Juergen Nickelsen <ni@tellique.de> To: freebsd-chat@FreeBSD.ORG Subject: Re: gpl'd diff files Message-ID: <364BF5FF.C5C2A1D1@tellique.de> References: <199811050828.AAA00949@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: [a patch distributed under the GPL] > If you use code substantially from the patch, then you will be > required to GPL-infest everything you use the code in. The > definition of "derivative work" is pretty broad - you can probably > get away with using information (eg. register maps, hardware > interface procedures) obtained by reading the code, but if you copy > code from the patch, you lose. In this context it may be instructive to quote Richard Stallman, when he writes about how Unix programs can be rewritten for the GNU project (from http://www.gnu.org/prep/standards_3.html): Referring to Proprietary Programs Don't in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.) If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results. For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in core and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler). Or, on the contrary, emphasize simplicity instead of speed. For some applications, the speed of today's computers makes simpler algorithms adequate. Or go for generality. For example, Unix programs often have static tables or fixed-size strings, which make for arbitrary limits; use dynamic allocation instead. Make sure your program handles NULs and other funny characters in the input files. Add a programming language for extensibility and write part of the program in that language. Or turn some parts of the program into independently usable libraries. Or use a simple garbage collector instead of tracking precisely when to free memory, or use a new GNU facility such as obstacks. Of course this is about GPLed software versus UNIX(TM) software, but I think some of it can be applied to BSD-licensed software versus GPLed software as well. -- Juergen Nickelsen <ni@tellique.de> Tellique Kommunikationstechnik GmbH Gustav-Meyer-Allee 25, 13355 Berlin, Germany Tel. +49 30 46307-552 / Fax +49 30 46307-579 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?364BF5FF.C5C2A1D1>