Good morning, On 19.02.2017 00:48, Rolf Leggewie wrote: >>> I am sure Osmo did not intend to release as public domain. >> What you actually say is: IF we leave it as it is, the worst case is >> that the software could be public domain. > > No. The software has whatever license it has. We are just documenting > what that is. While doing this due diligence we might actually find out > that the license as stated is not what the author intended (a license > bug if that's how you want to look at it). Debian is doing this to > guarantee to its users that all software complies with DFSG and thus the > users do not have to do this work. Again, there really is no way around > this.
I meant leave it as it is "upstream".
In my opinion the software is DFSG-compliant in any way. If the
copyright holder is Osmo or Team audio-recorder or the software is
public domain.
As you said: If the license as stated is not what the author intended,
we can call his attentation to that. But apart from that we are
documenting. And if the license is DFSG-compliant, there is no reason
here, to not include the package into Debian.
> I am not sure that debian/copyright is currently complete, yet.
> "licensecheck -r" lists quite a few files under LGPL license for example
> and "rgrep -i copyright ." gives a lot more names than currently
> documented. There's still work to be done here.
You are right. Indeed everything seems to be under LGPLv3. I will ask
Osmo if this was intended. The boilerplates in the source files have to
be correct in either way, since the shorten the LGPL as GPL.
COPYING should also be adjusted.
I can do that, as soon as I recieve an answer from Osmo.
There are source files without copyright notice. Do we have to add that?
For example the header files under src/ .
>> We could drop the file, we just would have to run intltoolize before
>> the build process. I was not quite sure how to do it.
>
> It is already being done in line 18 of the current debian/rules file via
> "--with autoreconf". So, at least for Debian it seems that file (and
> possibly others) is not necessary and will be replaced during the build
> anyhow.
I think you are wrong here. intltoolize is not run by autoreconf.
> dh-autoreconf is a superset of autotools-dev and thus I pushed an
> untested fix to the rl-wip branch on github. Feel free to cherry-pick
> after verification.
Done.
> The Depends and Build-Depends lines look surprisingly long. Why do you
> have so many explicit runtime dependencies in Depends? Isn't this
> picked up automatically by ${misc:Depends} and ${shlibs:Depends}? If
> necessary this can be fixed later, but it struck me as odd when I
> stumbled upon it now.
I copied both Build-Depends and Depends from the upstream control file.
I'm not too familiar with ${misc:Depends} and ${shlibs:Depends} . Maybe
you would like to fix this?
> On 19.02.2017 04:12, David Rabel wrote:
>> I was just thinking: Do we have to add a paragraph in
>> debian/copyright
>> for files we delete with debian/clean?
>
> Yes, absolutely. The only other option is to create a separate
> dfsg-free upstream tarball and strip the relevant files from that
> tarball.
Done.
> In your case, of course, you might also use your upstream powers and
> consider to drop the file upstream depending on whether or not it
> should be shipped in upstream releases.
Probably Osmo wants to keep those files. We can ask him, of course.
> Thanks again for your work.
Thank you for your help.
Yours
David
signature.asc
Description: OpenPGP digital signature
