Drupal policy is that hosting 3rd-party libraries on d.o. is usually a no-no, and that hosting non-GPLv2-or-later code is definitely a no-no.

Libraries API appears to be the consensus solution for managing 3rd-party libraries.

Comments

mbutcher’s picture

mbutcher commented

The README explains this. The version of QueryPath that I included is GPL'd. As I am the author of the module and the QueryPath library, I am "allowed" to distribute it this way (technically, the fact that QP is MIT means *anyone* can distribute it this way). This has been verified several Drupal.org and association members when QP was first released a few years ago.

Now, should there be a *pragmatic* argument for using the Libraries API, I'd be willing to consider it. But "Yet Another License Disagreement" is not a good reason to make the module that much harder to download, install, and use.

The point of including the library is simple: Make it as easy as possible to use QueryPath inside of Drupal.

Matthew Davidson’s picture

Matthew Davidson commented

The README doesn't actually mention that you've been granted an exception to the 3rd-party library policy by the d.o. webmasters (if I understand correctly on the grounds that you are the original author, not that anyone can legally relicense more permissively-licensed code under the GPL, which is not generally enough to get an exception, and can be trickier to do correctly than most people realise). Adding that to the README will prevent someone re-raising this issue every year or two.

The README also says "Right now, you also need to manually fetch and install the QueryPath
library from http://querypath.org", which suggests to the reader that the library might even have been accidentally committed at some stage.

Excellent work, by the way.

mbutcher’s picture

mbutcher commented

Are there any pragmatic arguments for using some external library management system? Or are you suggesting now that changing the wording of the README is, in your opinion, sufficient to cover your initial complaint.

Matthew Davidson’s picture

Matthew Davidson commented

The README changes are enough to deal with my concerns.

If it's likely that a significant number of people want to use a different version of the library than that bundled in the module (a possibility mentioned in the README), or you think dependent modules might end up insisting on different and incompatible versions of the library, I think Libraries API might be worth investigating just to save you reinventing the wheel in dealing with these issues. But that opinion's just based on the fact that it's what most of the high-profile modules that depend on 3rd-party libraries (eg. WYSIWYG) use, rather than any deep technical knowledge. It could well be overkill in this case; I have no personal preference.

JamesAn’s picture

JamesAn commented

Normally, I'd also strongly side with using the Libraries API to better standardize how third-party or external libraries are handled by Drupal. The main reasons seem to be enumerated in this post.

Since you're the owner of both this module and the QueryPath library, all the technical reasons seem moot (e.g. licensing issues, coupling this module's release with the release cycle of QueryPath, worrying about multiple installations of the library).

Using Libraries API to manage the QueryPath library in Drupal may make this module obsolete though, as the functions this module fills (e.g. checking the existence of QueryPath, its version, and inclusion in the rendering process) would mostly be done through the Libraries API. Modules that currently depend on this module can check for QueryPath by making calls to the Libraries API.

Aside from the "elegance" of congregating all external libraries together, there doesn't seem to be any actual benefit in refactoring to use Libraries API, not to mention taking a hit in ease of use since administrators would then need to fetch QueryPath on their own (or use drush-make).

JamesAn’s picture

JamesAn commented
Issue summary: View changes

d.o. doesn't use Markdown. Duh.