legal June 2009

legal@lists.fedoraproject.org

17 participants
15 discussions

Re: [Fedora-legal-list] CAcert.org license
by Tom Callaway 12 Feb '16

12 Feb '16

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

4 6

Legal CD/DVD/BD writing software for RedHat and Fedora
by Joerg Schilling 13 Aug '09

13 Aug '09

Hi! In former times, there was an excellent cooperative relationship between the development of cdrtools and the various Linux distributions (in special with Debian). Unfortunately, this changed in Spring 2004, a few months after the Debian package maintainer for the cdrtools has been replaced with a new and non-cooperative "downstream". As a result, during the past few years, many Linux users have become upset from the results of a completely unneeded conflict initiated by the non-cooperative "downstream" package maintainer. Many Linux distributions (including RedHat and Fedora) have become victims of this conflict. The conflict started in May 2004 with some anti-OSS and anti-social actions against the OSS project bundle "cdrtools". The non-cooperative "downstream" package maintainer started his high profile attack against the cdrtools project in May 2004. His attacks have been based on his personal frustration that was solely caused by his missing programming skills and his personal concept of dealing with these deficits. He later extended his attacks and finally incorrectly claimed that there were license problems in the cdrtools project and created a fork. As _reaction_ on his claims and in order to defend the freedom of the cdrtools software against these claims that have been based on an incorrect GPL interpretation (it would turn the GPL into a non-free license if taken seriously), the license of the original software was changed to avoid the GPL as far as possible. This was done after many people from the OSS community and several lawyers have been asked about possible problems, caused by the planned license change. As nobody did see a problem, the license change was carried out. A lot of new code and functionality was introduced since then and many older bugs have been fixed in the original software. Nearly 50% of the current code is code that was introduced or rewritten after the license change did take place. Note that the people who claim that there is a "potential problem that might result in a lawsuit" did never verify a possible problem and as they do not even own any Copyright on the code, they themselves are not allowed to sue people based on the cdrtools code. At the same time, the fork introduced many new bugs and questionable changes that reduced it's portability and it's usability. While the code quality of the fork declined, some of the changes introduced Copyright law violations [1] and even GPL [2] violations, making the fork undistributable. In December 2006 the initiators of the unlawful changes have been contacted and informed in depth about the violations. They have been asked to make the fork legal again to no avail. Eight months after the fork was created, the development of the fork stopped on May 6th 2007 as it's initiator stopped "working" on it. For some time, I was in hope that the big number of bugs in the fork (there are approx. 150 different bugs in total if you sum up all entries from all bug tracking systems from various Linux distributors) and the fact that it is no longer actively been worked on, would cause the Linux distributions to return to the legal original software. This did unfortunately not happen. I did wait a long time in hope that the problem will go away initiated from judiciousness but after some time, I am no longer willing to tolerate the distribution of the questionable fork. About a year ago, I asked the Sun Microsystems legal department to do another full legal review for the original software to make sure that none of the claims from the people who attack cdrtools is valid. In October 2008, the Sun legal department confirmed that there is no legal problem with the original software. At CeBIT on March 6th 2009, there was a meeting with me (Jörg Schilling, the main developer and main Copyright holder), Simon Phipps (the Sun Microsystems OpenSource Evangelist), a neutral observer and a FTP-master from Debian. During this meeting, Debian agreed to start shipping the original software again as soon as possible. I am in hope that RedHat and Fedora will also start to distribute the original software again and stop distributing the fork "cdrkit" because it is in conflict with the Copyright law [3] because it is full of well known bugs and because it is missing most features, people today expect from such software. Missing features are a typical result from decoupling from the main stream development. The source in the fork is based on 4 year old sources from the original. Note that working on the code from the fork is not an option as the initiators rejected to remove the Copyright violations 30 months ago and as too many show stopper bugs are unfixed in the fork since more than 24 months. I am looking forward to see RedHat and Fedora start to ship again the legal original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ and rejoin the community of OSS and user friendly distributions. Don't let the OSS users suffer anymore from the conflict introduced by a single hostile person. RedHat and Fedora should deliver what people need in order to be able to write CDs/DVDs/BluRays and this is the original software. The original software is easy to compile (you just need to type "make" - or better "smake") and it is 100% complete, so it does not need any unusual software package besides a compiler. The original software is expected to be always bug-free as bug fixes typically take only a few hours. The original software strictly follows all written conditions from the GPL [4]. Under the assumption that the GPL is a free OSS license [5] (and in special is compatible with the text in section 9 of the OSS definition) and that typical Linux distributions are at least mostly legal, the license combinations used in cdrtools are of course legal too, according to the best GPL explanation [6] [7] I could find in the net and of course according to the Sun Microsystems legal department. Lawrence Rosen, the Author of [6] and [7] advised the Open Source Initiative (www.opensource.org) -------------------------------------------------------------------------- Some statistics on the project activities: Cdrecord started as project in January 1996, but it was built on top of older Code (e.g. libschily from 1984, libscg from 1986 and the schily makefile system from 1992). Cdrtools include now also e.g. mkisofs that started as Project in September 1993 and that is maintained by the cdrtools project since spring 1997. The license change towards using CDDL for most code has been done on May 15th 2006. In the time between January 1985 and December 1995, there have been 638 file putbacks done in 385 groups (385 unique delta comments). In the time between January 1996 and May 14th 2006, there have been 8847 file putbacks done in 4280 groups (4280 unique delta comments). In the time between May 15th 2006 and today, there have been 4735 file putbacks done in 1695 groups (1695 unique delta comments). Approx 30% of all putbacks have been made after May 15th 2006, this is why the fork misses so many features people like to see today.... In the time past May 6th 2007, there have been 2441 file putbacks done in 882 groups (882 unique delta comments). During the same time, there have been 63 putbacks in the fork. This why people call the fork "dead". In other words: the original software has a sustained rate between 2.5 and 3 file changes per day since more than 13 years. This is why there are no know bugs and no known problems with the original software. While the original project did deliver ~ 50 new releases (that did not have any known bugs at the time of delivery) since May 15th 2006, the fork did not deliver a single release without plenty of well known bugs. -------------------------------------------------------------------------- [1] http://www.gesetze-im-internet.de/urhg/__13.html [2] Whether it not the GPL violations apply to Redhat and Fedora also, depends on the way a typical Redhat/Fedora installation looks like. [3] http://www.gesetze-im-internet.de/urhg/index.html [4] http://www.opensource.org/licenses/gpl-2.0.php [5] http://www.opensource.org/docs/definition.php [6] http://www.rosenlaw.com/html/GPL.PDF [7] http://www.rosenlaw.com/Rosen_Ch06.pdf Please help to defend OpenSource Software against attacks! Best Regards Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js(a)cs.tu-berlin.de (uni) joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

