Short answer

  • A software license is permission, with conditions, to use, copy, change, or share software that someone else owns under copyright. It answers a question that buying, downloading, or seeing code does not answer on its own: what exactly are you allowed to do with this program, and under what limits? Software licensing is the system behind that permission. A copyright owner uses a license to grant some rights while keeping others. The license may set conditions, such as keeping a copyright notice in place. The license, not the price, the download button, or the installer, defines the legal scope of use. If no license grants you a right, assume that right has not been granted, even when software is visible, free to download, or easy to copy.

What a Software License Does

Think of a license as the rules that travel with the software. It names the software. It identifies who gives permission. It identifies who receives permission. It lists what the recipient may do. A license for an everyday program may cover installation on a stated number of devices. It may cover updates for a stated period. A license for developer code may cover copying, changing, and sharing a changed version. A license also covers matters that are easy to miss. It can limit liability. It can disclaim warranties. It can require attribution. It can require changed files to be marked as changed. It can require a changed version to be shared under the same license. Separate three things. First, the software itself. Second, copyright ownership. Third, the license. Seeing source code is not holding a broad license.

Copyright is the reason licensing exists for most software. The United States Copyright Office explains that copyright protects original works of authorship as soon as an author fixes the work in a tangible form of expression. It lists computer programs among the types of works covered. Copyright protects expression, not ideas, procedures, methods, systems, processes, concepts, principles, or discoveries. In plain terms, copyright can protect the particular code a developer wrote. It does not protect the general idea of doing the same job. Another developer can write original code that performs a similar function. The Copyright Office also lists exclusive rights held by a copyright owner. These include reproducing the work, preparing derivative works based on it, and distributing copies to the public. The owner may authorize others to exercise those rights. A software license is one way to give that authorization. Registration is separate. Copyright exists automatically once a work is fixed. Registration is not mandatory, although it has benefits, including the ability to enforce United States rights through litigation for United States works.

Buying Software Is Usually Not Buying the Software

When people say they bought software, they usually mean they bought a license to use it. Or they bought access to a service that runs it. They did not usually buy the copyright. They did not usually buy the source code. They did not usually buy the right to copy and resell the program. This explains many everyday surprises. A program can stop working when a subscription ends. A license can limit use to one person or one computer. A company can change terms for a new version, while the old version remains under its earlier terms. Buying software is different. Software is copied, installed, run, and often updated through a service. The license controls those acts. It may allow installation on several devices for one household, or only one installation. It may allow use at work, or limit use to personal use.

The Main Parties and the Main Words

  • Licensor: the party giving permission, such as a company, an individual developer, a foundation, or another copyright owner.
  • Licensee: the party receiving permission, such as a person, a team, or a company.
  • Source code: the human readable form of a program, the form developers normally read and change.
  • Object code, binary code, or executable code: the machine readable form that a computer runs.
  • Derivative work: a work based on an earlier work, such as a changed version.
  • Distribution: giving copies to others, whether by download, sale, sharing, or another transfer.
  • Sublicense: permission given by a licensee to someone else, where the original license allows it.
  • Grant: the permission itself. A license may grant a worldwide, royalty free, non exclusive license to use, copy, modify, and distribute software.

What a License Usually Covers

  • What is licensed: one program, one version, one library, or a whole package, and whether it includes documentation or future updates.
  • Who may use it, and where: any person or only named users, anywhere or only in a stated territory.
  • How many devices, accounts, or installations: a stated number of devices, seats, users, servers, or cores.
  • For what purposes: any purpose, personal use only, commercial use, educational use, or another stated purpose. Open source licenses, as defined by the Open Source Initiative, do not discriminate against fields of endeavor, so an open source license should not restrict use to noncommercial purposes. A proprietary license can be much narrower.
  • Copying, changing, and sharing: some licenses allow only running the program. Others allow copying, changing, and sharing, with conditions such as keeping notices, marking changes, sharing source code, or using the same license for a changed version.
  • Patents and trademarks: some licenses include an express patent grant. Some say nothing about patents. Some expressly withhold trademark rights.

