Published: Feb. 12, 2018

Last week, the term open source itself turned 20! While the ideals of free and open source code had been discussed before January 1998, that was when Netscape released their browser source code. 

We think it is going to change the way people actually develop these products dramatically for many, many years to come. This will be a historic day in that chain of events. - Jim Barksdale, Netscape CEO

It did. It was. But are the links this chain as strong today as 20 years ago?

Version 1 of the GNU GPL (GPL-1.0) was released in February 1989 followed by GPLv2 (GPL-2.0) in June 1991. Dries open-sourced the software behind Drop.org and released Drupal 1.0.0 in January of 2001.  

I’m not sure if there are other documents that survived the Drupal.org updates and the great Git Migration, but thanks to the Archive.org’s Way Back Machine you can still access the Drupal project’s contributor policy from 12/04/2004.

Q: What license should I use?

A: We currently require that all submissions carry the GNU/GPL license. This
may, or may not change in the future. For more information on the GNU/GPL,
point the browser of your choice to http://www.gnu.org/.

You don't have to include a LICENSE.txt in your theme or module's
directory because there is global LICENSE.txt in the top-level directory
of the contributions repository.  Furthermore, a LICENSE.txt will
automatically be added to each packaged theme or module (.tgz file) that
is offered for download at http://www.drupal.org/.

Other than getting more specific about the GPL-2.0+ policies and improving FAQ, the Drupal project's approach to licensing remained largely unchanged until 2018. 

Did you know that Drupal themes and modules can now include popular font packages like Font Awesome?

Probably not, but the DA and Dries finally approved a change that officially allows non-code assets like images, text and fonts that use licenses other than GPL-2.0 to achieve similar goals to the 4 essential freedoms the GPL protects.  WordPress made this change several years earlier.  Despite claiming to have the same general licensing policy as Drupal, they’ve actually encouraged theme developers to add assets using a variety of license for many years.  These licenses can be included in projects distributed as GPL-2.0 because things like images, text and fonts are treated as assets that aren't part of the code.

WordPress now has more than 5,300 themes available on WordPress.org.  There are even more commercially available themes that walk a strange line of GPL compliance.  I know what you are going to say.  Many of these WordPress themes are junk.  Hundreds of these aren’t fully compatible with the current WP release. They have so many themes for a single use case like a recipe site or a bed and breakfast that require specific plugins.

All true… but I'll counter with the fact that there are thousands of WordPress themes and currently, only 270 themes available for Drupal 8.

You could argue that Drupal’s themes have to be more flexible to support any content type or view a site build dreams up and that many of Drupal themes are base themes that are designed to support custom theme development.

Again. All true… but I'll counter with the fact that there are thousands of WordPress themes and currently, only 270 themes available for Drupal 8.

While licensing policies are only one of many differences between the Drupal and WordPress theming ecosystems, the negative impact the additional effort required to complete Drupal's multistep installs has on adoption is a factor.

Won't Composer fix the multistep install issue?

It will, but it introduces new challenges like keeping up with the changes happening off the island. One change is that the Software Package Data Exchange (SPDX) specification that Composer uses has deprecated the use GPL-2.0+ in favor of GPL-2.0-or-later. SPDX is standard Composer uses for licensing.

Scary Red Deprecation for GPL-2.0+

Wait... So How Exactly are Drupal Projects Deprecated?

I have to apologize.  I’ve used a clickbait title to get you to read this far.  But be honest, if I titled this post “Drupal’s Use of GPL+ in Composer.json is Deprecated in Favor of GPL-2-or-later” would you have even opened the post? 

While 2017 was a really dramatic year for open source, there are very few people in the world who really understand these licensing conflicts and even fewer members of the Drupal community.  Most of us would prefer to believe we learned everything we need to know about sharing in kindergarten and just want to write, share and use code without getting lawyers involved. 

Unfortunately for the GPL to work, someone has to understand the details and enforce them.

This is where the Drupal's Licensing Working Group comes in.  Unlike the Drupal Security, Infrastructure or Community working groups, most members of the Drupal community have probably never heard of the Licensing Working Group.

To this group, Facebook’s decision to change the license of React after WordPress refused to use with the BSD + a patent clause was epic.  If you're still reading and understood why that licensing change was so important, please contact me.

LWG Appear.in Screenshot

The LWG currently has 3 members; Gisle Hannemyr  (University of Oslo), Shawn DeArmond (University of California Davis) and myself (University of Colorado Boulder) and we’d like to expand the group. The Drupal project faces a number of challenges as we move from the safety of our island to a very different landscape for licensing and distribution than what existed in 2001. 

The Apache-2.0 Problem

Yesterday Amazon published a WordPress plugin that integrates with their Polly service.  The fact that Amazon developers wrote the plugin is noteworthy and the functionality is interesting, but this is not what caught my attention.

If you download the plugin from WordPress.org and look in /vendor/aws/LICENSE.md, you’ll see that the Polly library is licensed as Apache-2.0.  While it’s easy to find code using a variety of licenses that are clearly not GPL-2.0 compatible in plugins available for download from WordPress.org, the WordPress uses a similar strategy to Drupal where we don't police contributions.  Both projects will only take action if someone reports the issue.  So I did.

I'm hoping that between this post and that issue, I can elicit a response from the WordPress community about how they plan to deal with the Apache-2.0 problem. 

Drupal projects are constantly running into Apache-2.0.  The popular Accelerated Mobile Pages (AMP) module requires a library Google has licensed as Apache-2.0. This currently makes it impossible to include a functional version of that module in a Drupal distribution.  Strangely, the most popular AMP plugin for WordPress reporting more than 200K installs and written by Automattic doesn't use Google's library.

In addition to becoming the license of choice for influential groups like Google, Amazon, and Mozilla, GitHub heavily promotes 3 licenses when starting a new project.

GitHub Choose a License Options (MIT, Apache-2.0 or GPL-3.0)

Of these, only an MIT license would allow the project to be committed to a Drupal module or theme or packaged with a Drupal distribution. This isn't only an issue with PHP libraries, the core Modernizing JavaScript initiative is starting to hit this as well.  

While there was once a time when developers working in Drupal could ask large project to change their licensing and actually make it happen, even then it was a Don Quixote-esque undertaking that took years.  I don't see a future where the Drupal project can get all of the projects we want included to use a different license or survive without being able to package those projects with our projects.

The LWG tries to advocate for licensing policy related changes that encourage contributions while helping to protect the DA from legally questionable activity on Drupal.org, but these aren't easy questions.  There are downsides to distributing Drupal projects as GPL-3.0 or ignoring the licensing compatibility concerns the Free Software Foundation has with Apache-2.0, but we need to find our way forward soon.

I've proposed a Core Conversation session for DrupalCon that I really hope is accepted.  How compatible the Drupal.org's policies are with the realities of collaborative development off the island will have a huge impact on the project's future as well as Drupal.org ability to remain relevant for project development and distribution.