Software Copyright Evolution
Doghouse – Licenses
From no licenses to too many, software copyright finally made its way to including today's free software designation.
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.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Gnome Fans Everywhere Rejoice for the Latest Release
Gnome 47.2 is now available for general use but don't expect much in the way of newness, as this is all about improvements and bug fixes.
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.