On Tue, 2008-12-09 at 23:03 +0100, Matthias Saou wrote:
> > >>>>> "TC" == Tom \"spot\" Callaway <Tom> writes:
> > TC> Given that it does not give permission for us to redistribute (the
> > TC> cornerstone requirement for Content licenses), this license is not
> > TC> acceptable for Fedora.
> > I guess I'm glad I looked before approving the package, but I have to
> > wonder: Do the cacert folks actually want anyone to use their
> > certificates? I mean, this prevents basically everyone from using
> > them, because they can't come with the OS or the browser.
> Personally, the more I read the document, the more I'm confused.
> "You may NOT distribute certificates or root keys under this
> licence"... does this mean we can distribute under a different license?
Well, sortof. The wording here is strange because you can get a
different license from the CA issuer. We can't just pick a license, but
the CA issuer might be willing to give us a different one.
> Would it be worth getting in contact with CAcert.org in order to try
> and have them allow us to redistribute the root certs under conditions
> which are acceptable to the Fedora Project?
Probably, yes. :)
On 11/26/2012 09:53 AM, Stephen Gallagher wrote:
> MIT +no-false-attribs License
> Permission is hereby granted, free of charge, to any person
> obtaining a copy of this software and associated documentation
> files (the "Software"), to deal in the Software without
> restriction, including without limitation the rights to use,
> copy, modify, merge, publish, distribute, sublicense, and/or sell
> copies of the Software, and to permit persons to whom the
> Software is furnished to do so, subject to the following
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.
> Distributions of all or part of the Software intended to be used
> by the recipients as they would use the unmodified Software,
> containing modifications that substantially alter, remove, or
> disable functionality of the Software, outside of the documented
> configuration mechanisms provided by the Software, shall be
> modified such that the Original Author's bug reporting email
> addresses and urls are either replaced with the contact information
> of the parties responsible for the changes, or removed entirely.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER DEALINGS IN THE SOFTWARE.
This is Free and GPL-Compatible. Use:
I would like guidance on propagation of licenses within Apache Maven pom.xml
files. Short introduction:
Maven pom.xml files specify project build process and various metadata. They
*can* contain licensing information embedded in a special <licenses> tag. We
package relatively a lot of simple pom packages (i.e. there's only the xml file
packaged + few fedora glue). Not all of these files are clearly licensed but
they almost always have parent pom.xml files (specified in <parent> tag).
What I believe makes sense is that if the pom.xml file doesn't specify license,
we should assume the license is the same as parent pom. In any case the files
are relatively simple so they might not be even copyrightable (but better safe
Can we get clearance for this or similar approach? Note that contacting
upstreams with these requests have mostly been fruitful with new projects, but
we have quite a few old things where they are long abandoned (but still used).
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Red Hat Inc. http://cz.redhat.com