In our support roles in the Project Application Issue Queue, we often have to bat things back, saying "No, you can't just copy&paste in a thing you found on github".

But to provide support for the proper way of doing things, that often means sending developers to the instructions for using Libraries API correctly and writing instructions for manual download steps for the end-user.
Understandably, adding manual steps for the end-user is seen as slowing adoption, and unneccessarily annoying.

If we are really over-delivering, I also provide (D7 anyway) hints on how to use drush make files to smooth out the downloads and installs, and HOOK_requirements() to check the downloads. Drush make files in contrib modules make distributions and simplytest.me so happy.

But to get to my point:
In the brave new Composer-driven world - it seems that modules, distributions, and even themes are now able to declare downloadable requirements in their composer.json.

This has its own licensing issues #2816757: Impact of Using Composer to Build D8 Distributions - primarily the summary that (if I read it correctly)

It's totally OK for a Drupal.org-hosted project to list a third-party library (of various licenses) as a requirement in its composer.json - the end-user is free to download those independently and now, somewhat automatically.
(This does introduce a potential conflict for distributions that provide tarballs, as they would then be redistributing the code with conflicting licenses, unless whitelisted)

But aside from the tarball question...

I'm posting in the LWG queue here because I think it's our role to help do things right, not just tell people they are doing things wrong.
I'm posting in LWG initially, because the licensing restriction is one of the most obvious reasons that people are required to be doing their own separate downloads instead of just pasting stuff in.
So, what is the right advice to give?

My question is:

Is it appropriate to now advise D8 module developers to leverage their composer.json requirements to get around code redistribution issues?

- as I just did in #2360445: Git policy violation

Are we able to provide a useful clarification or doc page that endorses this practice?

The existing instruction about Defining dependencies in composer.json makes no mention of licensing there yet. I would like to say "and this is the recommended way of dealing with 3rd party licensing conflicts" - if that's true!
Using Composer to manage Drupal site dependencies discusses the new way to declare drupal.org module (only) dependencies, but makes no comment on using composer normally to fetch non d.o stuff.

Are their gotchas or implications to doing this more widely?

What sort of changes or compromises may a developer encounter if switching from make, libraries API, the older composer-manager project, or other workflows to this method?
Does using per-module composer.json dependencies now change what users expect to get in a downloaded stand-alone tarball? Trying to think this part through confuses me.

Can we (pretty please) use this on javascript libraries?

I've been able to have much joy in a drupal-project style composer-based build and downloading javascripts in a way similar to Example composer.json file for File Browser. I'm aware of the official composer distain for using Composer in this way, but dammit, it works! and is endorsed by composer-installer...

    "extra": {
        "installer-paths": {
            "libraries/{$name}": [
                "type:drupal-library"
            ],

What I'm seeing is that this method (or one much like it) could give us the carrot to let all the third-party-wrapper-module developers do things right, instead of just slapping them back with a delete that code now sort of complaint.

So lets help everyone by defining what "the right way" is!

Related: #2605130: Best practices for handling external libraries in Drupal 8/9/10 and 11 - is mostly about where libraries get put - there's not much there on the download and install steps, though @crell and others have started thinking about that also.

Comments

dman created an issue. See original summary.

kreynen’s picture

kreynen commented
Related issues: +#2715441: Support for distributions
gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Issue summary: View changes

Thanks for starting this important discussion.

Crell (member of he LWG), was a very early Composer evangelist. He also knows a lot about how to correctly leverage Composer for external downloads. I hope he can find the time to answer some of your questions.

Crell’s picture

Crell commented

Hey look, I've been called out... :-)

First, yes, IMO in 2016/2017 the Right Way(tm) to manage 3rd party PHP dependencies is via Composer. If you have a 3rd party PHP library you need that isn't available via Composer, submit a PR to them to add a composer.json file and then bug them to register on Packagist. Then, use the Drupal Composer project. With the alternate repository endpoint being hosted by the Drupal Association I'd consider it sufficiently-official now to recommend it for just about everyone.

Clarifying that as the preferred way to use Drupal is something I would encourage, but it out of scope for the LWG.

As to licensing...

Given limited resources, there's not a ton we can do. However, if wishes were horses I'd recommend the following:

1) Add a section to the Composer documentation page that warns people about potential licensing issues. Viz, if they download a 3rd party lib via Composer then it *may not be GPLv2*, and they are responsible for ensuring that the resulting application is a permissible result. It should also provide guidance on what various implications are. Off the cuff I'd offer the following text for consideration:

Be aware that while Drupal and all Drupal modules are released under the GNU GPL version 2-and-later, libraries downloaded via Composer may not be. You are responsible for ensuring the compatibility of the licenses of software you use, as we cannot control what software you download. As a guideline:

1) Libraries under the MIT or BSD license, the GPLv2-and-later (listed as "GPLv2+" in composer.json), or LGPLv2-and-later (LGPLv2 or LGPLv2+), or LGPLv3+ are safe to use unconditionally.
3) Libraries under the GNU GPLv2-only license are safe to use, however the resulting site/application may only be distributed under GPLv2, not GPLv3.
3) Libraries under the GNU GPLv3 are safe to use, however the resulting site/application may only be distributed under GPLv3, not GPLv2.
4) Libraries under the Apache2 license may be used, however, the resulting site/application may only be distributed under GPLv3, not GPLv2.
5) A library that does not explicitly specify a license is unlicensed and it is illegal for you to use in any form. Many library authors forget to explicitly specify a license when they release code. If you come across such a library, please contact the author and ask them to add one of the GPLv2+-compatible licenses above (GPLv2+, LGPLv2+, MIT, and BSD).
6) Treat all other licenses as though they are not allowed to be combined with Drupal or GPLed code until proven otherwise.

