Open Source Licenses - A Quick Dive-In

in open •  8 years ago  (edited)

Open Source Licenses - A Quick Dive-In

Understanding the meaning behind the boring texts in open source licenses

Abstract

Every software developer sooner or later decides to use a  library, a framework, an already developed system or even a product that  uses or is published under an open source license. This article aims to  provide a simple, easy to understand interpretation of the rules in some  of the popular open source licenses and help developers and project  managers start understanding the basic concepts behind free software.    

Introduction

Open source software has become an important factor in the software  development industry. High-level strategical decisions, through  software engineering down to low-level development can be influenced by  the decision to use open source components. The benefits of  incorporating open source components are numerous - speed, quality of  development, achieving compatibility with other products, community  support, etc. However, the decision whether to do this or not often  depends on the applied license. Understanding the license is often a  difficult task due to the usage of complex words and phrases which  otherwise should satisfy legal norms.  

Common Truths

There are several common points that are true for all open source  licenses. Commonly a license addresses issues such as terms of usage,  distribution and modification. For example a license could limit the  usage to a number of cores in a machine, or number of simultaneous  users, or usage in time, just to name a few. Limitations are even harder  when it comes to distribution and copying. Generally, all open source  licenses are free from such kind of burdens. Open source licenses are  different from the ordinary end-user license agreements (EULA) for the  fact that they allow more than disallow. Telling if a license is a  “real” open source license or only named so is a difficult task. For  that reason, the Open Source Initiative (OSI) has created a list of  recognized licenses [1] which  follow the common principle of the open source spirit. In the rest of  this article, when we say “open source license” we will refer to those  recognized by OSI.  

Free Usage

Users of software published under an open source license should not  be afraid of running the software on as many machines as they wish,  provide it to as many users as they want or need and use it for whatever  reason they have in mind. This is the first important difference from  the proprietary software. And it has a great impact on taking the  decision to deploy or to use open source software.  

Free Distribution

Arguably, open source software would not be so popular these days  if it wasn’t its liberal distribution rules.The rules are very simple:    

  • Get it for free
  • Distribute the software to as many users as you can or wish
  • If you are skilled in sales, sell and re-sell it!
  • Distribute it in any form and on any media
  • Modify it and improve it

This is the second enormous difference to the proprietary software.  Users, salesmen and developers are given the freedom to access the  software and to further distribute it without consideration.   

Free Modification

While free usage and free distribution are important for users,  salesmen and decision makers, one of the most important sides of a  software published under an open source license is the opportunity and  the right to be able to have a look at, and even change the actual  source code. In certain cases, this is a vital right that gives the  developers and software engineers advantage, speed of development and  numerous direct solutions for hard to solve problems.  

Specific Obligations

While the characteristics mentioned above are common for all open  source licenses, there are major differences in certain obligation  clauses which can have critical impact on the way a project uses the  open source software. Depending on the license of the used software, a  project may need to publish part of or even all of its source code.  Generally, open source licenses are separated in two distinct categories  – those requiring compensation by opening the code that uses them,  often classified as “copyleft“, and those which do not insist on that, usually described as more “liberal“.  There are many debates on which of both types serves better the open  source spirit, a subject we are not going to discuss here. On the  opposite, software engineers, project managers and developers should  decide for themselves if a license is suitable or not for the project  they are involved with when it comes to a liberal or copyleft strategy.  

Popular Open Source Licenses

At the time of writing of this article the number of licenses approved  by OSI is more than sixty. This section covers only a small portion,  including the most popular licenses widely used in the open source  universe. However it can be said that the rest of the approved licenses  more or less share most of the special obligations covered by the  licenses described here. Arguably, the majority of open source projects  are licensed under one or combination of several of the following  licenses:    

  • GNU General Public License (GPL) – one of the  most popular licenses, the one used widely in Linux-based operating  systems. The typical representative of the “copyleft” type. The license  which is recommended and promoted by The Free Software Foundation [2].
  • GNU Lesser General Public License (LGPL) – a  less-restrictive “copyleft” license, slightly different than GPL for the  cases in which its “copyleft” obligation is applied.
  • Berkeley Software Distribution License (BSD) – a  traditional counterpart of the GPL license, for its liberal attitude  allowing commercial usage without obligation for direct compensation.
  • Mozilla Public License (MPL) – a balanced  license that tries to give respective freedoms to both commercial and  free software worlds. The license is endorsed by the Mozilla Foundation [3], thus most (if not all) of the projects supported by the foundation use it.
  • Apache License – a liberal license which does  not require from the derivative works to be licensed the same way, but  only “remind” of the usage of the Apache License in the distributed  software. Friendly to its usage in commercial software. The license is  authored and fully endorsed by the Apache Software Foundation [4], thus most of it projects are using it as a preferred license.
  • Public Domain – sometimes there are no specific  requirements or obligations accompanying the source code of a project or  a product. Sometimes for the reason of simplicity and attitude  developers decide to put no limitations, letting it be part of the  Public Domain. Shortly, public domain software implies no regulation in  the way the software is used.

Taking The Decision

There may be multiple reasons for avoiding usage of open source software, including but not limited to: 

  • Development model of the open source element
  • Obligations of its license
  • Usage of third party intellectual property
  • Support

Depending on the distribution policy or the business model of  the developer, it could be decided that all or none of the mentioned  reasons apply, or respectively that all of them are to be considered.  Independent on that, the license is usually the first legal base for a  decision, while the rest, still being as important as the license, often  will require a deeper investigation at a later stage of the decision. 

Decision Forces And Use Cases

When it comes to the license, your decision will be affected  by several forces. Knowing well the priorities and the requirements of  your project which these forces imply will give you a fast answer to the  question “To Use or Not To Use?”. Of course these forces are not  self-excluding and the decision should be based on a combination of  them, depending on their weights. Here are some of the well known ones:

  • Type of Usage –  Depending on whether the software that will include an open source component will be developed for commercial usage or on the opposite, for non-commercial  may have impact on your choice for a liberal or a copy-left license.  Liberal licenses such as Apache and BSD are often preferred because they  allow other applications to “wrap” them without the need to disclose  already developed source code, thus preserving the investment behind its  development. On the opposite, if the software is to be published for  non-commercial usage, both liberal and copy-left licenses are  appropriate. The concrete selection depends on whether you see making  the software open source as a viable development model, thus selecting a  copy-left license, or it is to be developed privately and selecting a  liberal license (see bellow) which will not force you to open the entire  product.
  • Type of Development – Sometimes opening the source  code of an already developed software makes sense in business or  strategical aspect, for example if the target is to get contribution by a  larger audience of software developers with little or no direct  investment in development. If the type of development is open then  considering copy-left license is a sane choice for it enforcing the very  core idea of keeping the code open source, eventually reaching a larger  base of developers being able to look at the code through all its  iterations of change and avoiding closed evolution. On the other side,  preferring a closed model of development, where a selected number of  developers work together, the used component should not affect the  process of development. This really means that the license of the  questioned piece of software should be liberal enough.
  • Affected Architectural Layers – The type of open  source license provided by a component may affect the architecture or  the building structure of the software using it. Depending on its place  in the chain of links between software parts it could be decided if its  usable or not. For example, if the component is a library and it is  licensed under the GPL you will be obligated to open the entire code of  your application. But if this library is licensed under the LGPL it is  not necessary unless you change the code of the library, then developers  are obligated to release the code of the changes applied to it. The  LGPL license is primarily designed to be less-restrictive when it comes  to usage of the open source code as a library, while at the same time it  insists on giving back code whenever the licensed code has been  changed. It is evident that if a library is licensed under Apache or  BSD, no restrictions or obligations apply related to software code  disclosure. Further, there are cases where the open source component  under question is a whole framework on top of which whole new systems  can build. Again, the license will decide if developers need to open  source upper layers or not. However, even a GPL licensed development  framework may declare the so called “exceptions” which allow specific  licensing of the elements using it. An example for this is the popular  platform for development – the Java Development Kit. It has been  licensed under the GPL but still allows applications which are built on  top of it to be licensed under a different license.

Open Source in the Wild

The principles mentioned here may sound idealistic or it may be  hard to believe that commercial products benefit from open source by  both leveraging existing code and giving out code. But there is already a  large list of consumer and business products that managed to get the  best out of the open source world. And, vice versa, some of the products  in the wild are using open source code, but try not to follow the  licenses, because they are either afraid their intellectual property  will be lost or they just don”t understand the importance of following  license rules. Thus, there are community supported initiatives like the  “GPL Violations Homepage” [5],  which try to defend the rights of the developers publishing under GPL.  

Conclusion

Deciding on whether to use an open source component or not is a  complex task. This article constitutes a brief overview of the key  principles of open source licensing. It introduces the initial basis for  considering the usage of third party open source components. Because of  the nature of the open source culture and because of the rich diversity  of projects licensed under an open source license every particular  component needs a proper evaluation and investigation regarding its  license, intellectual property, development model, community, support,  and other factors that might influence directly or indirectly the  development and the distribution of software using it.   

References

open opensource licenses software legal
8 years ago by

Downvoting a post can decrease pending rewards and make it less visible. Common reasons:

  • Disagreement on rewards
  • Fraud or plagiarism
  • Hate speech or trolling
  • Miscategorized content or spam

Submit
$0.00
    4 votes
    0
    Authors get paid when people like you upvote their post.
    If you enjoyed what you read here, create your account today and start earning FREE STEEM!