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, 7 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, 1 month
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
9 years
Source Requirements
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
A couple of questions.
1) can we please stop making source isos? the source is available in
the source tree.
2) cloud WG wants to be able to produce updates images, what are our
requirements to ensuring source compliance with the GPL?
Today the sources for livecds and appliance images are only in the
source tree and not separated out. if we do updates images some sources
will be in the base source tree and some in updates, however the
updates sources will go away if the package gets another update. the
only single source where we could point people at is koji.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJS+hz3AAoJEH7ltONmPFDR1icQAKhOvFziBsnYpi+wSYTGZUAH
++P1NeCQ4DKDz046kHJ5bGqw+IPNykwOP9RFKTx2v1ajAcMdvxWhR55+QextwHhn
b7lXE84mn+AM2uU64l+dVFireCi+Lh5XAVBO0aHGM5/olw/8DDuoVn+17O6ooaVr
mEQ/mGfjUDE+YDIIEcPjJ9HxkvQu3QDedayqThGfRZO4W8nLCBcAtCLm0kLC5Kv7
aVbRghC4wEKLU/PY7HzmlXla6GJfwZ024fE6qrZ6tyN6Rhn1x6xtT4WbU6GUDLKu
qZjUDX/p689VnH1PT+W9B0Oy9Z8TkfrtouxfoLVtzEThv3APE2K33H7MyrHS8ORy
ii1XHttX2bSmt92Wuj8ceY92oZk00wfTwJ4dUQj4ZQYQbyGAW31uymtiPwTUNTcw
3tgaSCeaI7w1W+dsyKcRVQyiau2WUojGhXdTf2r9dTuAuIGIJogg7iyhCDc45O3m
0u7snSxpYZ/jgpODC45sO/JvevYSD4vzCwFA4vW14jDKobCvLCiPt7atSI/uivwt
qO6TiiapgBCtkjYO98Pcqhu5x0xx7jS86iOi+D02hZGWx+7twsOaj6DyaZYuZyaf
sbonFLT0zejhcYgE+CAv+zPPeAKmapFZK7Gj3Kb3MWbxpwrWsyrTiy8MgFyp9wDl
9yFR9Bdcrpr+DhhF5KcR
=jifW
-----END PGP SIGNATURE-----
9 years, 4 months
Retaining old binaries and SRPMs vs package git
by Colin Walters
Hi,
My "OSTree" system which I'd like to deploy in Fedora treats operating
system binaries like git treats source code - they have a versioned
history. This is in contrast to the default mode of operation with RPM
and higher level systems like Koji which will garbage collect older
binaries that are not part of a release.
This rpm-ostree is not a new source-level build system - merely a new
representation of the binary RPMs.
Now, I want this system to be compliant with both the letter and spirit
of the GPL - you should be able to find the source for a given binary
that's included in the OSTree repository.
My understanding is that normally with yum/rpm as they are today, "rpm
-qf /usr/bin/bash" telling you the binary came from the bash package,
and then "rpm -qi bash" showing you the source RPM name, then finally
locating the bash-$version.src.rpm provided from e.g.
http://koji.fedoraproject.org/koji/buildinfo?buildID=482681
is sufficient.
With OSTree, I may not even include rpm inside the composed tree (the
system shipped to users) - in that case, I include the output of "rpm
-qa". While the file -> package mapping is not included in this model,
the source is available and provided by Fedora.
So that's my first question - do I need to include the file-level
mapping so one can go from binary -> package -> source package?
Second, Koji may garbage collect the RPMs and SRPMs, for an obsoleted
build, but rpm-ostree may retain the binaries.
Is the package git sufficient for this purpose? One can reconstruct
the SRPMs from that. Or would we need integration between Koji and
rpm-ostree to avoid having SRPMs garbage collected as long as they're
stored in the OSTree repository?
Thanks in advance for any advice or help!
9 years, 6 months
python ecdsa module
by Orion Poplawski
I'm looking to package this:
https://pypi.python.org/pypi/ecdsa
needed by python-paramiko-0.12.X.
It says:
This library provides key generation, signing, and verifying, for five
popular NIST "Suite B" GF(p) curves, with key lengths of 192, 224, 256, 384,
and 521 bits. The "short names" for these curves, as known by the OpenSSL
tool, are: prime192v1, secp224r1, prime256v1, secp384r1, and secp521r1.
Now from following the openssl discussions it appears that only selective
curves are being allowed in Fedora - and specific ones can be requested.
At the moment it appears that prime256v1, secp384r1, and secp521r1 are
operational in openssl, but that prime192v1 and secp224r1 are not. I've filed
https://bugzilla.redhat.com/show_bug.cgi?id=1067697 requesting that they be
enabled.
In the meantime, can I ship the python-ecdsa package as is? Do I need to
disable the prime192v1 and secp224r1 code in it first? Is removing it in a
patch okay, or do I need to ship a sanitized source tarball?
Thanks!
Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
9 years, 7 months
Requirements for an official Fedora account for Google Cloud Engine
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
The Cloud Working group would like to provide official Fedora images in
Google Cloud Engine[1] in addition to the ones we upload to
Amazon's EC2. What do we need to do to legally have an account that we
can use as the official source of Fedora provided images. I am concerned
with ensuring that all legal agreements are properly setup and signed.
I do not know if there is any other cloud providers that we wish to
automatically provide images to at this point.
Dennis
[1] https://cloud.google.com/products/compute-engine/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJS/LBmAAoJEH7ltONmPFDRtwQQALhAZWzCetj24MT84EhpAw30
oEUjvLv0HmgfsTbk8Bc/bFG+l8sZp0H1QUsHuit9lWrPIPbybZQwS8YKU6bhcOVY
N3wgUDGY3E3SGpS78RNuGiB9MxYbwYpBskQwfFbXzPvGjWWH9JN3RMmOP1/solaT
ZUsbpGhExhp2BwLFKTV/RIMXpOdqC8RKe67eQpbwfv769HbPiVnhQimax7v9wvVb
BMstmXq1oOAuifIyQ+1eihWxuLe1zaysey9ORgM/9+VItfqsAWJWzCbgs4vAyNcU
0wvP1dkFcdk+jojaWbqyeVDM6DkE+R8YFZf25HM3FNGkbAtUKy6HPMBBPElYew40
/q0opGz+y6mQ0tH1iPqmhyIqECdQtWKBFfNkfm4yi2q+NaEYWse9R4WQZOiTSEBL
4j0ijOJvoUHFBW4NOY/oPIbovq6PNtrqDAyF9I3+OkbVqdxIVlwZ+zYgJWSRe4kN
VVgyNvSyU7aKoVRzqiuo3/uOgfg9QrEPX2saCjVAXgFHzAlOJ6yq28qH9ub5XrY7
2kh/FnndejW15D2M36DHqr6iBoKkw6RDtheXiDbL2bmtfBOCMg963bGYqRvQSZsj
KITimtVi/J48W07FKGXPBeOhnf1QiDyFHK1t4PZv0lrBLhdqN5dEI1iTatQiaeHu
yOHk4dEjLBfUVgcs2y8H
=LUHZ
-----END PGP SIGNATURE-----
9 years, 7 months
Use of IBM AIX logo
by Lukas Zapletal
Hello,
in our open-source project Foreman we use various Linux distro icons,
example screenshot:
http://theforeman.org/static/images/screenshots/host_listing.png
Now, we have a patch from our community which adds support for IBM AIX
UNIX and it was coming with logo created from the official graphics:
http://www.recarta.co.uk/sites/default/files/images/ibm-aix-logo_0.jpg
(This is just a random copy returned by Google)
We have removed that from the patch and accepted it without the provided
logo for now, it was apparently resampled (smaller) version of the
official IBM logo.
Now, there is quite strict trademark policy by IBM which explicitly
disallows the use of their logos:
http://www.ibm.com/legal/us/en/copytrade.shtml
On the other hand, they allow "fair use" to some degree, which is not
explicitly specified in that document. Can be icon of that (small) size
considered as "fair use"?
It is legal to draw similar logo in GIMP (blue circle, green filling
with "AIX" in white) and then scale that down to size of an icon and use
that in our software?
If not, do we have any other options? I guess the second option could be
to create similar logo which would be different from the one presented
(different colors, font maybe). What kind of changes is considered as
different enough?
To be clear, Foreman is not yet in Fedora, but we are planning to
include it as all our dependencies get accepted. It's a long process, we
provide Fedora repositories with our software for now.
Thanks for help and happy New Year all!
--
Later,
Lukas "lzap" Zapletal
irc: lzap #theforeman
9 years, 7 months