Proprietary Licenses

A proprietary license keeps most rights with the owner. It grants only the rights stated in the agreement. Source code is usually not provided. The user may run the program, install it within stated limits, and receive updates or support if the agreement includes them. The user normally may not copy the program beyond stated backup or installation limits, change it, share it, or build a competing product from its code. Proprietary licenses take many forms. A retail license may cover one household or one device. A business license may cover a stated number of seats or servers. An enterprise agreement may cover a whole organization, with volume terms and audit rights. A trial license may allow evaluation for a stated period. A freeware license may allow use at no charge, while still keeping software proprietary and restricting copying or change.

Free Software and Open Source Software

Free software and open source software are closely related terms. The Open Source Initiative’s frequently asked questions describe them as two terms for the same thing in practical effect: software released under licenses that guarantee a specific set of freedoms. History and emphasis differ, but both labels point to licenses that allow use, study, change, and sharing, subject to license conditions. The Free Software Foundation defines free software through four essential freedoms. Freedom 0 is the freedom to run the program for any purpose. Freedom 1 is the freedom to study how the program works and change it so it does your computing as you wish, with access to source code as a precondition. Freedom 2 is the freedom to redistribute copies so you can help others. Freedom 3 is the freedom to distribute copies of your modified versions to others, again with access to source code as a precondition. The Foundation stresses that free means freedom, not price, using the familiar contrast between free speech and free beer. A free program can be sold. A program given away at no charge is not free in this sense unless it grants those freedoms. The Open Source Definition, maintained by the Open Source Initiative, sets ten criteria that a license must meet for software distributed under it to be labeled open source.

Permissive Licenses

A permissive license is an open source license that is not copyleft. The Open Source Initiative describes a permissive license as one that guarantees the freedoms to use, modify, and redistribute, but permits proprietary derivative works.

  • MIT License: the classic short example. It grants permission, free of charge, to any person obtaining a copy of the software and associated documentation files to deal in the software without restriction, including the rights to use, copy, modify, merge, publish, distribute, sublicense, and sell copies. Its main condition is that the copyright notice and permission notice must be included in all copies or substantial portions of the software. It provides software as is, without warranty.
  • BSD licenses: similar in spirit, with short texts and notice requirements. Do not treat every license with BSD in its name as identical. A three clause BSD license and a two clause BSD license differ in one clause that can matter for attribution and endorsement.
  • Apache License 2.0: permissive, but more detailed. It grants a perpetual, worldwide, non exclusive, no charge, royalty free copyright license to reproduce, prepare derivative works, publicly display, publicly perform, sublicense, and distribute the work and derivative works in source or object form, subject to its conditions. It includes an express patent license from contributors, with termination of that patent license if the licensee brings patent litigation alleging that the work infringes. It requires recipients to receive a copy of the license. It requires changed files to carry prominent notices stating that they were changed.

Permissive licenses suit projects that want the widest possible reuse, including reuse in proprietary products. The trade-off is that improvements made under a permissive license do not have to come back under the same license.

Copyleft Licenses

Copyleft uses copyright to protect sharing rather than to restrict it. The Open Source Initiative explains copyleft as licenses that allow derivative works but require them to use the same license as the original work.

  • GPL: the best known strong copyleft license. GPL version 3, dated 29 June 2007 and published by the Free Software Foundation, describes itself as a free, copyleft license. Its preamble states the goal plainly: to guarantee freedom to share and change all versions of a program, and to make sure it remains free software for all its users. If you distribute copies, whether gratis or for a fee, you must pass on the same freedoms you received, make sure recipients receive or can get the source code, and show them the terms so they know their rights. Strong copyleft has a wide scope. Under the GPL, the copyleft condition can reach a whole program based on GPL code, not only the files that were changed. That is why GPL compatibility matters: code under a license that adds restrictions the GPL does not allow may not be combinable with GPL code in a distributed program. Private modification is different. Copyleft is normally triggered by distribution, not by private use. A developer may create a private modified version without an obligation to disclose the modifications, as long as the modified software is not distributed to another person.
  • AGPL: the GNU Affero General Public License adds a network use condition. The Open Source Initiative notes that the AGPL requires offering source code, under the AGPL, to anyone to whom the software’s functionality is made available as a network service.
  • LGPL: the GNU Lesser General Public License is a weaker form of copyleft in effect, designed mainly for libraries. It allows a program to link to an LGPL library without necessarily placing the whole program under the LGPL, subject to its conditions, while changes to the library itself remain under the LGPL.

