I know this is going to be controversial, but the way licensing issues are being handled on D.O. has gotten so ridiculous it is no longer safe to assume that code you are downloading from Drupal.org is GPLv2+ or GPLv2 compatible. We've made a lot of progress making the Packaging Whitelist licensing policies much easier to understand, but what do we say to a developer who is told they can't add a library to their .make when other developers just commit the same files directly to git?

So now that I've publicly stated what most people who follow the Webmaster, Infrastructure, and Whitelist queue already know, what can be done about it?

The biggest change should be to consistently enforce the policies we already have. As a community, we are failing. I understand that no one has time to police all the code committed to git, but the current Webmasters don't act on licensing issues when they are reported. According to https://drupal.org/licensing/faq#q14 users are told to...

Please file an issue in the Webmasters issue queue (specify "Licensing problem" for the component) and we will look into the matter.

It really doesn't seem like anyone has ever known what to do with clear violations of the policies. When you look at https://drupal.org/project/issues/webmasters?status=All&component=Licensing, there are several reports of non-GPLv2 or non-GPLv2 compatible licensed code committed to git and nothing ever seems to happen. In some cases, the issues have existed for years and the modules are now used by thousands of sites.

#722554: flowplayer module includes Flash player protected with GPL 3 licence
#241881: Pageear/Curlypage GPL violation

Developers who follow the rules or ask for exceptions get nowhere slowly:

#2010902: Asking for exception so that Source Sans Pro font can be added to core
#2139273: Allow GPL Friendly Font Licenses
#1720156: Required permission to upload the 3rd party libraries to Drupal.org

Developers like who just commit something that isn't GPLv2+ or GPLv2 compatible can just continue to do it in project after project:

#2153121: Font Awesome is not GPL compatible and must be removed from git
#2153271: Font Awesome is not GPL compatible and must be removed from git

The only response from @themebrain has been to #2153139: Unpublish Distributions with Forks of Core < 7.32 which is where he creates even more issues by recommitting code from dozens of projects and third party libraries. I really thought that the way @themebrain ignored the licensing policies and committed thousands of redundant files from 3rd party libraries and Drupal.org project (including versions of core with security issues) would result in a quick response, but > 30 days later and there is no change to the projects. Releases are still published and users can still download code that isn't GPLv2+ or GPLv2-compatible from Drupal.org.

I had to go back to 2010 to find an example of an issue that resulted in someone actually removing files when the developer didn't respond to a licensing issue themselves.

I'm willing to help with this, but I think we need to establish some clear steps for what should happen after a violation is identified before taking action on any of the current issues.

Is there a document that describes what is supposed to happen when licensing issues are reported?
How long do you give a project maintainer to respond?
If they refuse to remove the files or add files they've been told are a licensing violation, what happens next?
Who has the final say on legal licensing questions if the developer disagrees with the interpretation of GPL compatibility?
Does the 3rd party code policy even matter any more?
Do we need to wipe all records of a file from git or is simply unpublishing the project's releases and posting a note to the project page enough?
If the project maintainers refuse to address a licensing issue, does everyone with permission to maintain a project lose their git privileges, only the person who made the offending commit, only the project node's owner?

I recently reopened #1245534: Using a third party library in mytinytodo. In that case the developer asked about GPLv3, was clearly told no, then when ahead and committed files w/ a GPLv3 license anyway. The response is that we again have to ask, so what do we do about this? The developer now says that the GPLv3 licensed files will eventually be re-licensed by the original author as GPLv2+. How long do we wait for a license to be changed? Is it OK to leave the Apache 2.0 licensed Bootstrap files in projects if we know future versions of that library will be licensed as MIT or do any files from versions of Bootstrap that aren't licensed properly need to be removed?

I personally think there should be changes to the strict GPLv2+ or GPLv2-compatible policies for distributions and fonts, but until/unless that happen the licensing policies need to be enforced consistently if we want to continue telling people that what they download from Drupal.org is GPLv2+ or GPLv2-compatible.

