[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Debian, KDE and the GFDL problem
From:       Isaac Clerencia <isaac () debian ! org>
Date:       2006-01-05 8:47:24
Message-ID: 200601050947.25066.isaac () debian ! org
[Download RAW message or body]

Hello list, 

As many might be aware, the Debian project has been concerned about the
non-freeness of the GNU Free Documentation Licence for a few years
already, and although conversations with the Free Software Foundation
have been ongoing for at least four years, we don't know if our
legal advise to the FSF will end up in a new GFDL version being
published that addresses the problems in time for the new Debian
release (Etch, which will be released in December 2006).

Due to some changes[0] to the wording of the Social Contract[1] made by
the Debian project, it was decided that the principles of freeness
described by the DFSG would need to apply to all works included in the
Debian archive, not only software. This, of course, includes
documentation licensed under the GFDL.

This week, Debian Developer Anthony Towns sent an email proposing Debian
to release a statement[2] that would make the Project's position with
respect to the GFDL official and mandatory. This is expected to be voted
upon in two weeks, and it's highly probable it will pass with a broad
majority.

For detailed information on why Debian thinks the GFDL is not
acceptable, see Manoj Srivastava's "Position Statement" document[3] on the
subject.

Now, sorry for this long introduction, but I didn't expect kde-devel
readers to know what's going on in the debian-vote battlefield. :)

When this vote concludes, Debian maintainers will be forced to get rid
of non-free documentation, including GFDL docs, from the .debs and
.tar.gz's. Today, the team of developers in charge of packaging KDE in
Debian (known as Debian Qt KDE team), started to realise that if we don't
start doing something about it now, we might be delaying the etch
release, given the amount of work that removing the works covered by the
FDL in KDE modules is.

We basically have two practical options, because we better not wait for
the FSF to make the required changes to the GFDL:

1) Edit KDE tarballs for every version of every module including a
   GFDL'ed manual and repackage them without them.

   This would be a great amount of work, and would leave Debian without a
   single user manual for our users to read up in Yelp. I guess we could
   get rid of khelpcenter too. :)

2) Convince manual authors to a) relicense their works under the GPL, or
   b) double-license them under both the GFDL and GPL.

I personally vouch for 2b) as it gives more choice to people, and doesn't
change the current licensing situation too radically. Also, for reasons
explained in the previously mentioned documents, having different
licences for a program and its documentation is a bad idea, and dual
licensing takes care of that too.

The members of the Debian Qt KDE team are interested in what the KDE
project thinks about this problem. If you think relicensing the manuals
is a good idea, we'd have to ask for relicensed works in the future and start 
a hunt of every copyright holder to get permission to relicense the manuals.
Of course, we would help as much as possible to make this happen.

This problem is not KDE specific. A long list of GNU packages and GNOME
modules are on the same boat, according to members of the Debian GNOME
team, who have approached the GNOME project with this same concern,
in an attempt to fix the problem on their end. (in fact this mail is a 
filtered version of the one sent to the GNOME list [4].

Thanks,
Isaac

[0] http://www.debian.org/vote/2004/vote_003
[1] http://www.debian.org/social_contract
[2] http://lists.debian.org/debian-vote/2005/12/msg00115.html
[3] http://people.debian.org/~srivasta/Position_Statement.xhtml
[4] 
http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00033.html

-- 
Isaac Clerencia
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]