IDNA Convert needs LGPL class

Thanks for contacting the LWG!

The group was established recently and we are currently working on a set of new procedures and guidelines for third part code. These new guidelines will also describe how to document the presence of additional licenses (such as LGPL 2.1 in your case) in a distribution.

We are not going to review any exception requests until the new guidelines are in place, nor are we going to take any action against projects that have an exception request pending. Postponing until the new guidelines are in place.

(The new procedures and guidelines will be subject to public review by the community before implemented.)

The bureaucracy again kills developer initiative.

I am sorry you feel this way about it.

Just to make things clear: The LWG did not create the present Git Repo Policy. Our charter is to review it, try to come up with a better policy, get it approved by Dries, the Drupal Association, and the community, and finally implement it.

The present policy is that an exception is not granted for a third party library if the library is available for download elsewhere. An yes, despite this being the official policy, some exceptions that violated the policy was granted - because in the past, exceptions were in most cases granted ad-hoc through private arrangements between developers and certain prominent community members - with no audit trail and no transparency.

Drupal and the Drupal.org git repo has become too large for this form of governance to be managable, and this is why the LWG and its "bureaucracy" has been established.

Would it be a solution to use the Libraries API to handle the dependency for the class?

The rationale behind the Libraries API is explained on its project page:

We do not want to host third-party libraries on drupal.org for a multitude of reasons, starting with licensing, proceeding to different release cycles, and not necessarily ending with fatal errors due to conflicts of having the same library installed in multiple versions.

By not using the Libraries API to register its dependency on an external library, IDNA Convert is not following Drupal best practices.

Your right: Drupal best practices follows from the Drupal Git Repository Usage policy, which you have agreed to (agreeing to this is a condition for getting the permission to push to the Drupal.org Git repositotory). I quote (emphasis in the original):

DO NOT include code from a non-Drupal project in the repository. If your module requires non-Drupal code, such as a third-party JavaScript/PHP library, provide a link to where the other code can be downloaded and instructions on how to install it.

So according to best practices you're not allowed to put third party materials in your repo. Period.

So just forget about me suggesting that you registered it with Libraries API and were granted an exception to keep it in the repo. Just comply with the Drupal Git Repository Usage policy and remove the third party library from the repo.'

Since this is a PHP repo, you shall probably be able to resolve this by having a composer.json file in your repo and get it installed by composer after the user has downloaded your project.

In the issue description I provided SMTP module example which includes third-party LGPL code. Double standards?

The SMTP module is making progress in getting the third party phpMailer out of its repo, please see #2711559: Set phpMailer as a external library using composer (and update it to 6.0).

If you're aware of other projects with third party code in their repo that has not been in dialogue with the LWG about this, please let us know.

You totally missed my point and the reason why I am asking for the exception. I would like to simplify the installation process for my users and not make it more complicated.

In the issue summary, you refer to the answer to Q10, and you write:

According to the licensing FAQ we can in some special cases and as an exception include LGPL code inside projects. (my emphasis)

Unfortunately, that is not what it says in the licensing FAQ. Here is the relevant part of the answer to Q10:

If you wish to contribute a bridge module to a Drupal Git 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 a Git 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 Licensing Working Group issue queue first to discuss it. (my emphasis)

I fully understand that you want to simplify the installation process for your users. Unfortunately, that is not a valid reason for an exception to be made.

What would you suggest?

I suggest that you implement composer.json to download the library from packagist. This works for Drupal 7 as well as Drupal 8, and will simplify the task for your users as it will allow them to use composer to integrate said third party library with your module.

Can you also ask SMTP module maintainers to do the same?

FYI: They are already doing the same (see #2711559: Set phpMailer as a external library using composer (and update it to 6.0)).

To summarize, if you want your bridge project depending on a third party library hosted on Drupal. org, the following two options exists:

1. For PHP code, the preferred mechanism for adding 3rd party dependencies without directly including the code in the Drupal.org repo is referencing the package via a composer.json file.
2. Alternatively, making use of the Libraries API module for registering a third party library can be used for adding 3rd party dependencies.

If you feel that neither of these are suitable for your project, then I guess the best solution for you and your project is to move the project to GitHub.

I will move the project to Github when I have time.

That's a good plan.

Since the exception request has not been approved, I am changing the component to "Violation" and status to "Needs work".

Please set it to "Needs review" after you've moved the third party materials out of the HEAD of the 7.x-1.x branch and unpublished the releases from the project page.

To make your project findable by Drupal users, you can link to the project at GitHub from its Drupal.org project page.

You may also want to read this: https://www.drupal.org/node/2743493

Please ask questions here if there is anything in the process that is unclear.

It should not take a lot of work or time to clean out the repo and move the project to GitHub. To avoid having the project marked as unsupported/abandoned, please complete the process within two weeks from now.

please complete the process within two weeks from now

Is this official policy, I can't find anything that states that as an offical policy.

Jeff Burnz said:

Is this official policy, I can't find anything that states that as an offical policy.

The official mandate the LWG operates under is documented on the LWG project page and in the Licensing Working Group Charter.

The part that is relevant to this specific case is this:

The LWG exists to be an authoritative voice in the event of license policy disagreements. They do so by engaging in the following activities: […] Enforcing licensing policies on contributed code/assets. This includes responding to reports of license violation in a timely manner, providing ample notice to a contributor that they are in violation of the licensing policy and what the steps to resolution are, and where necessary taking action against a project in violation such as unpublishing it until the code is brought into compliance with the license.

IMHO, the resolution proposed by me in this case is in accordance with our mandate. If you disagree, please open up a new issue to discuss this.

OK, so two weeks is not an official policy. I have no idea why someone would open a new issue to discuss the issue.

That sound rude, my apologies.

@Konstatin Komelin,
thank you for taking action. I am marking this as "Fixed".