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
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
7 years, 7 months
Linking of GPL-only and GPL-incompatible libraries
by Florian Weimer
What's Fedora's stance on linking GPL-only libraries into the same
process as a library which is considered GPL-incompatible (such as
4-clause BSD) if this linking happens rather indirectly?
We currently link psql against both libreadline and libcrypto/libssl
(OpenSSL), so if that is okay, more indirect linking should be
acceptable as well.
However, I'm not sure I'd appreciate that if I were a GPL-only library
author who chose that license deliberately (perhaps even with a desire
to sell alternative licensing), and some intermediate libraries makes my
work available under a more permissive license, only wrapped in a
different programming interface.
--
Florian Weimer / Red Hat Product Security Team
8 years, 7 months
Exceptions restricting program name are compatible with "LGPLv2 with exceptions", correct?
by Jeff Backus
Hi,
I would like to package a window manager named Notion. It is a fork of
the Ion(tm) window manager. Ion(tm) is released under the LGPLv2.1 with
an addendum that restricts derivative works from calling said works
Ion(tm) or using a name that implies being apart of the Ion(tm) project.
The nature of these restrictions appears to be inline with the GNU free
software philosophy, as is stated in the following paragraph:
However, rules about how to package a modified version are
acceptable, if they don't substantively limit your freedom to
release modified versions, or your freedom to make and use modified
versions privately. Thus, it is acceptable for the license to
require that you change the name of the modified version, remove a
logo, or identify your modifications as yours. As long as these
requirements are not so burdensome that they effectively hamper you
from releasing your changes, they are acceptable; you're already
making other changes to the program, so you won't have trouble
making a few more.
-- "What is Free Software?" (https://www.gnu.org/philosophy/free-sw.html)
The addendum is included below for reference. The complete license,
including addendum, is available here:
https://github.com/jsbackus/notion/blob/master/LICENSE
Given that the software I would like to package is released under a
different name, I do not see any conflicts with Fedora's licensing
guidelines. Am I correct in my interpretations? Is this license
compatible with Fedora's "LGPLv2 with exceptions" license?
Thank you in advance for your time and any clarification you can provide.
Regards,
Jeff
-= Begin License Addendum =-
Copyright (c) Tuomo Valkonen 1999-2009.
Unless otherwise indicated in components taken from elsewhere, this software
is licensed under the GNU Lesser General Public License, version 2.1
("LGPL",
reproduced below), extended and modified with the following terms:
If the name Ion(tm) or other names that can be associated with the Ion
project are used to distribute this software, then:
- A version that does not significantly differ from one of the
copyright holder's releases, must be provided by default.
- Versions not based on the copyright holder's latest release (on
the corresponding "branch", such as Ion3(tm)), must within 28 days
of this release, be prominently marked as (potentially) obsolete
and unsupported.
- Significantly altered versions may be provided only if the user
explicitly requests for those modifications to be applied, and
is prominently notified that the software is no longer considered
the standard version, and is not supported by the copyright holder.
The version string displayed by the program must describe these
modifications and the "support void" status.
Versions for which the above conditions are not satisfied, must be
renamed so that they can not be associated with the Ion project, their
executables must be given names that do not conflict with the copyright
holder's version, and neither the copyright holder nor the Ion project
may be referred to for support.
In the text of sections 0-2, 4-12, and 14-16 of the LGPL, "this License"
is to be understood to refer to the LGPL extended with these terms and,
where applicable, possible similar terms related to the names of other
works forming a whole. Sections 3 and 13 of the LGPL are void. Where
contradictory, these additional terms take precedence over the LGPL.
End of terms.
Explanations
Trademarks: With the terms above primarily appealing to copyright law,
should any of the indicated trademarks be found invalid, does not excuse
you from the conditions imposed by those terms. The use of these names
in contexts other than redistribution of this software and modifications,
is outside the scope of the terms above, and governed by applicable
trademark or other laws.
With regard to modules and other extensions to Ion(tm), the permission
is hereby granted to use "Ion" as part of the name, provided that it
occurs in a form suggesting that the work is supported by neither the
copyright holder nor the Ion project: "Foo for Ion" instead of "Ion Foo",
etc.
Significant change: Bug fixes are insignificant as additions. Basic changes
that are needed to install or run the software on a target platform, are
insignificant. Additionally, basic/small configuration changes to better
integrate the software with the target platform, without obstructing the
standard behaviour, are insignificant. Everything else is significant,
unless expressly declared otherwise by the copyright holder.
Distributions: For example, suppose an aggregate distribution of software
provides an `installpkg` command for installing packages. Then the action
`installpkg ion3` (resp. `installpkg ion`) should provide the latest release
of Ion3 (resp. the latest stable release) 28 days from release date at the
latest, or prominently notify the user that the provided version is (likely
to be) obsolete and unsupported. The latest release being provided by
default, or prominently appearing in a listing, constitutes prominent
marking of earlier releases as obsolete. Specific versions (including
modified versions) may be provided if the user explicitly requests for
those, within the constraints set above.
The intent of these terms is to curb the power that "distributions", as
the primary sources of software for many users, have in defining what
is perceived as Ion. By providing significantly modified versions and
out-dated development snapshots without prominently mentioning this fact,
they do not present the work in a light that the author can agree with,
and create a burden of dealing with (new) users seeking for support for
such versions.
-= End License Addendum =-
--
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus
9 years, 3 months
XML::Parser::Lite license
by Petr Šabata
Dear legal,
my reviewer has raised a question about the package license.
As I can only argue with my, likely flawed opinion, could you
state whether the following terms are acceptable for Fedora
and what License tag should be used?
# The following code may be freely used and distributed provided that
# this copyright and citation notice remains intact and that modifications
# or additions are clearly identified.
Thank you,
Petr
9 years, 3 months
Wiki page about blobs, proprietary kernel and firmwares
by Alexandre Moine
Hi all,
I write a article about firmware and blobs on my blog [1], where I
suggest the creation of a wiki page about blobs, proprietary kernel and
firmwares. I think it's really necessary, because I don't found any
information about the proprietary kernel and blobs in Fedora. If you
search, you can found some informations about firmwares (in the Legal
part of packaging). In my opinion, we need an official policy written
somewhere. So, I require your help to write this page because I don't
have the required informations, and official positions... But I can help
to write them :)
Chris Roberts volunteered to re-tag this page.
Thank you in advance,
Alexandre
9 years, 4 months
lutris
by Christopher Meng
Hi,
Lutris is a gaming platform for Linux, I'm not sure if such software
can be included in Fedora or not. The client is pure open sourced but
users may get non-free programs from it.
Can anyone help review it?
Thanks.
http://lutris.net/
--
Yours sincerely,
Christopher Meng
Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт.
http://cicku.me
9 years, 4 months
GPLv2+ library in AGPLv3 application
by Miro Hrončok
Hi,
I need someone to either support me on this or give me a reason why I'm
wrong:
There is a library, that is distributed under the terms of GNU General
Public License, version 2 or any later version.
And then there's an application, that uses (either dynamically or by
copying it's source) the library. The app is distribute under the terms
of GNU Affero General Public License, version 3.
From the information that I found GPLv2 and AGPLv2 are incompatible
trough they are almost the same.
While in GPLv3 there is a section 13, that allows the software (in this
case our library) to be linked or combined in the final product with
AGPLv3 licensed software, the result being (re)distributed as AGPLv3.
http://www.gnu.org/licenses/gpl.html#section13
The library having the "or any later version" used, I might chose to
redistribute it as GPLv3 and therefore everything is fine.
Also, form section 13 it seems that there is no difference if I link or
copy the software.
It would also be a good idea to add AGPL here:
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#GPL_Compatibil...
Thanks.
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9 years, 4 months
Google compute engine + trusted testers
by Sam Kottler
Greetings legal@,
I've been working on the behalf of the cloud WG to get Fedora images built for Google's new compute engine platform. As part of this work, Google has asked interested people (Red Hat employees or not) to join their 'trusted tester' program. Here's the program described by Google: 'As a Google Trusted Tester, you can be part of an exclusive group that helps improve our products by providing candid feedback and identifying problems before anyone else gets to use them.' This allows people working on the images to get access to more advanced features of GCE to upload and test them using features that might not yet be available. I have the full document if anyone is interested in seeing it (I'm weary of publishing the whole thing to this list), but the gist is that it's a confidentiality agreement and indemnification/limitation of liability document.
So...is it permissible to ask Fedora contributors to sign this document? I'm happy to provide any additional information or connect a representative of the legal team with contacts at Google.
-Sam
9 years, 4 months
Allowed content in Copr
by Miroslav Suchý
Hi,
can someone please check:
https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr
(section What I can build in Copr?)
I write there someting reasonable for me, but you know IANAL.
Just to clarify:
* Copr is run in Fedora Cloud, so those packages reside in Fedora
infrastructure.
* No one but owner of project (and people which he allow to) will be
modifiing packages. I.e. no proven packagers like in Fedora.
Mirek
9 years, 4 months
