Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=474549 Philipp Dunkel <p.dunkel@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |p.dunkel@xxxxxxxxxx --- Comment #41 from Philipp Dunkel <p.dunkel@xxxxxxxxxx> 2011-10-31 14:36:46 EDT --- Hi, I am a former Board Member of CAcert Inc. and was intimately involved in drafting many CAcert Policies as well as these licenses. While i am not authorized to speak on behalf of CAcert Inc. I believe I can help here to further an understanding between the two communities. There are three main problems in getting this done. 1. RedHat Legal and this thread view the issue as one of "software" or "content" licensing. Since a certificate, especially a root certificate is neither "just content" nor is it "just software", this is bound to fail. 2. RedHat understands limiting liability to a "vendor". However liability has different vectors in PKI in combination with open communities that make warranty limitations useless to a community like CAcert. 3. Reliance, warranty, use and the like have distinct meanings in the CA world. These meanings don't necessarily mesh well with the software world I will try to explain what the issues/thoughts at CAcert were in the hope that this will further inter-community understanding and maybe enable this bug to be successfully resolved. @1: Certificates are neither content nor software: Certificates have a single purpose. They are a piece of information that is useful only in determining the validity of a digital signature. As such they are, to an extent "software" as they are used to calculate a verification of a signature supplied. In so far as they are a file containing data that is not fundamentally executable a certificate is also "content". However that misses the whole point of certificates and what they really are. They are really legal statements saying: "If you can take a signature and muck it around with this bit of digits here, then we certify that the information contained is valid". Now while licensing for a piece of content, such as a book, or a piece of software, is a solved issue, the licensing of "neither-software-nor-content-but-a-bit-of-both-but-not-really" stuff is not something that RedHat or the OSS world in general has solved yet. However it is something that CAcert is expert at. Which leads me to @2: Why limitations of liability and the like are insufficient in the CAcert context One of the big problems for CAcert that other CAs do not have is in fact that CAcert is an open community. The members of our community are bound to each other as well as CAcert Inc. via the CAcert Community Agreement (CCA). This clearly regulated the claims any one in our community, such as providing for arbitration, limiting cash liabilities and so forth. In this context, we as a community are willing to make certain legal guarantees, such as statements about the reliability of certificate information and the like. The problem arises because in the CA/PKI world such statements are made not only between a CA and someone using a certificate to verify some signature, but rather it is a triangular relationship. A CAcert member makes a statement to a user and because the CAcert Member is a member CAcert makes an auxiliary statement to the user. Now if all a CA is worried about is its own behind, then limiting liability is sufficient. But CAcert is a community, and we do watch out for more than just CAcert Inc., we also watch out for our members. However we cannot disclaim the liability of a member to a user for communications that take place between the member and the user directly. The only recourse is that we state "If you are not bound by the CCA you may not rely (as defined) upon anything CAcert says with its certificates" Because this then eliminates any reliance in statements made via CAcert certificates between the member and the user. So is this a "use restriction"? Absolutely. You may not use CAcert certificates as a base for your decision making. You can use them to establish secured connections to websites, you can even use them for e-commerce, provided you find some other means to verify that the certificate in question is that of your commerce partner. But you may not take the fact that CAcert has signed a certificate to MEAN anything, unless you are bound by separate agreement to CAcert. @3. The terms we use do not necessarily mesh well Limiting liability, what does rely mean, what does use mean, what is a draft policy, and the like are another cause for misunderstanding between the RedHat and CAcert communities. We have a very well defined set of meanings for these words and they re described in our policies. However while these meanings are basically in line with the common use, they do have important nuances. Unless someone (including a lawyer) is willing to actually read the policies in full, it becomes very hard to understand all these nuances. This is one of the reasons we actually train our members in this regard. So most of our members, especially those more experienced, are very well informed on these matters. ---- Because of the specific environment CAcert operates in and the specific needs of an open community in this space, our policies and licenses have to diverge from the standard OSS licenses, since they are tailored to different needs. So long as this is ignored no progress on this issue will be reachable. For anyone interested in policy details I would direct you to: http://svn.cacert.org/CAcert/principles.html for our community principles as well as http://www.cacert.org/policy/ for our most relevant policies. If someone from RedHat, especially RedHat Legal, wants to work on getting somewhere on this, I am always available either by email or by phone (inquire by mail for number). Regards, Philipp -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review