MIT/BSD: Anyone can do anything with your software, but must recognize you as the author

Users are granted the freedom to use the software for any purpose, including commercial and private uses, without any significant restrictions. This broad permission can lead to wider adoption and use of the software.

These licenses allow users to freely redistribute the original or modified versions of the software. This can include selling the software as part of a larger product, which can potentially increase the software’s reach and impact.

Users can modify the software and distribute the modified versions under the same license.

Unlike copyleft licenses (e.g., GPL), MIT/BSD licenses do not require modifications to be released under the same license. Users can integrate the software into proprietary products without releasing their source code.

The license terms are simple and easy to understand, which reduces legal overhead and confusion.

The software is provided 'as is' without any warranties

• Read the Original BSD 4-Clause License
• Read the New BSD 3-Clause License
• Read the FreeBSD / Simplified BSD 2-Clause License

Apache 2: Anyone can do anything with your software, but must recognize you as the author

The minimal MIT/BSD style 'attribution only' AKA 'permissive licenses' do not include the patent grant clause.

Contributors grant you a free, worldwide patent license to use and sell their software contributions, but if you sue someone for patent infringement related to this software, this license ends

The Apache 2 License also explicitly discusses the NOTICE text file that's used in all Apache projects, but less popular outside of the Apache Project.

GPL: Nobody, not even you, can sell your software, but cloud providers can profit renting it

With the GPL, it may be possible to sell a license to organizations that don't want to comply with the share-alike (copyleft) clause, this is referred to as Dual Licensing. Dual Licensing only works for organizations that want to change your code, and don't want to publish those changes. If your software works for them out of the box - the goal for most developers when thinking of their users, no fee will ever be paid directly for the software - a license fee

Since the GPL allows anyone, even Billion Dollar Busiensses, to freely use, modify, and distribute the software, the financial value of selling the software directly is undermined. This shifts the revenue model from license fees to service-based models that cloud providers are in a far better position than developers to capitalize on.

The Affero GPL (AGPL) triggers the share-alike clause when the software is provided as a service. For organizations that want to change the code while providing the software as a service, this creates a small revenue opportunity in a very narrow set of circumstances.

SSPL: AGPL derivative rejected by the OSI, ignored by the FSF

The SSPL is fascinating. It prompted the OSI to post The SSPL is Not an Open Source License

The SSPL is basically the AGPL, but explicitly stating that 'offering this software as a service' requires you to publish all of the code that makes your offering possible

A company that offers a publicly available MongoDB as a service must open source the software it uses to offer such service, including the management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the source code made available.

Both the AGPL and SSPL address 'software as a service', the SSPL extends beyond the direct software itself to encompass the entire service infrastructure. Per the Debian Free Software Guidelines, Point 6 freedom from discrimination against fields of endeavor.

The SSPL represents a rethinking of the FSF's copyleft principle. You can argue that the SSPL strengthens and broadens the scope of copyleft from just the software itself to the entire service infrastructure required to run the software. You can also argue that the SSPL is overreach designed to impact cloud providers freedom to sell software written by others as a service.

The FSF appears to decline comment on the SSPL, however FSF founder Richard Stallman wrote we have not studied the SSPL. and

I tend to think that trying to impose copyright-based rules that stretch beyond the bounds of one single program is abuse of copyright, based on what I learned in the past.

The SSPL is an interesting case. You can clearly see the developers position that the SSPL is an even stronger form of the Copyleft principle. You can also clearly see how the SSPL is clearly designed to prevent Cloud Providers like Amazon's AWS from selling software with an 'OSI Approved License', directly generating massive revenue, and giving nothing to the developer.

Business Source License: Paid for Production Use

Fair Code license that allows for copying, modification, creation of derivative works, redistribution, of the code, but not production use.

The BSL has been reviewed and endorsed by Bruce Perens, the co-founder (together with Eric S. Raymond) of the Open Source Initiative.

After 4 years, the code must be relicensed under the GPL v2.0 or later

Usage is limited to non-production use, or production use within the limits of the Additional Use Grant specific to each BSL product.

Similar to the Fair Source License and the Open Source Eventually

Commons Clause: Prevent commercialization of your software by third parties

Fair Code license clause (not a complete license) that restricts 3rd parties ability to compete with you.

While the SSPL directly targets Cloud providers of your software, the Commons Clause generally prevents any 3rd parties from competing with you to offer your software for sale, whether that's selling hosting, selling consulting or selling support that's value comes entirely or substantially from your software

Commonly added to the MIT and BSD licenses