An open source license is a legal document that defines how others can use, modify, and distribute your source code. Without a license, your code is technically "all rights reserved" under copyright law—meaning nobody can legally use it. Adding an open source license gives explicit permission and sets clear expectations. It protects both you (the author) and your users by establishing rules around attribution, liability, patent rights, and derivative works. Choosing the right license ensures your project aligns with your goals, whether that's maximum adoption or ensuring all derivatives remain open.

Permissive licenses (like MIT, Apache 2.0, BSD) impose minimal restrictions on how others can use your code. They allow proprietary (closed-source) derivatives, meaning a company can take your code, modify it, and sell it without releasing their changes. You only need to keep the original copyright notice.

Copyleft licenses (like GPL, AGPL) require that any derivative works also be distributed under the same license. This ensures the code and all its derivatives remain open source. Weak copyleft (LGPL, MPL) applies this requirement only to the original library or modified files, allowing proprietary software to link to it. Strong copyleft (GPL, AGPL) applies to the entire derivative work. AGPL additionally closes the "ASP loophole" by requiring source disclosure even when the software is only used over a network.

Both are permissive licenses, but Apache 2.0 includes an express patent grant that protects users from patent infringement claims by contributors. It also requires stating significant changes made to the code. MIT is simpler, shorter, and does not address patents. Choose MIT if you want maximum simplicity and broadest adoption. Choose Apache 2.0 if your project may involve patents, if you're a large organization, or if you want explicit protection against patent lawsuits. Many corporate-backed open source projects (like those from Google, Apache Foundation) use Apache 2.0 for this reason.

GPL v3 was released in 2007 to address modern challenges not covered by v2 (1991). Key differences include:

• Patent protection: GPL v3 includes an express patent grant; v2 relies on implicit patent protection.
• Anti-tivoization: GPL v3 prevents "tivoization" — using hardware restrictions to prevent users from running modified software on devices.
• Compatibility: GPL v3 is compatible with Apache 2.0; GPL v2 is not.
• DRM: GPL v3 addresses digital rights management and prohibits using GPL code in DRM systems that block user modifications.

Choose GPL v3 for modern projects with patent concerns. Choose GPL v2 if you need compatibility with older GPL v2-only projects (like the Linux kernel).

The GNU Affero General Public License (AGPL v3) closes the "ASP loophole" (also called the "SaaS loophole"). Under GPL, if someone modifies your code and runs it on a server (as a web service), they don't have to release their changes because they aren't "distributing" the software. AGPL requires that even network users receive access to the source code. Choose AGPL if your project is a web application, API, or network service and you want to ensure all modifications remain open—even when deployed as SaaS. Popular examples include MongoDB (before they switched to SSPL) and Nextcloud.

A patent grant is a clause in some open source licenses (notably Apache 2.0, GPL v3, MPL 2.0) that explicitly grants users a license to any patents the contributor holds that cover the code. Without an express patent grant, a contributor could theoretically sue users for patent infringement even if the code is open source. MIT and BSD licenses lack an express patent grant, meaning patent protection is only implied. For projects where patents are a concern—especially corporate or research projects—choosing a license with an express patent grant (Apache 2.0, GPL v3) provides stronger legal protection.

Yes, you can change the license of your project at any time—for future versions. However, you cannot retroactively revoke the license from previously released versions. If you own all the copyright (meaning you wrote all the code, or contributors signed a CLA assigning copyright to you), switching is straightforward. If you have multiple contributors, you generally need all contributors' consent to change the license unless you have a Contributor License Agreement (CLA) in place. Some projects use a "GPL v2 or later" clause for flexibility. Always consult legal advice before making significant licensing changes to a multi-contributor project.

The GNU Lesser General Public License (LGPL) is a "weak copyleft" license designed primarily for software libraries. It allows proprietary applications to link to the LGPL-licensed library without requiring the entire application to be open sourced. Only modifications to the library itself must be shared under LGPL. Choose LGPL when you've built a reusable library and want it to remain open source, but also want to encourage adoption by proprietary software. GTK, FFmpeg, and many GNU libraries use LGPL. Use standard GPL instead if you want all derivative works to be fully open source.

The only difference is the non-endorsement clause in BSD 3-Clause. This clause prohibits using the names of the project or its contributors to endorse or promote derivative products without specific permission. BSD 2-Clause omits this clause entirely. In practice, BSD 3-Clause provides slightly more protection for the reputation of the original authors. Both are extremely permissive, short licenses. BSD 3-Clause is used by projects like Go and d3.js, while BSD 2-Clause is used by projects like Nginx and Redis (before their license changes).

The Unlicense is a license that effectively dedicates your work to the public domain by waiving all copyright and related rights to the fullest extent legally possible. It's as close to "no license" as you can get while still having a legal document. However, public domain dedication is not legally recognized in all jurisdictions (notably some European countries), and the Unlicense includes a fallback permissive license for those cases. For code, the Unlicense is OSI-approved. Alternatives include CC0 (Creative Commons Zero, though CC recommends against using it for software) and 0BSD. If you want to give away all rights with no conditions whatsoever, the Unlicense is a solid choice.