The following was presented on Usenet by Terry Lambert, who has been heavily involved with design work on the free BSD implementations. I have cleaned up the wording a bit; I have no problems with any of the points he made.
The standards to which it conforms are available without license or requirement of non-disclosure to X/Open, The Open Group, CCITT, or any other standards licensing body.
POSIX-implementing OS's are non-proprietary, since you can freely obtain the NIST/pcTS (POSIX Conformance Test Suite), even though POSIX branding and the POSIX standard are technically proprietary.
The language(s) in which the OS is implemented are publically available.
Language implementations need not be freely available, but that is to be encouraged.
The OS's APIs are fully documented.
Source available OS's are fully documented, since the source that implements the APIs can be freely examined (though secondary documentation on most source-available OS's is often poor; tertiary documentation in the form of white papers, algorithms, etc., is generally good. But we are concerned with primary documentation).
The OS's ABI's are fully documented.
It is possible to turn non-standards conformance "extensions" to base functionality OFF.
Example: The primary problem Unix has traditionally had is Unix vendors, like USL, squabbling with other Unix vendors, like SCO, by adding "extensions" to make applications for their platform not run on their percieved competition's platforms. In general, this is the "We can't compete with Microsoft" mentality.
Examples abound; but the clearest indication is that there is no "big red switch" to turn off extensions so applications developers can develop without using the extensions accidently, and thus be guaranteed that their software will run on all Unix platforms.
Source available OS's qualify (albeit poorly) under this rule, since you could modify the source to turn off extensions.
Side note: IMO, the x86Open group will not be able to meet this criteria, since they have not picked a subset of a commercial OS's ABI to standardize on (Given the software base, Solaris seems the best bet). If a source available OS could guarantee that you could flip a "big red switch," and all developers were guaranteed that code written using that platform would run, unmodified, on that platform, other source available platforms, and one or more commercial Unix implementations, then that OS would instantly be the reference platform of choice for all future Unix work.
The use (not utilization) of applications built on the OS is not restricted.
This somewhat covers the API, but it also covers the licensing issues that some platforms have.
No, I am not referring to the GPL, since it does not affect applications built on a GPL'ed platform; I am referring to the new JAVA license compared to the old JAVA license, and specifically, the classes.zip file and the licensing and distribution restrictions.
Applications developers and end users have an instrument for effective feedback to the OS developers/vendor.
If the architecture of the OS makes it impossible to achieve some goal because the OS is architected in a way as to deny the goal, then it must be possible to get the architecture changed. A good example here is the MS press release stating that they would be adding "RealTime-Like features." Vague similies do not a scheduler capable of running a "Mars Pathfinder" make.
No baseball trading cards.
The OS must not rely on patented algorithms (yes, I know that this is a US problem) or cryptographic algorithms that are not available in all countries which allow their import (countries that don't allow cryptography import are specifically omitted, since they are intentionally shooting at their feet).
The OS must not rely on restrictively licensed reference implementations. A good example from the Unix world is "Motif;" it is a "standard," but in order to use it, you must license the technology from The Open Group.
For all technology dependencies, there must be a freely available reference implementation.
If the reference implementation makes inheritable licensing restrictions (as GPL does), the technology must be severable.
For example, if the technology were LDAP, the LDAP reference implementation could be GPL'ed, and since it is architected to be severable on defined API and layering boundries, it is acceptable as a technology dependency.
The OS must enforce non-promiscuity.
An applications vendor should not be permitted to take advantage of a covert channel with the OS that another applications vendor could not also utilize.
For example, if an application vendor knew an OS had a "magic API" for doing globbing in the kernel instead of user space, and that as a result of that, the amount of non-applicable data being pushed across the system call interface was drastically reduced (example: a directory iteration interface for use by a visual browser, which could be asked to return only files of a specific type), the "magic API" must be documented or it must be removed.
This is somewhat the same as #3 and #4 combined, but it must be explicitly stated that, though an OS is permitted to have proprietary extensions which may be probed for and utilized by an application, there should be a sharp distinction drawn between the application running bettter on the OS because of the extension, and the application being unable to run equivalently on another OS because the information needed to implement the extension was proprietary.