Re: Firmware & Social Contract: GR proposal
On Tue, Sep 05, 2006 at 05:44:04PM +1000, Anthony Towns wrote:
> 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.
Ok, this seems indeed obvious, from the discussion that followed, and the
general consensus, but ...
> 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:
... you do a gigantic leap to this conclusion, which is not at all waranted by
the above poll.
The idea was that it is too short until the etch release (actually it is way
too late, since kernel freeze was in early august) to solve the non-free
firmware issue, and your little poll clearly stated that this was a poll aimed
at releasing etch on time, not to revert the decision already taken on this
subject.
> ----
> 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
So, we can include GFDL documentation, and other non-free stuff in main again ?
> (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.
Nice, especially as firmware falls more often than not in this category.
> (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.
Oh, so you revert the social contract to the older wording, which fails to
consider most firmware cases, and then make a special exception for all those
non-firmware stuff we already removed ?
> (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.
And then grant a special excemption, not for the duration of the etch release,
but in general for firmware. I wonder what was the rationale for (a) then ?
Could you not have written the same without reverting the social contract to
its older form ? This only adds to the confusion instead of clarifying it.
> (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;
So, you plan to pay folk to explain to the world at large why debian should
not apply the DFSG to firmware programs :)
> 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.
Mmm.
I dislike this way of doing it, you want to, instead of making an exception
for etch, generalize the situation, and then come back in a year or so, to
finally solve the issue.
> ----
>
> 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.
Bah. The above wording sounds much like compromising our ideals in order to
release etch, however you word it. I would much prefer us to be clear and
honest about this, and clearly state, as we did for the GFDL documentation and
others for sarge, that altough we worked in order to achieve it, we have not
yet reached it for the etch release, and are thus postponing the issue for
etch+1.
> 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
How can a commitment to release *ETCH* on time be a permanent cost, i mean,
once etch is out the door, it won't matter anymore to the solution of this
problem.
> 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).
So, why do you want to reopen the debate about it ? I mean, the problem is not
really if firmware or fonts or whatever is software, but what we want to have
in main or not. These are fully orthogonal issues, and all those arguing that
we should accept firmware in main because it is not 'software' are misguided
at best, and misleading at worst.
Let's be open and direct, all the stuff which goes on the debian cds and/or is
in debian archive is software, and then discuss the relative priority of
having it in main or not.
Also, your position here totally fails to address the situation of non-free,
which was especifically created for things like this, and instead of renaming
firmware as data or classifying stuff as non-software, it would be much better
to commit to a long-term clarification of the usage of non-free, starting by
adding categories to it (can-be-distributed being the most interesting one),
having it autobuilt, as well as claryfying the wordings of the social
contract where non-free is referenced, and not saying the hypocrit non-free is
not debian, but instead saying something more truthful, like the "non-free
appendix of the debian system".
> 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
Mmm, i am not sure, but does the DFSG really include not-trademarked (or
not-patented) claims ?
> 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.
Mmm.
> Seconds and comments appreciated.
I hope those comments will be useful, they may be seen a bit strong or
whatever, but i hope you will be able to see past the wording to the content.
Friendly,
Sven Luther
Reply to: