From bochecha at fedoraproject.org Thu Jan 1 16:29:56 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 01 Jan 2009 17:29:56 +0100 Subject: [Fedora-legal-list] Dock-like application status Message-ID: <1230827397.24782.22.camel@localhost.localdomain> Hi, First of all, I wish you all a happy new year. I saw in the Brazilian Fedora magazine [1] that Apple had patented its Dock application. The magazine says that the patent covers ? positioning of icons and cursors, as well as the zoom effect when the mouse moves over an icon ?. The actual text of the patent [2] is: """ Methods and systems for providing graphical user interfaces are described. To provide greater access and consolidation to frequently used items in the graphical user interface, a userbar is established which includes a plurality of item representations. To permit a greater number of items to reside in the userbar, a magnification function can be provided which magnifies items within the userbar when they are proximate the cursor associated with the graphical user interface. """ Is the legal team aware of this issue ? What's gonna happen about those dock-like applications in the Fedora repositories, given the Fedora policy on patented software ? Regards, [1] https://www.redhat.com/archives/fedora-marketing-list/2008-December/msg00240.html [2] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,434,177.PN.&OS=PN/7,434,177&RS=PN/7,434,177 ---------- Mathieu Bridon (bochecha) French Fedora Ambassador ---------- "They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." ~Benjamin Franklin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Mon Jan 5 02:41:18 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 04 Jan 2009 21:41:18 -0500 Subject: [Fedora-legal-list] Heads-up on new Samba4 licence In-Reply-To: <1231109625.3641.41.camel@naomi.s4.naomi.abartlet.net> References: <1229728698.3901.8.camel@naomi.s4.naomi.abartlet.net> <1229874010.19374.56.camel@localhost.localdomain> <1231109625.3641.41.camel@naomi.s4.naomi.abartlet.net> Message-ID: <1231123278.18570.9.camel@localhost.localdomain> On Mon, 2009-01-05 at 09:53 +1100, Andrew Bartlett wrote: > On Sun, 2008-12-21 at 10:40 -0500, Tom "spot" Callaway wrote: > > On Sat, 2008-12-20 at 10:18 +1100, Andrew Bartlett wrote: > > > Samba4 (which is under review for inclusion into Fedora) will soon ship > > > some data (the Active Directory schema) under less-than-usual licence > > > terms. > > > > > > The attached file gives the text. > > > > > > I believe it is no less free than Free licences on Fonts that require > > > redistribution with software. > > > > > > The review ticket is: https://bugzilla.redhat.com/show_bug.cgi?id=453083 > > > > > > If this causes a problem, presumably the packager can strip > > > setup/ad-schema (and the whole server implementation) from the tarball. > > > > Andrew, do you know if these specific schemas fall under the OSP? > > I can't see it on the list, and I would be very supprised if it was. It > does however fall under the 'no patents' WSPP licence agreement that the > PFIF signed with Microsoft, as Microsoft provided it to me under that > agreement. > > http://www.protocolfreedom.org/PFIF_agreement.pdf > > (It isn't much different to the rest of Samba in that regard) Okay. I'll look over this and hopefully have this cleared before the end of this week. Thanks, ~spot From tcallawa at redhat.com Thu Jan 8 16:29:57 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 08 Jan 2009 11:29:57 -0500 Subject: [Fedora-legal-list] xBill legal opinion required In-Reply-To: <29fee02b0812260250g564e1b38h199c69255fee8cd6@mail.gmail.com> References: <29fee02b0812260250g564e1b38h199c69255fee8cd6@mail.gmail.com> Message-ID: <1231432197.3318.38.camel@localhost.localdomain> On Fri, 2008-12-26 at 11:50 +0100, Andrea Musuruane wrote: > 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. We're checking into this, and I'll let you know what RH Legal decides. Thanks, ~spot From sundaram at fedoraproject.org Fri Jan 9 04:46:11 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 09 Jan 2009 10:16:11 +0530 Subject: [Fedora-legal-list] hotbabe and Fedora Message-ID: <4966D693.3000002@fedoraproject.org> Hi http://dindinx.net/hotbabe/ Someone asked me if they can submit this to Fedora, FYI refer http://lwn.net/Articles/113644/ Rahul From rfontana at redhat.com Fri Jan 9 05:00:56 2009 From: rfontana at redhat.com (Richard Fontana) Date: Fri, 9 Jan 2009 00:00:56 -0500 Subject: [Fedora-legal-list] hotbabe and Fedora In-Reply-To: <4966D693.3000002@fedoraproject.org> References: <4966D693.3000002@fedoraproject.org> Message-ID: <20090109000056.1f67598a@calliope> On Fri, 09 Jan 2009 10:16:11 +0530 Rahul Sundaram wrote: > Hi > > http://dindinx.net/hotbabe/ > > Someone asked me if they can submit this to Fedora, FYI refer > > http://lwn.net/Articles/113644/ Unlike Debian, the Fedora Project classifies the Artistic 1.0 as non-free. - RF From rfontana at redhat.com Fri Jan 9 05:39:51 2009 From: rfontana at redhat.com (Richard Fontana) Date: Fri, 9 Jan 2009 00:39:51 -0500 Subject: [Fedora-legal-list] hotbabe and Fedora In-Reply-To: <20090109000056.1f67598a@calliope> References: <4966D693.3000002@fedoraproject.org> <20090109000056.1f67598a@calliope> Message-ID: <20090109003951.5d803e3b@calliope> > On Fri, 09 Jan 2009 10:16:11 +0530 > Rahul Sundaram wrote: > > > Hi > > > > http://dindinx.net/hotbabe/ > > > > Someone asked me if they can submit this to Fedora, FYI refer > > > > http://lwn.net/Articles/113644/ > > Unlike Debian, the Fedora Project classifies the Artistic 1.0 as > non-free. Presumably, at least in unmodified form, it would also fail the guidelines set forth at https://fedoraproject.org/wiki/Packaging:Guidelines but, given the licensing issue, we need not reach that question. - RF From mikhail.kalenkov at gmail.com Sat Jan 10 19:26:51 2009 From: mikhail.kalenkov at gmail.com (Mikhail Kalenkov) Date: Sat, 10 Jan 2009 22:26:51 +0300 Subject: [Fedora-legal-list] scid legal opinion required Message-ID: 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. From tcallawa at redhat.com Tue Jan 13 16:01:33 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 Jan 2009 11:01:33 -0500 Subject: [Fedora-legal-list] scid legal opinion required In-Reply-To: References: Message-ID: <1231862493.3635.13.camel@localhost.localdomain> On Sat, 2009-01-10 at 22:26 +0300, Mikhail Kalenkov wrote: > 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. Well, what I would do is to send Eugene Nalimov an email asking him for the licensing terms for his tablebase decoding code. Specifically, we want to know what the terms are for: * use * modification * redistribution For sanity sake, suggesting the GPL would also be a good idea. ~spot From roozbeh at gmail.com Tue Jan 13 20:08:04 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Tue, 13 Jan 2009 12:08:04 -0800 Subject: [Fedora-legal-list] policy on shipping/using flags Message-ID: 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_to_refer_to_my_language 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 From kwade at redhat.com Tue Jan 13 20:29:08 2009 From: kwade at redhat.com (Karsten Wade) Date: Tue, 13 Jan 2009 12:29:08 -0800 Subject: [Fedora-legal-list] policy on shipping/using flags In-Reply-To: References: Message-ID: <20090113202908.GZ13560@calliope.phig.org> On Tue, Jan 13, 2009 at 12:08:04PM -0800, Roozbeh Pournader wrote: > 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. I don't really have anything to add other than that this seems like a good topic, you've given the scope some good thought. If this is not really on-topic for legal, you could bring it to fedora-advisory-board. What I've always "heard" about why we don't use flags for languages in fact matches what is on wiki/Languages. I always considered it simple respect for the varying opinions in the world, combined with the fact that a language is not the same as a country, so using flags is inaccurate. For a torrent tracker that is in fact tied to a country of origin for the torrent source, the flag makes sense. The upstream has to be willing to keep that updated, though; when a country changes flags, for example. However, is there a source for free-as-in-freedom images for all flags? Is Deluge making their own? - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter at thecodergeek.com Wed Jan 14 07:10:05 2009 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 13 Jan 2009 23:10:05 -0800 Subject: [Fedora-legal-list] policy on shipping/using flags Message-ID: <1231917005.31369.32.camel@localhost.localdomain> [Please forgive the lack of a proper Reply-To header for threading on this one. I subscribed to this list only after reading the beginnings of this thread on the archives, and have copied the content into this message from those postings.] On Tue, 13 Jan 2009 12:29:08 -0800, Karsten Wade wrote: > For a torrent tracker that is in fact tied to a country of origin for > the torrent source, the flag makes sense. The way Deluge upstream uses the flags is to mark the country of origin for the details in the "Peers" information tab, so that's not really applicable here. > The upstream has to be willing to keep that updated, though; when a > country changes flags, for example. However, is there a source for > free-as-in-freedom images for all flags? Is Deluge making their own? Well, the flags that Deluge uses are PD images from FamFamFam.com [1], and the Deluge developers do intend (as is my understanding) to keep them updated. However, the original source is rather old (from 2005 according to File Roller) so I do not know if _that_ upstream is inactive simply from lack of necessity or due to other priorities. [1] http://famfamfam.com/lab/icons/flags/ And, Roozbeh: Thanks very much for bringing up this discussion in such a thought-provoking way. I hope we can get this issue resolved - one way or the other - in a timely manner. :) Peter Gordon (codergeek42) ??????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Wed Jan 14 15:38:56 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 14 Jan 2009 10:38:56 -0500 Subject: [Fedora-legal-list] policy on shipping/using flags In-Reply-To: <1231917005.31369.32.camel@localhost.localdomain> References: <1231917005.31369.32.camel@localhost.localdomain> Message-ID: <1231947536.3518.35.camel@localhost.localdomain> On Tue, 2009-01-13 at 23:10 -0800, Peter Gordon wrote: > And, Roozbeh: Thanks very much for bringing up this discussion in such > a > thought-provoking way. I hope we can get this issue resolved - one way > or the other - in a timely manner. :) Indeed. I have Red Hat Legal looking over this issue. ~spot From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jan 14 16:31:19 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 15 Jan 2009 01:31:19 +0900 Subject: [Fedora-legal-list] shipping icons possibly trademarked Message-ID: <496E1357.4060205@ioa.s.u-tokyo.ac.jp> Hello. Currently on rawhide "cairo-dock" (this is package name) tarball which is created by checking out upstream SVN repository contains some icons which may be trademarked by some game software companies. They are under: plug-ins/Cairo-Penguin/data/themes/*/ I would appreciate it if you would check if these icons can be included in Fedora srpm and installed with binary rpms. If not I can simply remove these icons from cairo-dock tarball. Regards, Mamoru From tcallawa at redhat.com Wed Jan 14 19:34:51 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 14 Jan 2009 14:34:51 -0500 Subject: [Fedora-legal-list] shipping icons possibly trademarked In-Reply-To: <496E1357.4060205@ioa.s.u-tokyo.ac.jp> References: <496E1357.4060205@ioa.s.u-tokyo.ac.jp> Message-ID: <1231961691.3518.157.camel@localhost.localdomain> On Thu, 2009-01-15 at 01:31 +0900, Mamoru Tasaka wrote: > I would appreciate it if you would check if these icons can be > included in Fedora srpm and installed with binary rpms. > If not I can simply remove these icons from cairo-dock tarball. These icons need to be removed. ~spot From dominik at greysector.net Wed Jan 14 23:19:16 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 15 Jan 2009 00:19:16 +0100 Subject: [Fedora-legal-list] mldonkey's src/utils/lib/md4.h licence Message-ID: <20090114231916.GD18644@mokona.greysector.net> Hello. As noted in https://bugzilla.redhat.com/show_bug.cgi?id=452584#c13 , mldonkey appears to include a header file with a licence I wasn't able to identify. My concern is that (if I'm reading it correctly) it doesn't grant explicit permission to distribute derivative works, only "make and use" them. Am I mistaken? Is this licence acceptable for Fedora? Quote: /* Copyright (C) 1990-2, RSA Data Security, Inc. All rights reserved. License to copy and use this software is granted provided that it is identified as the "RSA Data Security, Inc. MD4 Message-Digest Algorithm" in all material mentioning or referencing this software or this function. License is also granted to make and use derivative works provided that such works are identified as "derived from the RSA Data Security, Inc. MD4 Message-Digest Algorithm" in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided "as is" without express or implied warranty of any kind. These notices must be retained in any copies of any part of this documentation and/or software. */ Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tibbs at math.uh.edu Wed Jan 14 23:52:45 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jan 2009 17:52:45 -0600 Subject: [Fedora-legal-list] mldonkey's src/utils/lib/md4.h licence In-Reply-To: <20090114231916.GD18644@mokona.greysector.net> References: <20090114231916.GD18644@mokona.greysector.net> Message-ID: >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: DM> Am I mistaken? Is this licence acceptable for Fedora? The info at https://fedoraproject.org/wiki/Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F seems to be on-point here. - J< From mtasaka at ioa.s.u-tokyo.ac.jp Thu Jan 15 07:37:30 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 15 Jan 2009 16:37:30 +0900 Subject: [Fedora-legal-list] shipping icons possibly trademarked In-Reply-To: <1231961691.3518.157.camel@localhost.localdomain> References: <496E1357.4060205@ioa.s.u-tokyo.ac.jp> <1231961691.3518.157.camel@localhost.localdomain> Message-ID: <496EE7BA.5010206@ioa.s.u-tokyo.ac.jp> Tom "spot" Callaway wrote, at 01/15/2009 04:34 AM +9:00: > On Thu, 2009-01-15 at 01:31 +0900, Mamoru Tasaka wrote: > >> I would appreciate it if you would check if these icons can be >> included in Fedora srpm and installed with binary rpms. >> If not I can simply remove these icons from cairo-dock tarball. > > These icons need to be removed. > > ~spot Done on the latest Fedora CVS, will be pushed on rawhide after next. Thank you. Mamoru From dominik at greysector.net Thu Jan 15 09:55:09 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 15 Jan 2009 10:55:09 +0100 Subject: [Fedora-legal-list] mldonkey's src/utils/lib/md4.h licence In-Reply-To: References: <20090114231916.GD18644@mokona.greysector.net> Message-ID: <20090115095508.GB15589@mokona.greysector.net> On Thursday, 15 January 2009 at 00:52, Jason L Tibbitts III wrote: > >>>>> "DM" == Dominik 'Rathann' Mierzejewski writes: > > DM> Am I mistaken? Is this licence acceptable for Fedora? > > The info at > https://fedoraproject.org/wiki/Licensing/FAQ#What_about_the_RSA_license_on_their_MD5_implementation.3F_Isn.27t_that_GPL-incompatible.3F seems to be on-point here. That's spot on! Thanks a bunch. I don't know how I missed it. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From stickster at gmail.com Fri Jan 16 13:49:38 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Jan 2009 08:49:38 -0500 Subject: [Fedora-legal-list] Truly public namespaces on Fedora wiki Message-ID: <20090116134938.GF17851@localhost.localdomain> This question came up at a FUDCon discussion about the wiki. The wiki globally asserts that pages are licensed under the OPL, and we license in that fashion pursuant to contributors having signed the CLA. However, in the FUDCon: namespace, we allow the public to edit pages, because that's the nature of FUDCon. We do not require people to become Fedora account holders or CLA signers to attend FUDCon, but those people must be free to pre-register, thus these pages must be editable by non-authenticated persons. These edits by non-authenticated persons will be labeled with an IP address. Notably, it's possible that a Fedora account holder (who could authenticate) might accidentally edit these pages in a non-authenticated way. The effect would be that the edit would look like any other non-authenticated edit even though presumably the Fedora account holder fully intended it to be an authenticated edit and thus covered by the CLA, and so forth. The wiki does not provide the means for a non-authenticated person to confirm OPL licensing. It does warn anyone who saves an edit that their work may be edited and that material must not be copied onto the wiki without proper permission, and links to the Legal:Licenses page where the OPL licensing statement lives. But there is no statement to the effect that "By clicking the Save Page button, you agree that your submission will be licensed under the terms found at _____". Since we switched to MediaWiki it's possible that we've simply failed to provide an equivalent language transfer in this case. So my questions are as follows: 1. Can a non-authenticated person agree to the OPL license when making a submission, such that the agreement is meaningful and enforceable (or at least free of risk for the Fedora Project) without personally identifying information? 2. If the answer to #1 is "yes," should we attach a statement of affirmative licensing prominently near the "Save Page" button? 3. If the answer to #1 is "no," should we alter FUDCon:, and any other namespace on the wiki designed to be publicly editable, to provide their contents under public domain or no license, and notate that on the Legal:Licenses page? My hope is that the answers to #1 and #2 are "yes," but I wanted those answers to emerge here on fedora-legal-list if possible. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Jan 16 14:47:43 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Jan 2009 09:47:43 -0500 Subject: [Fedora-legal-list] Truly public namespaces on Fedora wiki In-Reply-To: <20090116134938.GF17851@localhost.localdomain> References: <20090116134938.GF17851@localhost.localdomain> Message-ID: <1232117263.4394.14.camel@localhost.localdomain> On Fri, 2009-01-16 at 08:49 -0500, Paul W. Frields wrote: > 1. Can a non-authenticated person agree to the OPL license when > making a submission, such that the agreement is meaningful and > enforceable (or at least free of risk for the Fedora Project) > without personally identifying information? In the limited boundary set of people signing their name to attend FUDCon, yes. In a larger set of data, possibly not. > 2. If the answer to #1 is "yes," should we attach a statement of > affirmative licensing prominently near the "Save Page" button? It could not hurt. > 3. If the answer to #1 is "no," should we alter FUDCon:, and any > other namespace on the wiki designed to be publicly editable, to > provide their contents under public domain or no license, and > notate that on the Legal:Licenses page? I would rather have any publicly editable pages include prominent notice near the "Save Page" button that by hitting the "Save Page" button, you're indicating that all changes made are done under the OPL license, and if you do not agree with these terms, you should not make changes. I'd also like to minimize the amount of namespaces which are designed to be publicly editable without signing the CLA. ~spot From stickster at gmail.com Fri Jan 16 14:58:26 2009 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 16 Jan 2009 09:58:26 -0500 Subject: [Fedora-legal-list] Truly public namespaces on Fedora wiki In-Reply-To: <1232117263.4394.14.camel@localhost.localdomain> References: <20090116134938.GF17851@localhost.localdomain> <1232117263.4394.14.camel@localhost.localdomain> Message-ID: <20090116145826.GG28057@localhost.localdomain> On Fri, Jan 16, 2009 at 09:47:43AM -0500, Tom spot Callaway wrote: > On Fri, 2009-01-16 at 08:49 -0500, Paul W. Frields wrote: > > 1. Can a non-authenticated person agree to the OPL license when > > making a submission, such that the agreement is meaningful and > > enforceable (or at least free of risk for the Fedora Project) > > without personally identifying information? > > In the limited boundary set of people signing their name to attend > FUDCon, yes. In a larger set of data, possibly not. > > > 2. If the answer to #1 is "yes," should we attach a statement of > > affirmative licensing prominently near the "Save Page" button? > > It could not hurt. > > > 3. If the answer to #1 is "no," should we alter FUDCon:, and any > > other namespace on the wiki designed to be publicly editable, to > > provide their contents under public domain or no license, and > > notate that on the Legal:Licenses page? > > I would rather have any publicly editable pages include prominent notice > near the "Save Page" button that by hitting the "Save Page" button, > you're indicating that all changes made are done under the OPL license, > and if you do not agree with these terms, you should not make changes. > > I'd also like to minimize the amount of namespaces which are designed to > be publicly editable without signing the CLA. I agree with this too. Maybe we can get Ian "WikiNinja" Weller or Nigel "G-Man" Jones to get a proper and prominent notice attached to the wiki, above or next to the Save controls. Since it's been made immutable, I can't access the notice we used on the Moin wiki, but I'm almost certain we had one there. Shall we just use that text, if someone can retrieve it? -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ianweller at gmail.com Fri Jan 16 21:37:21 2009 From: ianweller at gmail.com (Ian Weller) Date: Fri, 16 Jan 2009 15:37:21 -0600 Subject: [Fedora-legal-list] Truly public namespaces on Fedora wiki In-Reply-To: <20090116145826.GG28057@localhost.localdomain> References: <20090116134938.GF17851@localhost.localdomain> <1232117263.4394.14.camel@localhost.localdomain> <20090116145826.GG28057@localhost.localdomain> Message-ID: <20090116213721.GA23536@gmail.com> On Fri, Jan 16, 2009 at 09:58:26AM -0500, Paul W. Frields wrote: > On Fri, Jan 16, 2009 at 09:47:43AM -0500, Tom spot Callaway wrote: > > I would rather have any publicly editable pages include prominent notice > > near the "Save Page" button that by hitting the "Save Page" button, > > you're indicating that all changes made are done under the OPL license, > > and if you do not agree with these terms, you should not make changes. > > > > I'd also like to minimize the amount of namespaces which are designed to > > be publicly editable without signing the CLA. > > I agree with this too. Maybe we can get Ian "WikiNinja" Weller or > Nigel "G-Man" Jones to get a proper and prominent notice attached to > the wiki, above or next to the Save controls. > > Since it's been made immutable, I can't access the notice we used on > the Moin wiki, but I'm almost certain we had one there. Shall we just > use that text, if someone can retrieve it? > Well wouldn't ya know it, a WikiMedia website -- the MediaWiki help pages -- are a precedent for this sort of thing. Their entire Help: namespace is public domain so that other wikis can import it without problem. http://www.mediawiki.org/wiki/Help:Contents http://www.mediawiki.org/w/index.php?title=Help:Signatures&action=edit Now, how does this work? http://www.mediawiki.org/w/index.php?title=MediaWiki:Copyrightwarning&action=edit -- Ian Weller http://ianweller.org GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 "Technology is a word that describes something that doesn't work yet." ~ Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From luis at tieguy.org Fri Jan 23 13:01:25 2009 From: luis at tieguy.org (Luis Villa) Date: Fri, 23 Jan 2009 08:01:25 -0500 Subject: [Fedora-legal-list] Fwd: EUPL status In-Reply-To: <20090123124555.GA10138@loric-alpo.emea.hpqcorp.net> References: <5da54c9d0901210619l1f67d71cj265a1cf0bb2c0dc8@mail.gmail.com> <20090123124555.GA10138@loric-alpo.emea.hpqcorp.net> Message-ID: <2cb10c440901230501g6d664f8arc662faed6bcbee3@mail.gmail.com> FYI: EUPL 1.1 has been approved, and (apparently) should resolve the issues with 1.0. ---------- Forwarded message ---------- From: Martin Michlmayr Date: Fri, Jan 23, 2009 at 7:45 AM Subject: Re: EUPL status To: Walter van Holst Cc: "license-discuss at 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-licence From rrakus at redhat.com Mon Jan 26 09:26:20 2009 From: rrakus at redhat.com (Roman Rakus) Date: Mon, 26 Jan 2009 10:26:20 +0100 Subject: [Fedora-legal-list] cddl license in cdrtools Message-ID: <497D81BC.60305@redhat.com> Hi. I have found cddl licesne is OK, but not GPL compatible. May I use cdrtools in Fedora? If not, why? Thanks RR From sundaram at fedoraproject.org Mon Jan 26 09:33:28 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Jan 2009 15:03:28 +0530 Subject: [Fedora-legal-list] cddl license in cdrtools In-Reply-To: <497D81BC.60305@redhat.com> References: <497D81BC.60305@redhat.com> Message-ID: <497D8368.9010900@fedoraproject.org> Roman Rakus wrote: > Hi. > I have found cddl licesne is OK, but not GPL compatible. May I use > cdrtools in Fedora? If not, why? You cannot afaik. CDDL is a free and open source but GPL incompatible license. The problem with cdrtools is that, it is a mix of GPL and CDDL licensed filed that makes them undistributable by anyone except the author. http://lwn.net/Articles/198171/ Rahul From bjohnson80498 at gmail.com Mon Jan 26 17:36:52 2009 From: bjohnson80498 at gmail.com (Bernard Johnson) Date: Mon, 26 Jan 2009 10:36:52 -0700 Subject: [Fedora-legal-list] tivodecode package Message-ID: 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. From dominik at greysector.net Mon Jan 26 18:35:31 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 26 Jan 2009 19:35:31 +0100 Subject: [Fedora-legal-list] tivodecode package In-Reply-To: References: Message-ID: <20090126183530.GC12639@mokona.greysector.net> On Monday, 26 January 2009 at 18:36, Bernard Johnson wrote: > 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) I think you mean "demuxing" here. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tcallawa at redhat.com Mon Jan 26 19:11:20 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 26 Jan 2009 14:11:20 -0500 Subject: [Fedora-legal-list] tivodecode package In-Reply-To: References: Message-ID: <497E0AD8.2090909@redhat.com> On 2009-01-26 at 12:36:52 -0500, Bernard Johnson wrote: > 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) Well, there really is a fourth: this is possibly a DMCA violation. Upon consultation with counsel, we decided that we're much happier with this living in RPMFusion as a result. ~spot From bjohnson80498 at gmail.com Mon Jan 26 21:10:44 2009 From: bjohnson80498 at gmail.com (Bernard Johnson) Date: Mon, 26 Jan 2009 14:10:44 -0700 Subject: [Fedora-legal-list] Re: tivodecode package In-Reply-To: <497E0AD8.2090909@redhat.com> References: <497E0AD8.2090909@redhat.com> Message-ID: Tom "spot" Callaway wrote: > On 2009-01-26 at 12:36:52 -0500, Bernard Johnson > wrote: >> 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) > > Well, there really is a fourth: this is possibly a DMCA violation. Upon > consultation with counsel, we decided that we're much happier with this > living in RPMFusion as a result. > Thanks for the quick response. From roozbeh at gmail.com Wed Jan 28 06:05:01 2009 From: roozbeh at gmail.com (Roozbeh Pournader) Date: Tue, 27 Jan 2009 22:05:01 -0800 Subject: [Fedora-legal-list] Legal issues with new font guidelines Message-ID: 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 From tcallawa at redhat.com Wed Jan 28 13:18:15 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 08:18:15 -0500 Subject: [Fedora-legal-list] Legal issues with new font guidelines In-Reply-To: References: Message-ID: <49805B17.5000803@redhat.com> On 2009-01-28 at 1:05:01 -0500, Roozbeh Pournader wrote: > 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. IMHO, in such a scenario, it is acceptable to put a copy of the license in each binary RPM. This will not cause conflicts, because it is the same file in the same location. If this obsoletes the need for a -common package, then do not create one. However, the license may be embedded inside the font itself. Might be worth poking it with FontForge to see. If it is, then this is not necessary. ~spot From tcallawa at redhat.com Wed Jan 28 14:54:29 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 09:54:29 -0500 Subject: [Fedora-legal-list] Legal issues with new font guidelines In-Reply-To: <69b4e2192bac43361fc4da7237b64078.squirrel@arekh.dyndns.org> References: <49805B17.5000803@redhat.com> <69b4e2192bac43361fc4da7237b64078.squirrel@arekh.dyndns.org> Message-ID: <498071A5.6000601@redhat.com> On 2009-01-28 at 8:41:39 -0500, "Nicolas Mailhot" wrote: > However if you don't you'll have to deal with the directory ownership > of the common font directory (I purposefully didn't want to open this > particular can of worm) and other common files. > > Also documentation can be bulky, especially when upstream provides in > in pdf or .doc form with embedded bitmaps of what the font looks like. Well, it seems like there wouldn't be much of a case to obsolete -common in that scenario, just move the license into each subpackage. ~spo From nicolas.mailhot at laposte.net Wed Jan 28 13:32:39 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jan 2009 14:32:39 +0100 (CET) Subject: [Fedora-legal-list] Re: Legal issues with new font guidelines In-Reply-To: References: Message-ID: Le Mer 28 janvier 2009 07:05, Roozbeh Pournader a ?crit : > 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. I don't think anyone can sue us because someone extracted stuff from an rpm and installed it without using rpm itself when all our own uses pass through rpm. I'd rate this risk at 1 on a scale of 100, when us distributing misappropriated font content included in a font file that we didn't detect in time would be 90. And in fact our current problem is more to get upstreams to write correct, complete and accurate legal documentation than upstreams complaining we do not propagate this documentation properly. But IANAL, and if there is a legal need, there is no technical limitation that would prevent duplicating the same files in all the subpackages of the same srpmmany times over. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Wed Jan 28 13:41:39 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jan 2009 14:41:39 +0100 (CET) Subject: [Fedora-legal-list] Legal issues with new font guidelines In-Reply-To: <49805B17.5000803@redhat.com> References: <49805B17.5000803@redhat.com> Message-ID: <69b4e2192bac43361fc4da7237b64078.squirrel@arekh.dyndns.org> Le Mer 28 janvier 2009 14:18, Tom \"spot\" Callaway a ?crit : > If this obsoletes the need for a -common > package, then do not create one. However if you don't you'll have to deal with the directory ownership of the common font directory (I purposefully didn't want to open this particular can of worm) and other common files. Also documentation can be bulky, especially when upstream provides in in pdf or .doc form with embedded bitmaps of what the font looks like. -- Nicolas Mailhot From billcrawford1970 at gmail.com Wed Jan 28 14:00:14 2009 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 28 Jan 2009 14:00:14 +0000 Subject: [Fedora-legal-list] Re: Legal issues with new font guidelines In-Reply-To: References: Message-ID: <200901281400.14804.billcrawford1970@gmail.com> On Wednesday 28 January 2009 06:05:01 Roozbeh Pournader wrote: ... > 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. ... > 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". Put the license text file (I'm assuming it's not all that big) as %doc for each subpackage; it should end up in a separate directory under /usr/share/doc, thus eliminating any worry about file conflicts should someone update the license at any point and a user upgrade one font subpackage but not the other. From nicolas.mailhot at laposte.net Wed Jan 28 14:52:09 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Jan 2009 15:52:09 +0100 (CET) Subject: [Fedora-legal-list] Re: Legal issues with new font guidelines In-Reply-To: <200901281400.14804.billcrawford1970@gmail.com> References: <200901281400.14804.billcrawford1970@gmail.com> Message-ID: <9a94d1322ad20805c0336130eef1d458.squirrel@arekh.dyndns.org> Le Mer 28 janvier 2009 15:00, Bill Crawford a ?crit : > Put the license text file (I'm assuming it's not all that big) This is not a safe asumption > as %doc for each > subpackage; it should end up in a separate directory under > /usr/share/doc, thus > eliminating any worry about file conflicts should someone update the > license at > any point and a user upgrade one font subpackage but not the other. This is not a problem, the template forces each subpackage to depend on the exact version of the common subpackage, so all the subpackages installed on a system will always be updated in lockstep. -- Nicolas Mailhot From tcallawa at redhat.com Wed Jan 28 15:14:32 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 10:14:32 -0500 Subject: [Fedora-legal-list] Legal issues with new font guidelines In-Reply-To: <7995db6da8f5ab13b8cade6f3ebbf103.squirrel@arekh.dyndns.org> References: <49805B17.5000803@redhat.com> <69b4e2192bac43361fc4da7237b64078.squirrel@arekh.dyndns.org> <498071A5.6000601@redhat.com> <7995db6da8f5ab13b8cade6f3ebbf103.squirrel@arekh.dyndns.org> Message-ID: <49807658.8080700@redhat.com> On 2009-01-28 at 10:08:01 -0500, "Nicolas Mailhot" 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 From ville.skytta at iki.fi Wed Jan 28 17:13:49 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 28 Jan 2009 19:13:49 +0200 Subject: [Fedora-legal-list] Legal issues with new font guidelines In-Reply-To: <49807658.8080700@redhat.com> References: <7995db6da8f5ab13b8cade6f3ebbf103.squirrel@arekh.dyndns.org> <49807658.8080700@redhat.com> Message-ID: <200901281913.49571.ville.skytta@iki.fi> On Wednesday 28 January 2009, Tom "spot" Callaway wrote: > 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. And by the way, if it would be necessary even given the above, the issue would not be limited to fonts packages at all but would apply lots of other subpackage splits in the distro as well. From oget.fedora at gmail.com Wed Jan 28 21:53:57 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 28 Jan 2009 16:53:57 -0500 Subject: [Fedora-legal-list] Unalz: is there a patent issue? Message-ID: 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/ From mikhail.kalenkov at gmail.com Fri Jan 30 18:30:36 2009 From: mikhail.kalenkov at gmail.com (Mikhail Kalenkov) Date: Fri, 30 Jan 2009 21:30:36 +0300 Subject: [Fedora-legal-list] scid legal opinion required In-Reply-To: <1231862493.3635.13.camel@localhost.localdomain> References: <1231862493.3635.13.camel@localhost.localdomain> Message-ID: 2009/1/13 Tom spot Callaway : > On Sat, 2009-01-10 at 22:26 +0300, Mikhail Kalenkov wrote: >> 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. > > Well, what I would do is to send Eugene Nalimov an email asking him for > the licensing terms for his tablebase decoding code. Specifically, we > want to know what the terms are for: > > * use > * modification > * redistribution > > For sanity sake, suggesting the GPL would also be a good idea. > > ~spot I wrote to Eugene Nalimov but didn't received any response. Could you make a conclusion based on available facts? Mikhail Kalenkov. From tcallawa at redhat.com Fri Jan 30 18:35:23 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 30 Jan 2009 13:35:23 -0500 Subject: [Fedora-legal-list] scid legal opinion required In-Reply-To: References: <1231862493.3635.13.camel@localhost.localdomain> Message-ID: <4983486B.5040406@redhat.com> Mikhail Kalenkov wrote: > I wrote to Eugene Nalimov but didn't received any response. Could you > make a conclusion based on available facts? We should not ship Eugene's code. We have no permission. ~spot