7 35

Re: http://www.fsf.org/news/dont-depend-on-mono
by Kevin Kofler 30 Jun '09

30 Jun '09

Matej Cepl wrote: > His point was that thousands of line of hardly obfuscated Javascript > (think Google Docs) is hard to recognize from binary-only distribution, > which I can see as pretty good argument. Right. The point isn't really about JavaScript the language, but about its integration into browsers and how it ends up used. It basically hides proprietary software in what users perceive as "content". Kevin Kofler

1 0

Re: [Fedora-legal-list] http://www.fsf.org/news/dont-depend-on-mono
by Bill Nottingham 29 Jun '09

29 Jun '09

Seth Vidal (skvidal(a)fedoraproject.org) said: >>> However, I don't think there's anything to worry about here. The only >>> reason that we ship mono *at all* is that we're covered by some OIN >>> patents on it. I'm not sure which OIN patents those are, but >>> essentially if Microsoft wants to pick that fight, >> >> ... it's not OIN patents, it's that mono is in the OIN list of protected >> packages. Just clarifying. > > Does OIN cover the specific version we're carrying? I thought OIN was > version specific. It covers a specific version of a package, and the functionality provided by that version in any successive release of that package. So, even though libX11 was split out of the xorg-x11 package after the OIN package list was approved, it's still covered. Bill

1 0

Re: http://www.fsf.org/news/dont-depend-on-mono
by Rahul Sundaram 29 Jun '09

29 Jun '09

On 06/29/2009 08:49 PM, drago01 wrote: > On Mon, Jun 29, 2009 at 5:08 PM, Kevin Kofler wrote: >> drago01 wrote: >>> Another don't use $LANGUAGE because its evil post from RMS. >> >> So what? His concerns are real. > > Depends on how you read them and whether you agree with him or not. > And for most cases I don't. > > Saying mono is evil while having DotGNU seems odd to me > (http://www.gnu.org/software/dotgnu/) Did you even read the article? I don't see where FSF cliams mono is evil. Their position is far more nuanced than that. What FSF is suggesting is to treat Mono purely as a (legacy) compatibility layer and not use it for new applications. "This is not to say that implementing C# is a bad thing. Free C# implementations permit users to run their C# programs on free platforms, which is good. (The GNU Project has an implementation of C# also, called Portable.NET.) Ideally we want to provide free implementations for all languages that programmers have used. The problem is not in the C# implementations, but rather in Tomboy and other applications written in C#. If we lose the use of C#, we will lose them too. That doesn't make them unethical, but it means that writing them and using them is taking a gratuitous risk." Rahul

1 0

Re: http://www.fsf.org/news/dont-depend-on-mono
by Kevin Kofler 29 Jun '09

29 Jun '09

drago01 wrote: > Saying mono is evil while having DotGNU seems odd to me > (http://www.gnu.org/software/dotgnu/) He also recommends against using DotGNU to develop your new Free Software in (because of the same patent risk as for Mono). >> I'm not familiar with the JavaScript story, but if he really recommended >> against using it, there was certainly a valid reason. > > http://www.gnu.org/philosophy/javascript-trap.html That's a rant against web apps rather than against JavaScript as a language and I agree with that one too: web apps are a way to push proprietary software onto people who claim to use only Free Software. In most cases, a portion of the code runs on your browser (that's where JavaScript comes into play), but is often licensed under a proprietary license, another portion runs on the web server and is completely out of your control (so it's even more proprietary than the average proprietary software). If you're using a proprietary web app, you're NOT using Free Software, but proprietary software, even if the browser you're using is Free Software. Kevin Kofler

1 0

Re: http://www.fsf.org/news/dont-depend-on-mono
by Kevin Kofler 29 Jun '09

29 Jun '09

drago01 wrote: > Another don't use $LANGUAGE because its evil post from RMS. So what? His concerns are real. > ($LANGUAGE has been Java, Javascript and now C#). Java used to be non-Free, so of course it was bad to depend on it. Especially for those programs which didn't work with the implementations which were Free Software at the time (GCJ/Classpath-based stuff). I'm not familiar with the JavaScript story, but if he really recommended against using it, there was certainly a valid reason. Kevin Kofler

1 0

http://www.fsf.org/news/dont-depend-on-mono
by Frank Murphy 29 Jun '09

29 Jun '09

Is there any contingency plans in place, for a worst case scenario if C#, is lost? FesCo? Legal? Is there any searchable parameter, to work out what something is coded in\depending on (code wise) This is not the normal "**** mono" post. I hope, I worded it enough, that my concern is: Fedora and *All* our Users (http://fedoraproject.org/wiki/Overview#What_is_Fedora.3F) Frank -- jabber | msn | skype: frankly3d http://www.frankly3d.com

4 3

BSD license?
by Christian Krause 28 Jun '09

28 Jun '09

[ I'm resending this mail since it looks like the first one got lost. ] Hi, I'm reviewing the package xscope and I'm unsure whether the supplied license [1] can be considered 100% as the BSD license (the wording is different to the examples in https://fedoraproject.org/wiki/Licensing/BSD ) Thanks in advance! [1] http://cgit.freedesktop.org/xorg/app/xscope/tree/COPYING Best regards, Christian

2 1

[Help] License question about poppler-data
by Jochen Schmitt 25 Jun '09

25 Jun '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, someone have mark the following review request with FE-LEGAL: https://bugzilla.redhat.com/show_bug.cgi?id=507675 The license says, that the content is redistributable but you have not the permission to modified the content. Because the package contains only content, that license is acceptable for fedora from my point of view. It may be nice, if anyone can aggree with my statement. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkpDrWQACgkQT2AHK6txfgxQ3gCgl+l94h8uK/9j4w0P7PvenZW/ iPUAn1Pb+xUnX/rUiOwesG0v+bkM2h5a =4sw/ -----END PGP SIGNATURE-----

1 0

Re: [Fedora-packaging] Digging up an old dead thread ...
by Tom Callaway 24 Jun '09

24 Jun '09

On 06/24/2009 02:22 PM, steve wrote: > Now, I have 2 questions for fedora-legal: > > a. Specific to the last two packages (ldd_pdf and javanotes) -- The > upstream license for both of those specify the license version number > (CC-BY-SA version 2 and 2.5), however, the page that lists acceptable > licenses for Fedora[1] does not provide any version numbers. So, should > I modify the License tag or should the wiki page be updated ? No, you just don't need to specify the version. We only specify the version in the license tag when there is a significant change in compatibility or there are versions of a license which are non-free. In the case of CC-BY-SA, all versions of that license are considered the same, and all are free. Just use: License: CC-BY-SA for all instances of the CC-BY-SA, regardless of versioning. > b. About other CC licensed content -- A lot of the available content is > licensed with the Non-Commercial restriction, which is considered as a > Bad License according to the wiki page on licensing. Why is > non-commercial only restriction considered bad ? ...and is there an > alternative to including this in the official Fedora repository -- for > instance the rpm fusion repository ? Commercial use restrictions make a license non-free, which is why they are not acceptable in Fedora. ~spot

1 0

FYI - chntpw package
by Richard W.M. Jones 09 Jun '09

09 Jun '09

Just for your information: https://bugzilla.redhat.com/show_bug.cgi?id=504595 I'm going to add the patch from Debian to resolve this issue. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

3 6

BlueJ: Help with Licence Check?
by Frank Murphy 06 Jun '09

06 Jun '09

http://www.bluej.org/about/license.html Before I do anything package wise, would this licence be compliant with Fedora Guidelines (Third Party\Exceptions) Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible

2 1

Songbird and EULA
by Rahul Sundaram 05 Jun '09

05 Jun '09

Hi Potential issue with Songbird and EULA is brewing at https://bugzilla.redhat.com/show_bug.cgi?id=453422#c64 Appreciate some comments from legal on this. Rahul

2 1

Regarding status of SRP (Secure remote password) support
by Peter Lemenkov 01 Jun '09

01 Jun '09

Hello All! Fedora ships gnutls (and, probably, other applications) w/o SRP support, which was disabled years ago (in the era of Jeff Jonston). See technical description here: http://en.wikipedia.org/wiki/Secure_remote_password_protocol Being curious lad, I quickly googled about its patents issues and found numerous discussion in the past. For example: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09292.html http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08027.html >From these discussions, I found that patent holder provides a royalty-free license: http://otl.stanford.edu/pdf/97006.pdf I cannot find any other patent-related info at the dedicated site (created by patent holder): http://srp.stanford.edu/ Maybe it's time to re-add support for SRP back in Fedora? -- With best regards!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

legal June 2009