Copyleft suits projects that want improvements to stay open. The trade-off is complexity and compatibility work.

Weak Copyleft and File Level Copyleft

Weak copyleft sits between permissive and strong copyleft. It requires sharing for a defined part of the work, but allows the larger work to use other terms for other parts. The Mozilla Public License 2.0 is the clearest example of file level copyleft. If you modify MPL licensed files and distribute them, those files must remain under the MPL, with required notices and source availability for those files. New files that you add, and that are not modifications of MPL files, can be under different terms, including proprietary terms, when they form part of a larger work. That file boundary is the point of the license. MPL 2.0 also includes a patent grant from contributors and compatibility provisions for combination with GPL, LGPL, and AGPL code as secondary licenses, unless the initial author opts out of that compatibility by notice. Weak copyleft is not a vague compromise. It is a precise scope rule, with copyleft at the file level rather than the whole program level.

Public Domain, Dedications, and Source Available

Public domain is not a license. It is a legal status for works that are not under copyright, either because copyright never applied, because the term expired, or because another rule places the work outside copyright. The Open Source Initiative notes that public domain status varies by jurisdiction, that not all jurisdictions have a public domain in the same sense, and that there is no license text to evaluate through its approval process. A work truly in the public domain may be copied at will, but proving that status, and dealing with different rules in different countries, can be complex. Public domain dedications try to solve that problem by using a legal tool to waive rights to the fullest extent allowed by law, with a fallback license where a waiver is not effective. Creative Commons CC0 is the best known example.

Commercial License Models

Commercial licensing adds pricing and measurement models on top of copyright permission. They can apply to proprietary software, to support for open source software, or to a service built around software. A perpetual license, in ordinary commercial language, grants the right to use a stated version indefinitely, usually for a one time fee, subject to termination for breach. It does not always include future versions, support, or maintenance. A subscription license grants use for a stated period, usually renewed by payment. When the subscription ends, the right to use the software normally ends too, unless the agreement allows continued use of an installed version or provides a grace period. Seat based, named user, device based, concurrent, and site models measure use in different ways. A named user license counts people. A device license counts machines.

How to Read a License

You do not need to be a lawyer to read a license usefully, but you do need a method.

  • Start with the grant, not the marketing page. Find the sentences that say what you may do, and list them in your own words. Then find the conditions, and list them as a checklist. Then find the limits, including warranty, liability, trademark, patent, and termination terms. If any section is unclear, treat that as a question, not as permission.
  • Check the version and the full text. License names are reused, and versions differ in important ways. GPL version 2 and GPL version 3 differ on patents, on anti circumvention, and on installation information for user products, among other points. Apache License 1.0, 1.1, and 2.0 differ as well. MPL 1.1 and MPL 2.0 differ on compatibility and simplicity. Use the SPDX identifier where one is given, such as MIT, Apache-2.0, GPL-3.0-only, GPL-3.0-or-later, or MPL-2.0, because the identifier names a specific license text rather than a family name. The SPDX License List provides a standardized short identifier, full name, license text, and canonical permanent URL for each license and exception, which helps tools and teams name licenses without ambiguity.
  • Check notices and files. Many open source licenses require keeping copyright and license notices, and Apache License 2.0 requires NOTICE file handling where a NOTICE file is present.
  • Check compatibility and change. Check compatibility before combining code, and check what happens on change, including marking changes and keeping notices when distributing a changed version.

How to Choose a License

