Re: Bits from the DPL: Freedom and etch
Anthony Towns wrote: > (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. It would have been very helpful, Anthony, if you had linked to the list of *exactly* what drivers are at issue. (And exactly what the legal issues are for each one: GPL-without-source and no-license-text drivers are serious and separate issues, and affect far more drivers than properly-licensed sourceless firmware affects.) I suggest a d-d-a post adding this link: http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: Freedom and etch
On Tue, Aug 29, 2006 at 12:39:03PM +0200, Pierre Habouzit wrote: > I'm very suprised by that mail that completely forgot to mention the > ongoing discussions about a GR about firmwares. There is already three > proposals for that GR[1] and I wonder why those have not been > mentionned. Err, but it did: ] 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. [...] ...? > The current amendments all have the > corrolary that etch won't be delayed, either because an exception will > be proposed (don's proposal) TTBOMK, Don's proposal doesn't actually include that exception, just mentions that it would be a possibility. > So question to the DPL: I really wonder why a formal announce of that > unofficial poll has been made, instead of encouraging people to review > the amendments that have been proposed, and even propose a new one if > needed, so that that GR can come, and that we know where we are going > instead of guessing. There isn't a secret agenda here -- I'm planning on using the information from those polls to work out what I'll focus on as far as the GRs are concerned. Others probably will too, while still others will make up their mind entirely on their own, or possibly already have. Personally, I also think it's worthwhile having some announcements that focus on what we've actually achieved, rather than the controversies generated by the few things that are still on our TODO list. YMMV. Cheers, aj signature.asc Description: Digital signature
Re: Bits from the DPL: Freedom and etch
Le lun 28 août 2006 20:35, Anthony Towns a écrit : > Hello, world! > > […] > > 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. I'm very suprised by that mail that completely forgot to mention the ongoing discussions about a GR about firmwares. There is already three proposals for that GR[1] and I wonder why those have not been mentionned. I'm also worried that the debate seems to be presented as "relase etch in time and put firmwares in main" versus "care about firmware freeness and release later". That's not what has been discussed on debian-vote for one or two weeks already. The current amendments all have the corrolary that etch won't be delayed, either because an exception will be proposed (don's proposal) or because we don't care about firmware until we have a viable technical solution to do the split (joss's proposal) or because we decide that firmwares are not programatical things (steve's proposal). Given that, and that you are not able to assure the users that the result of their poll will be followed: * I fear that the issues of those polls would put pressure on the GR voters, * I also fear that if the GR issue is not what the polls showed that the user wanted, we will have a hard time to cope with our angry users, that will feel they have been made as a fool of that story. So question to the DPL: I really wonder why a formal announce of that unofficial poll has been made, instead of encouraging people to review the amendments that have been proposed, and even propose a new one if needed, so that that GR can come, and that we know where we are going instead of guessing. [1] http://lists.debian.org/debian-vote/2006/08/msg00032.html http://lists.debian.org/debian-vote/2006/08/msg00215.html http://lists.debian.org/debian-vote/2006/08/msg00185.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp5nZKmCUBrq.pgp Description: PGP signature
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 wh
