On 18.02.2017 20:37, David Rabel wrote: > Hi there, > > I uploaded a new audio-recorder package to mentors: > https://mentors.debian.net/package/audio-recorder
Awesome! Thanks. I see you pushed changes to github so I will focus my review on what's up there, assuming it is identical to what's on mentors.debian.net I've not looked at mentors. 60fd5fd4c It's a trivial fix, but if upstream has that spelling error I think it would be better to keep it. Where do you draw the line? Who knows, there might be some kind of intended meaning that you and I missed? In that part of our work, we are just documenting, not correcting IMO. 08dc66295a I'm not sure if changing "The entire Linux community" to "Team audio recorder" is sufficient. I'm not sure such an entity exists and it's basically equally opaque. If it's not specific enough to understand who to contact in case you'd like to ask for a relicensing of the code then it's not specific enough for Debian. Let's say you'd like to develop a closed-source variety of audio-recorder, who would you need to ask for permission? Besides, as I already mentioned previously, my feeling is that nobody but Osmo Antero has copyright. There are two conditions that need to be met for this NOT to be true; 1) significant contributions from third parties and 2) those parties requested for copyright when making those contributions. 2) is not documented in the files and it should be IF there was a third-party copyright. I understand that Osmo enjoys drinking his vine and keep things simple. But he is making things unnecessarily complicated here by adding an opaque group of people to the copyright holders. I believe that what he wants to do is acknowledge outside contributions. That's what the AUTHORS file is for which is actually present but does not list anybody besides him. It's fine for him to make a broad statement there such as "a multitude of patches were gladly received by a number of people from the Linux community. If you'd like to see your name here specifically contact me at XYZ". Copyright is about who owns the ultimate rights to the source. GPL extends quite a few of those rights to the users (such as the right to modify, redistribute, etc.) What Osmo is doing (and I'm absolutely certain that is unintentional) is to give basically everyone who can somehow claim to be part of the Linux community to fully OWN the code and that includes the right to relicense it, for example. This would effectively make the source public domain and strip it of the protections the GPL provides (such as disallowing redistribution as a closed-source binary program). I am sure Osmo did not intend to release as public domain. This absolutely needs clarification, no way around that. My suggestion is to simply drop the erroneous and very dangerous line giving the Linux community or Team Audiorecorder the copyright. All users already have very broad rights protected under the GPL. Adding that line actually puts those rights in jeopardy. dfe98839e3 adds Ian Holmes as copyright holder for src/gst-recorder.c. If there are any other other copyright holders then that's the way we should handle copyright attribution for them as well, unless they have copyright in a broad number of files. 329aa8ce287 "Other" is not a good name for License. I suggest to follow https://tracker.debian.org/media/packages/g/granule/copyright-1.4.0-7-4 or https://github.com/giuliopaci/SPro/blob/master/debian/copyright which I found doing a quick Google search. https://lists.debian.org/debian-legal/2015/01/msg00054.html says there is a later version of the file with a better worded license term. If that's the case it would be advisable for upstream to exchange the current for the later version. If upstream doesn't do this, we can also do it in Debian only. If the file is not necessary to build the binary, we might want to simply drop it via debian/clean. This question needs more consideration. > Mainly it is an update of the debian/copyright file. But while I edited > it, I found a lot of auto-generated files in the source tarball. So I > deleted them via dquilt patch. I hope this is the right way to handle > such files. Are they giving any problems during the build? If no, then I'd say not to bother with them at all. If yes and they aren't removed by "dh clean" already then the file debian/clean is the proper place. Have a look at "man dh_clean". Simply put, you can list file names one per line in debian/clean to be removed as one of the first steps during the build. Wildcards are allowed, RegExp might be. This is better than using patches because deleting a 1MB file it takes a patch that's slightly bigger than 1MB. It's easier to read during code inspection as well. Regards Rolf
