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. :)
I'm trying to get certification for a new license which is newly written
Can you point me where to start
Thanks in advance
Tareq Al Jurf
Riyadh, Saudi Arabia
I was looking at the some of the dependencies generated by AutoReqProv
in the RPMS in Fedora 11 and I noticed the following:
provided-by: nspluginwrapper (gplv2+)
provided-by: readline (gplv2+)
How is this possible? I don't think EPL or PHP licenses are allowed
to dynamically link to GPLV2+ libraries.
I see that neither of these dependency problems exist in RHEL 5.4
(eclipse-swt is known as libswt3-gtk2 in RHEL 5.4).
ps. I'm a B.Sc. student doing a research project on licensing
problems in open source linux distros, so I'm excited to see if my
techniques have actually found some real life licensing problems.
The strict GPLv2 in packet-dlm3.c is coming from this:
* #defines are mostly copied from
* *.[ch] files in linux/fs/dlm/ and linux/include/linux/dlm.h
** Copyright (C) Sistina Software, Inc. 1997-2003 All rights reserved.
** Copyright (C) 2004-2005 Red Hat, Inc. All rights reserved.
** This copyrighted material is made available to anyone wishing to use,
** modify, copy, or redistribute it subject to the terms and conditions
** of the GNU General Public License v.2.
rsync's RPM says it is gplv3+.
The rest of the source is mostly GPLv3+ with some ZLIB.
The "maketree.py" file doesn't seem too important. I ran it for fun
by just typing:
And now I have 688MB of randomly named files and directories under
/tmp/foo (420 directories, 8420 files). So I'm not really sure if the
fact "maketree.py" is strictly GPLv2 matters at all.
I'm planning to open a website about fedora.I think I have to sign TLA to
legalize this but I have no idea about how to do this...
I tried to connect with legal@fedor* they didn't replied to me
Can anybody give me some directions?
during a package review I've stumbled over the following problem:
- a package ships the following in its tarball:
a LGPLv2 library
a GPLv2+ main application
- the main application statically links the library and only the
resulting binary is shipped in the final rpm
If I interpret
correctly, the 2nd table should be consulted and so this mix is
acceptable and the license mentioned in the spec file should be GPLv2+
(since the resulting binary would have this license).
I'm a little bit unsure about:
- Does the fact, that the library is statically linked, affects the
compatibility or does the same rules apply as for dynamic linking?
- Since the LGPL sources would be in the src.rpm, do we have to mention
both licenses in the spec file?
Thank you very much in advance!
The new Fedora Wireless Guide includes photographs of different types of
In each case, the manufacturer's logos and/or (obviously) the design of
the hardware itself is visible in the photograph.
1. Are the manufacturer's labels on the hardware and/or the design of
the hardware itself (particularly the styling of the USB adapter in the
first picture) likely to be protected by copyright?
* Is our use of the image to illustrate a generic component of a
particular type likely to be covered by "fair use" for publication in
the United States?
* Is this protection likely to cause problems for people who want to
reuse our content? (I'm thinking in particular of places that have no
"fair use" or equivalent concept in their copyright law, or for reusers
who want to use the image in a completely different context) -- and if
so, do we care, or are reusers on their own here?
2. Could using specific pieces of hardware to illustrate a generic type
of hardware be construed to be an endorsement of this particular piece
of hardware or its manufacturer? If so, do we want to do this in our docs?