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
Hi,
php-channel-* packages only provides 1 repository configuration file
which is available from web, ex:
http://pear.phpqatools.org/channel.xml
For now License is often taken from the packages provided.
Ex php-channel-phpunit is "BSD" because all packages provided in the
phpunit channel are BSD.
Some are "Public Domain"
Ex : php-channel-horde, because provided packages are released under
various licenses (BSD, MIT, GPL, ...).
Shouldn't all the php-channel-* set as "Public Domain" ?
In this case, I will add a small note in the PHP Guildelines.
Thanks,
Remi.
Hello, legal. I'd like some advice, please.
I maintain the jemalloc package for Fedora and EPEL. To make it compile
on EPEL5/POWER, I need a patch for 32bit atomic operations on ppc. I
found one in the Boost library (Boost license), but some googling
discovers it actually originates from apr (Apache license). jemalloc is
distributed under the BSD license
I'm unsure on how compatible the BSD and Apache licenses are.
Could I just add the patch and a few extra lines to COPYING with %ifarch
ppc ppc64, %if 0{?rhel} == 5, mentioning the Apache license and the
patch for that platform?
Note that the patch is no longer needed in epel6 and fedora. I guess
modern versions of gcc provides the missing atomic stuff.
I have contacted jemalloc upstream. Their comments suggest that this is
a non-issue, that is, that the code in question is too specific to be
copyrighted with a license, since the number of ways to implement atomic
operations for a specified cpu are very limited, and all the sketched
implementation examples floating around use more or less the same
algorithm.
Patch and short discussion starts here:
http://www.canonware.com/pipermail/jemalloc-discuss/2012-March/000136.html
I also contacted apr upstream. The initial commit of the code was done
by Greg Ames, http://marc.info/?t=101356337500001&r=1&w=2 . He pointed
me to the latest version, and told me to use it while adding the Apache
License, and added "I think you'll find that the Apache license is very
compatible with the BSD license."
PS: Note that Greg's initial commit preceeds the one copy-pasted into
the Boost library, so if this actually is an issue, Boost (or the Boost
maintainer in Fedora?) should check out this as well.
Ingvar
On Tue, May 15, 2012 at 08:30:56AM -0400, Kaleb Keithley wrote:
>
> I presume that because this looks like a BSD (no advertising clause) license that it would be okay to include as "contrib" code with Gluster.
Yes, as noted by Emmanuel Dreyfus this is the GPL-compatible 2-clause
BSD license.
> It's not in the Fedora Project list of {good|bad} licenses yet, hence the reason I'm also forwarding to legal(a)fp.o.
The FreeBSD variant is listed
https://fedoraproject.org/wiki/Licensing/BSD#2ClauseBSD
It includes a sort of disclaimer of opinion at the end. Perhaps Fedora
should list a more generic version of the 2-clause BSD license as the
example, or should list one separately.
- RF
>
>
> ----- Forwarded Message -----
> From: "Emmanuel Dreyfus" <manu(a)netbsd.org>
> To: kkeithle(a)redhat.com
> Cc: "Gluster Build System" <jenkins(a)build.gluster.com>
> Sent: Tuesday, May 15, 2012 7:51:38 AM
> Subject: Re: Change in glusterfs[master]: Provide missing basename_r and dirname_r
>
> Kaleb KEITHLEY (Code Review) <root(a)dev.gluster.com> wrote:
>
> > It's misleading to say these are FreeBSD's thread-safe functions.
> > FreeBSD's implementations aren't thread-safe. A more accurate
> > description is that these are thread-safe implementations derived from
> > FreeBSD's implementations.
>
> What about adopting Android flavor? It is 2 clause BSD and does not use
> pthread stuff. I suspect it will be better performance-wise.
>
> http://www.netmite.com/android/mydroid/bionic/libc/bionic/basename_r.c
> http://www.netmite.com/android/mydroid/bionic/libc/bionic/dirname_r.c
>
> --
> Emmanuel Dreyfus
> http://hcpnet.free.fr/pubz
> manu(a)netbsd.org
>
Hello,
Many Fedora-approved software licences require binary distributions to include the license text along with the software. For example the family of BSD licenses says that "redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution" and ASL 2.0 says that "You must give any other recipients of the Work or Derivative Works a copy of this License". My understanding is that in case of Fedora redistributing a copy of the license along with RPM package is a prerequisite for redistributing it al all.
In some cases the upstream itself doesn't redistribute the copy of the license. From technical point of view it's fine because they are copyright holders and therefore they can do whatever they want with the software they have rights to. In some other cases the upstream is providing source code only and source distribution doesn't require including the text of the license.
Fedora Licensing Guidelines says: "if (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc". This can cause problems in some cases.
My questions are:
1. According to Fedora Licensing Guidelines, is it prohibited to include the text of the license within the binary RPM package if the source package does not include the text of the license?
2. Isn't redistributing binary RPMs without the license text included (in case the license requires that) considered as violation of the license?
3. What is the proper way of handling the case when upstream is rejecting requests to include the license text in their distribution, while they are requiring Fedora to include it?
(An example of an affected package is annox, which is currently in its review process: https://bugzilla.redhat.com/show_bug.cgi?id=808768)
Thank you,
Mikolaj Izdebski
Red Hat
Hello,
I am in the process of packaging up a JMapViewer [1], the
JMapViewer_src.jar inside of the release zip [2] file includes a little
bing.png which is used by some functions.
I already contacted upstream and there is no problem removing those
functions altogether, since it is fairly modular. I also already removed
the png and all relevant pieces of code in accordance to this guide [3],
since I thought it is appropriate in this case.
I just wanted to know if this is unnecessary and there is no problem in
shipping this picture or if the removal is right.
I hope I didn't forget anything,
Johannes
[1] http://wiki.openstreetmap.org/wiki/JMapViewer
[2]
http://svn.openstreetmap.org/applications/viewer/jmapviewer/releases/2011-0…
[3]
http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohib…
What is the current situation with MP3 allowance in Fedora? I thought
2012 was the year when we could -at least- have not-patent-encumbered,
free MP3 _decoding_. Can you please update us on the latest status?
Thanks,
Orcan