License in LICENSE.txt is unclear

Generally, the licence file describes a single licence, and it doesn't make any reference to licence versions coming after.

The license file is automatically created by the code that creates the tarball archive; to know if the license is only GPL 2, or GPL 2 and later, you should look at what Drupal.org policies state.

For what I remember, Drupal.org talks of GPL 2 licensed code.

We could open an issue in the Drupal.org queue.
Effectively, it would be better to have the two files on the same place; the only reason to keep them separated could be because the license conditions are the same for all modules, and for Drupal core modules.

Anyway, it's not something the single modules/themes can control, as those files are controlled by the packing system.

Fixing title slightly. Also moving to a bug report.

We distribute the GPLv2 copy of LICENSE.txt from gnu.org. But there is nothing either in that file or anywhere else in the package that indicates the information in the licensing FAQ (that it is indeed GPLv2 *or later*). And since we're not using copyright headers in our files like we really ought to be, this information is really really hidden for people actively looking for it.

Maybe an auto-generated COPYRIGHT.txt as part of the packaging script which mentions the "Full name" of each of the people listed on the CVS access tab, that also links off to the licensing faq for more info, so we don't have to "hack" LICENSE.txt?

Let's get Larry and SFLC in on this.

Kieran

sure - why don't you roll a patch for project module to add license information to every .info file as a comment?

The LICENSE.txt file automatically packaged with contrib is also *not* the same file that's included with core. That seems weird. Furthermore, the copy of LICENSE.txt that the packaging script uses is a checkout from contributions/LICENSE.txt, but that file has been massacred in CVS by various folks screwing things up in the root of the contributions repository (which sadly, is outside the realm of our repository access control). Luckily, it's just a stale checkout used by the packaging script, not something we checkout fresh each time, so we're still using the same file, but this is pretty yucky. FYI, I put a copy of the exact file used by the packaging script here for comparison:

http://drupal.org/files/LICENSE.txt

I'd really like someone from the DA or otherwise an authority on such matters (e.g. Crell) to comment on The Right Thing(tm) to do here. Whatever we decide, it'll be easy to implement in package-release-nodes.php, and I'm happy to do it. I'm just not personally in a position to make an authoritative decision on these sorts of legal issues. An auto-generated COPYRIGHT.txt would be easy/fine, if that would help -- but, I think the main issue is LICENSE.txt, not copyright.

Could we use the file that is used by the Core repo instead?

ianal, but I think there really is no meaningful license in the absence of a copyright.

Core is now shipping with a very minimal copyright.txt file.

I think it would make sense to autogenerate such a file for any project that does not have one in cvs itself.

Google for "Berne convention".

@killes #13: Gladly, though which branch of core? Should we just always package contrib with whatever core's HEAD copy of LICENSE.txt says at the time? Match the LICENSE.txt for the corresponding branch of core that the contrib is for (e.g. for 6.x releases of contrib, grab core's DRUPAL-6 LICENSE.txt)? Either way is easy, I just need to know what to do.

@pwolanin #14: We could easily include core HEAD's copy of COPYRIGHT.txt in all released packages that don't have such a file themselves. It'd be more DB intensive, but we could also query for all users that committed to a project and include them (although that would pull in translators which IMHO shouldn't be explicitly listed in the COPYRIGHT.txt for the module itself). We could grab the folks that currently have CVS access, but that's misleading in the case of modules that were written by someone and adopted by others, or a co-maintainer that came and went, etc.

I suggest we mandate that each module has a COPYRIGHT.txt file, and refuse to package if it hasn't.

@killes - yes a copyright is automatic, but may not be enforceable without a copyright notice.

@dww - autogenerating the list of committers sounds appealing, but we should consider any edge cases (e.g. I commit a patch on behalf of the security team). Matching the license txt to the corresponding core branch or just pulling from cvs HEAD would both be fine for now, I think.

This comment is (c) 2009 by pwolanin

I'll happily provide a file that says that it is intentionally left empty....

It is not neccessary to provide a copyright.txt file. Copyright exists without such files.

killes@Kaktus:~$ locate copyright.txt
killes@Kaktus:~$ locate COPYRIGHT.TXT

nothing.

I have 2047 Open Source packages installed and none have such a file.

@killes -

Joomla! calls it COPYRIGHT.php

Drupal HEAD has COPYRIGHT.txt file

The ASF Solr project has a NOTICE.txt file

The ASF httpd project has a NOTICE file

Xapian has an AUTHORS file.

etc.

- I think preventing packaging without a COPYRIGHT.txt is a terrible idea.

- I'm not convinced we need a COPYRIGHT.txt file at all, but IANAL.

- Most source code I know of includes the copyright as a comment at the top of each file. I'd like us to avoid that if at all possible.

- I agree that auto-generating a list of "authors" is problematic, as I tried to point out in #16.

- I think core's COPYRIGHT.txt is probably sufficient instead of an explicit list of names:

All Drupal code is Copyright 2001 - 2008 by the original authors.

- #550770: COPYRIGHT.txt still thinks it's 2008 for interested parties. ;)

@pwolanin

Indeed, apparently each of my Debioan packages has a file named "copyright".

However, these files seem to contain only the original licenses of the programm packaged + the names of the packagers.

Especially the latter I find doubtful, but is of no concern here.

I think I agree with dww: there is nothing to be done here besides making sure that the LICENSE.txt file comes from a source that cannot be modified by people who shouldn't do that.

Tagging and subscribing, will try to weigh in tomorrow.

Does this still need to be addressed?

Closing old issues. Please re-open if needed.