The ebuilds have LICENSE="BSD X11", but file sha1hl.c is released under a different licence. It contains the following notice: * ---------------------------------------------------------------------------- * "THE BEER-WARE LICENSE" (Revision 42): * <phk@login.dkuug.dk> wrote this file. As long as you retain this notice you * can do whatever you want with this stuff. If we meet some day, and you think * this stuff is worth it, you can buy me a beer in return. Poul-Henning Kamp * ----------------------------------------------------------------------------
Best would be to convice the author that we all owe him a virtual beer, but if he would be so nice and relicense (or otherwise reimplement the trivial code). There are so many licenses - and then these "fun" licenses... The idea is fun of course, when you sit there hacking and beer just went empty, but for us as distributors it's a PITA, really. :( This code actually is a hodgepodge of licenses: md4c.c is RSA-MD4 md5c.c is RSA-MD5 sha1.c is public domain other files have copyright notices, but no license information...
Maybe adding "as-is" to LICENSE could be enough here?
(In reply to comment #2) > Maybe adding "as-is" to LICENSE could be enough here? Well, I'm no lawyer. To me a different license is a different license even if they only differ slightly in their wording. What we have as as-is file in the license subdirectory is and has to match the license the code is under. Just because you read "as is" in some license dosesn't make it THE as-is license. Even though it's dead annoying, I'd stick to it word by word, unless a good bunch of lawyers tell me otherwise. :|
Uhm? So stick it to $PORTDIR/licenses, we already have WTFPL-2 there after all. What's the 'problem' here?
Seems that Jakub follows all beer-related issues. :p OK, seriously, the plan is then: - Change LICENSES to "BSD X11 RSA-MD4 RSA-MD5 BEER-WARE" - Add the snippet from comment #0 as licenses/BEER-WARE @taviso: Do you mind if I commit this myself?
(In reply to comment #5) > OK, seriously, the plan is then: > - Change LICENSES to "BSD X11 RSA-MD4 RSA-MD5 BEER-WARE" > - Add the snippet from comment #0 as licenses/BEER-WARE "public-domain" missing. Also, I didn't check all files for other licenses, but having another look at it, the only file freferencing X11 is install.sh, which basically is the classic "as-is" license, not X11. And when you think it cannot worse, it does: skey.3 and skeyinfo.c are BSD licensed, but unfortunately 4-clause BSD, that is includung the dead old advertising clause - making it incompatible to the GPL, which may cause even more problems...
(In reply to comment #6) > "public-domain" missing. I think an explicit "public-domain" is not needed in addition to more restrictive licences. (Otherwise many more packages would need it since they also contain some public-domain files.) > [...] the only file referencing X11 is install.sh, which basically is the > classic "as-is" license, not X11. install.sh is neither installed nor used during the build process. But you are right, the newer source files, e.g. errx.c, flock.c, login_cap.c are under a licence that is commonly called X11-like, but that we carry under the name "MIT". > And when you think it cannot worse, it does: skey.3 and skeyinfo.c are BSD > licensed, but unfortunately 4-clause BSD, that is includung the dead old > advertising clause - making it incompatible to the GPL, which may cause even > more problems... Again, skey.3 is not installed. And skeyinfo.c was re-licenced for OpenBSD long time ago: <http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/skeyinfo/skeyinfo.c.diff?r1=1.4&r2=1.5>. So we could take their version if absolutely necessary. OTOH, that would be way too much effort for such a trivial program. So, "BSD MIT RSA-MD4 RSA-MD5 BEER-WARE"?
(In reply to comment #7) <http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/skeyinfo/skeyinfo.c.diff?r1=1.4&r2=1.5>. > So we could take their version if absolutely necessary. OTOH, that would be way > too much effort for such a trivial program. What matters is the distributed code we have, not some other code which has been relicensed later. And if you look at skeyinfo.c from the tarball our ebuild is fetching and the one from the OpenBSD repository, the code is not the same. Ours must be quite old or something, the hompage mentioned in the ebuild is unfortunately not reachable to find out more about it. I don't know, if these codebases are compatible, but taking the code from OpenBSD would be surely a sane solution.
(In reply to comment #8) > And if you look at skeyinfo.c from the tarball our ebuild is fetching and > the one from the OpenBSD repository, the code is not the same. Huh? The code of skeyinfo.c in the tarball (before patching) is _exactly_ the same as revision 1.6 in the OpenBSD repository.
Fixed in CVS.
Reopening for proper resolution.
(In reply to comment #11) > Reopening for proper resolution. Sorry, wrong bug.
*** Bug 172840 has been marked as a duplicate of this bug. ***
