Licensing Working Group Charter - Draft 1

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Crell's picture

Based on recent discussion and feedback from the community the Drupal Assocation is looking to create a new Licensing Working Group. The LWG would be dedicated to handling issues relating to code licensing.

The proposed charter for the new Working Group is below. We are looking for public feedback on the charter before the charter is presented to the board. If the discussion results in notable changes to the charter I may post a follow-up draft in a new discussion.

The charter below is open for discussion until 1 November.


Mission

The mission of the Licensing Working Group (LWG) is to establish and enforce policies regarding license management for code and related assets hosted on Drupal.org and to communicate those policies to the community at large. The LWG acts as a group to maintain the guidelines and processes for license policy enforcement and to recommend and guide development of tools and infrastructure that are needed for said enforcement.

Scope / Duties / Responsibilities

Scope

The LWG is responsible for the guidelines, policies, standards, tools, and processes around licensing of code and related assets hosted on Drupal.org, and to enforce these policies.

Specific Duties

The LWG exists to be an authoritative voice in the event of license policy disagreements. They do so by engaging in the following activities:

  • Establishing and maintaining policy on the license by which code and assets are distributed from Drupal.org. This includes both "first-party" resources (code/assets uploaded directly to Drupal.org) as well as "third-party" resources (external code/assets packaged for download on Drupal.org).
  • Maintaining the "whitelist" of allowable third-party licenses/projects. Said whitelist (https://www.drupal.org/packaging-whitelist) will be used in projects such as Distributions that pull in external, third-party code for packaging on Drupal.org.
  • Maintaining documentation related to licensing policy. This includes the Licensing FAQ (https://www.drupal.org/licensing/faq), policies on third-party code contributions on Drupal.org (https://www.drupal.org/node/422996), Drupal Git Repository Usage policy (https://www.drupal.org/node/1001544), etc. Create an additional document: “Contacted by the LWG. Now what?”
  • Enforcing licensing policies on contributed code/assets. This includes responding to reports of license violation in a timely manner, providing ample notice to a contributor that they are in violation of the licensing policy and what the steps to resolution are, and where necessary taking action against a project in violation such as unpublishing it until the code is brought into compliance with the license.
  • Partnering with other working groups, such as the Drupal.org Software/Infrastructure Working Groups, or the Documentation Working Group, on tools/policies to help with license policy enforcement that fall under the scope of those groups. Recommendations for tool/policy changes are made as a group.

Exclusions

Items specifically not within the scope of the LWG's duties:

  • Actively policing and proactively looking for license violations; the group is more responsive in nature, fielding reports that come in (which may or may not originate from group members).
  • Responding to specific legal actions, such as DMCA Takedown notices. These should be directed to the Drupal Association, which is a legal entity, as opposed to a group of volunteers.
  • The LWG can make recommendations as a group, but cannot make changes (e.g. GPLv2 to GPLv3) to the license by which first-party code is distributed from Drupal.org. This decision rests with the project lead, Dries Buytaert.
  • Issues relating to trademark enforcement and violation (either by Drupal or Drupal modules or by 3rd parties of the Drupal trademark) are not within the scope of the LWG.
  • Content on Drupal.org, which is not checked into a Git repository, is not regulated by the LWG.

Process

Transparency

The LWG aims to be as transparent as possible by deliberating and documenting its decisions publicly in an issue tracker. The group will meet on a recurring basis to review new reports that have come in and take any action required.

Any proposed policy adjustments that affect a non-trivial number of contributors will be as widely publicized as possible and include a public "request for comment" period.

Community-proposed changes to existing policies and/or standards

Any party who feels a policy or standard maintained by the LWG could be improved may propose a change to the policy in question via the LWG's issue tracker. Generally, modification proposals should solicit discussion and support from members of the Drupal community before being brought forward to the LWG.

Received proposals will be evaluated by the LWG, and may be accepted, rejected, or referred back to the proposer with a request for further elaboration or community discussion on the issue. In some cases, the LWG may refer the issue directly back to the community for further discussion before making a final decision.

Appeals

If any of the involved parties feels a decision of the LWG is unreasonable, they can escalate it to an appeal. The appeals person/panel will then review the decision, and may choose to either uphold or change it. In the meantime, the decision of the LWG stands. The appeals panel shall consist of Dries Buytaert and/or his designate(s) for community/social issues, or the Drupal Association for legal issues.

Membership

The working group consists of a chair and 4-5 other members. The Drupal Association Board appoints the members of the group.

Charter revisions

The charter will be revised as needed. Any proposed charter revisions must be ratified by Dries Buytaert and/or his designate(s) prior to acceptance into this charter. In the future, this charter may be revised to modify the charter revision process, subject to the aforementioned condition.

Comments

Code and Content

tsvenson's picture

I think this is a step in the right direction, licensing is still a growing issue and we probably can't stay at GPL2 forever.

@Crell's intro:

The LWG would be dedicated to handling issues relating to code licensing.

Proposed charter:

...regarding license management for content and code.

Just included to point out the diff that the charter also mentions content

Also want to say that separating code and content, when it comes to licenses, is probably as good an idea as the ongoing separation of code, config and content going on for Drupal itself.

--
/thomas
T: @tsvenson | S: tsvenson.com

Needs tweak

Crell's picture

Hm, we should probably remove the mention of "content" in the intro of the license itself. The intent is for LWG to be responsible for "stuff in Git". "Stuff on the website" would be someone else.

Assets, not content

gisle's picture

I think the charter should say:

regarding license management for code and assets.

"Assets" are non-code stuff in Git (fonts, icons, images, documentation, etc.). As Crell says, the LWG will be responsible for "stuff in Git". It should be clear from the charter that there are non-code stuff in Git, and that the LWG will regulate that as well as the code.

I agree that "assets" is a

kreynen's picture

I agree that "assets" is a much better term, but let's avoid using "stuff in git" as the determining factor for the LWG's scope. The charter specifically tasks this group with maintaining the Drupal.org whitelist. That list is currently used for packaging distributions on Drupal.org, but there has been some discussion about a dependency injection whitelist in the future as well.

Distributions should only include references to projects as links in their .make. Technically a reference to the asset is in git, but the asset itself should never be committed to the distributions.

Content can be an asset, but the asset term is also general enough to describe anything that is "packaged and distributed from Drupal.org". The charter already includes "distributed from Drupal.org", but I think adding "packaged" would help keep the LWG out of sandboxes. It wouldn't be until a project was being promoted (and thus packaged) that it would fall within the LWG's scope to actually evaluate a reported violation and eventually enforce the licensing policy. I think reigning in the scope in is going to be essential for the group to actually get anything accomplished. The security team limits their scope even further than just avoiding sandboxes. They only deal with issues in "stable releases (Y.x-Z.0 or higher)" with contrib, though the Security Working Group Charter allows the group to define the policies, so maybe that isn't necessary in the charter...

While the SecWG owns the policies and processes that the Security Team uses, the definition of those policies and processes are expected to be developed within broad consensus from the Security Team members

When we get into the technicalities of a project that is just code vs. code that includes or interacts with assets using different licenses, what is allowed and what isn't gets very confusing... and as a result, very time consuming.

Sandboxes

Crell's picture

While I can see the appeal to ignoring sandboxes it's a different situation than the security team. In this case there's also legal liability issues involved. We don't want to be offering code on Drupal.org that causes licensing problems for users, sandboxes or otherwise, and that may open the Drupal Association up to legal liability if someone checks in 3rd party code they're not legally allowed to check in. I think we have to still cover sandboxes.

I will adjust the text above around content vs. assets later tonight.

CHANGE NOTICE - "code and related assets"

Crell's picture

Per discussion above, I've changed "content and code" to "code and related assets" in the Mission Statement and Scope sections.

Discussion is still open for another 2 weeks if anyone else has feedback!

Licensing FTW!

Darius Garza's picture

Looks great, awesome initiative. Is there any way to get involved and/or help out with the working group? Licensing is definitely a passion of mine.

cheers,
d.

This is great I'm glad this

redndahead's picture

This is great I'm glad this has gotten started. Not sure it's important, but you may want to be more specific by saying core/modules/themes/distributions that are hosted in the drupal.org project repositories. This is a charter and not a license so I don't think it's a big deal if it goes either way.

I look forward to see what comes out of this. The structure looks great.

Glad to see the initiative in

slashrsm's picture

Glad to see the initiative in this direction. There are lots of questions regarding licensing we should find answers to. This will hopefully make everyone's life easier. Specially contrib modules, themes and distributions contributors.

I agree we should cover sandbox projects too. They come with the code we technically distribute to the world. We should protect that code, it's authors, users and Drupal as a project same as we do for full modules.

I am interested to help with this issues if needed.

Janez Urevc - software engineer @ Examiner.com - @slashrsm - janezurevc.name

Legal

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week