Easy open source licenses

A simple description of open source licences so you’ll know how to use them

The Open Source Community and Licenses

The open source community creates and uses free software. A copyright ensures that the author possesses exclusive rights to their product. With a licence the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose as long as they follow the terms of the licence it was distributed under. Here at Wanariwe often come across libraries that fall under different kinds of regulations. If you come cross this topic for the first time it’s not necessarily the easiest to wrap your head around. There are several articles and websites concerning the topic of open source licences – some of which will be linked at the end of the post.
The main purpose of this article is to make it easier for open source developers to choose a licence for their software and to provide basic knowledge about the topic. However this post may not be considered as legal advice – it is only a guide to the world of open source licences.

Currently there are tons of open source licences being used all over the world but the majority of them fall under only a couple of types. This post will be focusing on those most popular, most widely used licences.

Note: If you don’t provide any licence to your software, it will be copyrighted automatically. People may read your code and learn from it but any other use of it is illegal without permission. To utilize any part of the product people need to contact you personally. When you try to invest into the open source community, you may want to choose one of the licences below to avoid the inconvenience of not having any.

The following paragraphs will be describing these three main types of open source licences:

  • public domain
  • permissive licences
  • protective licences

Open source licenses - What is GPL?

Public Domain

If you want your software to be freely available to anyone with no strings attached, you may put your product into the public domain. To do so, you only have to make a statement that you release all rights to the work. You can accomplish this by using the Public Domain Mark or publishing your work under the Creative Commons 0 licence (CC0). Once this is done the product is owned by the public as a whole. Take into consideration that this process is irrevocable. (You can’t take it back! :D)

Permissive software licence

Permissive software licences are otherwise called BSD-like, BSD-style (for Berkeley Software Distribution – more on this later) or “non-copyleft” licences and they basically let you do anything with the licensed software as long as you give the proper recognition to the original owner and you don’t hold them liable for any problems that might be caused by the software. As its name predicts these type of licences typically give the developers more freedom when it comes to the terms of using the licensed product.

Apache 2.0

The Apache 2.0 licence, along with being permissive, creates a strong legal ground for projects. In case you are planning on expressing grant of patent rights but you want to use a permissive licence, the Apache licence is probably a good option for you.

Summary:

  • you can copy, distribute, and modify the software
  • you can sublicense (as a licensee you can grant the licence to a third party for specified rights or uses of the product)
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can practice patent claims of contributors to the code
  • you can use and modify the software for private use without publishing it
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t use the contributors’ names, trademarks or logos
  • you have to state any moifications made to the software
  • if there is a NOTICE file in the library you have to include that NOTICE file when you publish your software – note: you may extend the NOTICE file
  • you have to provide a copy of the Apache v2 licence in the project
  • you have to include the copyright notice in your source files

The copyright notice should be included in the source files. The licence also recommends that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.

Some notable projects distributed under Apache 2.0: 

  • Android operating system,
  • AngularJS

As of now Apache 2.0 is the third most commonly used licence in the open source community.

BSD

BSD licence was first used for the Berkeley Source Distribution (a version of UNIX) and was developed at the University of California at Berkeley (UCB). BSD basically says “here’s the source code, do whatever you want with it, but if you have problems, it’s your problem”. Most variants of BSD include a section that prohibits the use of the name of the organization or the contributors to promote products. BSD evolved throughout the years and has 3 major subtypes as detailed below.

4-clause BSD

Also known as: Original BSD

Mainly because of the advertisement clause this version of BSD is not really used anymore but it is useful to learn about as it is the original version.

Summary:

  • you can copy, distribute, and modify the software
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t use the contributors’ names, trademarks or logos
  • you have to include the full text of the licence in your source files
  • you have to include the original copyright notice in your source files
  • you have display an acknowledgement in all advertising materials of the original source

3-clause BSD

Also known as: BSD 2.0, Revised BSD, New BSD, Modified BSD

The 3rd clause of the original BSD was removed as with time it grew complicated. As you can see above it required authors of all derivative works to acknowledge the original source in all advertising materials. This means that with every generation of derivative work the acknowledgement segment had to be extended which is not a particularly handy situation.

Summary:

  • you can copy, distribute, and modify the software
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t use the contributors’ names, trademarks or logos
  • you have to include the full text of the licence in your source files
  • you have to include the original copyright notice in your source files

Simplified (2-clause) BSD

Also known as: Simplified BSD, FreeBSD

The simplified BSD loses the last clause of the prior two versions that prohibits any endorsement or promotion of the product using the contributors name or organization without a written permission.

Summary:

  • you can copy, distribute, and modify the software
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you have to include the full text of the licence in your source files
  • you have to include the original copyright notice in your source files

Some notable projects distributed under BSD: 

  • Sbt (Simple Build Tool for Scala and Java),
  • Django
  • Dart
  • Ruby

MIT

The MIT licence was originally developed by the Massachusetts Institute of Technology. This licence puts only a very small amount of restrictions on the reuse of the software distributed under its terms. It’s the simplest, shortest, and it’s the easiest to understand. MIT license does not include an express patent license as both the BSD and the MIT licenses were drafted before the patentability of software was generally recognized under US law. The MIT licence basically says that anyone can use and modify the software as long as they provide the proper acknowledgement and that they can’t hold you responsible for the quality of the software.

