Follow-up Comment #2, task #14997 (project administration): Hello Ineiev!
> I've noticed some inconsistencies in your tarball, I'd love to resolve them > before your package is registered on Savannah. Ah, sorry! Sure. A first question: As you probably have seen, GNU Mes has a git repository at http://gitlab.com/janneke/mes This is probably something for after this review, just to mention I would like to import that to Savannah and remove the copy at gitlab. > These files lack copyright and license notices: > .dir-locals.el > tests/read.test > README > install.sh > HACKING > INSTALL > AUTHORS > scaffold/tests/91-goto-array.c > build_aux/export.make > build-aux/setup-mes.sh Okay, I have added headres to these... > (please check other copyrightable files as well, including images). ...and I also added headers to 82-define.c 90-goto-var.c I got 90-goto-var.c and 91-goto-array.c from rain1 on #bootstrappable freenode irc as an example of their requirements, I could do with them whatever I wished. I relicensed them as GPLV3+, if that's not OK I can remove them. > lib/alloca.c This one is interesting; alloca.c was taken from binutils-2.10.1, and I made modifications. So, I added my (C) there with a notice /* alloca.c -- allocate automatically reclaimed memory (Mostly) portable public-domain implementation -- D A Gwyn Taken from GNU binutils 2.10.1. Minor changes Copyright © 2018 Jan (janneke) Nieuwenhuizen <jann...@gnu.org> I realise that `public-domain' may not be good enough? binutils' ChangeLog first mention of alloca.c says Thu Jun 25 04:43:22 1992 John Gilmore (gnu at cygnus.com) * alloca.c: Incorporate fixes from gdb/alloca.c. FIXME: Eventually move gdb's alloca configuration files here, and remove gdb/alloca.c and its Makefile.in support. My changelog says that I added this file because I needed it to bootstrap gcc-3.4. However, we now bootstrap gcc-2.95.3 and then move on to gcc-4.7.4. So, if it's really problematic I could try to find out if we can drop it. WDYT? > module/mes/psyntax.pp This is a generated file as it was generated by a patched Guile-1.8. Guile also distributed it this way, I think that should be OK? > module/srfi/srfi-16.scm says it's LGPLv2.1+, however, no > LGPL text comes with it; I suggest that you either add the text > of that license or relicense those files under the GPLv3+. Ah, that's because it was taken from Guile-1.8; relicenced. I did the same for srfi-1.scm srfi-16.scm srfi-26.scm getopt-long.scm > Somewhat worse with module/sxml/xpath.scm, module/mes/pmatch.scm: > they are LGPLv3+. The difference is: LGPLv2 permits relicensing > under GPLv2+; the LGPLv3 only permits relicensing under the GPLv3; FSF lawyers > said me the LGPLv4 and later probably will permit relicensing under the > corresponding version of the GPL, > but technically one can't tell for sure. Ouch, that's unfortunate and unexpected! These also were taken from GNU Guile...and Guile uses these to run Nyacc and we need them as well. I'm not sure what to do? Would it be an idea to ask the Guile developers? > The same with module/mes/peg/{cache,using-parses}.scm and some other files, > but they are copyrighted by the FSF, so relicensing to future versions of GPL > is likely to be manual, but not problematic (of course, if you don't add > modifications by other copyright holders). I have removed PEG which postpones this part of the problem. Changes are up on the wip-gnu branch at: http://gitlab.com/janneke/mes a preliminary tarball: http://lilypond.org/janneke/mes-0.17-rc.tar.gz Thanks! Greetings, janneke _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/task/?14997> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/