legal May 2017

legal@lists.fedoraproject.org

13 participants
9 discussions

Sleepycat license with SaaS restriction
by Florian Weimer 08 Jul '25

08 Jul '25

cryptlib is licensed under the Sleepycat license with a SaaS restriction: “Note that decoupling the software from the user, for example by running in a SaaS configuration, does not exempt you from these requirements.” (Full text attached.) This was not part of the original Sleepycat license, so a new license tag is required. Maybe this license is not even free; this additional clause seems to be a restriction on use. But perhaps it is not so different from the AGPL. Thanks, Florian

6 8

Henry Spencer's license
by Petr Šabata 06 Mar '23

06 Mar '23

Dear legal, While checking the contents of our `perl' package, I noticed the following: (...) /* NOTE: this is derived from Henry Spencer's regexp code, and should not * confused with the original package (see point 3 below). Thanks, Henry! */ /* Additional note: this code is very heavily munged from Henry's version * in places. In some spots I've traded clarity for efficiency, so don't * blame Henry for some of the lack of readability. */ /* The names of the functions have been changed from regcomp and * regexec to pregcomp and pregexec in order to avoid conflicts * with the POSIX routines of the same names. */ (...) * pregcomp and pregexec -- regsub and regerror are not used in perl * * Copyright (c) 1986 by University of Toronto. * Written by Henry Spencer. Not derived from licensed software. * * Permission is granted to anyone to use this software for any * purpose on any computer system, and to redistribute it freely, * subject to the following restrictions: * * 1. The author is not responsible for the consequences of use of * this software, no matter how awful, even if they arise * from defects in it. * * 2. The origin of this software must not be misrepresented, either * by explicit claim or by omission. * * 3. Altered versions must be plainly marked as such, and must not * be misrepresented as being the original software. * **** Alterations to Henry's code are... **** **** Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, **** 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 **** by Larry Wall and others **** **** You may distribute under the terms of either the GNU General Public **** License or the Artistic License, as specified in the README file. (...) You can see the whole file here: https://metacpan.org/source/SHAY/perl-5.20.1/regexec.c I looked but couldn't find any common name for this license of Henry's. Is it on our list? Is it free? What name should I use in the License tag? Thank you, Petr

5 9

any blockers for mjpeg based applications?
by James Hogarth 23 May '17

23 May '17

Hi, I don't see any references to mjpeg blockers in the Fedora wiki from an initial search, but out of an abundance of caution I wanted to get a confirmation on the legal list before carrying out this package review: https://bugzilla.redhat.com/show_bug.cgi?id=1445923 The application produces an MJPEG stream, is there any legal blockers for this or is it okay to package in Fedora? James

2 1

Adopt Debian-style 'common licenses' convention?
by Richard Fontana 09 May '17

09 May '17

Debian and at least some of its derivatives have long had a requirement that each package have a so-called "copyright file" which among other things is supposed to contain "a verbatim copy of its copyright information and distribution license". However, for certain widely-used licenses, copies are not bundled with individual packages, but instead a systemwide copy of each is installed in /usr/share/common-licenses. These include, from what I gather, the Apache License 2.0, some version of the Artistic License, each extant version of the GPL and LGPL, and (oddly) certain versions of the GFDL. I've been thinking recently that Fedora, and the derivatives of Fedora maintained by Red Hat engineers, would benefit from adopting a similar approach, though I wouldn't suggest using an identical set of licenses. I had a conversation with Neal Gompa yesterday and got the impression he did not consider this to be an entirely crazy idea. I have some concerns about the current Fedora practice of installing certain individual package license files (including license files that appear in thousands if not tens of thousands of Fedora packages in identical form) in /usr/share/licenses and think this particular Debian practice might be a marginal improvement in certain respects. Any thoughts on this idea? Richard

6 6

fedora packaging: Inclusion of license(s) in fedora packages
by Siddharth Sharma 06 May '17

06 May '17

Hi, If a project source code contain license files we need to include those files using %license macro. If package splits into multiple packages then which sub package must have license files ? It might be confusing so I will try to explain scenario. Usually when devel package is installed it installs main package with it. So whenever user install main package or devel package they get license files by default if included in main package. But for example if a package splits into main, libs, and devel package and user can just install libs package without actually installing devel and main package then at that point code is distributed without license. What needs to be done in such cases ? Is it required to embed license in each sub-package ? Siddharth Sharma

2 2

Viagra. For an active life. Buy at our store.
by Kevin 05 May '17

05 May '17

1 0

mp3 patents + encoding in Fedora
by Neal Gompa 05 May '17

05 May '17

Hey, I just saw that Technicolor has terminated its mp3 patent licensing as of April 23[1]. Would this potentially mean we can start having mp3 encoding in Fedora now? [1]: https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html -- 真実はいつも一つ！/ Always, there's only one truth!

2 1

vagrant-hostmanager-1.8.6 license change: MIT → MPLv2.0
by Randy Barlow 05 May '17

05 May '17

vagrant-hostmanager has changed its license from MIT to MPLv2.0 with version 1.8.6: https://github.com/devopsgroup-io/vagrant-hostmanager/compare/v1.8.5...v1.8… Due to this, I only plan to release 1.8.6 on Rawhide[0]. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1447820

1 0

Re: License of jnlp-servlet.jar - part of Oracle JDK
by Mark Wielaard 01 May '17

01 May '17

Hi Dalibor, [It seems the fedora legal list somehow dropped your response, so keeping on CC.] On Thu, 2017-04-27 at 10:31 +0200, dalibor topic wrote: > the issue has been marked as resolved. Thanks. Apparently some legal issues do indeed take years to resolve :) But nice to see the license text being clarified now. > After downloading 8u131 demos and samples from > http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133… > I took a quick look at some of files and they seemed fixed. Yes I couldn't find the "nuclear facility" clause anywhere anymore in http://download.oracle.com/otn-pub/java/jdk/8u131-b11-demos/d54c1d3a095b4ff… And the "Oracle BSD License" now seems to simply be the standard BSD license without any extra terms. Do note that there are still files (all under sample/jnlp/ except for the GNUmakefile) that refer to SUN in the disclaimer text (instead of ORACLE or leaving the company name out). But I assume that is fine. Thanks, Mark > cheers, > dalibor topic > > On 18.11.2013 18:55, Dalibor Topic wrote: > > On 11/13/13 5:39 PM, Dalibor Topic wrote: > >> On 11/13/13 10:37 AM, Mark Wielaard wrote: > >>> Hi all, > >>> > >>> I added Dalibor from Oracle to the CC, who has been helpful cleaning up > >>> some license issues around java in the past. > >> > >> As Tom said [0], filing a bug in the bug tracker is the way to go. I'll track down > >> the owner of the file, and let you know what the bug ID is once I've done that. > > > > I filed an issue, it's available at https://bugs.openjdk.java.net/browse/JDK-8028538 . > > > > cheers, > > dalibor topic > >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal May 2017