Last updated 8 June 2016.

This is the policy for 3rd party code libraries in Drupal's contribution repositories.

In general 3rd party libraries and content are forbidden, so do not commit any. Instead, document for your users how to find and install the library/content themselves.

Exceptions can be made if the 3rd party library/content:

  1. had to be modified to work with Drupal, and the modifications were not accepted by the original author;
  2. is generally difficult to find, or the specific version needed is hard to find;
  3. is no longer maintained by the original author;
  4. has a license that allows us to distribute it under GPLv2+.

Getting an exception needs explicit approval by Drupal Licensing Working Group (LWG). Exception requests should be posted in the LWG's issue queue with the component "Exception Request". (Upfront: 90% of all exception requests are moot. Only ask for an exception if it is really required.)

For any exception to be made, the 3rd party library/content MUST be licensed under GPLv2+ or have a permissive license that allows it to be re-licensed under the GPLv2+.

This policy does not apply to original code written by a project maintainer. For example, if you write an integration library to connect a Drupal module to another API, you may include it in a repository (licensed under the GPLv2+), since this will be the original version of the library.

To avoid any misunderstanding: This policy applies all third party materials, including code (PHP and Javascript), CSS, media files (fonts, images, videos and sound) and text. Please note that the current Drupal Git Repository Usage policy only allows assets (i.e. data) under GNU/GPL version 2 and later to be placed in the repo. Specifically:

All files checked into the repository (code and assets) must be licensed under GPL version 2 and later.

Maintainers who violate this policy or refuse to correct violations brought to their attention may have their project unpublished or Git access revoked. For more discussion see: Related:


Aveu’s picture

Because the "exceptions" rule follows the other rules it *might* confuse some users that the exception reasons can trump all the above rules so I am writing this to share my understanding (the D.A.'s Legal team will correct me if I am in error) ...

Rule #3 above "absolutely and always" does **NOT** cancel or override Rule #2, ever! 

None of the listed reasons for exceptions change copyright status. Just because a work has to be modified, is hard to find, and/or is no longer maintained does NOT "automagically" make the author's copyrights go away.

Do not upload non-GPLv2+ code. Period.

I suggest adding something to this effect at the end of Rule 3 to make it less confusing.

gersh’s picture

If I use a third-party library to generate code, then what is the status of that code?

jenlampton’s picture

This policy has changed, we are now able to include GPL-compatible code in Drupal's repository.

Tommy Kaneko’s picture

Any of the above exceptions needs approval by administrators

This is understood, but how do we gain approval from the administrators?
[EDIT] - there is now a link to ask for approval - thank you.

Design is my game

sreynen’s picture

The Libraries API module is a good way to follow this policy for modules that depend on 3rd party code.

DamienMcKenna’s picture

What's the official policy for handling projects that committed non-GPL2-compatible code? Because of how the d.o git server is set up it is not possible to remove or change old commits, therefore even if the files are removed it will still be possible to download them again via git.

Damien McKenna | Mediacurrent

gisle’s picture

The LWG does not, as a rule, require projects to remove anything from Git history that is legally and freely available elsewhere on the web. In such cases, removing such components from the HEAD will be considered sufficient. This exclude them from the packaged releases, which is what the majority use when they download contributed modules and themes from

However, in the case of a real copyright violation (i.e. the repo contains a component that may trigger a DMCA takedown notice from its owner), the component must also be purged from the Git history. As you point out, the d.o. git server does not allow users to remove or change old commits. In most cases, this is handled by the entire repo being deleted, and then recreated after the copyrighted component has been completely removed from the project's history (usually by doing a Git rebase).

- gisle

DamienMcKenna’s picture

Could we please have an official ruling on whether MIT-licensed libraries can be included. The above is too general and, given the number of MIT-licensed libraries out there it would be useful to have a clear answer.

Damien McKenna | Mediacurrent

Leeteq’s picture

Why has this been unanswered for almost a year?

( Evaluating the long-term route for Drupal 7.x via BackdropCMS at )

klausson’s picture

Does anybody know what the proper process is for images? The rules are pretty clear on code - must be GPL2. But images are not typically licensed under GPL, especially when we are looking at things like logos for products that Drupal integrates with. Is there a process to follow or a specific license required? The use case is that I'm working on an integration project and I do have permission and encouragement to use their logo from the company that owns the rights to the trademark and the logo. But since it is not declared GPL, it will fail the 3rd party inclusion test.

gisle’s picture

@klausson - rules are pretty clear on images too. They must be GPL2 as well.

Please see for a longer answer.

- gisle

gisle’s picture

Could we please have an official ruling on whether MIT-licensed libraries can be included. The above is too general and, given the number of MIT-licensed libraries out there it would be useful to have a clear answer.

There exists a whitelist of GPLv2 Compatible Licenses. The Expat (also known as the "MIT") license is on the list. This means that the Expat (MIT) license can be included.

However, you still have to make an exception request to be allowed to include any third part material in the Drupal Git repository. As of February 2015, a Drupal Licensing Working Group (LWG) has been set up to process exception requests in a (I hope!) consistent and timely manner.

Exception requests should be posted in the Drupal Licensing Working Group issue queue (LWG) with the component "Exception Request".

- gisle