Permissions come from the owner’s agreement.
This is a category, not one standard licence. The owner decides what users may do: run the app, install it on several devices, modify it or redistribute it. The terms may allow commercial use, charge a fee, or make the app free to download.
What to keep in mind
Read the actual agreement. Choosing “Proprietary” in a menu does not write an agreement for you, and visible source code does not automatically give permission to reuse it.
A simple example
You release a paid desktop app and grant customers permission to install it. Reselling or modifying it depends on your terms.
Background: code without reuse permission ↗Use it widely. Keep the notice.
You can use, modify, distribute and sell the software, including inside a closed-source product. You do not have to publish your changes.
What to keep in mind
Keep the copyright and permission notice in copies or substantial portions of the software. MIT also disclaims warranties; it is not a promise of support.
A simple example
You include an MIT component in a paid app. Keep its required notice; your own app does not have to become open source.
Read the MIT licence ↗Broad reuse, with an explicit patent grant.
Commercial and closed-source use are allowed. Contributors grant rights to relevant patents covering their contributions, subject to the licence’s conditions and patent-litigation termination clause.
What to keep in mind
Provide the licence, identify modified files, retain relevant notices and carry over applicable NOTICE attributions when supplied. The licence does not grant general trademark rights.
A simple example
You modify an Apache component for your product. Document the changes and carry over the required licence and notices; publishing your source is not required.
Read Apache 2.0 ↗Broad reuse, without implying endorsement.
Use, modify and redistribute the software, including in commercial, closed-source products. There is no source-sharing requirement.
What to keep in mind
Keep copyright, conditions and disclaimers in source distributions and reproduce them in documentation or other materials with binary distributions. You cannot use the owner’s or contributors’ names to endorse a derived product without written permission.
A simple example
You ship a BSD component in an app. Include its notices, but do not claim its authors endorse your app.
Read BSD 3-Clause ↗The shorter BSD option.
Commercial use, modification and redistribution are allowed, including in closed-source products. Unlike BSD 3-Clause, this text has no separate non-endorsement clause.
What to keep in mind
Keep the copyright, conditions and disclaimers in source distributions and reproduce them with binary distributions in documentation or other materials. The missing clause is not a general licence to use someone’s trademarks.
A simple example
You distribute a compiled app containing BSD 2-Clause code and include the required notices with the release.
Read BSD 2-Clause ↗A short licence with broad permission.
You may use, copy, modify and distribute the software for any purpose, with or without a fee. Closed-source reuse is allowed; changes do not have to be published.
What to keep in mind
Keep the copyright and permission notice in all copies. The software comes with a warranty disclaimer.
A simple example
You reuse an ISC utility in a commercial tool and preserve its licence notice.
Read the ISC licence ↗07File-level copyleft
Mozilla 2.0
Share the covered files, not necessarily your whole app.
The Mozilla Public License (MPL 2.0) allows commercial use and combination with proprietary code. When distributing covered software outside your organisation, make its MPL-covered source files, including your modifications, available under MPL.
What to keep in mind
Preserve notices and tell recipients how to obtain the covered source. Separate files containing only your own code can use other terms. “File-level” is the key distinction.
A simple example
You modify an MPL file and distribute an app containing it. Share that covered file’s source; separate proprietary files can remain closed.
Read Mozilla’s MPL FAQ ↗08Library copyleft
LGPL 3.0+
Keep the library open; allow other application licences.
An application can link to an LGPL library under different terms, including proprietary terms, if it meets the licence’s requirements. When distributing the library, provide its required source and keep library modifications under the applicable copyleft terms.
What to keep in mind
Provide the notices and GPL/LGPL texts, and allow users to modify or replace the library. Depending on linking, this can require relinkable application files or a suitable shared-library mechanism. Static linking is not simply exempt.
A simple example
You ship an app using an LGPL library. Users must have a compliant way to use a modified library. The “+” permits version 3 or a later LGPL version.
Read LGPL 3.0 ↗Preserve the same freedoms when distributing.
Commercial use and selling copies are allowed. If you distribute a covered program or a derivative combined work, provide the corresponding source through a permitted method and license the covered work under GPLv3.
What to keep in mind
Keep notices, document changes and follow the source-delivery rules. GPLv3 includes explicit patent provisions and, for certain user products, installation-information requirements. Separate, independent programs in an aggregate are not automatically covered.
A simple example
You distribute a modified GPLv3 app. Recipients receive GPL rights and access to its corresponding source; you may still charge for the app.
Read GPL 3.0 ↗An earlier GPL, with its own conditions.
You may run, modify and sell the software. Distributing a covered derivative work requires GPLv2 licensing and source availability under its permitted methods. Merely using a GPL tool does not automatically license everything you create with it.
What to keep in mind
Keep notices and follow source-delivery obligations. GPLv2-only cannot simply be relabelled GPLv3. Permission to use later versions must come from the project’s licensing notice.
A simple example
You distribute a modified GPLv2-only program. Follow GPLv2, rather than assuming a newer GPL version is interchangeable.
Read GPL 2.0 ↗GPL-style sharing, plus a network condition.
Commercial use is allowed. AGPL includes distribution obligations and an additional requirement: if you modify the program and let people interact with that version over a network, prominently offer those users its corresponding source at no charge.
What to keep in mind
Do not treat “we only host it” as a way around this condition. The requirement concerns the covered program; it does not automatically cover every independent service on your server.
A simple example
You modify an AGPL web app and run it as a hosted service. Offer its corresponding source to the users who interact with it, even without sending them an executable.
Read AGPL 3.0 ↗