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. :)
1) I came across another review with the same license question. The
source files have one of the
GPLv2, GPLv2+ and LGPLv2+ headers each. They get compiled and produce
1 final binary executable. None of the headers (or other source code
files) go to the final RPM.
What goes to the license tag of the package?
2) Hypothetical question (although happens rather frequently): What if
there was a -devel subpackage and .h files with different licenses
ended up in this -devel subpackage?
Could you please clarify if the Trusster  Open Source License is an
acceptable Free/Open Source Software License for the Fedora project.
The Teal  project uses this license:
=== BEGIN ===
Trusster Open Source License version 1.0a (TRUST)
copyright (c) 2006 Mike Mintz and Robert Ekendahl. All rights reserved.
Redistribution and use in source and binary forms, with or without
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Redistributions in any form must be accompanied by information on
how to obtain
complete source code for this software and any accompanying
software that uses this software.
The source code must either be included in the distribution or be
available in a timely fashion for no more than
the cost of distribution plus a nominal fee, and must be freely
redistributable under reasonable and no more
restrictive conditions. For an executable file, complete source
code means the source code for all modules it
contains. It does not include source code for modules or files
that typically accompany the major components
of the operating system on which the executable file runs.
THIS SOFTWARE IS PROVIDED BY MIKE MINTZ AND ROBERT EKENDAHL ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
OR NON-INFRINGEMENT, ARE DISCLAIMED. IN NO EVENT SHALL MIKE MINTZ AND
ROBERT EKENDAHL OR ITS CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
=== END ===
 Trustter. http://www.trusster.com
 Teal. A Verification Utility and Connection Library.
Hello Fedora! (Is this thing on?)
Sorry for the very wide net, but we wanted to make sure as many members
of our community could see this as possible.
For some time now, Fedora has been working with Red Hat Legal to come up
with a replacement for the Fedora Individual Contributor License
Agreement (aka, the Fedora ICLA). As a result, the Fedora Project
Contributor Agreement (FPCA) has been approved by Red Hat Legal, and is
now being presented to the Fedora Community for comments and discussion.
The full text of the FPCA, along with a FAQ, can be found here:
Please, take a moment and read the FPCA and the FAQ. It is not a long,
or overly complicated document, as legal documents go, but it is
important that all Fedora Contributors read it over and make sure they
understand it and like it (or can at least agree to it).
Fedora Legal wishes to give the Fedora community a window of time for
discussion and review of the FPCA. This window is open until May 18,
2010 (2010-05-18). After that point, either a revised FPCA will be
released for review, or we will begin the process of phasing in the FPCA
and phasing out the Fedora ICLA.
Thanks in advance,
Tom "spot" Callaway, Fedora Legal
P.S. Fedora Legal would like to give a huge thank you to the people
involved behind the scenes to make the FPCA possible. The primary author
was Richard Fontana, with feedback from Tom Callaway, Pamela Chestek,
Paul Frields, and Robert Tiller. Feel free to give them gifts (for
example, drinks or tasty snacks) as thank yous, although, this is not a
requirement (legal or otherwise). ;)
Tatica and some other Fedora LATAM folks took some great photos of
Tatica put together a nice banner for the F13 release notes using one of
We have a few concerns with respect to having the participants sign
release forms. The first issue is that we found the Fedora Picture Book
release form, and it seems to apply to all countries, but, we are
worried because we want to use one of the photos for the release notes.
So we're not sure what to have those folks sign. The Fedora Picture Book
release form is here, for reference:
I found some generic Red Hat release forms that have a wider breadth in
terms of usage, but they are specific to countries. The only LATAM
countries I could find forms for are Brazil and Chile. I'm also a little
confused as to whether the form should be for the country the event the
photos are taken at is held, or should it be for the country the
person(s) in the photo are from?
One final concern Tatica raised is that many of these folks do not speak
English. I know we have a policy of not translating legal text in Fedora
itself. Tatica is wondering if it might be okay for her to provide a
Spanish translation for the forms in any case.
We want to make sure we do this the right way. Any advice is greatly
"The Fedora Project Board may, by public announcement, subsequently
designate an additional or alternative default license for a given
category of Contribution (a "Later Default License"). A Later Default
License shall be a free software license (for Code) or a free content
license (for Content) and shall be chosen from the list of acceptable
licenses for Fedora, currently located at
http://fedoraproject.org/wiki/Licensing, as that list may be revised
from time to time by the Fedora Project Board. "
it doesn't indicate there is any chance to opt out of the new license
even if it conflicts with the one the contribution was submitted under.
Presumably this is intentional and desired.
However this agreement doesn't seem to put any minimum requirements for
the "free" licenses listed at http://fedoraproject.org/wiki/Licensing .
Without that we are just trusting on faith that that list will in fact
list licenses that contributors think are "free".
What happens in http://fedoraproject.org/wiki/Licensing is changed in error
or by someone not authorized to make a change?
So perhaps there are a few ways that the license could be changed to a
I don't remember seeing information on whether the project preferred an
explicit or default license for spec files nor how to document a different
license for the spec file (presumably the license tag doesn't apply to it)
than for the remainder of the package. (A quick search didn't find anything
either, but there could be some documentation that I didn't find.)
It would probably be a good idea to better document this in the packaging