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
7 years, 9 months
Legal CD/DVD/BD writing software for RedHat and Fedora
by Joerg Schilling
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
14 years, 3 months
License for wallpapers in old Fedora releases
by Nicu Buculei
At the Design-Team we figured it would be handy to provide (perhaps in a
gallery) wallpapers from the old releases, so the users who liked them
can have a handy access at the images. It is also useful to have when
documenting our history.
However, we have a licensing issue with the images created before the
team establishment, from Fedora Core 1 to Fedora 7, when they were
created behing the closed doors, at the Red Hat Desktop Team.
My understanding is, being created Red Hat employees as part of their
normal job and included into Fedora, those should have some Free license.
However, for compatibility with the artwork produced currently and for
easy access by everybody, it would be useful to have access to those
images under a CreativeCommons license (Attribution or Attribution -
Share Alike).
From seeing the recent license chance of the wiki, I expect the license
change for old wallpapers to be also doable but legal advice is needed.
--
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/
14 years, 3 months
Re: [Fedora-legal-list] nautilus-dropbox question
by Tom Callaway
On 07/28/2009 06:02 PM, David Cantrell wrote:
> The setup thing doesn't do any compilation or anything like that. The archive
> downloaded is already compiled by Evenflow. All the setup thing does is
> unpack it. nautilus-dropbox runs it.
So, there is no source code available for any of the bits being downloaded?
If so, then it definitely isn't acceptable for Fedora because dropbox
isn't open source.
~spot
14 years, 4 months
Re: [Fedora-legal-list] nautilus-dropbox question
by Tom Callaway
On 07/28/2009 05:48 PM, David Cantrell wrote:
> As there is nothing to patch, I guess this makes nautilus-dropbox destined for
> the ForbiddenItems list. The contents of ~/.dropbox-dist is handed to you by
> www.getdropbox.com when you run "dropbox -i". It's already built and
> self-contained at that point. The only thing that one could possibly do is
> remove libraries and commands in ~/.dropbox-dist and symlink to the ones on
> the system, but that seems like a lot of work for nothing and no guarantee
> that it'll work.
>
> Sad. Dropbox is actually a really cool service.
Can't you patch the dropbox "setup thing" to not be stupid? :)
~spot
14 years, 4 months
nautilus-dropbox question
by David Cantrell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm not sure if this has been discussed before, but I'd like to package
nautilus-dropbox for inclusion in Fedora. There are a few concerns I have and
if this program is something destined for the ForbiddenItems list, I'd like to
know that before I go and package it.
First off, what is nautilus-dropbox? If you head to www.getdropbox.com,
you'll find information about the Dropbox service from Evenflow, Inc. There's
a neat video you can watch on the site. In short, it's a shared folder that
you can use across multiple computers. Makes it easy to sync up projects and
files.
nautilus-dropbox is a GPL'ed component they wrote for GNOME desktops. This is
the part you download from them and install. The provide packages for Ubuntu
and even a Ubuntu deb repository, but nothing for Fedora beyond Fedora 10.
I'd like to skip to just including nautilus-dropbox in our repos if possible.
Questions and concerns:
1) nautilus-dropbox is licensed under the GPL, but the image files they
include in the package are not. Specifically, it says:
All images included in this package constitute data and are not licensed
for you to use under the terms of the GPL. You may not use the images
included in this package for any reason other than redistributing
this package without first obtaining permission from Evenflow, Inc.
You are explicitly forbidden from using these images in any other
software package. This includes the files:
data/icons/hicolor/16x16/apps/dropbox.png
data/icons/hicolor/22x22/apps/dropbox.png
data/icons/hicolor/24x24/apps/dropbox.png
data/icons/hicolor/32x32/apps/dropbox.png
data/icons/hicolor/48x48/apps/dropbox.png
data/icons/hicolor/64x64/apps/dropbox.png
data/icons/hicolor/64x64/emblems/emblem-dropbox-syncing.png
data/icons/hicolor/64x64/emblems/emblem-dropbox-uptodate.png
data/icons/hicolor/64x64/emblems/emblem-dropbox-unsyncable.png
While it appears we can redistribute them with nautilus-dropbox, users would
not be allowed to use these images for other things. Is replacing them
sufficient for Fedora packaging? What about the pristine source? Can they be
left in the source archive or does that have to be scrubbed?
2) nautilus-dropbox itself is a small piece of the larger dropbox client
system. When you install it, it will determine if you have ~/.dropbox-dist on
your system. If you don't, it will run the dropbox setup "thing", which
downloads dropbox-dist from Evenflow for your system and places it in
~/.dropbox-dist. The contents of ~/.dropbox-dist are precompiled variants of
all of the libraries and programs they need to run. Dropbox appears to ignore
the system versions and just has you use whatever they include.
This isn't really part of nautilus-dropbox, it's just installed by the setup
program on the first run. The concern here is do we care about programs that
download large wads of precompiled software and stuff it in dot directories?
Thanks,
(When replying, please include me directly because I'm not on
fedora-legal-list.)
- --
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpvbHIACgkQ5hsjjIy1Vkl8oACgiCGSoRsv79ryyKjqJN3muuvM
1pkAoInXZ9Hkt0XKjoNdMCxFdxW/zhr1
=yTzN
-----END PGP SIGNATURE-----
14 years, 4 months
aria2 license
by Rahul Sundaram
Hi,
http://aria2.sf.net was marked as GPLv2 so far. I recently took over the
package and noticed that the license is actually GPLv2+ with an
exception for OpenSSL. That doesn't seem to be specifically covered
under the licensing page.
I have marked it as GPLv2+ with exceptions in the latest rawhide update.
If someone could verify this, it would be useful.
Rahul
14 years, 4 months
Openssl license "infectivness" and GPLv2 compatibility
by Michal Hlavinka
Hi,
I'm maintaining apcupsd package. Apcupsd itself is under GPLv2 license.
Apcupsd daemon in this package is linked against a few libraries including
net-snmp and openssl.
licenses are (based on License tag in rpm):
OpenSSL : OpenSSL
net-snmp : BSD and MIT
I'd like to know answers for these questions:
1) Is apcupsd allowed to link against openssl since openssl seems to be
incompatible with GPLv2? [1]
2) Because net-snmp itself is linked against openssl, should not its license
in fact be BSD and MIT and OpenSSL?
3) If apcupsd is not allowed to link against openssl, is it allowed to link
against net-snmp which is linked against openssl?
Cheers,
Michal Hlavinka
[1] http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-
incompatible_licenses
14 years, 4 months
netcdf-perl license
by Orion Poplawski
Currently, the netcdf-perl package license is listed as "NetCDF". The
text of the license was recently changed to make the crediting
UCAR/Unidata a non-obligitory request.
I've attached the copyright file. I'd appreciate whether knowing
whether I should change the text of the License field.
Thanks!
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
14 years, 4 months
