The term open source refers to something people can modify and share because its design is publicly accessible. Open-source software (OSS) is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software to anyone and for any purpose.
Whether OSS or not, A software license is a set of legal conditions for the use or redistribution of software. A typical software license grants the licensee, typically an end-user, permission to use the software in ways where such a use would otherwise potentially constitute a breach or infringement. By the same principle, OSS licenses are licenses that comply with the principles of distribution terms of open-source software — in brief, they allow software to be freely used, modified, and shared.
What are our options while choosing a license or choosing an OSS component?
It all depends on your project and business approach. If you are a commercial establishment and want to keep the final output (software product) as a proprietary software and do not want to share with outside world, you should prefer MIT, Apache or BSD license. These licenses, as applied to the original licensed code, allow that code to be used in proprietary software and do not require that open source versions of the code be distributed. Code created under these licenses, or derived from such code, may go “closed” and developments can be made under that proprietary license, which are lost to the open source community. For the same reason, however, these licenses are very flexible and compatible with almost every form of open source license.
The MIT license is an attractive option for many as it allows you to share the code under a copyleft license without forcing others to expose their proprietary code, it’s business friendly and open source friendly while still allowing for monetization. Being a short, simple and permissive software license, you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source. There are many variations of this license in use. But this grant of rights under MIT is subject to conditions: The copyright notice and the permission notice shall be included in all copies or substantial portions of the software – irrespective of the mode of your usage – whether you are forking it or not. “Forking” is when you clone the open-source product and customize it to your needs.
The only real conditions of using MIT licensed software is that the copyright notice must remain intact. That means name and the dates of original copyright author need to be part of the license file and then you add your own name and dates next to or below the original notice.
Unlike other licenses like the GPL that require you to make a copy of the source code to any user of the software, the MIT allows you to keep your source code private so long as you give credit in the license file along with a copyright notice. The MIT license allows you to use your code for commercial purposes. It’s your code so you should be able to do this regardless. What’s great about this condition of the MIT license is that other users of your code can use it for commercial purposes.
The following text is an indicative way to include the copyright notice and permission details to be included:
Begin license text.
Copyright <YEAR> <COPYRIGHT HOLDER>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
End license text
The <year> and <copyright holder> tags refer to the date of publication of the code and the person in whom the copyright is vested, which is generally going to be the creator of the code. This part of the license essentially surrenders all of the rights that the copyright holder typically receives, including, the exclusive right to commercially exploit the work and to develop derivative work from the work.
The Apache License is a permissive free software license written by the Apache Software Foundation (ASF). It allows users to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software under the terms of the license, without concern for royalties. The Apache License is very similar to the MIT Licenses already described.
BSD licenses are a group of permissive free software licenses, imposing minimal restrictions on the use and distribution of covered software. This is in contrast to copyleft licenses, which have share-alike requirements. The abbreviation BSD stands for, the Berkeley Software Distribution (BSD), a Unix-like operating system. The original version has since been revised, and its descendants are referred to as modified BSD licenses.
GNU General Public License:
The GNU General Public License is another widely-used free software licenses that guarantee end users the freedom to run, study, share, and modify the software. The GPL series are all copyleft licenses, which means that any derivative work must be distributed under the same or equivalent license terms. This is in distinction to permissive software licenses, of which the BSD licenses and the MIT License are widely used, less restrictive examples. Also, The licensee is allowed to charge a fee for this service, or do this free of charge. In fact, the GPL explicitly states that GPL works may be sold at any price.
But the tricky part is, while giving the right for commercial usage, if someone want to improve an open source project and plan to make some monetary benefit, the GPL forces that author to expose how they made the original better. For this reason, it is a strong copyleft and open source license and ensures that all released improved versions are kept as free software. By using this you can avoid the risk of having to compete with a proprietary modified version of your own work. Therefore, the incentive to improve on software for commercial purposes is highly diminished when something is licensed under the GPL.
An alternate form of copyleft, the GNU Affero General Public License (AGPL) is designed for programs that are likely to be used on servers. It ensures that modified versions used to implement services available to the public are released as source code to the public.
Do we need to opensource it all the time?
The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.
In a custom software development transaction, we may come across various clients who have the fear of OSS due to various reasons. They may be worried about no-liability on the consulting company and “as ‘is” warranty conditions. Generally, they may come up with a language like this: “Vendor warrants that the Licensed Software does not include open source software.” In most cases, that’s not a prudent approach. Excluding OSS altogether is sometimes impossible or unnecessary and not a business friendly approach, since it means developers have to write more code from scratch. As agile and DevOps increasingly dominate the tech world, software development lifecycles are shortening. Open source libraries offer a wide range of ready-made components that can help you cut the time it takes to develop a product.
The below language will address these concerns to a certain extent, if the software developing client is in a position to advise the client on OSS licensing conditions, “Vendor represents and warrants that the Licensed Program does not include software subject to any legal requirement that would restrict Licensee’s right to distribute or otherwise provide deliverables or part of it to its customers or third parties of its choice”.
Begin license text.