legal February 2014

legal@lists.fedoraproject.org

12 participants
11 discussions

Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway 12 Feb '16

12 Feb '16

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

4 6

winetricks
by T.C. Hollingsworth 01 Aug '15

01 Aug '15

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

5 7

Linking of GPL-only and GPL-incompatible libraries
by Florian Weimer 25 Aug '14

25 Aug '14

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

3 12

Modified version of ASL 2.0
by Parag Nemade 30 Jun '14

30 Jun '14

Hi, I want to know if this http://code.google.com/p/impacket/source/browse/trunk/LICENSE is a valid license which is modified version of ASL 2.0 license. Regards, Parag.

4 5

Source Requirements
by Dennis Gilmore 12 May '14

12 May '14

-----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-----

3 7

Retaining old binaries and SRPMs vs package git
by Colin Walters 10 Mar '14

10 Mar '14

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!

3 3

python ecdsa module
by Orion Poplawski 20 Feb '14

20 Feb '14

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

2 1

Requirements for an official Fedora account for Google Cloud Engine
by Dennis Gilmore 19 Feb '14

19 Feb '14

-----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-----

2 1

Use of IBM AIX logo
by Lukas Zapletal 14 Feb '14

14 Feb '14

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

4 5

Time::ParseDate license clarification
by Denis Fateyev 09 Feb '14

09 Feb '14

Hello there, I'm planning to package Time::ParseDate [1] Perl module for Fedora, but still unsure about its license acceptability [2]. *"Copyright (C) 1996-2010 David Muir Sharnoff. Copyright (C) 2011 Google, Inc. License hereby granted for anyone to use, modify or redistribute this module at their own risk. Please feed useful changes back to cpan(a)dave.sharnoff.org <cpan(a)dave.sharnoff.org>."* Can it be considered a good license? If yes, which name or designation should I put into package's License tag since there is no Google or such style license in the allowed list [3]? Thanks, --- wbr, Denis. [1] http://search.cpan.org/~muir/Time-ParseDate-2013.1113/ [2] http://search.cpan.org/~muir/Time-ParseDate-2013.1113/lib/Time/ParseDate.pm… [3] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal February 2014