Comments

gisle’s picture

I agree that the current situation regarding licensing is bad.
It is certainly not safe to assume code from Drupal.org's git repo is GPLv2+ or GPLv2 compatible. The current policy is frequently violated, and violations are frequently ignored. However, we need to decide what to do about it (instead of just pretending that this problem does not exist).

There is also are a problem that copyright law regarding moral rights is not enforced on Drupal.org when third party content is hosted.

There is another problem that community documentation on Drupal.org is licensed under a non-GPLv2+ compatible license (CC BY-SA 2.0), making it technically illegal to include materials from the community documentation in a project package, and vice versa.

Here is my input:

  1. The present policy (only GPLv2+ or GPLv2 compatible assets permitted) needs to be enforced or revised. Assets (e.g. images, fonts, icons and style sheets) are often bundled with projects (e.g. Sticky Sharre Bar). However, assets are very rarely available under a GPLv2+ or GPLv2 compatible license. Instead, they're may available under some permissive licenses (in praticular SIL OFL) that makes it legal to include the asset in a repo. If the present git policy are to be enforced, a number of projects that currently are hosted on Drupal.org need to move somewhere else (e.g. GitHub).
  2. Copyright law requires moral rights to be observed when third party content (including third party content under GPLv2+) is distributed. Almost no third party content currently hosted on Drupal.org observes moral rights. This needs to change. My take on this is contributors need to be better informed about moral rights and how to observe them.

Other CMS systems competing with Drupal have more flexible licensing arrangements.

For instance Joomla! have the following it its licensing FAQ:

In our opinion, templates are composite packages that consist of both code elements and non-code elements. We believe that the code elements of a template must be licensed under the GNU GPL because they are derivative works. However, the non-code elements are just data acted upon by the software and may be licensed in any way the author sees fit. The non-code elements include elements like Images, Movies, Animations, CSS and formatting markup. Source: http://opensourcematters.org/license-trademark-and-copyright/licensing/5...

WordPress simply lists the licenses that are permitted for fonts and icons included in packages - see: http://make.wordpress.org/themes/guidelines/guidelines-resources/

I believe the current situation regarding 3rd party licensing is potentially very damaging to Drupal.org and probably also non-governable. The only reason the system appears to "work" is because the current policy is currently not enforced. That is not responsible governance.

I propose to set up an Ad Hoc Committee on Drupal.org Git License Reform of friends of Drupal (for instance by setting up a "Licensing reform" group at https://groups.drupal.org/ ) to work on a producing white paper that describes the current situation regarding licensing and why it is problematic, as well a concrete suggestion for a reformed policy. The goal is to present the white paper for the board of the Drupal Association, and (hopefully) to get the association to make a decision on the Drupal.org Git License that can lead to more responsible governance.

After the policy has been decided, the ad hoc committee should also provide community documentation for two target audiences. Git policy enforcement guidelines for the webmasters, and "How to comply with the Drupal.org Git license policy" for contributors.

I know this issue already has the attention of the Drupal Association. However, I think a good white paper may be required to give the Association a better understanding of both the stakes and the options.

gisle’s picture

Issue tags: +licensepolicy

Added "licensepolicy" tag.

gisle’s picture

Issue tags: -licensepolicy +licensingpolicy

Holly's minutes says we should use "licensingpolicy", not "licensepolicy". Retagging.

gisle’s picture

Project: Drupal.org site moderators » Drupal Licensing Working Group
Component: Licensing » Documentation

Moving to LWG issue queue.

(We probably need to consolidate all those separate discussions about possible amendments to the licensing policy into a single thread.)

gisle’s picture

Component: Documentation » Policy

Changing component ("Policy" was not available when I moved it.)

gisle’s picture

Priority: Critical » Normal
Status: Active » Fixed

While there may still be Git policy violations that the LWG don't know about in the repo, there is now a LWG to follow up violations a procedure for dealing with them has been established.

I see no point in having this one open. Closing as "Fixed" and adjusting priority.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.