If you come across a module that has a Composer-dependency on a PHP library that does not use one of the above licenses, please file an issue with the Licensing Working Group.

2) It would be lovely to write a parser that can scan uploaded modules for composer.json files and, if it finds one whose dependencies are not one of the above, flags it for us. It shouldn't block the Git push but should warn the user in some fashion. We've discussed this before but the resources to do so on Drupal.org have been unavailable.

3) We've also discussed adding a "license check" command to Composer (which would help with point 2). It would look through a composer.lock file, index all the various licenses in use, and ideally flag any incompatibilities and/or note the resulting license for the whole application. I don't think Jordi (the Composer maintainer) is against it, but someone needs to write it. (Volunteers welcome.)

I cannot speak to Javascript libraries, as that package management ecosystem is less well-developed and doesn't tie into Composer nicely.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

The only thing the GPL covers is *distribution, copying, modifying* it is a copyright license, not a EULA.

The end user can always *use* any combination of licenses they want. The GPL does not cover *use*. You are free to run whatever you want. The resulting application will *always* be a permissable result, unless you are combining with other software that is covered by a EULA that explicitly prevents that.

Notions like

A library that does not explicitly specify a license is unlicensed and it is illegal for you to use in any form.

are not a valid interpretation of the GPL, unless you are *expliticly* calling out "use" as "distributing". edit: you have be given *some* sort of license to use code. Otherwise you have no rights to use it.

So the only scenario the end user needs to be concerned with is if they intend to create a derivative work and *redistribute* that derivative work. I can think of two scenarios where that might apply:

  1. A drupal.org user wants to build a complete product with drupal as a component and also bundle it with non gpl assets (say, a media management center or something).
  2. A drupal.org user is building a drupal site for a client

The first scenario isnt one I think we should put any resources or effort into enabling or supporting. If you wish to create a drupal derived product, it is up to you to ensure the legality of that.

The second scenario is *very* ambiguous as to whether or not that constitutes distribution. If you are under a contract with a client, then you can be considered to be the same entity or that you are working on *their* software, or it could be that the final product when 'handed over' is an act of distribution. I guarantee you can find a lawyer that will interpret it either way, and since it has never been tested in court, there is currently no exactly right answer to this.

Crell’s picture

Crell commented

Mixologic: The comment about a library with no license has nothing to do with the GPL. It has to do with copyright law. Copyright law is grotesquely stupid at this point, especially in the US, but such is life. It is illegal to make a copy by download of code you don't own unless you have a license to do so. The odds of a random person on GitHub actually enforcing that are low, but it is the legal reality.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

Ah sorry. I've seen the "cant use incompatible software" myth so many times that I missed the fact that unless you're given *some* sort of license, then you don't have any rights whatsoever.

You are absolutely right about unlicensed works and I stand simultaneously corrected and enlightened.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented

The comment about a library with no license has nothing to do with the GPL. It has to do with copyright law. Copyright law is grotesquely stupid at this point, especially in the US

