Problem/Motivation

This module includes multiple updated versions of core provided JavaScript libraries (which are not altered). They are actively maintained and easy to find in other locations on the internet.

Ultimately it does not adhear to [the current] Policy for 3rd party libraries on Drupal.org.

This is currently blocked on a higher level issue discussion: #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL.

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Original report by @kreynen

This module includes 3 versions of JQuery and JQuery UI that aren't altered, are actively maintained, and easy to find in other locations on the internet.

http://drupalcode.org/project/jquery_update.git/tree/refs/heads/7.x-2.x:...
http://drupalcode.org/project/jquery_update.git/tree/refs/heads/7.x-2.x:...

This is a clear violation for the current Policy for 3rd party libraries on Drupal.org.

My goal is not to see this module changed, but to illustrate popular modules that violate the current policy in an effort to get the policy revised so that making installs easier for users is a legitimate reason for including a 3rd party library in a module. This is related to...

#1856438: Provide project bundling exception for custom build of CKEditor

Comments

kreynen’s picture

gisle’s picture

Issue summary:View changes
Issue tags:+licensingpolicy

Added tag.

markcarver’s picture

Title:Violation of policy for 3rd party libraries on Drupal.org?» [policy][jquery_update] 3rd party libraries
Category:Bug report» Task
Priority:Major» Normal
Issue summary:View changes
Status:Active» Postponed
Parent issue:» #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL

I am marking this postponed on the related issue as we really cannot do much until an official stance has been decided (either way).

FWIW, I believe (not entirely sure) the reasoning behind why jquery_update includes the jQuery and jQuery UI versions is because their [predecessing] code is already bundled with core (thus already vetted?).

gisle’s picture

For the record: There is no such thing as "already vetted" in the current policy.

The current policy says that you need an explicit exception granted to include third party materials in a distro (the exception must be applied to the distro, not the material), and there is no record of this project ever being granted one. Further, since the libraries are easily available from the jQuery website, and to download and install them only requires a separate installation step, an exception should not be granted under the current policy - see https://www.drupal.org/node/422996 and https://www.drupal.org/node/66113 where this is explained.

However, I agree with postponing this until #1856762: Revisit and Redefine Drupal's Policy on hosting 3rd party files and/or files that is not strictly GPL is sorted out.

To anyone wondering what is going on: We try to tag every issue with a possible license violation with the tag licensingpolicy to get an overview over how the current policy is enforced (or, not to beat around the bush: not enforced).

Please note: No immediate enforcement is planned (as should be obvious: nobody has tried to enforce this since it was opened in 2012). We first need to get an overview of the current situation. Then we need to decide what to do about it.

markcarver’s picture

For the record: There is no such thing as "already vetted" in the current policy.

Which is why I added a question mark at the end. I know there isn't such a thing in the policy. However, this specific module is rather unique in that it is replacing existing core libraries; hence probably why it includes them. Not saying I agree either way TBH and have very little interest in starting a comment war. Just offering a possible reason is all.

kreynen’s picture

This was actually vetted (as much as anything was), but rejected back in 2007 when developers used the development mailing list to discuss this type of issue. At least some of the maintainers of JQuery Update have been knowingly violating the policy since that discussion. The issue with JQuery Update came up when I was trying to get an official exception to the policy to commit WYSIWYG related javascript so that the TinyMCE would load something for users out "of the box" that they could then replace with a full blown version of TinyMCE they downloaded from Moxiecode later. This was before the Library module when most module maintainers instructed users to add the library to the module dir. TinyMCE was the most popular WYSIWYG module on Drupal.org at the time and the issue queue was full of "I don't see TinyMCE after enabling the module" and "I updated and TinyMCE is now gone". The code I was asking to commit was originally licensed as LGPLv2, but even after the team at Moxiecode agreed to allow it to be re-licensed as GPLv2 or later the answer was still no

A number of reasons were given including that the additional code was going to make CVS unmaintainable. That was obviously an excuse from someone who just didn't want this code in the Drupal repo.

I was told in no uncertain terms that if I committed the code, my CVS privileges would be revoked. As a result, I stopped updating TinyMCE.

You can read my recap of that discussion or the entire thread , but @jjeff's input towards the end of the discussion still rings true today...

What exactly does "foreign code" mean?!? If we write it from scratch,
it's not foreign, right? What if we copy some of the code from
another GPL project? What if we only slightly modify another GPL
project, perhaps just enough to make it work with Drupal? Well then
it can't be downloaded from the original source. Are you telling me
that this can't be included in the contrib repository? This sort of
modification is the entire spirit of the GPL! It's about freedom and
growth. By not allowing it into the repository, we are actually
diverging from the spirit of the GPL.

How modified does a project need to be in order to be considered
"native" Drupal code? I would submit that it DOES NOT need to be
modified at all in order to be considered Drupal code. In the case of
Drupal 5's JQuery, Drupal includes JQuery version 1.0.3 which is now
fully deprecated in the JQuery community. Many of the JQuery plug-in
maintainers do not continue to distribute plug-ins that function with
1.0.x and so there is no way to link to these plugins and ask users
to download them elsewhere. So in the form of the old versions of
these plugins, we have unmodified code, that for all intents and
purposes, only works with Drupal and can only be found in the Drupal
code repository.

We have a great resource with the Drupal CVS repository. I think that
we should be as accepting as possible in order to foster creativity
and growth. The GPL and Source Forge both provide examples as to the
spirit of this openness. I think we should take notes. The larger
that Drupal becomes, the more "gray area" code will emerge. I believe
the rules for code inclusion should be very very simple: All code
must be GPLed.

Don't get me wrong, I would be ALL FOR allowing LGPLed code into the
repository, but I also understand that the line needs to be drawn
somewhere. But I think when people talk about *not* allowing at-one-
time-external GPLed code into the Drupal repository, they're simply
on crack.

Unfortunately the "crackheads" got their way and the policy went unchanged and inconsistently enforced for 5 more years until @Jen Lamption pushed for a revision to the policy again in 2012 based on work @quicksketch was doing with CKEditor. At that point it was obvious Drupal.org had gotten out of sync with the approach other projects were taking, but no changes were made after weeks of discussion... so here we are again.

Since https://www.drupal.org/project/jqmulti is able to provide similar functionality to jquery_update without violating the policy, it's obviously possible to do that. There is no technical reason for giving JQuery Update an exception. It doesn't meet any of the current criteria.

Back in 2012, JQuery forced Drupal to update our approach to licensing when that team stopped dual licensing JQuery as MIT and GPLv2. If Drupal.org didn't adapt our policy to allow MIT and other lax licenses, we couldn't have committed newer, MIT-only licensed version of JQuery. We would have had to start asking users to download JQuery separately and place it in the correct directory before they even installed Drupal.

Based on this history, it seems logical to use JQuery Update as a test case to form new policies around. If "because it's easier to install the module" is a good enough reason to grant JQuery Update an exception to commit copies of JQuery to be distributed with the module, then it should be good enough for any other contrib module to get an exception.

It would obviously be better if modules could get the libraries they depend on out of their module directory and into sites/all/libraries using some yet to be defined .make/post enable/packaging process, but that's really separate issue from whether the code is allowed in git right now.

markcarver’s picture

Title:[policy][jquery_update] 3rd party libraries» [jquery_update] 3rd party libraries

I, perhaps, unintentionally misconstrued this issue by placing [policy] in the front of the title when we should in fact be discussing it in the parent issue. @kreynen, I think your comment (which has been very helpful btw and I agree with, mostly) would be more beneficial to everyone as a whole over there. I think we should keep this issue specifically reserved for actually implementing whatever is decided over there (if anything).