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.
khmeros-fonts package do not have separate license text file but its
license is picked from the license text inside ttf file. Is there any
guidelines for this?
Can we package font files provided vaild license text is included
inside ttf file only?
This may be a goofy question, but just in case it's not:
Does changing the stock 3-clause BSD license to say "Some rights
reserved" instead of "All rights reserved" make any difference at all to
the meaning of the license? On the off chance that it actually does,
can the resulting license still be called "BSD"? I suspect someone's
just being cute but I guess it's safer to ask than assume.
On 06/24/2010 02:21 PM, Peter Larsen wrote:
> On Thu, 2010-06-24 at 14:08 -0400, Tom "spot" Callaway wrote:
>> On 06/24/2010 12:31 PM, Frank Murphy wrote:
>>> Thought I would forward this here?
>>> As been involved with Freemedia,
>>> the answer could also be relevant there.
>> So, the short answer is that our Legal/Export page is still accurate.
>> The long answer is much much longer and more complicated, but it has to
>> do with how exports to Iraq are actually handled, large amounts of
>> individuals in Iraq are still export restricted, specifically, remnants
>> of the Baath party scattered around in different parts of the country
>> and the government. We do not have a license to export Fedora to Iraq,
>> and while it is possible for us to apply for one, there is a high
>> probability that it would be denied. Accordingly, Red Hat Legal is
>> treating Iraq as export restricted.
> Appreciate the answer and clarification Spot; I was aware that there's a
> list of individuals and groups that are restricted, but the wording on
> the fedora export restriction terms were much much broader than that.
> How does the availability of "get-fedora" to those regions relate into
> this answer? Doesn't it violate the same conditions by allowing the
> download in the first place?
Our current pages are in compliance with US Export policy. This is an
area where we have spent much time, and have dedicated people at Red Hat
Legal who handle export compliance.
On 06/21/2010 12:05 PM, Paul Wouters wrote:
> On Mon, 21 Jun 2010, Tomas Mraz wrote:
>>> I would be great if we could change the spec file to have a proper flag
>>> to enable/disable GOST/ECC so that people can easilly rebuild with GOST
>>> support if they need to (and it is legal for them). Would that be
>>> legally possible?
>> This is not possible as the ECC algorithm sources are removed from the
>> source tarball prior to adding it to the Fedora CVS.
> Would it still be possible to have the define with a comment to grab the
> source outside the CVS repo? I am just trying to minimise the work that
> has to be done and maintained separately from the Fedora openssl.spec file.
On Mon, Jun 21, 2010 at 11:07:05 -0400,
Paul Wouters <paul(a)xelerance.com> wrote:
> Some references showing there should not be any known IPR issues filed
> with the IETF that would prevent implementing RFC standards using ECC:
DJB has made some public comments on why he doesn't think any patents apply
to ECC work he has published at:
He isn't a lawyer, but his comments may still be useful.