Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway
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. :)
~spot
7 years, 1 month
Please define "effective license" (for the love of consistency)
by Orcan Ogetbil
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?
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=537325#c4
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?
Orcan
12 years, 8 months
Trusster Open Source License
by Shakthi Kannan
Hi,
Could you please clarify if the Trusster [1] Open Source License is an
acceptable Free/Open Source Software License for the Fedora project.
The Teal [2] 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
modification,
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 ===
Thanks!
SK
[1] Trustter. http://www.trusster.com
[2] Teal. A Verification Utility and Connection Library.
http://www.trusster.com/products/teal/
--
Shakthi Kannan
http://www.shakthimaan.com
12 years, 8 months
Proper description of mysql's documentation license?
by Tom Lane
Bug #560181 correctly points out that although mysql's code is
distributed under GPL, the associated documentation is not.
The reporter proposes classifying it as "Redistributable, no
modification permitted", but I thought I'd ask this list about
opinions on the best license tag for it. The doc license looks
like this:
Copyright 1997-2008 MySQL AB, 2009 Sun Microsystems, Inc.
This documentation is NOT distributed under a GPL license. Use of this
documentation is subject to the following terms: You may create a
printed copy of this documentation solely for your own personal use.
Conversion to other formats is allowed as long as the actual content is
not altered or edited in any way. You shall not publish or distribute
this documentation in any form or on any media, except if you
distribute the documentation in a manner similar to how Sun
disseminates it (that is, electronically for download on a Web site
with the software) or on a CD-ROM or similar medium, provided however
that the documentation is disseminated together with the software on
the same medium. Any other use, such as any dissemination of printed
copies or use of this documentation, in whole or in part, in another
publication, requires the prior written consent from an authorized
representative of Sun Microsystems, Inc. Sun Microsystems, Inc. and
MySQL AB reserve any and all rights to this documentation not expressly
granted above.
Also: I am thinking of putting the docs into a separate -docs subpackage
with its own License tag, rather than confusing matters by labeling the
whole package with two very different tags. Any objections to that?
Could the "with the software" bit above be read to prohibit such a
scheme? Plan C would be to drop the docs entirely and just offer a link
to mysql's website, but I don't like that very much ...
regards, tom lane
13 years, 1 month
PHP PEAR channel definition license
by Jon Stanley
I'm running into an interesting problem with PHP PEAR channel
definition licensing. All that this really is is an XML file that
defines where to get the channel, etc, similar to a yum repo
definition.
The problem is that there is no copyright specified for this file.
Looking at other review requests, it looks like either the license
field was pulled out of thin air with no explanation, or they used the
license of the PHP modules distributed by the channel. This approach
seems wrong to me, as there could obviously be modules covered by
several different licenses.
At a more basic level, is such a file a even a copyrightable work? I
don't believe so, because it contains no creative expression
whatsoever - it's just metadata
13 years, 1 month
New package license review proposal
by Jason L Tibbitts III
I figured I'd start with this list and broaden to devel@ if people think
it's a good idea.
In doing (very) many package reviews, I've found one of the most
time-consuming things to be doing a proper license review. Even
something simple with, say, an LGPLv2+ notice can get complicated when a
single GPLv2 file sneaks in. It's complicated enough that I suspect in
many cases license review just isn't being done. Plus the complexities
of licensing coupled with the complexities of our packaging guidelines
really poses a high barrier for anyone wanting to do proper license
reviews.
So I'm proposing that we separate the roles of the package reviewer from
the license reviewer, allowing someone who wants to concentrate on
licensing do participate in the review process without having to deal
with the complexities of the packaging guidelines (or even building the
software). This isn't intended to preclude someone from taking a new
request and doing both packaging and licensing review, but simply to
allow folks to go through the existing reviews and indicate that they've
been checked for licensing issues so that someone could later go through
and review the packaging without having to struggle over the licensing.
I propose to handle this with a simple entry in the whiteboard and a
comment by the reviewer. I can add a report under
http://fedoraproject.org/PackageReviewStatus listing tickets which need
license review, and am prepared to write a utility to facilitate things
as much as possible. When a license question comes up, FE-Legal would
be blocked just as it is now. (Apologies to spot.) I would ask for
help from others to document the license review process as much as
possible.
I think in the end that with a dedicated team of folks doing license
checks, we can get the review process moving a bit quicker and cut down
on incidences of unwanted things leaking into the distro that have to be
cleaned up later.
- J<
13 years, 2 months
amap license
by Michal Ambroz
Hello dear list members,
I would like to ask whether the amap license and amap program itself would be eligible to be included in the Fedora.
Tool is opensource with license based on GPLv2 with additional restrictions, but I am not sure whether it is free enough
to create amap package for Fedora.
http://freeworld.thc.org/thc-amap/
Thank you
Michal Ambroz
------------------------- License ----------------------
LICENCE FOR AMAP (all version)
by van Hauser <vh(a)thc.org>
1. This software comes with no warrenty or promised features. If it works
for you - fine. It just comes "AS-IS", which means as a bunch of bits and bytes.
2. Anyone may use this software and pass it on to other persons or companies
as long as it is not charged for! (except for a small transfer/medium fee)
3. This tool may *NOT* be used for illegal purpose. Please check the law
which affects your doing. I will have got no liability for any damage etc.
done with this tool legally or illegaly.
4. If this tool is used while providing a commercial service (e.g. as part
of a penetration test) the report has to state the tools name and version,
and additionally the authors (van Hauser and Dj RevMoon) and the distribution
homepage (http://www.thc.org).
5. If this tool is used within a commercial tool (being called out of such a
tool or being incorporated), the report generated has to state the tools name
and version, and additionally the authors (van Hauser and Dj RevMoon) and the
distribution homepage (http://www.thc.org). A tool is "commercial" if it either
costs money to purchase it, has a license fee, and/or has costs for upgrades.
Additionally, a commercial version or license etc. must be made available to
the author free of charge.
6. In all other respects the GPL 2.0 applies
13 years, 2 months
unable to define license type
by Jiri Skala
Hello,
I found a license cited below during srpm review. I'm not able to define
what kind of license is it. Could you help me with it? The source is a
part of iputils package together with other sources/binaries. There is
more type of licenses. Particular binaries contains sources of one
license type. The package is used in Fedora and RHEL-6. I suppose spec
file license definition should appear:
License: BSD with advertising and GPLv2+ and <unknown_licence>
Thank you for your help in advance
Best regards
Jiri
Unknown license type:
* Rdisc (this program) was developed by Sun Microsystems, Inc. and is
* provided for unrestricted use provided that this legend is included
on
* all tape media and as a part of the software program in whole or
part.
* Users may copy or modify Rdisc without charge, and they may freely
* distribute it.
*
* RDISC IS PROVIDED AS IS WITH NO WARRANTIES OF ANY KIND INCLUDING THE
* WARRANTIES OF DESIGN, MERCHANTIBILITY AND FITNESS FOR A PARTICULAR
* PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE
PRACTICE.
*
* Rdisc is provided with no support and without any obligation on the
* part of Sun Microsystems, Inc. to assist in its use, correction,
* modification or enhancement.
*
* SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE
* INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY RDISC
* OR ANY PART THEREOF.
*
* In no event will Sun Microsystems, Inc. be liable for any lost
revenue
* or profits or other special, indirect and consequential damages, even
if
* Sun has been advised of the possibility of such damages.
*
* Sun Microsystems, Inc.
* 2550 Garcia Avenue
* Mountain View, California 94043
13 years, 2 months
