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
8 years, 2 months
xBill legal opinion required
by Andrea Musuruane
Hi all,
I'd like to now if xBill is suitable for inclusion in Fedora:
http://www.xbill.org/
License, as stated in the man entry, is GPL (no version specified).
My concerns regard the use of various logos in the game.
Also note that this game has been packaged until 2001 in Red Hat.
Regards,
Andrea Musuruane.
15 years, 2 months
policy on shipping/using flags
by Roozbeh Pournader
I recently found that Deluge is using country flags to indicate the
location of bittorrent peers. Flags are cute and nice of course (and a
mental exercise), but are geopolitical hot spots.
Upstream didn't like the concern, calling some people (including me?)
"crazy ideologists". But the Fedora maintainer (Peter Gordon) fixed
the bug in Rawhide (but we're still shipping flags in F9 and F10):
https://bugzilla.redhat.com/show_bug.cgi?id=479265
But this is not why I'm writing. I'm writing because during the
report, I found that we really don't have any official policy on
flags. All I found in the wiki was what I had written myself a while
ago, here, which is just based on my own experience as an i18n guy:
http://fedoraproject.org/wiki/Languages#I_wish_to_use_my_country.27s_flag...
But we really need a policy. And I thought this list is the best forum
to get it into shape. The history is like this: With RHL 8.0, Red Hat
decided to remove the Taiwan/Republic of China flag from KDE because
of sensitivities/legal requirements of mainland/People's Rebublic of
China. That created some public unease, including people stopping to
use RHL because of that. Red Hat went a bit further of course, and
removed all national flags in a later version.
This is not restricted to Red Hat of course. Microsoft is usually in
the spotlight for such geopolitical concerns:
On geopolitical issues resulting in a worse user experience for
timezone selection:
http://blogs.msdn.com/oldnewthing/archive/2003/08/22/54679.aspx
On swastika symbols in Japanese fonts causing user outrage (the
characters were in Unicode at U+534D and U+5350):
http://www.microsoft.com/presspass/press/2003/dec03/12-12FontLetter.mspx
These questions remain. Sorry for being a bit forward looking, but I
would hate to revisit the issue later:
* What is the exact policy for Fedora? Why? Is it because of Red Hat's
liability or is there other reasons too?
* How serious is shipping flags? Should they be removed as soon as
they are discovered? For example, should Deluge remove them from F9
and F10 as well?
* Should country flags be avoided at all costs, or is it just the
association of countries/territories/languages with flags that should
be avoided? For example, is it OK to use an icon showing three flags
(of say, US, Italy, and France) to indicate a locale/language
selection application?
* What about organization/regional/political/historical/religious/linguistic
flags? Examples: UN's flag (presently used as the default icon for
System > Administration > Language in F10), Mississippi's flag, the
LGBT flag, Hezollah's flag, the Confederate flag, the Jain flag, the
Nazi flag, the Tibet flag, and the Esperanto flag. All of these could
be controversial.
* What about political symbols (including the stuff you see in coats
of arms or in the middle of flags)? For example, is it OK to use the
lebanese cedar to refer to an input method for Lebanese Arabic or use
the Tajikistani crown to refer to the Tajik language?
* What about flags used for edutainment purposes? For example, is it
OK to ship an educational game that teaches kids about country flags
or historical flags? Is it OK to use a flag for country/language
selection in a game UI to be used by kids who can't read yet (but may
be able to recognize flags for their country/language)?
* Presently, the Unicode consortium is considering a proposal to
encode various symbols (called emoji) used in Japanese cellphones in
the Unicode Standard. This very large set includes flags of a few
countries, like the flag of the People's Republic of China:
http://www.unicode.org/~scherer/emoji4unicode/snapshot/utc.html#e-4E5
[warning: hundreds of small icons on the page]
>From what I can tell, the proposal has a very high chance of
acceptance, and those flags will become Unicode characters. When fonts
we ship start to include glyphs for such flags, what do we do? Do we
remove them from the fonts when shipping them?
Thanks for reading until here,
Roozbeh
15 years, 2 months
scid legal opinion required
by Mikhail Kalenkov
Hi all,
I'd like to know if scid is suitable for inclusion in Fedora
http://scid.sourceforge.net/
License, as stated in the COPYNG file, is GPL. Tarball includes some
nonGPL staff
(opening books) that can be removed without great losses to package.
But also scid includes some nonfree (?) Nalimov code which is
important for me. File COPING says about Nalimov code the following
************************
Please note: although there is no explicit copyright notice in the
tablebase decoding code, all rights are reserved by its author
Eugene Nalimov and you should ask for permission before using it.
He has granted permission for its distribution in Scid, and out of
courtesy I ask that if you make use of the tablebase code outside
of Scid, please ask Eugene first. His email address is at the end of
the file src/egtb/probe.txt.
************************
What do you think about Nalimov code? I am sure that this code is not
accepted in Fedora, but RPMFusion guys asked me to clarify that
question here.
Mikhail Kalenkov.
15 years, 3 months
Unalz: is there a patent issue?
by Orcan Ogetbil
Hi,
I submitted unalz for review two weeks ago [1]. This is a free
decompressor with zlib+BSD license for the commercial compressor Alzip
[2]. Therefore it needs to be clarified by FE-Legal if there's a
patent issue with this compression format or not (I couldn't find
any). I had blocked FE-Legal but it didn't catch attention yet. Can
anyone from FE-Legal confirm that we don't have any patent problems
with this?
Thanks,
Orcan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=480249
[2] http://www.altools.com/
15 years, 3 months
Re: [Fedora-legal-list] Legal issues with new font guidelines
by Tom Callaway
On 2009-01-28 at 10:08:01 -0500, "Nicolas Mailhot"
<nicolas.mailhot(a)laposte.net> wrote:
> If we start worrying about this we may as well refuse to package all
> the fonts that do not include full licensing information in their
> metadata, since nothing would stop the hypothetical third-party to
> re-distribute the font files without the detached license file anyway
> (regardless in which package we deploy it)
Apologies in advance, I read the original emails rather early this
morning, and my brain was not yet fully booted. :)
In addition, I had forgotten that each font package/subpackage in a
family requires the -common package, so in normal operation, there is no
way a font package installed would end up without the license also present.
As Nicolas points out, we're doing due diligence here to ensure that the
license is installed along with the font package in the normal, expected
method of installation. In addition, any Fedora spin will pull in the
appropriate -common package onto the distribution media (whether it is a
Live spin or not), so it is incredibly unlikely that someone would be
able to make a release with the licensing missing. In fact, the only way
they'd be able to accomplish this is by explicitly ignoring dependencies
or blocking the -common package (or installing with --nodocs), and all
of these could be construed as passing the responsibility for licensing
compliance from Fedora and on to the poor fool who decided to poke their
packaging structure with a sharp stick.
To sum it up: It is my opinion that it is not necessary to include the
font license in each font package/subpackage as long as it is present in
the -common package, and each of the font package/subpackages properly
Requires the -common package.
Roozbeh, thanks for pointing this out, and apologies for not thinking
this all the way through before replying initially.
~spot
15 years, 3 months
Legal issues with new font guidelines
by Roozbeh Pournader
Hi.
I was dutifully converting my font packages to the new guidelines,
when I ran into a possible legal issue.
For the sake of argument, let us assume a font licensed under OFL,
called Mardana. The upstream tarball has two families inside, Mardana
Sans and Mardana Serif, in TTF format. The text of the OFL license is
not included in the TTFs themselves, but in a separate text file in
the tarball. Actually, let's assume the TTFs themselves don't have any
copyright or licensing metadata.
According to the new font packaging guidelines, there would be three
packages, mardana-fonts-common, mardana-serif-fonts, and
mardana-sans-fonts. All documentation related files will be in
*-common, and all the actual TTFs would be in *-sans-* and *-serif-*.
So, someone finds about the fonts, wants to use them on Windows,
searches for them, and finds our binary RPM for Mardana Sans, and
downloads it. She then opens it with some tool and installs it on her
machine.
But that's a license violation by us:
"2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. These can be
included either as stand-alone text files, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user."
But we are not providing any copyright notice or license in our binary
RPM, that is supposedly the "software" that that Font Software is
bundled with. All we say, is two pointers: "OFL" in the RPM license
tag, and "mardana-fonts-common" in the requires tag.
Of course, if the user really wants to, she can investigate the binary
RPM, and find pointers to the actual license, and go and find the
license. But we would not be redistributing the license with "each
copy".
Please enlighten me.
Roozbeh
15 years, 3 months
tivodecode package
by Bernard Johnson
I need a ruling on whether tivodecode can be accepted into Fedora. It's
currently submitted to rpmfusion, but Kevin Koffler thought it might be
able to be accepted into Fedora proper.
There were three things under consideration:
* Freeness of QUALCOMM software license - appears to be free software
* QUALCOMM encryption patents (free?)
* MPEG program stream decoding (not decompression)
https://bugzilla.rpmfusion.org/show_bug.cgi?id=342
Seems that the question regarding MPEG program stream decoding is
perhaps not and issue as pointed out by Kevin in comment #3. But the
freeness of the patent license is questionable.
15 years, 3 months
cddl license in cdrtools
by Roman Rakus
Hi.
I have found cddl licesne is OK, but not GPL compatible. May I use
cdrtools in Fedora? If not, why?
Thanks
RR
15 years, 3 months
Fwd: EUPL status
by Luis Villa
FYI: EUPL 1.1 has been approved, and (apparently) should resolve the
issues with 1.0.
---------- Forwarded message ----------
From: Martin Michlmayr <tbm(a)cyrius.com>
Date: Fri, Jan 23, 2009 at 7:45 AM
Subject: Re: EUPL status
To: Walter van Holst <walter.van.holst(a)gmail.com>
Cc: "license-discuss(a)opensource.org" <license-discuss(a)opensource.org>
According to OSOR, version 1.1 of the EUPL has just been approved by
the European Commission. So we just need someone to formally submit
the license for review.
See http://www.osor.eu/news/european-commission-approves-update-of-eu-public-...
15 years, 3 months