The name “MIT licence” is ambiguous as it can refer to the “Expat” or the “X11” version. Expat differs sightly from X11: X11 contains the following condition which is similar to the endorsement clause of the BSD licences: “Except as contained in this notice, the name(s) of the above copyright holders shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization.”

Summary:

  • you can copy, distribute and modify the software
  • you can sublicense  (as a licensee you can grant the licence to a third party for specified rights or uses of the product)
  • you can use the software for commercial purposes
  • you can use and modify the software for private use without publishing it
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t practice patent claims of contributors to the code
  • you have to provide a copy of the MIT licence in the project
  • you have to include the copyright notice in your source files

 

Expat form of the MIT copyright licence:

X11 form of the MIT copyright licence:

Some notable projects distributed under MIT:

  • Ruby on Rails, NodeJs,
  • jQuery,
  • Angular2

MIT licence is the number one, most widespread open-source software license nowadays.

Open Source: WTFPL

Do What the F*ck You Want To Public License is a little detour from all the seriousness and it is probably not a good idea to use it for proper projects. Naturally this is not a widely used licence but it takes the expression open source quite literally, so it sure deserves a mention in this article. This licence is a permissive one that essentially equals the act of providing your code to the public domain. The difference between public domain and WTFPL is that the latter one of course is an actual licence and that WTFPL can be used even when locally distributing to the public domain is not feasible due to local laws.

Protective software licence

Often called copyleft, this sort of licensing offers people the right to freely use the licensed product as long as they keep its constraints. The catch of copyleft licences is that the derivative work may only be published under the same license terms. Derivative work considering software basically means the product includes source code from the original program – even if it has been modified. Hence copyleft licences are often referred to as viral licences as they spread quickly with the usage of software distributed under the original licence terms.

GPL

The GPL (= GNU General Public Licence (originally this license was derived from the GNU OS, if you’re interested, check out more on this story here, though it’s not necessary for the use of this license)) is a copyleft license which means that any software that uses parts of any source licensed under GPL has to be published under GPL. This section describes v.3 of GPL.

Summary:

  • you can copy, distribute and modify the software
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can practice patent claims of contributors to the code
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t sublicense
  • you have to state any modifications made to the software
  • you have to provide build and installation instructions with the software
  • you have to provide access to the original software – either include the original or provide a way to obtain copies of the original
  • you have to provide a copy of the GNU GPL in the project
  • you have to include the original copyright notice in the project
  • you have to include the copyright notice (or line) in your source files

If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it. If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of it, along with the written offer. The reason they require the offer to be valid for any third party is so that people who receive the binaries indirectly can too order the source code from you.

The licence states that you should attach the following notice to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

Note: this is the original version of the copyright that can be modified to suit your needs (for instance placing a warranty).

As of today GPL is the second most commonly used licence in the open source community.

Some notable projects distributed under GPL:

  • Linux kernel,
  • GCC
  • Ruby

LGPL

LGPL (= GNU Lesser General Public Licence) is a less restrictive version of GPL. It is most commonly used on libraries. This section covers LGPL v3.

The main difference between GPL and LGPL is that while the GPL license requires you to share the code of all ‘derivative work’ under GPL, the LGPL requires you to share only the source code of the work ‘based’ on the LGPL-licenced components and not of the work which ‘uses’ it, meaning you are not obligated to share the code that is designed to work with the library by being complied or dinamically linked with it. Consequently the entire product doesn’t necessarily have to be distributed under the same licence. So derivative works including modifications or work statically linked to the library must still be distributed under LGPL, but works that only use it don’t need to be.

Summary:

  • you can copy, distribute and modify the software
  • you can use the software for commercial purposes
  • you can place warranty on the software – note: you have to explicitly express this as the original version of the licence claims no warranty
  • you can practice patent claims of contributors to the code
  • you can’t hold the original licence owner accountable for any damage caused by the software
  • you can’t sublicense
  • you have to state any modifications made to the software
  • you have to provide build and installation instructions with the software
  • you have to provide access to the original software – either include the original or provide a way to obtain copies of the original
  • you have to provide a copy of the GNU GPL in the project
  • you have to include the original copyright notice in the project
  • you have to include the copyright notice (or line) in your source files

Conclusion: Open Source Licenses

Permissive licences are awesome because the author isn’t limited in chosing a derivative work’s licence, so the possible circumstances are much wider. On the other hand copyleft licences ensure that any derivative work will be redistributed under the same terms which means that any descending software generation will also be available to use for the community under the given terms. When speaking of open source licences there is no right or wrong. The trick is to find the one that suits your wants and needs the most.

Tons more information could be written on this topic of open source licences. My goal was to provide a processable overview and I hope I managed to succeed.

For further information and orientation:

If you have any questions on this or being a junior at Wanari, go ahead and leave a comment!

PS.: If you just want to stay up-to-date, follow us on Facebook or join us on Google Plus.

Fanni Medvey

Fanni Medvey

Junior Backend Developer at Wanari

Latest posts by Fanni Medvey (see all)