zevv
COPYING File still in release tarball, missing license headers.
Hi,
Thanks for the great tool. I am packing it for conda-forge which will allow duc to be distributed using anaconda or miniconda. Licensing matters for distributors.
There are two issues I noticed when packaging:
- It is stated that the program is released under the LGPL yet the release tarball for 1.4.4 still contains a COPYING file.
- There are no license headers in the source code files as is recommended. For me as packager I don't know whether this project is licensed under LGPL 3.0, or under LGPL3.0 or later. This is usually mentioned in these headers.
Technically this means your latest release (1.4.4) is still under GPL2.0, as there are no license headers to indicate otherwise and only the COPYING file is included in the release tarball, not the LICENSE file. This may not be as you intended, as I can clearly see the license change in the changelog included in the tarball.
Hi Ruben,
We have some other changes and fixes outstanding, so I guess this is a good time to go to 1.4.5 and fix this while we do that. In the current master we have LICENSE instead of COPYING, so that should be solved. Personally I don't care about putting licenses in headers, maybe @l8gravely has an opinion about that.
Are there any other things we can or should do when making 1.4.5 that would make your live as a packager easier?
Personally I don't care about putting licenses in headers, maybe @l8gravely has an opinion about that.
Well, it makes it easier to use individual files from your project in other projects. When people do a blatant copy paste (which they do) at least the license context is preserved. I have had it happen to one of the projects I contribute to. Some files were blatantly copied, which was okay as the license was MIT and compatible with the license of the project they were copied into. But the original copyright context was lost, which is technically a violation from the copying party. It also meant that our work was not credited. So we went ahead and added license headers to all our files that did not have them yet. I think it is very useful, but of course, it is your call.
Also I found that the documentation also still mentions the GPL version 2 as the license. So it would be good to change that as well.
Are there any other things we can or should do when making 1.4.5 that would make your live as a packager easier?
Listing all the build dependencies in the documentation would be something. But since you already made a debian package I was able to get the dependencies from there.
I think the building is quite straightforward using autoconf and automake, so no suggestions there.
Thanks for the nice software!
Ico> We have some other changes and fixes outstanding, so I guess this Ico> is a good time to go to 1.4.5 and fix this while we do that. In Ico> the current master we have LICENSE instead of COPYING, so that Ico> should be solved. Personally I don't care about putting licenses Ico> in headers, maybe @l8gravely has an opinion about that.
I don't have a big care since it's mostly not my code. :-) But with the entire tool licensed explicitly, I think we're good.
Ico> Are there any other things we can or should do when making 1.4.5 Ico> that would make your live as a packager easier?
I've been piling up changes and getting ready to try and roll a new release, but I'm new to do it all, and my git-fu is weak at times.
I do have a bunch of documentation updates almost ready to roll up, since I did a bunch of builds on various releases to know which packages/libraries are needed for compiles.
Let me try to push them later today into a documentation branch.
"Ruben" == Ruben Vorderman [email protected] writes:
Zevv> Personally I don't care about putting licenses in headers, Zevv> maybe @l8gravely has an opinion about that.
Ruben> Well, it makes it easier to use individual files from your Ruben> project in other projects. When people do a blatant copy paste Ruben> (which they do) at least the license context is preserved. I Ruben> have had it happen to one of the projects I contribute to. Some Ruben> files were blatantly copied, which was okay as the license was Ruben> MIT and compatible with the license of the project they were Ruben> copied into. But the original copyright context was lost, which Ruben> is technically a violation from the copying party. It also Ruben> meant that our work was not credited. So we went ahead and Ruben> added license headers to all our files that did not have them Ruben> yet. I think it is very useful, but of course, it is your call.
I personally think we don't want a large header of license text added to each file, but a couple of lines giving the license and authorship wouldn't be a terrible compromise.
What do you suggest?
Ruben> Also I found that the documentation also still mentions the GPL Ruben> version 2 as the license. So it would be good to change that as Ruben> well.
What's wrong with GPLv2?
Zevv> Are there any other things we can or should do when making Zevv> 1.4.5 that would make your live as a packager easier?
Ruben> Listing all the build dependencies in the documentation would Ruben> be something. But since you already made a debian package I was Ruben> able to get the dependencies from there.
I've got this in a new branch for a bunch of distros. So it should be addressed soon.
Ruben> I think the building is quite straightforward using autoconf Ruben> and automake, so no suggestions there.
Ruben> Thanks for the nice software!
The kicker is turning out to be that pkg-config doesn't work for the same library across different distros, which is a pain and means I had to re-work it a bit.
Oh well... not the end of the world.
I personally think we don't want a large header of license text added to each file, but a couple of lines giving the license and authorship wouldn't be a terrible compromise. What do you suggest?
Well I am not a lawyer. The GNU project suggests a lengthy preamble for each file:
Copyright 1989 Foobar contributors
This file is part of Foobar.
Foobar is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
Foobar is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with Foobar. If not, see <https://www.gnu.org/licenses/>.
I guess that can be shortened to:
Copyright 2014 Duc contributors (Or your personal names)
This file is part of duc. Duc is distributed under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation, version 3. (The any later version clause can be added here as well).
It contains less information than the GNU endorsed header, but at least it contains all the necessary information. DISCLAIMER: not a lawyer. But it is better than no copyright information at all.
What's wrong with GPLv2?
Nothing, but you changed the license to LGPLv3, so the documentation should mention that IMHO.