Types of Licenses in Application Development and Their Differences

What Is a Software License?

A software license is a set of rules that explains how an application or source code may be used by others.

Through a license, the application creator can determine whether others may:

• Use the application for free.
• Modify the source code.
• Resell the application.
• Use the code for commercial projects.
• Create derivative works.
• Close the source code after modification.
• Must share the modified source code.

So, even if source code is publicly available on GitHub, it does not mean the code can be used freely without restrictions.

Without a license, copyright rules automatically apply. This means the code owner retains all rights, and others essentially have no permission to copy, modify, or distribute the code.

Open Source Does Not Mean Free Without Rules

Many people assume that open source means source code can be used for anything without conditions. In reality, each open source license has different rules.

Generally, open source licenses allow the software to be used, studied, modified, and shared. However, some licenses grant very broad freedoms, while others require derivative applications to remain open source.

Software licenses are usually divided into several main groups:

1. Permissive license
2. Copyleft license
3. Weak copyleft license
4. Proprietary license
5. Public domain license

Software License Comparison Table

License	Type	Commercial Use Allowed	Modification Allowed	Can Be Made Closed Source	Must Open Source Code	Patent Protection	Suitable For
MIT	Permissive	Yes	Yes	Yes	No	Not explicitly stated	Libraries, applications, personal projects
Apache 2.0	Permissive	Yes	Yes	Yes	No	Yes	Company projects and technology
BSD 2-Clause	Permissive	Yes	Yes	Yes	No	Not explicitly stated	Systems, libraries, and applications
BSD 3-Clause	Permissive	Yes	Yes	Yes	No	Not explicitly stated	Projects requiring creator name protection
ISC	Permissive	Yes	Yes	Yes	No	Not explicitly stated	Small projects and JavaScript libraries
GNU GPL	Strong copyleft	Yes	Yes	No for derivative works	Yes, when distributed	Depends on version	Fully open source applications
GNU LGPL	Weak copyleft	Yes	Yes	Yes, with certain conditions	Only specific library parts	Depends on version	Open source libraries
GNU AGPL	Strong network copyleft	Yes	Yes	Generally no	Yes, including network service	Yes on AGPLv3	Servers, SaaS, and web applications
MPL 2.0	File-level copyleft	Yes	Yes	Yes, for separate files	Only modified MPL-licensed files	Yes	Mixed open source and proprietary projects
Unlicense	Public domain-style	Yes	Yes	Yes	No	No	Simple code intended to be freed
Proprietary	Closed source	Per owner's permission	Usually not	Yes	No	Per agreement	Internal applications and paid products

1. MIT License

The MIT License is one of the simplest and most flexible open source licenses.

This license allows others to:

• Use the software.
• Copy the source code.
• Modify the source code.
• Sell the software.
• Include the code in paid applications.
• Convert the application to closed source.

The main requirement is that the copyright notice and MIT license text must remain included in all copies or substantial portions of the software.

Advantages of MIT License

• License text is short.
• Easy to understand.
• Friendly for commercial use.
• Can be used in closed source applications.
• Widely used in libraries and frameworks.

Disadvantages of MIT License

• Others can take the code, modify it, then sell it as a closed source application.
• Does not have patent protection as clear as Apache 2.0.
• The code owner cannot require modified versions to remain open source.

Suitable when

MIT is suitable for developers who want their source code to be used as widely as possible without imposing many restrictions.

2. Apache License 2.0

The Apache License 2.0 has similar characteristics to MIT. The software can be used, modified, distributed, and included in commercial applications.

The key difference is that Apache 2.0 includes provisions regarding patent grants. This license also requires attribution notices through files like LICENSE and, if available, NOTICE.

Advantages of Apache 2.0

• Can be used for commercial projects.
• Can be included in closed source applications.
• Has clearer patent protection and provisions.
• Suitable for company projects.
• Users are required to document important changes made.

Disadvantages of Apache 2.0

• License text is longer compared to MIT.
• Managing attribution and the NOTICE file can be more complex.
• Does not require derivative works to be open source.

Suitable when

Apache 2.0 is suitable for professional projects or companies that want a flexible license with clearer patent protection.

3. BSD License

The BSD License is a permissive license similar to MIT. It has several versions, but the most common are BSD 2-Clause and BSD 3-Clause.

Both allow use, modification, and distribution in both source code and binary forms.

BSD 2-Clause

BSD 2-Clause is also called the Simplified BSD License.

Its main requirements:

• The copyright notice must remain included.
• The license text and disclaimer must remain included.

BSD 3-Clause

BSD 3-Clause has one additional rule: the names of the creators or contributors may not be used to promote derivative products without permission.

Advantages of BSD License

• Simple and flexible.
• Can be used commercially.
• Can be included in closed source applications.
• Suitable for libraries and system software.

Disadvantages of BSD License

• Code changes are not required to be shared.
• Does not have patent provisions as clear as Apache 2.0.
• Others can create proprietary products using the code.

4. ISC License

The ISC License is a very concise permissive license. Functionally, it is nearly identical to MIT and BSD 2-Clause.

Users may use, copy, modify, and distribute the software as long as the copyright notice and permission text remain included.

Advantages of ISC License

• Very short text.
• Easy to apply.
• Allowed for commercial use.
• Can be used in closed source applications.

Disadvantages of ISC License

• Does not require modified versions to be open source.
• Patent provisions are not as clear as Apache 2.0.
• Less suitable when the creator wants to maintain openness of derivative code.

ISC is quite common in packages and libraries within the JavaScript ecosystem.

5. GNU General Public License or GPL

GNU is not a single license name. GNU has several types of licenses, such as:

• GNU GPL
• GNU LGPL
• GNU AGPL

The GNU General Public License or GPL is a strong copyleft license. This means that when GPL software is modified and distributed as a derivative work, the source code of that application must also be made available under a compatible GPL license.

GPL does not prohibit commercial use. Developers may still sell GPL software. However, recipients of the software must receive the rights granted by the GPL, including access to the source code under the conditions required by the license.

Advantages of GNU GPL

• Keeps software and its derivatives open.
• Improvements and developments can flow back to the community.
• Prevents others from taking the code and closing the source of derivative works.
• Suitable for community-based projects.

Disadvantages of GNU GPL

• Difficult to use in proprietary products.
• Must be careful when combining with other licensed code.
• Less suitable for companies that want to keep their product source code closed.

Is internal code required to be opened?

Not always.

If a GPL application is only used internally and not distributed to others, generally the source code does not automatically have to be disclosed to the public.

The main obligation of GPL typically arises when the software or derivative works are distributed.

6. GNU Lesser General Public License or LGPL

LGPL is a more flexible copyleft version compared to GPL.

This license is usually used for libraries. Proprietary applications may use or link to LGPL libraries as long as they comply with the license terms. GNU states that LGPL libraries can be linked with proprietary applications, unlike GPL which has a stronger copyleft effect on derivative works.

Advantages of GNU LGPL

• Suitable for open source libraries.
• Can be used by closed source applications.
• Changes to the LGPL library must still follow LGPL rules.
• Expands the use of the library without releasing all copyleft protections.

Disadvantages of GNU LGPL

• Integration rules are more complex than MIT.
• Linking and distribution methods need attention.
• Direct modifications to the library may trigger obligations to share the library source code.

Suitable when

LGPL is suitable when you create a library that you want to be usable by both open source and proprietary applications.

7. GNU Affero General Public License or AGPL

AGPL is a copyleft license specifically designed for software used over a network, such as:

• Web applications.
• Software as a Service or SaaS.
• APIs.
• Servers.
• Online platforms.

With regular GPL, a company can modify the software and run it on a server without distributing the application. In such a situation, the GPL's source code distribution requirement may not apply.

AGPL adds obligations related to software use over a network. Users who interact with a modified version of the software over a network must have the opportunity to access the corresponding source code.

Advantages of GNU AGPL

• Suitable for keeping SaaS applications open source.
• Prevents others from modifying a server application and closing its code.
• Provides stronger copyleft protection.

Disadvantages of GNU AGPL

• Difficult to use in proprietary applications.
• Often avoided by companies that do not want to open server source code.
• Integration needs careful review.

8. Mozilla Public License 2.0

The Mozilla Public License or MPL 2.0 is a file-level copyleft license.

This means that files that are already under MPL and later modified must remain available under MPL. However, those files can still be combined with other proprietary files within a single application.

Therefore, MPL sits between permissive licenses like MIT and strong copyleft licenses like GPL. MPL 2.0 is also an open source license recognized by the Open Source Initiative.

Advantages of MPL 2.0

• More flexible than GPL.
• Modified open source files remain open.
• Can be combined with closed source code.
• Suitable for projects with both open and proprietary modules.

Disadvantages of MPL 2.0

• More complex than MIT or BSD.
• Developers need to know which files are under MPL.
• Less suitable if you want the entire derivative application to remain open source.

9. Unlicense

The Unlicense is used when a creator wants to release code into the public domain to the fullest extent permitted by law.

Generally, users may:

• Copy the code.
• Modify the code.
• Sell the code.
• Distribute the code.
• Use the code without attribution.

The Unlicense imposes very few conditions on users.

Advantages of Unlicense

• Very free.
• Almost no attribution obligations.
• Suitable for small code snippets or sample code.

Disadvantages of Unlicense

• The concept of public domain may be treated differently in each country.
• Not ideal for company projects.
• Does not provide clear patent protection.
• Company contributors may prefer MIT or Apache 2.0.

10. Proprietary License

A proprietary license is a license for closed source applications. The rights to use the software are entirely determined by the application owner.

