Go to the first, previous, next, last section, table of contents.

# Keeping Free Software Free

This chapter discusses how you can make sure that GNU software remains unencumbered.

- Reading Non-Free Code: Referring to Proprietary Programs
- Contributions: Accepting Contributions

## 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.

## Accepting Contributions

If someone else sends you a piece of code to add to the program you are working on, we need legal papers to use it--the same sort of legal papers we will need to get from you. Each significant contributor to a program must sign some sort of legal papers in order for us to have clear title to the program. The main author alone is not enough.

So, before adding in any contributions from other people, tell us so we can arrange to get the papers. Then wait until we tell you that we have received the signed papers, before you actually use the contribution.

This applies both before you release the program and afterward. If you receive diffs to fix a bug, and they make significant changes, we need legal papers for it.

You don't need papers for changes of a few lines here or there, since they are not significant for copyright purposes. Also, you don't need papers if all you get from the suggestion is some ideas, not actual code which you use. For example, if you write a different solution to the problem, you don't need to get papers.

We know this is frustrating; it's frustrating for us as well. But if you don't wait, you are going out on a limb--for example, what if the contributor's employer won't sign a disclaimer? You might have to take that code out again!

The very worst thing is if you forget to tell us about the other contributor. We could be very embarrassed in court some day as a result.

Go to the first, previous, next, last section, table of contents.