In this case, USA is not to blame. This particular feature of copyright law (i.e. protection of author's right by default) follows from the Berne Convention of 1886. The USA wanted nothing of this for 102 years, but finally accepted this principle when it joined the Berne Union in 1988.

Actually, in the USA, if you don't publish with a clear copyright notice and a "All rights reserved" declaration, you only reserve your moral rights, not your economic rights. In Europe, economic rights are also reserved by default.

(This is of course irrelevant for the discussion at hand, but the USA is blamed for so many things that I wanted to clear up that this particular quirk of copyright law came out of Europe.)

greg.1.anderson’s picture

greg.1.anderson commented

When Composer to manage a Drupal site, you can easily determine which licenses are in use by running the composer licenses command.

The thing to look for, besides obviously proprietary licenses is Apache-2.0, which is incompatible with the GPL-2.0. If you find one of these, you can find out why it is included by using composer why.

As mentioned above, this is only an issue when distributing software.

Edit: Per https://www.drupal.org/node/2702125, the user can choose GPL 2 or GPL 3 when using Drupal, ergo Apache-2.0 is not an issue. I hadn't considered that.

Crell’s picture

Crell commented

It's more accurate to say it *may* not be an issue. If one module depends on a GPLv2-only library, and another depends on an Apache2 library, then you cannot build a distribution that uses both modules even though all of the Drupal code is GPLv2+. That's the sort of area where we cannot do much beyond education and some tools to help people discover such issues should they occur.

kreynen’s picture

kreynen commented

you can easily determine which licenses are in use

You can easily discover which licenses someone added to the composer.json file. This alone does not determine which licenses are used or their compatibility.

Something I find myself repeatedly pointing out is that SPDX has deprecated GPL-2.0+ in favor of using the License Expression Syntax to declare "GPL-2.0 AND GPL-3.0" or "GPL-2.0 OR GPL-3.0".

It is unlikely that any composer based tools developed to help sort out license compatibility issues are going to understand GPL-2.0+.

There are also issues related to how the package is used. While the Packagist tagline is "The PHP Package Repository" and Drupal's policies on PHP licensing is well established, you'll find a lot more than PHP in Packagist and Drupal's policies about non-code assets have never been completely clear. Legally, assets like https://packagist.org/packages/components/font-awesome don't require a GPL-2.0 compatible license to be distributed with Drupal because it is a non-code asset. https://github.com/components/font-awesome/blob/master/composer.json list both MIT and OFL-1.1, but if you dig into http://fontawesome.io/license/ you see that the MIT only applies to the code, not the font itself. The "MIT AND OFL-1.1" combination is actually easier to deal with than an "Apache-2.0 AND OFL-1.1" or "GPL-3.0 AND OFL-1.1".

While Composer and SPDX provide an improved structure that makes licensing discovery easier, it does not make it possible to completely automate compatibility checks.

While the GPL continues to hold up to legal challenges like the recent Artifex v. Hancom District Court decision, the Drupal project's licensing policies are not what people who've been working off the island are expecting or what the rest of the PHP community is doing.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Status: Active » Needs review

I have added a note about Including 3rd party libraries to the community documentation. Feel free to review it, and to comment in this issue, or expand and correct it in place.

It not only covers composer.json, but also including 3rd party libraruies using CDN and the Libraries API project.

It says in the issue summary:

The existing instruction about Defining dependencies in composer.json makes no mention of licensing there yet. I would like to say "and this is the recommended way of dealing with 3rd party licensing conflicts" - if that's true!

Yes, I think that we can say that this is true now.

If nobody objects to this documentation page in two weeks, I expect to close this issue as fixed.

I've not included the writeup from comment #4 above: 1) The LWG haven't really sorted out the GPLv3 problems yet - so far we're only prepared to allow permissive (aka "GPL-friendly") licenses. 2) This is advice about what you are allowed to distribute, not what you can use.

gisle’s picture

gisle
he/him
Primary language Norwegian Bokmål
Location Norway
commented
Assigned: Unassigned » gisle
Category: Support request » Task
Status: Needs review » Fixed

Two years has gone by without any more discussion. I think we can close this now. Moving to "Fixed". Anyone objecting have two weeks to reopen before is is automatically closed.

Note that in addition to guidance provided in https://www.drupal.org/node/2947530 there is also https://www.drupal.org/docs/develop/packaging-a-distribution/drupalorg-d...

Status: Fixed » Closed (fixed)

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