PETACORE / LICENCE GUIDE

Software licences.
In plain English.

What can you use, change and sell?
What do you need to share in return?

Start with the quick comparison ↓

THE SHORT VERSION

The difference is in the conditions.

Every open-source licence below permits commercial use. The main differences concern notices, patents and when source code must be made available. “Open source” does not mean “must be free of charge”. Proprietary permissions depend on the agreement.

Quick comparison — follow the detailed conditions below
Licence familyCommercial useSource-sharing scope
ProprietaryDepends on the termsDefined by the owner’s agreement
MIT, Apache, BSD, ISCAllowedNo general requirement to publish changes
MPL 2.0AllowedCovered files when distributed
LGPL 3.0+AllowedThe library; replacement/relinking conditions apply
GPL 3.0 / 2.0AllowedCovered work when distributed
AGPL 3.0AllowedCovered work; also modified versions used over a network

“Share source” does not always mean publishing everything on GitHub. The licence defines which source, who must receive access, and how it must be provided. GPLv3 source-delivery rules ↗

Permissive

Broad reuse, including closed-source products, with conditions such as keeping notices.

Copyleft

Sharing obligations keep covered code available under the licence when the relevant conditions are triggered.

Distribution

Giving someone a copy, for example an app download or installer. Running software privately is different from distributing it.

01

Custom terms

Proprietary

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 ↗
02

Permissive

MIT

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 ↗
03

Permissive

Apache 2.0

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 ↗
04

Permissive

BSD 3-Clause

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 ↗
05

Permissive

BSD 2-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 ↗
06

Permissive

ISC

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 ↗
07

File-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 ↗
08

Library 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 ↗
09

Strong copyleft

GPL 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 ↗
10

Strong copyleft

GPL 2.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 ↗
11

Network copyleft

AGPL 3.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 ↗

BEFORE YOU RELEASE

A menu choice is only the beginning.

  1. Check what you own. Your licence choice cannot override someone else’s code licence. Review dependencies and contributor permissions.
  2. Be precise about the version. “LGPL 3.0+” means version 3 or later, commonly written LGPL-3.0-or-later. For GPL/AGPL, use -only or -or-later to match the permission actually granted.
  3. Ship the actual terms. Include the appropriate licence text and required notices. Setting a package metadata field is not a substitute for complying with the licence.
  4. Check how you combine and ship code. Linking, modifying a covered file and bundling independent programs can have different consequences. Compatibility depends on the actual licences and structure.

Using a GPL program privately does not by itself require publishing your changes. Hosting a modified AGPL program for remote users is a different case. Read the GNU FAQ ↗

The guide explains the options; it does not change the licence of Petacore or your project. These are simplified explanations, not legal advice. The full licence text governs.