Hi all,
It's been a week, and the results from the three polls concerning what to
do about firmware are currently:
What is the most important for the release of Etch? (202 votes) [0]
Release on time (early december) 57%
Support hardware that requires sourceless firmware 26%
Do not ship sourceless firmware in main 15%
Since it appears Debian has to make a choice, which would you
prefer we do for etch? (197 votes) [1]
Allow sourceless firmware in main 63%
Delay the release of etch (so that we can support 18%
loading firmware from non-free)
Drop support for hardware which requires sourceless 17%
firmware
Developer only poll: (83 votes) [2]
Option 1 "Release etch on time"
defeats option 3 by 23 votes (51:28)
defeats option 2 by 52 votes (67:15)
defeats option 4 by 71 votes (76: 5)
Option 3 "Support hardware that requires sourceless firmware"
defeats option 2 by 39 votes (60:21)
defeats option 4 by 69 votes (74: 5)
Option 2 "Do not ship sourceless firmware in main"
defeats option 4 by 41 votes (59:18)
Option 4 "None of the above"
comes last
Obviously each of those polls only includes a self-selected minority of
the people they try to cover, but the results seem fairly consistent both
with each other, and what's been discussed so far on this list.
It therefore seems to me as though we're going to be failing to meet the
social contract again, and as a consequence I think we should seriously
reconsider whether the change we made in 2004 was the right one. So I'd
like to propose the following course of action for consideration:
----
The Debian Project resolves that:
(a) The Social Contract shall be reverted to its original form,
as at http://www.debian.org/social_contract.1.0
(b) The term "software" as used in the Social Contract shall be
presumed only to cover programs, scripts, libraries and similar
executable works to be executed directly as part of the Debian
System.
(c) In addition to the commitments made in the Social Contract,
the Debian System shall only include documentation, images,
sounds, video, fonts and similar works that meet the Debian
Free Software Guidelines, and are available in some reasonably
modifiable form.
(d) Notwithstanding the above, the Debian Free Software Guidelines
shall not be applied to logos, firmware or the text of copyright
licenses that may be included in the Debian System.
(e) Following the release of etch, the Debian Project Leader shall:
i. ensure that the Debian community has a good understanding
of the technical and legal issues that prevent the Debian
Free Software Guidelines from being applied to logos and
firmware in a manner that meets the needs of our users;
ii. ensure that project resources are made available to
people working on addressing those issues;
iii. provide a report to the Debian community on progress achieved
in these areas at DebConf 7 in Edinburgh.
(f) Following the release of etch, the Debian Project as a whole shall
reopen the question of which commitments should be codified in the
project's Social Contract. This shall including both an online
consultation with Debian users, Debian derivatives and the free
software community, and a public in-person discussion and debate
at DebConf 7 in Edinburgh in honour of the 10th anniversary of
the original publication of the Social Contract on the 4th
of July 1997.
----
Personally, I think it's a mistake to have a social contract that we
can't meet -- I would much rather say "we're not only meeting our social
contract, but we're going above and beyond it" than keep worrying about
how we've overpromised and keep having to underdeliver.
I think (e) is an important part of meeting our users' expectations,
as well as our own, that committing to releasing etch on time won't be
a permanent cost to our efforts towards free, sourceful firmware. I'm
happy to commit to it, and I presume whoever's elected DPL next year
will say during the campaign if they will or won't commit to it too,
so the project can take that into account. If people think that point is
worth adding to any of the other proposals that defer the free-firmware
issue to post-etch, that's fine by me.
It's fair to ask whether interpreting "software" to not cover all sorts
of other things we distribute is a sensible thing to do, whether on a
principled level ("but we *want* those other things to be free too"),
a logical level ("what about postscript, or self-extracting zip files of
documentation?") or a semantic level ("software means bits, it doesn't
mean executables"). But it seems to me that the current answer we have
to that question is not working -- and given the length of time we've
already had, I don't think there's a great likelihood that that will
fundamentally change any time soon. I think it would be a waste of time
giving it yet another chance instead of spending the time coming up with
something better. So personally, I think we really do need to start this
debate afresh, hence (f).
TTBOMK the Debian, Firefox and Thunderbird [3] logos all currently have
non-free copyright licenses acting as trademark protection, hence the
specific exception for logos, given images are mentioned previously. To
date, no one else has been particularly interested in helping work out
what we want to do about protecting the Debian logo by trademark instead
of (non-DFSG) copyright provisions.
I believe that 5.1(5) of the constitution allows the project leader to
propose draft resolutions/amendments without requiring the usual seconding
process (cf [4]). I'm not intending to exercise that power here; please
consider the above to be my personal view as a developer.
Seconds and comments appreciated.
Cheers,
aj
[0] http://forums.debian.net/viewtopic.php?p=31126
[1] http://forums.debian.net/viewtopic.php?p=31128
[2] http://master.debian.org/~jeroen/polls/firmware/
[3] http://www.mozilla.org/foundation/trademarks/faq.html
[4] http://www.debian.org/vote/1999/vote_0002
Attachment:
signature.asc
Description: Digital signature