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. :)
winetricks  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  and say that it
might be eligible for Fedora, so we'd like confirmation one way or the
I wanted to package UROnode, it seemed to be GPLv2+ licensed amateur radio
software (mirror ), but I came across the following weird text in the
package (in addition to the GPLv2 text):
> URONode is free to use around the globe with the exception of:
> anywhere in or by the Commonwealth of Massachusetts
> anywhere in or by the Commonwealth of Pennsylvania
> Because of their tactics, any of my software is not to be used in these two
> states. Your cooperation is appreciated..
> - N1URO
can be such package included in Fedora?
thanks & regards
I'm trying to sort out the license tag for rubygem-posix-spawn. This
package has a function that's copied from glibc. As explained in the
A small portion of the environ dup'ing code in ext/posix-spawn.c
was taken from glibc <http://www.gnu.org/s/libc/> and is maybe
Copyright (c) 2011 by The Free Software Foundation or maybe
by others mentioned in the glibc LICENSES file. glibc is
distributed under the terms of the LGPL license.
>From what I understand, this makes rubygem-posix-spawn dual-licensed
under the MIT and LGPL licenses, right?
I've opened a ticket upstream, and I'm not sure how to respond to
https://github.com/rtomayko/posix-spawn/pull/44 the author's comment
about the block glibc code being de minimis.
To summarize, should rubygem-posix-spawn have a License tag of "MIT
and LGPL", or just "MIT" ?
SDCC ("sdcc" RPM) source package ships with a "device/non-free"
hierarchy. Its header indicate that it's generated from files with usage
restriction and thus can not be distributed under the terms of GPL.
The files are (mainly?) hardware descriptions -- addresses of memory
locations, their symbolic names and eventually bit field definitions
with symbolic names of the bits. I believe they're absolutely essential
for interoperability with other (proprietary) tools.
Here's an example, for a single supported device:
I am not actually sure whether the notice in the header is correct,
whether the definitions in question are copyrightable and would like a
lawyer opinion on that. (I'm also not sure whether the court decision on
Oracle v. Google case about Java API is relevant in this context.)
If the code in question is in fact non-free what would be the proper way
of creating free equivalents? Reading the existing code and datasheets
and writing down the symbols? Would processing them automatically do?
Also, maybe we ought to remove it from the source package as well in