Last month I touched briefly on copyright and this month I would like to continue the theme of intellectual property by discussing licenses.

Initially software was not able to have a copyright.

If the sources were exposed and there was no contract, then, basically, the software was in the public domain and people could do whatever they wanted with it.

Copyright applied to software changed all that. In most jurisdictions, the copyright was generated automatically and the sources and binaries of the code were not authorized for copying or even use.

One or more licenses had to be applied to the software (either in source code or binary form) that told the user about what rights they had with that software.

Working for Digital Equipment Corporation (DEC) at that time, my colleagues and I were required to write specific licenses for our software products. We had to learn the specific legal terms for the software we obtained from our sources and realized that in many cases we were a "sub-licensee." The originators of the software still had certain legal rights to it that we had to protect. Some of these rights we passed on to our customers, and some we retained.

For example, in most cases, we were not authorized to pass on the source code to our customers because the supplier still maintained the source code rights to the binaries we supplied. A prime example of this was Adobe's Display PostScript engine that went into our X Window System server that rendered Display PostScript on our workstations. There were only two software engineers at DEC who could see that source code, one for Digital UNIX and one for OpenVMS.

When DEC's customers wanted to get the source code for Ultrix (as an example), which was based on 4.1c BSD Unix, the customer first had to buy a Unix source code license from AT&T, then buy a source code license from DEC, then buy a source code distribution from DEC, and they still could not compile and build the entire system. "Pieces" were missing, not because DEC did not want to pass them on, but because DEC could not pass them on.

Another interesting part of licensing was the licenses that universities like University of California, Berkeley; MIT; Carnegie Mellon; and others had in their source code. These universities typically wanted to give their software away to other universities to collaborate with research. However, they did not want to spend thousands of dollars in legal fees for each copy of the software when they were not going to sell it. So they hit on the plan to embed a license into the source code that not only told the users what their rights were, but also worked to indemnify the university, because the software was not warranted for any specific use.

Different universities had different desires, so there were various licenses with certain minor differences.

Over time there were other entities that wanted to get credit for the software, have changes to the software returned to them so they could fix them, or get feedback from the use of the software.

Add in commercial companies with their changes, and soon there was a plethora of licenses out there, with only minor (and usually useless) differences.

Eventually it was recognized that the licenses were too cumbersome, particularly when taking all of these licenses and trying to combine them onto one CD/DVD/ISO. The distribution's lawyers would have to read every license and see if they were compatible.

So a group of people got together and sorted through the licenses, separating out all the similar licenses and putting them into two main groups: "permissive" and "restrictive."

The permissive licenses typically had the least requirements for the developer using the sources to pass on their source changes, either to the next developer or the end user. The restrictive licenses, of which GPL is the most famous, required the user of the sources to pass their changes on to the next developer or the end user.

The collection of all of these licenses were called "open source." However, it is worthwhile to explain the real differences between permissive and restrictive licenses.

Companies and developers love permissive open source. They get to use the sources that others have developed, which allows them to make products faster and with tested code, yet they are not forced to pass on their intellectual property to their competitors or to their customers. Their customers have to wait for the developers to produce the changes the customer needs or the bug fixes.

Customers love restrictive open source, better known as free software. With free software the customer can support their own software. They can find other programmers who have the expertise to fix it and not be dependent on the developers that made it. Software freedom.