GNOME Bugzilla – Bug 161916
automake is given the --gnu argument, causing COPYING files to be overwritten
Last modified: 2005-02-11 09:34:05 UTC
Whenever I'm doing a distcheck, my COPYING file gets overwritten, from LGPL licensed to GPL licensed. The relevant code seems to be - if [ $REQUIRED_AUTOMAKE_VERSION != 1.4 ]; then $AUTOMAKE --gnu --add-missing --force --copy || exit 1 else $AUTOMAKE --gnu --add-missing --copy || exit 1 fi Perhaps we should be using --foreign instead?
Hmmm ... you're right. Not a good idea to be doing this. We suck. :-( 'foreign' might be a bit loose, though, since it is nice to make sure that people have things like a NEWS and AUTHORS files (which are relaxed in the "foreign" setting). Removing the --force flag is another option. It looks a bit impolite to just hit the existing files with big hammers like we are doing now. I'll think about the trade-offs a bit more. I have probably forgotten something that one of these flags does just off the top of my head.
An announce should probably be sent: it's quite possible that some overwritten COPYING files were committed to CVS. That's not good (tm).
This code came from a patch by Jordi that I reviewed. From memory the change was made since you would occasionally end up with dangling symlinks after certain upgrades or when a package changed automake versions. (eg. if you upgraded a package from automake-1.4 to 1.9 and didn't clean out the source tree, it would still have scripts like "missing", "install-sh", etc from 1.4). I hadn't realised that it was overwriting the license file though ...
When was the change to gnome-common committed to CVS?
Hey guys, I wonder if the LGPL -> GPL thing can't be overriden by options in the main Makefile.am. I don't know what option would be needed in this case. I agree that changing the COPYRIGHT file so happily isn't right, but the symlinks situation wasn't right either, and we want to call all the tools in autogen with more or less the same behaviour (before, some were forcing, others didn't, and some copied and others symlinked). So, are these viable options? - use AUTOMAKE_OPTIONS wherever necessary (haven't checked if there's an option that would help, but I think there is) - ask automake upstream to either not happily overwrite COPYRIGHT files, or add an explicit switch for this. The first one requires that we fix the affected modules one by one, and the second one makes us depend on a recent automake version, which might be a problem for some maintaienrs. I had noticed this behaviour in one of my modules, but the diff didn't reveal anything scary (s/19xx/YEAR/ and silly changes like that). Of course, I could not imagine it replaced entire copyright files when they weren't stock GPL... Are many modules affected?
Bill: according to the change log, it was committed on 2004-11-09. Jordi: the second option isn't really workable unless the automake developers release fixed releases of Automake-1.6, 1.7, 1.8 and 1.9, which is not likely even if they agree that the behaviour is buggy. The most robust solution (assuming we want to keep the --force flag for automake) would be to copy the COPYING file before running automake, and then compare it with the version after running automake. If they differ, then copy back the original.
Would this mean that the wrong copying file would still be part of the disted tarball though?
No. I was trying to sketch out something like this: cp -pf COPYING COPYING.tmp automake --force --copy cmp COPYING COPYING.tmp || cp -pf COPYING.tmp COPYING rm -f COPYING.tmp This way, the COPYING file would remain intact over the autogen.sh call, and we'd still get the benefits of updating standard automake files.
*** Bug 164191 has been marked as a duplicate of this bug. ***
Any update on this? James' proposal should work ok. I suggest we commit such workaround to CVS ASAP. The problem will get worse as more people use gnome-common on non-GPL modules.
BTW, the INSTALL file also gets overwritten. That should be fixed as well.
Created attachment 37103 [details] [review] gnome-common-dont-kill-copying.patch Here's a patch that seems to work okay for me. If you have an affected module, please try it and report any successes or problems. If nothing bad happens, I'll check it in. I don't think this has too big an impact though. Pretty much every library I had a checkout of fell into one of the following two categories: - had GPL in ./COPYING and LGPL in ./COPYING.LIB - was not using the gnome-common autogen.sh script (either that, or I've missed some packages)
Created attachment 37106 [details] all /cvs/gnome/*/COPYING files that changed since 2004-11-09 I just ran a script on window.g.o to check how many packages may need to be checked. Here's a summary of modules that seem to have had large changes to their COPYING files in that time period (excluding new modules): gnome-menus -- now has COPYING and COPYING.LIB gnome-themes libical zenity
James, what about INSTALL? For people that do the right thing and put installation notes in INSTALL instead of in README, this totally ruins their work. :( gnome-common maintainer, please consider extending jamesh's patch to protect INSTALL as well.
Gustavo: that should be pretty easy to do. If there are no problems with the patch, I'll get it to handle the INSTALL file too. Now as far as the above listed modules go, here's some more info: - gnome-themes has changed from LGPL 2.1 to GPL - libical has changed from an empty COPYING file to GPL (license headers indicate that it is dual LGPL/MPL though). - zenity has changed from LGPL 2.0 to GPL (I also widened the search and checked every COPYING,v file in the repository. The only extra changes found appear to have been fixed). CC'ing affected maintainers who aren't already CC'd.
James: Thanks for the patch; this fixes the problem for libwnck.
Okay, since there hasn't been any complaints, I've checked this fix into CVS. It should preserve both the COPYING and INSTALL files. According to the following Bonsai query, it looks like evolution-data-server/libical has been fixed: http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&&file=COPYING&date=explicit&mindate=2005-02-06 As for gnome-themes, I was mistaken last time. The license history appears to be: * switched from GPL to LGPL at rev 1.3 (2003-08-15) * switched from LGPL to GPL at rev 1.4 (2004-11-29) * switched from GPL to LGPL at rev 1.5 (2005-01-24) * switched from LGPL 2.0 to LGPL 2.1 ar rev 1.6 (2005-01-24), with the following prepended: NOTE: the setuid binaries in su-backend and pam-backend are GPL. The library itself is LGPL. So gnome-themes is probably okay, but the note doesn't mean much in the context of the module (I guess it was swiped from some other package).