5.3 Encumbered Files

It might occasionally be necessary to include an encumbered file in the FreeBSD source tree. For example, if a device requires a small piece of binary code to be loaded to it before the device will operate, and we do not have the source to that code, then the binary file is said to be encumbered. The following policies apply to including encumbered files in the FreeBSD source tree.

1. Any file which is interpreted or executed by the system CPU(s) and not in source format is encumbered.

2. Any file with a license more restrictive than BSD or GNU is encumbered.

3. A file which contains downloadable binary data for use by the hardware is not encumbered, unless (1) or (2) apply to it. It must be stored in an architecture neutral ASCII format (file2c or uuencoding is recommended).

4. Any encumbered file requires specific approval from the Core team before it is added to the CVS repository.

5. Encumbered files go in src/contrib or src/sys/contrib.

6. The entire module should be kept together. There is no point in splitting it, unless there is code-sharing with non-encumbered code.

7. Object files are named arch/filename.o.uu>.

8. Kernel files:

   1. Should always be referenced in conf/files.* (for build simplicity).

   2. Should always be in LINT, but the Core team decides per case if it should be commented out or not. The Core team can, of course, change their minds later on.

   3. The Release Engineer decides whether or not it goes into the release.

9. User-land files:

   1. The Core team decides if the code should be part of make world.

   2. The Release Engineer decides if it goes into the release.