legal July 2012

legal@lists.fedoraproject.org

11 participants
12 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

Leptonica license
by Ding Yi Chen 31 Jul '12

31 Jul '12

HI, I am going to pack leptonica (http://www.leptonica.com/) with the license http://www.leptonica.com/about-the-license.html It is somewhat different from ASL 2.0 What license should I use? -- Ding-Yi Chen Software Engineer Internationalization Group DID: +61 7 3514 8239 Email: dchen(a)redhat.com Red Hat, Asia-Pacific Pty Ltd Level 1, 193 North Quay Brisbane 4000 Office: +61 7 3514 8100 Fax: +61 7 3514 8199 Website: www.redhat.com Red Hat, Inc. Facebook: Red Hat APAC | Red Hat Japan | Red Hat Korea | JBoss APAC Twitter: Red Hat APAC | Red Hat ANZ LinkedIn: Red Hat APAC | JBoss APAC

1 0

Guidelines clarification - including additional license texts
by Mikolaj Izdebski 27 Jul '12

27 Jul '12

Hello, Some upstreams don't make source code releases. Instead they just provide access to source code repositories from where package maintainers can make their own tarball and use them to build SRPMs. Often these repositories don't contain anything except the minimal set of source files and build scripts, without any license files or documentation of any kind. This is especially true in Java world, where users are expected to use binaries built by upstream developers and not rebuild the software on their own. The problem arises when the license under which the software is redistributed requires a copy of the license to be shipped with any copies or derivative works of the software. Upstream doesn't have to do that because they are the copyright holders, but still the requirement for Fedora maintainers remains. A copy of the license must be included in RPMs in order for the package to be redistributable without violating the license terms (sometimes only binary in RPM, in some cases both SRPM and binary RPMs). Licenses that require including their texts with all derivative works include some widely used licenses like ASL 2.0, EPL, BSD and MIT. Some package maintainers don't include separate copies of license files because they believe this would be against the Licensing Guidelines. I would ask you to clarify the Guidelines to explicitly allow including separate license copies in cases that it is required, like the case mentioned above. Thank you, Mikolaj Izdebski

2 1

Could someone review erlang-sext?
by Peter Lemenkov 26 Jul '12

26 Jul '12

Hello All. There was a concern regarding legal status of a couple of source files which are distributed w/o explicit licensing term. I rewrote them completely while maintaining the original API and licensed the resulting work under MIT. https://bugzilla.redhat.com/show_bug.cgi?id=652648 Could someone please make a legal review of the current situation? If MIT isn't ok then I can relicense it under a different license - that's not an issue. -- With best regards, Peter Lemenkov.

1 0

Expanding binary firmware exceptions (slightly)
by Tom Callaway 24 Jul '12

24 Jul '12

I don't normally do this, but I'd like to propose a draft for public feedback before asking the Board to decide on it. There are two tiny holes I would like to add for expanding the binary firmware exception in Fedora: == QEMU ROMs == Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package. == ARM Firmware == Whenever possible, firmware that enables ARM devices to boot a Fedora OS (specifically, its Linux kernel) must be built from source and packaged normally. However, some ARM devices (e.g. Raspberry Pi) require proprietary firmware images to boot a Fedora OS (specifically, its Linux kernel). In these specific cases, an exception to include these firmware images in Fedora packages (and Fedora composed ARM images) is granted, as long as they meet the following requirements: * The files are non-executable within the Fedora OS context. (note: this means that the files cannot run on their own within Linux, not that they are just chmod -x). * The files are not libraries, within the Fedora OS context. * The files are standalone, not embedded in executable or library code (within the Fedora OS context). * The files must be necessary to enable Fedora to boot on a specific device. If other reliable and supported mechanisms exist which would not require this binary exception, then this exception does not apply. * The files are available under an acceptable firmware license (as previously defined for Binary Firmware), which is included with the files in the packaging. Files handled under this exception must use the same license tag as other binary firmware. ARM firmware packages must be named <foo>-firmware, where <foo> is the type of ARM device(s) that the firmware is intended for. ***** Thoughts? ~tom == Fedora Project

1 0

Re: [Fedora-legal-list] Packaging oVirt generated source
by Tom Callaway 24 Jul '12

24 Jul '12

On 04/23/2012 12:18 PM, Yaniv Dary wrote: > > > ----- Original Message ----- >> From: "Juan Hernandez" <juan.hernandez(a)redhat.com> >> To: "Yaniv Dary" <ydary(a)redhat.com> >> Cc: "Tom Callaway" <tcallawa(a)redhat.com>, legal(a)lists.fedoraproject.org >> Sent: Monday, April 23, 2012 7:01:22 PM >> Subject: Re: [Fedora-legal-list] Packaging oVirt generated source >> >> On 04/23/2012 05:20 PM, Tom Callaway wrote: >>> On 04/23/2012 10:50 AM, Juan Hernandez wrote: >>>> We would like to package for fedora the Data Ware House component >>>> of >>>> oVirt, which contains parts generated using Talend Open Studio >>>> (see [1]). >>>> >>>> This tool allows the user to define graphically some data flows >>>> and >>>> transformations and then generates Java code. The generated Java >>>> code >>>> states in the header that the license is LGPL and the tool itself >>>> claims >>>> to be open source using GPL v2 (see [2]). >>>> >>>> Is it acceptable from the legal point of view to create a Fedora >>>> package >>>> using the generated Java code as the source? After review with Red Hat Legal, code generated using Talend Open Studio that is explicitly licensed as LGPL is acceptable for inclusion in Fedora. Apologies for the extreme delay in responding to this issue. ~tom == Fedora Project

2 1

Gecode license
by Julian C. Dunn 24 Jul '12

24 Jul '12

I'm considering packaging Gecode for Fedora. The license seems pretty simple but I thought I'd run it by the Legal list first. What do you think? http://www.gecode.org/license.html - Julian [ Julian C. Dunn <jdunn(a)aquezada.com> * Sorry, I'm ] [ WWW: http://www.juliandunn.net/ * only Web 1.0 ] [ gopher://sdf.org/1/users/keymaker/ * compliant! ] [ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9 ]

2 1

missing ec and ecparam commands in openssl package
by Valent Turkovic 19 Jul '12

19 Jul '12

Hi folks at Fedora legal team, please give us a comment regarding missing ec and ecparam commands in openssl package in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=319901 Cheers, Valent.

4 5

OSGi Enterprise licensing
by Marek Goldmann 12 Jul '12

12 Jul '12

Most probably we'll need to package OSGi Enterprise, but I'm not sure about licensing of this project. The code itself (included in the.jar file, another story...) is ASL 2.0, but if you try to download it from the website, you need to agree to this: http://www.osgi.org/Download/Release5?info=nothanks Which is no more, no less OSGi Specification License, listed as bad license on the wiki: http://fedoraproject.org/wiki/Licensing#Bad_Licenses You can also download it directly, without the need to agree to the license on the website: http://www.osgi.org/download/r4v42/osgi.enterprise.jar http://www.osgi.org/download/r5/osgi.enterprise-5.0.0.jar How should we deal with it? Are we authorized to package it under ASL 2.0? Thanks! --Marek

1 0

New license for imapsync
by Nick Bebout 09 Jul '12

09 Jul '12

imapsync has changed its license from WTFPL to the following: http://imapsync.lamiral.info/COPYING Can I get guidance on what license tag to use for this? NO LIMIT PUBLIC LICENSE Version 0, June 2012 Gilles LAMIRAL La Billais 35580 Baulon France NO LIMIT PUBLIC LICENSE Terms and conditions for copying, distribution, modification or anything else. 0. No limit to do anything with this work and this license.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal July 2012