Hallo Markus, Am Saturday, den 20.09.2014, 13:02 +0200 schrieb Markus Koschany: > On 20.09.2014 09:57, Tobias Frost wrote: [...] > I still don't see why the current copyright file does not meet Debian's > quality requirements. Instead of one huge 900 MB -data package, the game > data was simply split into three different source packages. This makes > it much easier to fix bugs without having to upload all data files every > time. The split is not under dispute. Other packages do that too, for example redeclipse. But redeclipse do it "right" (in my view) and their generate-copyright-script which is aware of the package it acts on. (Your script can be enhanced to do that too. Probably less time effort that I spent already on this topic.) > I would like to stress: The source packages are not independent of each > other, they belong together. It is due to mere technical reasons that > the -data was split. In my opinion we are in full compliance with > Debian's Policy because teamviewer --daemon start > > - we state in d/copyright that the game data was split due to technical > reasons > - we use a reproducible and convenient way to determine all copyright > information. > - the copyright file is machine-readable and every file in each source > package is covered by an license paragraph in debian/copyright. > > Thus the whole copyright file is accurate. I disagree. Having 6362* entries in d/copyright which does not match any file is NOT accurate. To be very clear: I will NOT sign such a package with my PGP key. (*6392 is the number of lintian wildcard-matches-nothing-in-dep5-copyright messages, already music/ and sound/ subtracted) Due to the split I say "we now have 4 related, but independent source packages and they should be handled as such". The Relation is no guarantee that the packages will not diverge in the future. (e.g code could go forward, while data keeps the same, or vice verse) > > [...] > > Admitting, upstream is exemplary in case of tracking of its licenses > > (also with the scope for Debian!), and it really helps to automate this > > to get a skeleton dep5 file. > > Indeed. UFO:AI is an exemplary and excellent free software game and its > developers care a lot about tracking licenses. > > > However -- as with the output of licensecheck of the devscripts -- the > > output needs to be checked and compared to *every* files in the source. > > Right. This is already achieved. Which license information are incorrect? > > > The LICENSE file may (and have) also errors: For example there are files > > in this files with no copyright holder attributed. Or, there are URLs > > attributed as copyright owners. How does the script handle this? In the > > end this leads to wrongly attributed files that will either go unnoticed > > (so Debian is violating copyright law) or lead to an FTP Master reject. > > First of all the whole game is licensed under GPL-2+ and is copyright > The UFO:AI team. In addition the LICENSES file contains all information > about individual game data licenses that diverge from this general > assumption. > > One line in LICENSES looks like that: > > filename | license | author | source > > base/maps/africa/af_empty6a.map | GNU General Public License 2.0 or > later | Holger 'ShipIt' Gellrich | base/maps/africa/af_empty6.map > > The script splits all fields by the | delimiter and maps all filenames > to their corresponding licenses and copyright holders. If there is no > one mentioned under author one may assume that this is always a work by > the UFO:AI team. > > > > > To make it clear: I require an 100% accurate d/copyright and this is one > > of the few points that are not subject to negotiations. > > Absolutely. Could you elaborate on where a file is not accurately > addressed by copyright format 1.0? Who's the copyright owner of those? base/models/objects/vegi/palm_v1/palm1.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v1/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm1.md2 | Cr.g teative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 (if emtpy means upstream, UFO:AI Team is not in the list for that license and its not GPL-2+. Either way, d/copyright is wrong here.) contrib/7th.zip | | 2002 Iconian Fonts - Daniel Zadorozny - http://www.iconian.com/ contrib/scripts/compile_po.bat | | Kostia "Kildor" Romanov contrib/scripts/update_potfiles_in.bat | | Kostia "Kildor" Romanov no such files -- LICENSE has "too many files" radiant/bitmaps/texwindow_uniformsize.png | | orbweaver (commiter in darkradiant repository) | tobi@edoras:~/workspace/deb/mentors/ufoai/uf(no invariant)oai-2.5$ ls -la radiant/bitmaps/texwindow_uniformsize.png -rw-r--r-- 1 tobi tobi 101 Nov 2 2012 radiant/bitmaps/texwindow_uniformsize.png tobi@edoras:~/workspace/deb/mentors/ufoai/ufoai-2.5$ grep radiant/bitmaps/texwindow_uniformsize.png debian/copyright tobi@edoras:~/workspace/deb/mentors/ufoai/ufoai-2.5$ base/textures/tex_pics/art_africa008.png | Creative Commons Attribution-Share Alike 3.0 | Udit Kulshrestha | http://commons.wikimedia.org/wiki/File:Ole_Man.jpg Wikimedia says "Creative Commons Attribution-Share Alike 3.0 Unported" base/textures/tex_buildings/carpet024.png | GNU General Public License 2.0 or later | MCR | http://commons.wikimedia.org/wiki/File:42556-Antique-Persian-Tabriz-Carpets-hires.jpg Wikimedia says GNU Free Documentation Licidenticalense, Version 1.2 (no invariant) or any later version or CC-BY-SA-30 and author is Nazmiyal (Those were random picks out of the http-ones; to avoid the imopression that everytghing is wrong: Its not, there are correct ones, which I did not quote.) > [...] > >> I believe we shouldn't make the process of creating debian/copyright > >> even more painful and I think that a reference to > >> /usr/share/common-licenses is more than enough for the most widely used > >> free software license. > > > > I disagree. As said above, d/copyright is important. Yes, it is tedious > > to create it the first time and there are more exciting things to do, > > but it is a necessity to be done and to do it right. > > Absolutely agreed. But can you point me to examples where the short > reference to /usr/share/common-licenses was deemed not appropriate by > the FTP team? > > > The policy means you should not quote the verbatim license, but it is > > common practice to quoidenticalte the first 3 paragraphs. > > No, that's not true. A lot of maintainers write standalone paragraphs > for common licenses exactly as I do. > > > Otherwise we'll introduce fuzziness. > Consider License GPL-2+ > > You refer to the GPL-2 file, which makes it non-obvious that you have > > the "or later" option in place. For the causal user, its not > > self-explaining what the "+" means. > > Copyright format 1.0 clearly defines short names and keywords. GPL-2 and > GPL-2+ are well defined and unambiguous. > > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > > It is common practice and knowledge that GPL-2 refers to the GNU General > Public license 2 and GPL-2+ refers to the same license but includes the > "or later" clause. > > > Please add the few lines, I consider it not enough to just have the > > reference. > > Ok, that's fine. I completely understand that it is your prerogative as > a developer to determine what you consider suitable for an upload. > However I have touched more than 100 source packages already and I am > sure that this is not what Policy demands and merely an arbitrary > requirement. Even the rules for copyright format 1.0 state for the > License field: > > "Otherwise, this field should either include the full text of the > license(s) or include a pointer to the license file under > /usr/share/common-licenses." > > A pointer is really enough. Already stated: Not for me. BTW, the format 1.0 site has fine examples which all of them include the paragraphs. > [...] > >> d/watch just checks for new releases. It is far more convenient to work > >> with the upstream Git repository hence I have created get-orig-source > >> targets in src:ufoai. > > , that won't be a show stopper. > > As said in the beginning, I disagree. Each package needs to induvidually > > fulfill the quality requirments. > > > > If the watchfile does not retrieve the source, you need to have a > > get-orig-source in d/rules and document who to get source for that > > package in README.Source. > > But there is a README.source file in ufoai-music and it points to > src:ufoai where you can find all get-orig-source targets to retrieve the > original sources? Why is this not sufficient? > > > You can recommend there to go ufoai and > > execute get-orig-source there to avoid double downloads, but I expect > > that this will be possible also without downloading another source > > package. > > Sure I could duplicate the same code for every source package but what > would we gain? Quality? Reduction of maintenance work? Come on... Above you say keeping 4 duplicated copyright files in sync is fine and now you say you cannot handle to keep 4 identical get-orig-targets snippets in sync? (The snippets could use, for example, use the upstream version from d/changelog to get the right commmit -- using the upstream tag and not the git commit id, then everything is wonderful and likely never needs a change. I see all of the 4 source packages as related, but independent entities. > > (BTW, As you are repacking, so you should add the suffix +repack to the > > upstream version; this makes clear that you won't find the tarball > > upstream) > > Yes, but strictly spoken we don't repack the sources. We just use the > Git repository directly. > Therefore I think +repack would be misleading. Ok, lets leave that without +repack. (I still think people will have the expectation without it that they will be able to find the orig.tar somewhere on the net "as is", especially as there is no README.Source (but there will be one at the point of upload, I guess.) -- tobi
Attachment:
signature.asc
Description: This is a digitally signed message part