Users typically only receive permission to use the application, not to own or modify the source code.

Examples:

• Subscription applications.
• Internal company software.
• Paid cashier applications.
• Hotel management systems.
• Client-specific applications.
• Paid desktop software.

Common rules

• Cannot copy the application.
• Cannot share accounts.
• Cannot view or modify the source code.
• Cannot resell the application.
• Usage is limited by device, user, company, or time.
• Usage rights end when subscription stops.

Suitable when

A proprietary license is suitable when the application is a business product and the source code must be kept closed.

11. Dual Licensing

Dual licensing is a method of offering two license options for the same software.

Examples:

• Free with GPL for open source projects.
• Paid with a commercial license for companies that want to use the software without following GPL.

This model allows software creators to benefit from the open source community while also selling commercial licenses.

However, dual licensing is easier to implement when the source code copyright is fully owned by a single company or entity. If there are many contributors, the management of contribution rights must be clearly established.

Can Creative Commons Be Used for Source Code?

Creative Commons or CC is more suitable for:

• Articles.
• Images.
• Videos.
• Music.
• Documentation.
• Learning materials.
• Designs and creative content.

Creative Commons does not recommend using CC licenses for software and hardware because there are specific software licenses that more appropriately address matters such as source code, distribution, and modification.

In a single application project, you can use:

• MIT, Apache, or GPL for source code.
• Creative Commons for documentation, images, or other materials.

Ensure each part is explained separately to avoid confusing users.

Differences Between Permissive and Copyleft

Aspect	Permissive License	Copyleft License
Examples	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
Commercial use	Allowed	Allowed
Code modification	Allowed	Allowed
Can become closed source	Generally allowed	Generally not for derivative works
Must share changes	No	Yes under certain conditions
Level of restriction	Simpler	Stricter
Suitable for companies	Very suitable	Depends on business model
Suitable for open source community	Suitable	Very suitable
Code openness protection	Low	High

Which License Should You Choose?

Use MIT when

• You want a simple license.
• You want the code to be used as widely as possible.
• You don't mind if the code is used in closed source applications.
• You are creating a library or personal project.

Use Apache 2.0 when

• You want the freedom of MIT.
• You need clearer patent provisions.
• You are creating a company project.
• You plan to accept many contributions.

Use BSD when

• You want a simple permissive license.
• You are creating system software or a library.
• You don't want the creator's name used for promoting derivative products.

Use GPL when

• You want derivative applications to remain open source.
• You don't want companies to take the code and close its source.
• You are creating a community project.

Use LGPL when

• You are creating a library.
• You want the library to be usable by proprietary applications.
• You want modifications to the library to remain open.

Use AGPL when

• You are creating a SaaS or server application.
• You want changes used over a network to be shared.
• You don't want companies to run modified versions privately on their servers.

Use MPL 2.0 when

• You want part of the code to remain open.
• You still want to combine code with proprietary modules.
• You need a middle ground between MIT and GPL.

Use a proprietary license when

• The source code cannot be opened.
• The application is made for business purposes.
• You want to restrict software usage.
• The application is sold through a license or subscription system.

Example of License Application on GitHub

Typically, the license text is stored in the following file:

LICENSE

or:

LICENSE.md

That file is placed in the main or root folder of the repository. GitHub also recommends including the license file directly in the repository so that it is available when the project is cloned, downloaded, or distributed.

Example project structure:

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

Brief information can also be added to README.md:

## License

This project is licensed under the MIT License.
See the LICENSE file for more information.

Things to Check Before Choosing a License

Before deciding on a license, consider the following:

1. Can the application be used commercially?
2. Can others modify the source code?
3. Must modifications be shared?
4. Can derivative works be closed source?
5. Will the application be used as SaaS?
6. Does the project use third-party libraries?
7. Are the licenses of each dependency compatible?
8. Is there code from other contributors?
9. Is patent protection needed?
10. Will the application be sold to clients?

Don't just choose a license because it's popular. Choose a license based on the project's goals and how the application will be used.

Conclusion

Each software license provides different rights and obligations.

MIT, BSD, and ISC are suitable for projects that want to give broad freedoms to users. Apache 2.0 offers similar freedom with clearer patent provisions.

GPL is suitable for keeping derivative applications open source. LGPL is more appropriate for libraries, while AGPL provides additional protection for web applications, servers, and SaaS.

MPL 2.0 can be a middle ground because it only requires certain files to remain open. Meanwhile, a proprietary license is more suitable for business applications whose source code must remain closed.

License selection should be done early in development. Besides protecting the application creator, a clear license also helps users and contributors understand what is and is not allowed.

Note: This article provides a general explanation and is not legal advice. For large-scale commercial applications, heavy use of dependencies, or projects with many contributors, consult with someone knowledgeable about intellectual property law regarding license selection.