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
8 years, 3 months
winetricks
by T.C. Hollingsworth
winetricks [1] is free software, but I was originally under the
impression that it was ineligible for inclusion in Fedora because it
is used primarily to download and install non-free software. (That is
not it's only function, though--it also does some registry hacks and
can manage multiple WINEPREFIXes.)
However, some members of the community disagree [2] and say that it
might be eligible for Fedora, so we'd like confirmation one way or the
other.
Thanks!
-T.C.
[1] http://winetricks.org/
[2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=1992#c40
8 years, 9 months
This code may be freely used and modified for any purpose
by Miro Hrončok
HI,
how can I use this in a package?
Copyright 2001, softSurfer (www.softsurfer.com)
This code may be freely used and modified for any purpose
providing that this copyright notice is included with it.
SoftSurfer makes no warranty for this code, and cannot be held
liable for any real or imagined damage resulting from its use.
Users of this code must verify correctness for their
application.
Thanks a lot.
--
Miro Hrončok
--
Phone: +420777974800
Jabber: miro(a)hroncok.cz
11 years
Re: [Fedora-legal-list] Complex licensing interactions for OpenLMI
by Richard Fontana
On Tue, Apr 23, 2013 at 09:27:16AM -0400, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ping. I'd like to get an answer on this soon, if possible.
The answer is: yes, this arrangement is acceptable.
- RF
>
> On Thu 04 Apr 2013 01:07:53 PM EDT, Stephen Gallagher wrote:
> > On 04/04/2013 11:41 AM, Stephen Gallagher wrote:
> >> We have some concerns about whether our licensing will be in
> >> conflict in the OpenLMI project. I'll attempt to describe the
> >> topography. Tomas, please correct me if I have misrepresented
> >> anything.
> >>
> >> We have three components in question here:
> >>
> >> 1) The OpenPegasus CIMOM. This is a daemon licensed under MIT.
> >> It has a plugin architecture that enables it to dlopen() plugin
> >> modules and use them. (Dynamic linking by dlopen)
> >>
> >> 2) The SBLIM providers. These are a set of CIMOM plugins
> >> licensed under the MPL that provides some common, standard
> >> interfaces through OpenPegasus.
> >
> > Sorry, important distinction. This should have been EPL (as I
> > correctly mention below).
> >
> >
> >>
> >> 3) The OpenLMI providers. These are plugins licensed under
> >> LGPLv2+ that consume some of the functionality provided by the
> >> SBLIM providers, but which do so by means of local communication
> >> through the OpenPegasus CIMOM.
> >>
> >>
> >> Our question here is whether this is an acceptable arrangement.
> >> I see two potential pitfalls that I would like (hopefully) to
> >> have dispelled. A) I know it is acceptable for an MIT application
> >> to link separately to an EPL library and an LGPL library.
> >> However, is the resulting linked chimera also permissable, given
> >> that the two libraries themselves do not have a direct link? B)
> >> Is the indirect link between the OpenLMI providers (LGPL) and the
> >> SBLIM providers (EPL) acceptable, given that it does so only
> >> through interfaces provided by OpenPegasus (MIT) and not through
> >> direct function calls?
> >>
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlF2jDQACgkQeiVVYja6o6MLxACgrjW4NChOqq6tEePqH7aerHPS
> /SsAn3DK0o/jophaFb9EQS7jFeQ5dmEW
> =/oVt
> -----END PGP SIGNATURE-----
11 years
License of docbook-style-xsl package
by Stanislav Ochotnicky
I noticed that docbook-style-xsl package has License tag set to "Copyright
only". However this is the text of COPYING file:
Copyright
---------
Copyright (C) 1999-2007 Norman Walsh
Copyright (C) 2003 Jiří Kosek
Copyright (C) 2004-2007 Steve Ball
Copyright (C) 2005-2008 The DocBook Project
Copyright (C) 2011-2012 O'Reilly Media
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
conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
Except as contained in this notice, the names of individuals
credited with contribution to this software shall not be used in
advertising or otherwise to promote the sale, use or other
dealings in this Software without prior written authorization
from the individuals in question.
Any stylesheet derived from this Software that is publically
distributed will be identified with a different name and the
version strings in any derived Software will be changed so that
no possibility of confusion between the derived package and this
Software will exist.
Warranty
--------
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 NORMAN WALSH OR ANY OTHER
CONTRIBUTOR 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.
Is the above really considered copyright only? If so it might be nice to add it
to https://fedoraproject.org/wiki/Licensing:CopyrightOnly as a specific example.
Perhaps the word "shall" is cousing all of this to be copyright only? In any
way, clearing it up will help with bug reported against dblatex (which contains
modified versions of xslt stylesheets)
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11 years
perl-DBD-InterBase license
by Petr Šabata
Dear list,
I'm reviewing perl-DBD-InterBase [1] which uses the standard Perl
license. However, it includes the following special exception:
You may distribute under the terms of either the GNU General
Public License or the Artistic License, as specified in the
Perl README file, with the exception that it cannot be placed
on a CD-ROM or similar media for commercial distribution
without the prior approval of the author.
Is this acceptable with or even without the author's explicit
approval?
Thank you for your insight,
Petr
[1] https://bugzilla.redhat.com/show_bug.cgi?id=951873
11 years
Is this acceptable for Fedora
by Remi Collet
Hi,
In Horde_ActiveSync extension, file headers have
* @license http://www.horde.org/licenses/gpl GPLv2
* NOTE: According to sec. 8 of the GENERAL PUBLIC LICENSE (GPL),
* Version 2, the distribution of the Horde_ActiveSync module
in or
* to the United States of America is excluded from the scope
of this
* license.
Is it acceptable for Fedora ?
Thanks,
Remi.
11 years, 1 month
