Debian Weekly News - email

Date: Mon, 01 Nov 1999 19:30:00 -0500
From: Erich Forler <kf4548w2@umail.corel.com>
Subject: Status of Corel's Front end to Apt
To: <debian-legal@lists.debian.org>
I'm the Product Development Manager for Corel Linux and I hope it's
appropriate to provide a brief clarification on Corel Update (otherwise
referred to as the Front end to Apt and formerly known as Get-it) to
make sure there is no misunderstanding.
Corel Update is an application which dynamically links to libapt. When
the issue was identified to us, we contacted Jason, set the license on
our code to GPL and asked for an exemption to resolve the issue with the
Qt library as quickly as possible. Jason agreed to an exemption for QPL,
but since we're currently using Qt 1.44, we need an exemption for the QT
Free license. So as far as the license on the Corel code goes, there is
no issue since it is GPL. The only known outstanding issue to resolve is
that of the link of the Qt library under the Qt Free license and libapt
library under GPL. (As yet, we haven't been contacted by Ian, but if he
does, then that may raise another issue)
What I think is most important to gain from the previous discussion is
that interpretation of the GPL is a major issue and everyone involved
should try to help the GPL evolve to a state that is above all free from
ambiguity. The issue raised by Ian is not so much an issue for Corel to
address as much as it is something the development community has to
resolve itself first since its implications extend far beyond Corel
Update.
Richard Stallman has had some communication with one of our engineers
and I've started a document outlining some of the areas that Corel's
legal department was concerned with. Unfortunately, I haven't finished
it and sent it off to Bruce Perens and Richard yet. I would also like to
emphasize that it is not Corel's objective to propose modifications to
the philosophy of the GPL or to modify its intentions but to help
identify areas in need of clarification so that discussions like this
one can be finally resolved. Every time a developer or company falls
into a gray area of the license, it discourages the use of GPL code. As
a result, ambiguity and uncertainty in the GPL will work against greater
adoption and development of GPL software.
Erich Forler
.

Date: Tue, 2 Nov 1999 23:36:59 +0100
From: Richard Braakman <dark@xs4all.nl>
To: debian-devel-announce@lists.debian.org
Subject: Status of Potato
(Please send followups to debian-devel, not debian-devel-announce)
Potato looks ready to freeze. Its primary goals have been achieved,
and the only things left to do are to finish the bootdisks and fix
lots of bugs. I think it is advisable to freeze now, before we
start major new developments in potato.
Last weekend has shown that the bug count can be reduced rapidly
in intense sessions. We'll need more of those, and probably a large
number of packages will also have to be removed from frozen.
The freeze will be the coming weekend, on Sunday, November 7th.
Before the freeze, we will have to deal with the backlog in Incoming
somehow. There are more than 200 packages in it now and it's growing.
Help is on the way, but probably not in time. In any case, I do not
think it is wise to install a hundred new packages just before the
freeze! My plan is to handle all the packages that fix bugs, and
leave the rest for the new unstable.
After the freeze, I expect it will take a week or two for frozen to
settle down. A lot of bugs can be fixed in that time. This period
will be similar to the traditional freeze.
Then we can start with Test Cycles. These will address the problems
we had with the previous two freezes. A Test Cycle looks like this:
1. Boot disks and CD images are created.
2. The distribution is tested for a fixed amount of time. No changes
of any kind will be made to frozen during this time. Fixes for
problems that are discovered will of course be prepared, but they
will not be installed yet.
3. The results are evaluated. If the distribution is good enough to
release, it is released as it is.
4. Otherwise, fixes are installed, and if necessary, extra time is
taken to fix the problems.
5. New boot disks and CD images are created, and the cycle begins again.
Richard Braakman