Drupal.org distribution packaging requirements

The drupal-org.make file used by the Drupal.org packaging system must meet the following requirements:

• External libraries are validated against an allowlist of GPL-compatible libraries since all code distributed from Drupal.org must be GPL compatible. (See the criteria for packaging allowlist entries below).
• Git clones from Drupal.org sandboxes (as opposed to full projects) are not supported. #1432326: Support for git clones from Drupal.org sandboxes
• Patches hosted on servers other than Drupal.org are not supported.
• Modules and themes hosted on servers other than Drupal.org are not supported. #1427762: Allow modules/themes not hosted on Drupal.org to be packaged into distribution .make files.
• If you need to specify anything other than an official release of the Drupal core project itself, that needs to go into a separate drupal-org-core.make file. #1455614: Packaging script doesn't allow distributions to patch core or specify a git revision
• If you request a specific Git revision you must also define the branch that revision came from. #1371306: Add validation to ensure that if a .make file includes a git hash, it also defines a branch

Criteria for library's inclusion in the packaging allowlist

For a library to be added to the allowlist, it must:

1. Be requested via the allowlist issue queue by a module or profile maintainer and approved by at least one member of the LWG.
2. Be licensed under GPL-2.0-or-later, or an allowlisted, compatible license.
3. Not reference a git submodule or contain a component under a licence that is not allowlisted.
4. If a PHP library, it must be compatible with the version of PHP supported by the current Drupal Core release. (i.e., no PHP4-only libraries.)
5. Be in use by at least one supported Drupal module or installation profile.
6. Be less than 10MB compressed.
7. Not be legally questionable or malicious.

A library may be removed from the allowlist if:

1. The Security team deems that the library is not receiving proper security maintenance which poses a threat to drupal sites.
2. The maintainer of the library declares it to be deprecated and the LWG deem it prudent to be removed.
3. Its current license is not compatible with GPL-2.0-or-later.

Licenses compatible with GPL-2.0-or-later and GPL-friendly licenses

While Drupal is licensed under GPL-2.0-or-later, allowlist entries are only created for libraries that contain only code that are compatible with GPL-2.0-or-later according to the Free Software Foundation's list the most commonly encountered free software license.

Drupal also permits GPL-incompatible non-code assets (e.g. fonts, icons, images, etc.) to be packaged and/or distributed as long as the maintainer has the right to distribute them (i.e. they must have a free/libre license that permits them to be distributed “in aggregate” with GPL code). Such licenses are allowlisted as “GPLv-friendly”.

As the license identifier, please use the short identifier listed in the SPDX.org License List.

Most commonly requested license compatible with GPL-2.0-or-later:

Informal name	SPDX identifier	GPL-2.0-or-later compatibility
GPLv2	GPL-2.0-only
GPLv2+	GPL-2.0-or-later
LGPLv2.1	LGPL-2.1-only
MIT (Expat)	MIT
X11	X11
FreeBSD	BSD-2-Clause-FreeBSD
Modified BSD	BSD-3-Clause
ClearBSD	BSD-3-Clause-Clear
CC0	CC0-1.0
W3C	W3C
WTFPL	WTFPL
The Unlicense	Unlicense

Most commonly requested software library licenses that are not allowlisted under our current policy:

Informal name	SPDX identifier	Allowlisted
GPLv3	GPL-3.0-only
LGPLv3	LGPL-3.0-only
Apache 2.0	Apache-2.0
AGPL3	AGPL-3.0
No license

No new libraries avialable exclusively under one these licenses will be allowlisted. However, there are legacy entries in the allowlist that will allow distributions to package these. Please see the section about using libraries below for more information.

As for restricting the lisenses that are allowlisted for packaging on Drupal.org, it is a matter of policy. Our policy on not allowlisting GPL-3.0, Apache-2.0 or LGPL-3.0 licensed libraies is still being discussed. Please refer to this issue in the LWG issue queue to check on the status on this discussion.

For a complete list of GPL compatible licenses, please refer to the GPL-Compatible section of the Free Software Foundation's list the most commonly encountered free software license. This list includes licenses that are compatible w/ GPL-2.0 and GPL-3.0. Read the licenses details to confirm the licenses is compatible with GPL-2.0-or-later.

Most commonly requested GPL-friendly licenses:

Informal name	SPDX identifier	Is allowed
CC BY 2.5	CC-BY-2.5
CC BY 3.0	CC-BY-3.0
CC BY	CC-BY-4.0
CC BY-SA 2.5	CC-BY-SA-2.5
CC BY-SA 3.0	CC-BY-SA-3.0
CC BY-SA	CC-BY-SA-4.0
SIL Open font License 1.0	OFL-1.0
SIL Open font License 1.1	OFL-1.1
GPL+FE	GPL-2.0-with-font-exception

Using third party libraries

The only thing the GPL covers is distribution, copying, modifying. It is a copyright license, not a EULA. The end user can use any combination of licenses they want. The GPL does not cover use. This means that as an end user, you may create derivative works that make use of all sorts of libraries. However, because of the GPL, it may not be legal to distribute those derivatives. On Drupal.org, we monitor what we distribute, and make sure that what we distribute is legal. We do not monitor use.

However, if you distribute free software, for instance on GitHub or via some marketplace, it is your responsibility to ensure that what you distribute is legal.

As already noted, some distributions may contain free software components that cannot be freely combined with other free software components. Likewise libraries downloaded via composer may not come with a license that is compatible with other free software licenses. You are responsible for ensuring the compatibility of the licenses of software you distribute, as we cannot control how you create derivative works of Drupal.

If you use composer to manage your project, the command composer licenses allows you to see the license identifiers present in root composer.json.