Non-GPL code in Backup and Migrate CVS

The code is licensed under a BSD license, which is one of the GPL-compatible licenses.

Isn't this covered under section 10 of the licensing FAQ: http://drupal.org/licensing/faq#q10 ?

Is this actually an issue? It seems like this falls within the licensing guidelines.

The link reported in comment #1 contains the following text:

If you wish to contribute a bridge module to Drupal's CVS repository, please do not check in the 3rd party library itself. Doing so creates a fork of that 3rd party library, which makes it more difficult to maintain and only serves to waste disk space. Instead, provide detailed instructions for users to download and install that 3rd party library for use with your module. If you believe that your module is a special case where it really does need to be included in the CVS repository, usually only because you need to make substantial modifications to it in order for it to work, please file an issue with in the infrastructure issue queue first to discuss it.

In http://drupal.org/node/66113 is reported that:

So, in short:

1. Only GPL'd code/images/files
2. But no GPL code/images/files that are available from 3rd party sites as long as the proper version to use with your module is easily accessible. Easily accessible means that the release that works can be downloaded in a compressed file of some sort. If your users have to use svn/cvs to get the files then that is not considered easily accessible.

In http://drupal.org/node/422996, though, is reported that:

Exceptions can be made if the 3rd party library:

1. had to be modified to work with Drupal and the modifications were not accepted by the original author.
2. is generally difficult to find in the needed version.
3. is no longer maintained by the original author.

I added the library to the module since the module is aimed at a fairly non-technical audience and I wanted to make installation easier. (My experience with the 'describe how to install it' method with B&M Files tells me I'm not wrong on this one: http://drupal.org/project/issues/backup_migrate_files?text=archive%3A%3A...).

I understand that "Making it easier for the user" is not an listed excuse to get a variance from this policy so I imagine I won't, but I do have to say that I disagree with the policy. I understand the basic need to not allow, say, the entire Zend framework to be committed to the drupal CVS, but to apply this rule in all cases starts to feel a little arbitrary. The rule makes perfect sense for the 'bridge' type modules that link to enormous and ever-changing libraries, but in a case like this, I'm not fully onboard. The file is all of 46k and since I haven't changed it whatsoever, it cannot possibly be construed as a fork by any reasonable definition of the word. I'm really not seeing the difference between including a version of the file with the module and directing the user to download the very same version of the file from a different server and putting it in exactly the same place (other than confusing and inconveniencing the end user).

That's my opinion and my reasoning for ignoring the policy to begin with. I hope I didn't come off too rude or disrespectful, because I do respect and appreciate the hard work the infrastructure team put into keeping everything ticking along nicely here on d.o.

Let me know if you want me to pull the S3 file.

Ronan

Subscribing.

Subscribing.

To be honest, requiring every single file to be downloaded separately makes installing a module into a full-blown operation and really makes it impractical to do anything without drush make scripts. It's been bugging me for quite a while.

So I must say I agree with ronan, even if it's against the policy.

I think that not committing external libraries in drupal.org has its pros, especially if the library is used by more than a module.

What would happen if two modules use the same library, but different versions? If both the modules load the library for the same page, there will be surely a conflict.
Even in the case the library is used from just a module, what happen when the library is updated? Should the users will wait until the maintainer commits the new version of the library? What happens for those sites where the library creates problems and the maintainer should use the older version of the library? What happens if the administrator of a site has modified the library for his own site?

We have already rules about which libraries can be committed, and those rules should be followed.

Ronan's comments in #5, above, nail this issue.

It's also worth noting that the work around allowing 3rd party code to be whitelisted and included as part of install profiles are providing a way around this complexity: #779452: Whitelist for external dependencies

In this specific case, the code in Backup and Migrate is being used in accordance with the original author's wishes. The code is licensed under a GPL-compatible license. The code used is pretty small, and it has not been changed in any way.

Moreover, the version included with Backup/Migrate *works*. Additionally, the code is not under rapid devlopment; the most recent release is July, 2009, so the argument that this is even approaching a fork doesn't hold here.

+1 for closing this issue as a non-issue. The inclusion of this code in CVS feels in line with what the guidelines are, and in this case, no one is trying to circumvent/subvert the intent of the GPL.

If there is not consensus to just leave this be, I suggest that someone contact the original author and see if he would be open to dual licensing for this specific case.

kiamlaluno and I were cross-posting

RE:

What would happen if two modules use the same library, but different versions? If both the modules load the library for the same page, there will be surely a conflict.

This happens all the time - a few modules use the getid(3) library, swfobject2, etc. It's one of the problems that the libraries API was intended to solve, and one of the things pushing people to standardize around using sites/all/libraries

But this really gets sorted out by site buiders, on a site by site basis. This is not a problem that can be solved by d.o cvs policies.

In this case, we have code with a GPL compatible license, being used within the terms of the original author.

No harm, no foul.

There is nothing to discuss here. Drupal.org repositories only host code released on a "GPL 2 or later" license, as clearly stated in our Usage Policy:

All files checked into the repository (code and assets) must be licensed under GNU/GPL Version 2 or later.

It is even clarified in the FAQ that our repositories do not host any "GPL-compatible code".

This file is not released under the "GPL 2 or later" license, it needs to be immediately removed from our repositories.

As soon as we will have migrated to Git, it will become easier to reference external code, which will make the whole "it's easier for my users" argument moot. But note that the "Don't mix licenses" policy will probably stay in place.

It's gone now.

Marking as fixed as per #15

The file is still present in the MAIN branch: http://drupalcode.org/viewvc/drupal/contributions/modules/backup_migrate....

I have removed the file (http://drupal.org/cvs?commit=472884).

I forgot to change status.