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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]