Re: Bits from the DPL: Freedom and etch hik :-) At skimme, ny mail
On Monday 28 August 2006 20:35, Anthony Towns wrote:
> Hello, world!
>
> As a project, Debian is heavily committed to the ideals of free software.
> That's not news to anyone reading this, I'm sure, as it's something
> we've constantly worked to improve, whether that be by establishing our
> Social Contract and the Debian Free Software Guidelines or by working
> with other organisations such as Software in the Public Interest [0],
> the Free Software Foundation [1], the Open Source Institute [2], or
> Creative Commons [3] to further promote those ideals.
>
> Another two major steps we have made towards the ideal of software
> freedom over the course of the project has been removing the need to run
> non-free software to contribute to Debian -- made possible by Werner
> Koch's development of the GNU Privacy Guard (gnupg/gpg); and removing
> the need to run non-free software on our own servers, which was completed
> in May 2000 when we switched from qmail to postfix and exim for handling
> debian.org email [4].
>
> The most recent efforts in relation to this ongoing goal have been in
> paying increased attention to the freedoms provided for works other than
> regular applications and libraries -- most notably documentation [5].
>
> I believe the current expectation is that there will be absolutely
> no problems ensuring that the Debian System will not only be composed
> entirely of free applications and libraries, as it has for years, but
> also of free documentation, free graphics, free videos, free fonts,
> and free drivers.
>
> At this point, there seem to be only three areas where we won't easily be
> able to meet the goal of everything in the Debian System meeting the DFSG:
>
> (a) License texts only rarely explicitly allow other authors to create
> new, derivative licenses based on existing ones -- you either
> use what's there, or get your own lawyer to draft something in
> their own words.
>
> (b) We generally aren't able to consider distributing truly large
> "source" files, including losslessly encoded video, geographical
> data sets, or the complete design specification for some fonts.
>
> (c) A number of drivers in the Linux kernel include firmware to be
> uploaded to the chipsets they support that is provided as
> either a sequence of hex codes, or as a separate binary file --
> while modifying the code is allowed, in many if not most or all
> such cases, the firmware is effectively being provided without
> useful source.
>
> License texts themselves are not an easy issue to resolve, but this is
> somewhat balanced out by that generally not being necessary -- and indeed
> while we do encourage people to come up with modifications to software
> they use, coming up with new and modified licenses is often a much worse
> idea than reusing an existing free license, even if it has flaws.
>
> Large source files and how we should deal with them have been an
> unresolved concern for a long time -- Bug#38902 might give you some idea
> just how long. Up until now we've dealt with it by simply packaging the
> source in the form that we need it -- for which a reduced or compressed
> form almost always suffices. It will probably be some time yet before
> we can come up with a sensible technical approach here that balances out
> the bandwidth and storage usage appropriately.
>
> Firmware, however, is a much more immediately resolvable issue -- and
> one that has already progressed signficantly over the past few years
> as Linux's interface for loadable firmware has improved, and hardware
> manufacturers gradually become more comfortable with releasing free
> drivers and free firmware.
>
> The major problem remaining for Debian in handling that, is that we
> don't have a good way of supporting installs on hardware that needs
> firmware that we don't have source for and have separated into the
> non-free component. Joey Hess summarised the problems in dealing with
> that to the -vote list [6] and estimated six months of work developing
> the appropriate support in the installer, with presumably more time
> needed after that for testing and quality assurance.
>
> So the question is what should we do here? One approach would be to say
> "we're committed to making the Debian System completely free, so until
> that's done, we're not ready to release". Another is to say "we've made a
> lot of improvements since sarge, on this score and others, so let's get
> etch out now, and move onto the next bit after that". A third is to say
> "we've committed to getting etch out, and to making it be completely
> free -- if that means not supporting a range of hardware, so be it".
>
> One way or another we're going to have to make a decision on what
> approach to take fairly soon -- and general resolutions on how to square
> up the approach we take are already being discussed on the debian-vote
> list. Personally, I'd appreciate knowing which of the above goals Debian
> users and developers actually think are the most important before deciding
> I'm going to approach them; and to that end Jeroen van Wolffelaar has
> kindly setup a couple of polls you might like to vote in.
>
> Two polls for users are hosted on forums.debian.net [7] to all registered
> users, asking:
>
> What is the most important for the release of Etch?
> Release on time (early december)
> Do not ship sourceless firmware in main
> Support hardware that requires sourceless firmware
>
> and
>
> Since it appears Debian has to make a choice, which would you prefer we
> do? Allow sourceless firmware in main
> Drop support for hardware which requires sourceless firmware
> Delay the release of etch
> (so that we can support loading firmware from non-free)
>
> Unfortunately you can't indicate your preferences, so you have to choose
> one of them. You can leave comments, on the other hand; though I'm afraid
> it's unlikely we'll be making "CowboyNeal" the most important priority for
> etch no matter how many times it may be suggested as a write-in candidate.
>
> Additionally Jeroen has setup a developer only poll [8] that does allow
> preferences and is authenticated via GPG signatures in the same way
> regular Debian votes are. Unlike regular votes, however, the current
> results of the vote will be available before voting has closed.
>
> Note that both these polls are just an informal way of finding out what
> people think, and while they will be considered and taken into account,
> they won't necessarily be the final word on the matter.
>
> Thanks for your time!
>
> Cheers,
> aj
Reply to: