Re: RFS: aescrypt
Bernhard R. Link wrote:
> * Benoît Knecht <benoit.knecht@fsfe.org> [110804 20:54]:
> > I've seen that, but they need to make that perfectly clear in the
> > license header of each file in the tarball. An email sent to you and
> > reproduced in the debian/copyright file is not enough.
>
> There is nothing special about the source files. There is a need to
> have a license, there is no need that this license statement must be
> in the files itself or even in the tarball.
I don't get what you mean by "there is no need to have a license". A
software distributed without a license is always presumed to be
non-free. I do agree that the license doesn't have to be in the file
itself, but then there should at least be a license file in the tarball
stating what the license of all the included files is; and if there is a
license statement in the file (as it is the case now), it should state
all the rights granted to the user. Right now, the header says you're
free to distribute these files, and somewhere else one of the copyright
holder (in a private email, as far as I can tell) says you can do pretty
much whatever you want with those files. I don't think that's an
acceptable license grant; it's confusing at best.
> (Though it definitely extremly recommendable to have the license clearly
> stated in every file and the postamble of the GPL recommending this
> has definitely be counted as one of the best things the FSF ever did).
Agreed.
> > It is crucial
> > that they fix this _upstream_, you can't simply add a note in the debian
> > packaging about that.
>
> As long as debian/copyright contains something giving us and the users
> a license by people authorized to do so everything is fine.
>
> > And again, if they want to make sure that the license they're using is
> > free, they should use one of the well known free software licenses such
> > as the 3-clause BSD or the Expat license; if that's still too
> > restrictive for their taste, they could use a public domain license such
> > as CC0.
>
> While it is definitely recommendable to use something already existing
> to avoid common pitfalls, that does not mean everything else is
> impossible.
Indeed, I was just suggesting using these since they seem to have fallen
into one of these common pitfalls already. But if they modify their
"freeware" license in a way that makes it free, that's of course
perfectly fine (although I don't see the benefit of coming up with yet
another free license).
> > And please, if you're discussing these licensing issues with upstream,
> > don't forget to also remind them about including a copy of the GPL along
> > with the source; it _is_ a license violation not to do so.
>
> This is definitely something that is needed. (Or replacing the code
> with code unter other licenses, at least for sha256 there is less
> restrictive code flowing around).
>
>
> To get to the real problems:
>
> debian/copyright is not giving the license statement from those files.
> (the message it quotes does refer to something not quoted, I guess the
> statement found in the files).
>
> The original license statement as far as I see mostly misses the
> explicit permission to modify and distribute modified and to give
> others the same permission (or it should be clear that it gives those
> permissions to eveyone).
>
> The message quote in debian/copyright starts with describing what this
> license is supposed to do and then continues with "I’ll go further in
> saying...". Here it is unfortunately not very clear if this is a
> addional grant of license or a wrong description about the one found
> in the files.
> I think this needs improvement (having that in the upstream files
> would of course be nice, but as long as you can a explicit permission
> of the copyright holder that everyone may use, copy and/or modify
> and state this grant in the file that would be enough).
There are three contributors (according to debian/copyrigh, not all of
them are copyright holders, it's not clear why) listed in aescrypt.c for
example, so we'd need a statement from all the copyright holders,
preferably somewhere publically accessible. I still think it's way
easier to get upstream to fix the license headers.
Cheers,
--
Benoît Knecht
Reply to: