- 🇺🇸United States Kristen Pol Santa Cruz, CA, USA
Noticed today that the LICENSE.txt is in the project tarball, but not there when I to a git clone. I mentioned in the #drupalorg Slack channel and hestenet acknowledged the problem and this issue was pointed out by drumm.
Adapted from drumm's comment:
- We don’t want a lot of trivial issues adding LICENSE.txt to every project.
- There should be some CI to let maintainers know & correct it themselves.
IMO it would be great if this was added automatically somehow since otherwise everyone is doing duplicate work and may add the wrong info.
Sidenote and nitpick, should this be changed to LICENSE.md?
- 🇺🇸United States cmlara
There should be some CI to let maintainers know & correct it themselves.
See #3419509: Check license.txt files for GPL 2 or 3 →
As for an automated commit of a license file, considering the D.A. knows, or reasonably could be expected to know, that there are projects with a license other than GPLv2+ committed into G.D.O. an automated commit would likely pose serious legal concerns.
- 🇺🇸United States Kristen Pol Santa Cruz, CA, USA
I thought the Drupal license required all Drupal projects to adopt the same license.
- 🇺🇸United States cmlara
I thought the Drupal license required all Drupal projects to adopt the same license.
My understanding is that the D.O. Git policy requires users to agree to commit GPlv2 code. The agreement is not a copyright assignment. Failure to do so is a violation of D.O. policy which action may be taken (such as banning commit access in the future and removing the code from the repository) by D.O or the D.A. in response to violation.
Even if the D.O. Git User Agreement is sufficient to be considered an assignment of GPLv2 license to all code submitted, a single user can not release copyright for code by other copyright holders. Again the D.O./D.A. options are to asses a punishment on the committer and to consider deciding to cease distribution of the code.
Regarding “linking to Drupal” D7 had some significant ability to argue that all code was “linked” to Drupal as there was no separation. However the use of dependency injection in D8 and the Google LLC vs Oracle court ruling appear to make the validity of that murky with modern Drupal code and the line for what is linking has not to my knowledge been tested in courts.
IIRC the GPL’s linking position exempts libraries that are already commonly found, that has often been treated as simple as “distribute by another channel” (think composer and requiring other libraries). Additionally this can be complicated by the fact in many cases it is actually the GPLv2+ application (core) calling the non GPLv2 app (aka core/the user installing the module
may actually be violating the linking clause not the 3rd party module).Even if the Core license becomes applicable to contribute code via the linking clause a user could write a GPLv3 module and be compliant with the GPLv2+ core license while not being compliant with the G.D.O. policy, placing a GPLv2 license file would breach the license of the copyright holder and may not be protected by DMCA safe-haven protection. This gets more complicated when we start discussing licenses that are not variants of the GPLv2.
Additionally the current policy IIRC allows for GPLv2 and GPLv2+, the D.A. Would need to be absolutely sure they commit the correct text for each project.
Note: I am not an attorney, always consult a licensed attorney specializing in copyright law before changing the license of a project. The suggested phrase I would use for this discussion would be “unilateral change of source code from a license other than GPLv2(+) to GPLv2(+) without consent of all copyright holders by a non-copyright holder”.