Choosing a license depends on whether you are mainly a user or mainly a releaser, and on what outcome you want for the code. If you are choosing software to use, start from the job, then check the license. Does it allow your purpose, including commercial use if you need it? Does the device, user, or seat count fit your team? Does redistribution matter, for example if you will ship code inside a product or service? Does modification matter, for example if you will need to fix, adapt, or maintain code yourself? What about support, updates, and what happens when the agreement ends? A license that fits a hobby project may not fit a product that will be sold, hosted, or audited. If you are releasing your own code, start from the outcome you want for reuse. If you want the widest possible adoption, including adoption in proprietary products, a permissive license such as MIT or Apache License 2.0 is a common choice, with Apache License 2.0 adding an express patent grant and clearer notice rules. If you want improvements to stay open at the program level, choose GPL version 3, with AGPL version 3 when network use should trigger source sharing. If you want file level openness, choose MPL 2.0. If you want a public domain dedication, CC0 is a tool for that purpose, subject to its patent limitation.

What Happens Without a License

The default position, in plain terms, is that all rights are reserved unless a license grants them. If you find code online with no license file, no license header, and no statement of permission, you do not have a clear right to copy, change, or share it beyond what the law independently allows, such as a specific exception that applies to your use. Viewing code, learning from its general ideas, and writing your own original code are different acts from copying, changing, and distributing someone else’s code. The first group may be lawful in many cases, while the second group needs permission. This surprises many new developers. A public repository is not a public license. A code snippet in a forum post is not automatically licensed for any use, although forum terms may grant some rights. A file shared by a colleague is not automatically licensed for redistribution to a customer. In each case, ask what permission the copyright owner actually gave, in what document, for what acts.

Common Misunderstandings

  • Free means free of charge. In free software and open source discussions, free usually means freedom, not price. Free software can be sold. Paid software can be proprietary.
  • Open means visible. Source available code can be visible without granting open source rights. Open source requires a license that meets the Open Source Definition, including rights to use, study, modify, and share.
  • Buying means owning. Buying software usually means buying a license or access, not buying copyright or source code. Transfer, device, and version limits are set by the license.
  • A short license means a weak license. MIT is short and broad. GPL version 3 is long and detailed.

Frequently Asked Questions

What is a software license in one sentence?

A software license is permission from a copyright owner, with conditions, to use, copy, change, or share software in stated ways.

What is software licensing?

Software licensing is the practice of granting and managing those permissions. It includes choosing a license, stating its terms, tracking which components are under which licenses, and complying with conditions such as notices, source sharing, or seat limits.

Is a software license the same as buying software?

No. Buying software usually means buying a license to use it, or access to a service that runs it. It does not usually mean buying the copyright, the source code, or an unrestricted right to copy and resell the program.

Do I own software if I download it for free?

No, not in the copyright sense. A free download may come with a proprietary license, an open source license, or another set of terms. The license, not the price, decides what you may do. A download with no license gives you no clear right to copy, change, or share code beyond what the law independently allows.

What is the difference between proprietary and open source software?

Proprietary software keeps most rights with the owner and grants only the stated rights, usually without source code. Open source software is distributed under an OSI approved license that meets the Open Source Definition, including rights to use, study, modify, and share, subject to license conditions. Free software is a closely related term, defined by the Free Software Foundation through four essential freedoms.

What is the difference between permissive and copyleft licenses?

A permissive license allows proprietary derivative works, subject to light conditions such as keeping notices. A copyleft license requires derivative works, or a defined part of them, to be shared under the same license when distributed. Strong copyleft, such as GPL, applies broadly to a program based on the code. Weak copyleft, such as MPL 2.0, applies at the file level.

What does MIT allow, and what does it require?

The MIT License allows use, copying, modification, merging, publication, distribution, sublicensing, and selling, free of charge, subject to keeping the copyright notice and permission notice in all copies or substantial portions. It provides software as is, without warranty.

What does Apache License 2.0 add compared with MIT?

Apache License 2.0 is also permissive, but it adds an express patent license, clearer rules for marking changed files, retention of notices, NOTICE file handling, and a statement that trademark rights are not granted except for reasonable use in describing origin and reproducing NOTICE content.

What does GPL require when I distribute a changed version?

Under GPL version 3, if you distribute a changed version, you must pass on the same freedoms you received, make sure recipients receive or can get the source code, show them the terms, and mark your changes as required by the license. Private modification without distribution is treated differently.

What is AGPL, and why does network use matter?

AGPL is a strong copyleft license that adds a network use condition. If you make the functionality of modified AGPL software available as a network service, you must offer the corresponding source code to users of that service, under AGPL terms. That condition does not appear in the ordinary GPL in the same form.

Can I use open source software for commercial purposes?

Yes, in general. The Open Source Definition does not allow discrimination against fields of endeavor, and the Open Source Initiative states that all open source software can be used for commercial purposes, and can even be sold. Individual licenses still have conditions, such as notices or source sharing.

What should I do if code has no license?

Treat it as unlicensed for copying, changing, and sharing, unless a separate permission or a legal exception clearly applies to your use. Ask the owner for a license, choose a clearly licensed alternative, or write your own original implementation. If you are the owner, add a standard license to make your intent clear.

Can a license change after I start using software?

A project can release a future version under a new license, subject to contributor rights and earlier license terms. Your rights in a version you already received are normally governed by the license for that version, subject to its termination and other terms. Always check the license for the exact version you use or distribute.

Is this article legal advice?

No. This article gives general information about software licensing for learning purposes. It does not give legal advice for any person’s situation. License terms, local law, contracts, and facts can change the answer. For a high stakes decision, seek professional legal advice and read the full license text for the software in question.

Sources & references

  • Free Software Foundation, GNU Project, What Is Free Software? The Free Software Definition, including the four essential freedoms. Opened in full on 30 October 2026 at https://www.gnu.org/philosophy/po/free-sw.hr-en.html
  • Open Source Initiative, Frequently Answered Questions, including the definitions of open source software, copyleft, permissive licenses, commercial use, and public domain. Opened in full on 30 October 2026 at https://opensourceorg.github.io/osi_website_archive/archive.opensource.org/faq.html
  • United States Copyright Office, What Is Copyright? Including original works of authorship, fixation, exclusive rights, expression versus ideas, and registration. Opened in full on 30 October 2026 at https://www.copyright.gov/what-is-copyright/
  • Free Software Foundation, GNU General Public License version 3, 29 June 2007, preamble and terms and conditions, as reproduced in the Oracle documentation copy. Read in search results on 30 October 2026 at https://docs.oracle.com/en/industries/communications/network-data-analytics/23.1.0/nwdaf-lium-23-1-0/gnu-general-public-license-version-3-gpl-3.0.html
  • Open Source Initiative, The MIT License, including the permission grant and notice condition, as listed by SPDX. Read in search results on 30 October 2026 at https://spdx.org/licenses/MIT.html
  • European Commission Intellectual Property Helpdesk, How to Apache 2.0? Summarizing the copyright grant, patent grant and termination, redistribution conditions, NOTICE handling, and trademark limits of Apache License 2.0. Read in search results on 30 October 2026 at https://intellectual-property-helpdesk.ec.europa.eu/news-events/news/how-apache-20-2020-02-13_en
  • FOSSA, Open Source Software Licenses 101: Mozilla Public License 2.0, explaining weak copyleft, file level scope, and larger works. Read in search results on 30 October 2026 at https://fossa.com/blog/open-source-software-licenses-101-mozilla-public-license-2-0/
  • Creative Commons, CC0 FAQ, stating that CC0 is suitable for software, is compatible with many software licenses including the GPL, has not been approved by the Open Source Initiative, and does not license patent rights. Read in search results on 30 October 2026 at https://wiki.creativecommons.org/index.php?title=CC0_FAQ&direction=next&oldid=57588
  • SPDX, SPDX License List, describing standardized short identifiers, full names, license texts, and canonical permanent URLs. Read in search results on 30 October 2026 at https://spdx.org/licenses/archive/archived_ll_v2.4/index.html

Emma Hudson

Editor of Amberaisle — clear, thoughtful explainers for curious readers. More about the editor →