Open source software grants users many benefits. The main one is: the ability to use, change, and distribute a software library or project, with or without its source code, for any purpose, anywhere in the world. However, it’s also important to understand the fundamental idea behind open source – which is to make software accessible to all. And an open source license ensures this happens.
However, while many view open source licenses as allowing free and limitless access to reusable software, that's not always the case. It depends on which open source license the software is distributed under.
Open source licenses also benefit communities and support developers by providing useful libraries and content to many different audiences.
This article outlines what you need to know about open source licensing, details of each open source license, and which license TinyMCE WYSIWYG uses.
Types of open source software licenses
Many types of open source software licenses exist, and the following are the most well known. The publicly available definitions provide more information, but here’s a summary:
- Public Domain: Public domain software can be modified and used by anyone with no restrictions whatsoever.
- Permissive: Often called "Apache style" or "BSD style," permissive licenses have minimal restrictions on how a user can modify or redistribute the software, and are the most common in open source software.
- Copyleft: A copyleft license is a restrictive license that allows users to modify and distribute new software based on the code, but the code that you distribute must always be free to use and only licensed for personal use.
- LGPL: The name stands for "Lesser General Public License".The restrictions of a LGPL can be complicated, but the essential point is that LGPL is a compromise between the freedom of permissive licenses and the stronger limitations of a copyleft license
Out of the above licenses, public domain is often considered to be the least restrictive. Following this, permissive is the second-least restrictive, and LGPL falls in between permissive and copyleft licenses.
Of course, the other type of licensing we haven’t mentioned is commercial licensing. This is where most software sits – where it’s not part of the open source domain, but is instead proprietary software that you must pay for in order to access and use its code.
Open Source Software license types
When it comes to Open Source Software (OSS) license types, the two specific types to know about are permissive and restrictive. Here’s some specific information to know about each:
1. Permissive open source licenses
Permissive licenses have minimal restrictions and allow for proprietary, derivative works based on the original source. It's one of the main reasons why a permissive license is popular.
It’s generally agreed that the first permissive license created was the Prior BSD license. This was the first form of the BSD license, while another example is the Apache 2.0.
Currently, the most used permissive form of license is the MIT license.
2. Restrictive open source licenses
Also called a copyleft license, if you make a project available under this form of license, the code that you distribute must always be free to use and only licensed for personal use.
If you encounter a project using a restrictive or copyleft license, any derivative work of that copyleft-licensed software must be released under the same license as the original software.
Restrictive licenses are helpful for communities with goals like:
- Sharing improvements with a community
- Endorsing a collaborative approach
- Avoiding the code being made proprietary.
Open source license comparison
The following comparison charts the basic open source license differences. This is not an exhaustive comparison, and other resources should be considered before making any decisions around licenses.
License name |
Version Number |
Publication Date |
Modify Code |
Redistribute Code |
2.0 |
2004 |
Permissive |
Permissive |
|
2.0 |
2003 |
Limited |
Unclear |
|
3.0 |
Unclear, a family of licenses exist under this name |
Permissive |
Permissive |
|
4.0 |
2002 |
Permissive |
Permissive |
|
4.0 |
2002 |
Restrictive |
Restrictive |
|
- |
1999 |
Permissive |
Permissive |
|
3.0 |
2007 |
Restrictive |
Restrictive |
|
3.0 |
2005 |
Restrictive |
Restrictive |
|
- |
Late 1980s |
Permissive |
Permissive |
How to choose an open source license
Please note: The following statements are not legal advice and selecting the appropriate software license is not a decision to be taken lightly.
Key considerations to factor into your decision are the restrictions of user freedoms and protecting intellectual property, as well as the monetary value of creating new works from existing libraries. How the community interacts with the project is another important point to consider.
More than 60% of open source projects use one of the three best known licenses:
- MIT – more permissive
- GPL – more restrictive
- Apache 2.0 – more permissive
A good starting point for choosing your license, is taking a closer look at each of these three types. An important point to factor in is to identify if you’re creating a combined work or an application. For instance, the GNU explains:
"When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary, General Public License therefore permits such linking only if the entire combination fits its criteria of freedom...[meanwhile]...the Lesser General Public License permits more lax criteria for linking other code with the library."
In this case, choosing the Lesser General Public License (LGPL) gives users more freedom than a standard GNU license when it comes to a solution. The option to create a combined work exists with an LGPL. Using a GNU license would prevent this sharing of the project into a new, combined work.
Open source licenses to avoid
Some unusual forms of open source licenses also exist. For example, the GLWTS public license is permissive, with the provisions that all connections to the author are erased entirely. Another example is the Passive Aggressive license, where code from the project can be copied and modified, but cannot be run, executed, or built from the source.
Which OSS license does TinyMCE use?
For TinyMCE 6, In response to changing requirements and standards, the open source license changed from the LGPL to the MIT License. The change took place with the release of TinyMCE 6.0 after research and consultation. The decision TinyMCE made to change to the MIT Licenses was made with the belief that using the more permissive license would increase adoption and ultimately empower a new generation of developers to create apps that improve the world of content creation.
TinyMCE 5, the previous version, uses the Lesser General Public license. Here’s what the Free Software Foundation states about the Lesser General Public License (LGPL):
“The LGPL goes on to explain information about source code and integration…You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty…if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you.”
How the MIT license benefits users
Of the open source licenses, MIT is more permissive, and is the license used by established communities such as Ruby on Rails, jQuery, and Node.js. It’s been widely adopted among open source projects – oftentimes due to the simplicity of the license agreement itself.
The MIT license benefits users by providing freedom and flexibility when using TinyMCE 6 in commercial applications, modifying the code, and distributing the text editor code. In essence, for end users looking to try the rich text editor without burdensome compliance requirements, this license provides significant freedom and flexibility.
Where to go next?
What do you think of the different open source licenses? Let us know @jointiny. And if you have any questions about how using TinyMCE 6 with the MIT license works, you can contact us to find out more.