A brief look at who really owns your software.
Disclaimer: I am not a lawyer. This article is not legal advice, just an opinion.
Why write an article on software licensing?
Programmers don't usually think about licensing. We are definitely guilty of this. Our need to think about licensing cropped up when a customer started selling their business. The buyer asked, quite reasonably, who owns the software? Is it really ours to pass on? The answer is both simple and convoluted.
This simple answer, when a customer pays us to write software, the resulting code belongs to the customer. We do not retain an interest or charge royalties for the software we have been paid to create for a customer.
There are a few caveats to the ownership. The software we develop is subject to Open Source Licenses, our framework license, Public Domain "fair use" and software patents.
All of the below is common practice in the software development industry.
Open source software
Our software includes components from open source, which are subject to open source licenses. I will only touch on a couple of issues with open source licenses. For a detailed look into open source licenses look here https://opensource.org/licenses
Popular open source licenses include the GNU General Public License (GPL), Lessor General Public License (LGPL), Apache License and MIT license.
Typical open source software licenses allow customers to freely use, modify and redistribute software while the creator of the software retains copyright. The licenses also make it clear that the software owner has no liability or warranty obligations to users of the software.
Copy-left vs permissive license
The term Copy-left is a play on copyright. Copy-left licenses require programmers who include copy-left software in their own software to release their creations under the same copy-left license. The intention behind copy-left licenses is preventing commercial operators taking advantage of large bodies of open, free work and without giving anything back to the community. GPL is the most well known copy-left license.
Permissive licenses are the opposite of copy-left licenses. Permissive licenses allow the user to do what they like with the software. The license is in place so the creator can keep ownership of their work and to protect the creator from any liability if material defects are discovered in their code. MIT License and Apache License are examples of permissive licenses. MIT is my favorite because it is very short and to the point.
Hosted Software
There is provision in GPL licenses to allow companies to use GPL software in hosted web applications without giving away their own software. Simply hosting software and allowing customers to access the web application does not trigger the GPL requirement to make the code freely available. If at some future point, the software is sold to another party to host on their own servers all the software must be given to the third party, including source code.
With the IT world shifting to a cloud hosted model, GPL licensed software has never been an issue for us. All the software we create is hosted on a server, either our own server or a customers server.
There are even more restrictive licenses, such as the AGPL, which insist software source code is freely redistributed even if the software is cloud hosted.
Dual Licensing and GPL Stripping
The are companies which cannot accept the provisions of GPL licenses and will not use software licensed under the GPL.
Some software products will be dual licensed. There is a GPL license for general public use and a private license for customers willing to pay. This creates a clean solution for customers consuming the software and a revenue model for creators.
Alternately, to avoid the restrictions imposed by the GPL, it is possible to find and replace all GPL licensed components from a software project. This exercise is significant but do able.
Our Framework
Often when creating web application software, developers will use a software framework. There are many third party frameworks available, usually licensed under a permissive open source license. We, like many other software developers, have developed our own software framework and license it under the permissive MIT License
Frameworks make development faster, easier and more consistent. The framework handles generic tasks such as connecting to the database, managing files and images, manipulating dates, user authentication and other generic tasks needed for building web applications. Frameworks are integrated into the custom software developed for customers.
Why do we license our framework? Originally we had a clause in our general Terms and Conditions stating we could reuse generic pieces of code found in the customers software. When one of our customers went to sell their business we realized this clause looked out of place. So, we removed the clause, copyrighted our frame work, then licensed it under the MIT license. This brings our framework ownership and usage rules in line with other third party frameworks.
From our customers point of view, they can do what they like with the software. From our point of view, we can reuse generic pieces of code to improve delivery times and stability of future projects, and prevent our developers from getting too bored from doing the same thing over and over.
The Public Domain
There was a time before the world wide web became the repository of all knowledge. In this long forgotten time, if a software programmer needed help writing a line of code, she would refer to a manufactures manual, a media company's magazine or maybe phone a friend. The ownership of that line of code was obvious.
Today, when a developer needs help with a line of code, they will Google the answer. At maffey.com we often refer to and copy lines of code from public forums such as stackoverflow.com or forums hosted by software manufactures. Some of the lines of code we copy have licenses and copyright attached to them, for example stackoverflow.com attaches a creative commons license to content contribute to their forum. The owners of stackoverflow.com insist contributors have the necessary permission to share their code.
In many cases the contributors will not have clear ownership or rights to publish the code they are contributing. The contributor may have written the code in work time, so the code likely belongs to their employer. Or the contributor may have copied code from another forum. The code might even be directly out of the manual.
From our point of view, copying a few lines of code from the public domain constitutes “fair use” if there is any question of copyright infringement. Although, technically, the ownership and rights could be contested.
As an analogy, imagine a cake recipe from a magazine. Do you check the copyright attached to the recipe before making it? Does the magazine have a © all rights reserved clause in the footer? If the recipe calls for brown sugar, and you substitute with castor sugar you are modifying the recipe. Does the copyright allow for modification? If you modify the recipe are you meant to report the change back to the recipe owner? Can you tell a friend about the recipe? If a recipe includes technical tips, for example how to get the softness of butter just right, do you need to ask where this tip come from? Is that tip taught from copyrighted course material at a cooking school? Sounds ridiculous! This is the nature of copyright issues that could arise when using code from the public domain.
"Fair use" of code found in the public domain is a common sense issue. A good way to determine fair use is with quantity. Arguably if code fits on one page, it is fair use to copy. Copying a whole program or application without permission is a blatant breach of copyright. Anything in between grey. Following the cake analogy, consider the difference between a baker using and modifying a single recipe vs copying a whole cookbook.
Software patents
Everything you see on your computer screen has a patent attached to it. Apple Inc has a patent on scrollbars, IBM has a patent on hyperlinks, some patent troll has the patent on putting a hyperlink in a txt message. It is not possible to put together a software application without infringing on software patents.
Large tech companies register arsenals of patents. Google even purchased Motorola, transferred all of Motorola's patients to Google, and sold the rest of the company soon afterwards. Tech companies are not using these patents as a direct source of revenue, rather as a form of protection against other patent holders. Call it a "mutually assured destruction" policy should a legal patent war break out.
Patent trolls register patents or purchase companies holding patents to blackmail and sue innocent organizations using well established tech. This includes suing charities for using the scan-to-email feature on a photocopier to restaurants for offering WIFI to customers.
The problem with software patents and patent trolls seams limited to the USA.
In conclusion
When we produce software for a customer, the code largely belongs to the customer and the customer does not pay us a royalty.
We reuse generic parts of the software, the software framework, to build software for other customers.
Components of the software will be copyrighted by open source developers. This does not prevent the customer from using and modifying their software.
GPL licenses require the software source code to be re-distributed if the software is re-distributed to third parties.
Every software developer will be cutting and pasting "fair use" size chunks of code from public domain sources.
The plague of software patents can affect any organization at any time.