Bug#506040: Status of ceph ITP?
On Thu, 2010-12-02 at 01:30 +0100, Laszlo Boszormenyi wrote:
> I'm not an ftp-master, but your package maybe rejected[2] for two
> reasons. I think only debian/copyright is not enough, all source files
> should have a comment header about their license in short. You have it
I don't see where this is a hard requirement in the reject faq.
Essentially, as long as the files don't have a license that conflicts
with COPYING, then there's no need for a license header. I DO think its
a good idea to have a Copyright header in every file, but thats also
probably ok to have in an AUTHORS file or something like that.
> in cephfs.cc , cfuse.cc , etc; but missing in barclass.cc , cconf.cc ,
> cls_acl.cc and in others. Second is that you link with OpenSSL when your
> license is (L)GPL. See their FAQ[3] and the fact that I can't find any
> upstream license file permitting that nor it's mentioned in
> debian/copyright . Also you may see the debian/copyright of my packages,
> like neon27[4]: it has a pointer to the full license file
> under /usr/share/common-licenses/ .
> On the other hand, it went into Ubuntu without any problems. Clint,
> Noèl? Feel free to post comment on what needs to be done with ceph
> packaging to be accepted on the first round.
>
Laszlo, I did a thorough review of the licensing before working to get
ceph uploaded to Ubuntu, but I wasn't aware of the incompatibility
between the GPL/LGPL and OpenSSL. This page details it pretty well:
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Sage, I'd guess that you can work on getting an OK from the other
authors on adding an exception. I've opened a bug against CEPH in ubuntu
here:
https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/684011
Sage, if you can please update that bug's status when you have secured
an exception, that would be ideal, as I'm going to mark it as Critical,
so we'll probably have to drop ceph from Natty if there's no resolution
before the release, and consider dropping it from Maverick as well.
Also Sage, if the other authors (or you) are not comfortable with the
OpenSSL advertising clause, there's always GNUTLS which exists in large
part to address this sort of thing.
Reply to: