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
Leptonica license
by Ding Yi Chen
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
11 years, 2 months
Guidelines clarification - including additional license texts
by Mikolaj Izdebski
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
11 years, 2 months
Could someone review erlang-sext?
by Peter Lemenkov
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.
11 years, 2 months
Expanding binary firmware exceptions (slightly)
by Tom Callaway
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
11 years, 2 months
Re: [Fedora-legal-list] Packaging oVirt generated source
by Tom Callaway
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
11 years, 2 months
New license for imapsync
by Nick Bebout
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.
11 years, 2 months
