Splitting this off from #779452: Whitelist for external dependencies and #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites.

I believe we're pretty close to agreement on the policy. From the other issue, the current draft is:

---

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

  1. Be requested via the http://drupal.org/project/issues/drupalorg_whitelist issue queue by a module or profile maintainer, and seconded (RTBC) by at least one other community member, and
  2. Be licensed under a GPL-compatible license listed here: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
  3. 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.)
  4. Be in use by an active Drupal module or installation profile.
  5. Be less than 10mb compressed.
  6. Not be legally questionable or malicious.

A library may be removed from the whitelist if:

  1. The Security team lead 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 whitelist maintainers deems it prudent to be removed.
  3. It can be established that no current release of any profile on drupal.org uses or has used the library in the last 6 months. (not sure how feasible it is to track this, so maybe strike this point on the basis of practicality.)

The whitelist maintainer shall be nominated and confirmed by agreement of the drupal.org infrastructure team to serve until resignation, or removal by agreement of the infrastructure team. For these purposes, "agreement of the drupal.org infrastructure team" means effectively: "2 +1's from trusted folks, no objections for 2 weeks."

---

See also #1360460: Populate initial team of 3rd party packaging whitelist maintainers and #783186: Packaging: document whitelist

Thanks!
-Derek

Comments

dww’s picture

Issue summary: View changes

moved questions around the initial team itself to #1360460

dww’s picture

Issue summary: View changes

fixed del tags

dww’s picture

Title: Finalize and document criteria for the whitelist for external dependencies packaged with Drupal distributions » Finalize the criteria and process for the whitelist for external dependencies packaged with Drupal distributions

Sorry, the initial post was a bit confused since I forgot we already had #783186: Packaging: document whitelist open, and I decided to move the whole question of the initial team of whitelist maintainers to a separate issue: #1360460: Populate initial team of 3rd party packaging whitelist maintainers. The summary is now fixed. Re-titling to focus the scope on the main thing we need to do here: finalize the criteria and process.

Thanks,
-Derek

dww’s picture

Issue summary: View changes

updated summary based on #783186

greggles’s picture

I removed the word "lead" from the security team part. The team+lead(s) can figure out how their decision process will work and this policy doesn't need to be explicit about that process.

greggles’s picture

Implicit in my comment is a +1 on everything else, but it's worth saying: +1 on the amended version ;)

killes@www.drop.org’s picture

looks great to me!

geerlingguy’s picture

Status: Active » Reviewed & tested by the community

I like this, see no problems (legally or otherwise, but I'm no lawyer)... I dare to RTBC, since it seems we have at least three +1s and no negative remarks.

Gerhard Killesreiter’s picture

I think the voting part should be changed to "by agreement of the infra team" or something like that. We do neither have a proper infrastructure for holding elections nor do we have a proper definition for the electorate...

Gerhard Killesreiter’s picture

Issue summary: View changes

no need to explicitly state the structure of the security team in this policy

skottler’s picture

This looks good to me. +1

geerlingguy’s picture

It looks like the voting part was updated. I'm pretty happy with this, but I do think we could strike out:

It can be established that no current release of any profile on drupal.org uses or has used the library in the last 6 months. (not sure how feasible it is to track this, so maybe strike this point on the basis of practicality.)

As stated in the bullet, it wouldn't be very practicable. But we should probably think about how we're going to keep the list trimmed well in the future—projects do die quite often!

geerlingguy’s picture

Issue summary: View changes

s/majority vote/agreement/ since the infra team doesn't have clear membership or any mechanism to hold such votes.

geerlingguy’s picture

I added in "Be in use by an active Drupal module or installation profile.", mostly because some people may simply add a bunch of libraries they think would be useful, but would just clutter up the whitelist.

geerlingguy’s picture

Status: Reviewed & tested by the community » Needs review

Should probably have people look things over again before committing to the guidelines, since some things have changed since Dec. 22.

geerlingguy’s picture

Just pinging everyone subscribed... would someone like to RTBC so we can close out this issue and complete the packaging whitelist project page/guidelines?

We've been operating under these guidelines for a month, with no real problems or concerns raised.

dww’s picture

Status: Needs review » Reviewed & tested by the community

Looks fine to me. If/when we need to change them, we will. ;) So, are you going to document this or should I? Where were you going to put it?

Thanks!
-Derek

geerlingguy’s picture

Status: Reviewed & tested by the community » Fixed

I put the criteria for inclusion and removal on the Drupal.org distribution packaging requirements page (seems a good fit), and I've linked to it from the packaging whitelist project page.

dww’s picture

Sweet, thanks!

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

Anonymous’s picture

Issue summary: View changes

Added "Be in use by an active Drupal module or installation profile." and struck a line that should be removed.