[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Firmware & Social Contract: GR proposal

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:

These polls are USELESS.

They all show that people want to release Etch quickly.  This can be done
either by shipping stuff in violation of the SC, or by dropping stuff which
is in violation of the SC.

They provide no information on which people prefer.

Please try again.

> 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.

And they give no information.

> It therefore seems to me as though we're going to be failing to meet the
> social contract again,

False assumption.  The polls all say "release etch on time".  This is easy
to do by dropping hardware support.  You constructed the polls badly by
muddling two issues together.

> 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

....which Debian was obviously violating by shipping the
sourceless "firmware"....

>     (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.

First of all, this would mean that it covers "firmware".

Second, this would presumably cover .tex files, .texi files, .ps file, and
all other similar interpreted programs.

>     (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.

Oh, I see, this is the "We'll just write ourselves a big loophole" option.
(d) explicitly contradicts (a), (b), and (c).

It would be more honest to amend the Social Contract to admit this.

>     (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.

Previous and current DPLs have not done any of this yet; why should we
believe that the DPL will do this next time?  :-/  It seems like a 
commitment which isn't going to actually work.

>     (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.

This is reasonable.

Remember that this proposal requires a supermajority.

> ----
> 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.

Full agreement on that.

> 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").

It should cover them all, for all three reasons.  :-/

> 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 can only attribute this to obstructionism.  Practically, this is happening
because a small minority of developers have been staunchly opposed to fixing
any such legal issues.  This is the definition of "obstructionism".

> I think it would be a waste of time 
> giving it yet another chance instead of spending the time coming up with
> something better.

Watch out.  It's pretty clear what the majority thinks, and what the 
majority thinks is that the current answer is correct in the long run, even 
if it's not currently achievable.  :-/

> 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,
Which we all agree is BAD BAD BAD.

> 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.

100% FALSE.  Trademark licenses have been designed and proposed.  We have
been trying to get a legal opinion from SPI's lawyer.  We can't.  The
previous DPL and other people of "authority" in Debian have been unwilling
to change the licenses until we get such an opinion.  More obstructionism. 
Perhaps you can help by getting me a direct hotline to SPI's lawyer.

> 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.

When you wrote this, you were clearly not fully aware of the situation, so
please try again.

Nathanael Nerode  <neroden@fastmail.fm>

Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...

Reply to: