Licensing and Open Source

Key ideas

• Code without a licence is protected by copyright by default, so no licence does not mean free to use. Public on the internet is not the same as open source.
• Open source means the licence permits using, studying, modifying and sharing the code under stated conditions.
• Your dependencies come with their own licences. Each package you add, and each package it pulls in, has one. See Dependency Risks.

Two broad families

Family	Examples	In short
Permissive	MIT, BSD, Apache 2.0	Few conditions, usually keeping the copyright and licence notice
Copyleft	GPL, AGPL, LGPL	Modified or combined work may have to be shared under the same or a similar licence, depending on the licence and how you use it

This table is a simplification. Details differ, for example how a licence treats patents, network use or linking, which is why the exact text matters.

Before you add or share something

• Licences are identified by short SPDX names such as MIT or Apache-2.0. Package manifests and repositories usually state them.
• Check the licence of a dependency before adding it to work that is shipped or sold (images, fonts and data sets have licences too), keep required notices, and follow your organisation’s approved-licence policy if it has one.
• Do not paste code from forums, blogs or AI tools into a product without knowing its terms (see Verifying AI Output).
• Contributing to an open source project may require agreeing to its contribution terms, and code written for your employer may not be yours to publish. Ask first.
• Your own projects need a licence file if others are meant to use them.

When unsure

Stop and ask Legal or your compliance contact. Do not guess, and do not leave it to be discovered at release time.

Try it

Pick a small project you work on and list the licences of its direct dependencies, using the package manager’s metadata or each repository. Note which licences you recognise and which family they belong to. Look up one unfamiliar licence on SPDX or Choose a License.