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

Re: Firmware & Social Contract: GR proposal

Anthony Towns <aj@azure.humbug.org.au>
>     Since it appears Debian has to make a choice, which would you=20
>     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

As far as I can see, those choices are not orthogonal.

>     Developer only poll: (83 votes) [2]
>         Option 1 Release etch on time
>         Option 3 Support hardware that requires sourceless firmware
>         Option 2 Do not ship sourceless firmware in main
>         Option 4 None of the above

...and nor are these.

>     (a) The Social Contract shall be reverted to its original form,
>         as at http://www.debian.org/social_contract.1.0

However, that version imposes the same requirements.  It was merely
rephrased in an attempt to clarify the communication, with the hope of
stopping some attempts to put non-free in main.

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

This is nonsense, the equivalent of defining pi to be 3.  The rest of
the proposal is flawed as a consequence.

> Personally, I think it's a mistake to have a social contract that we
> can't meet [...]

There is no reason that we can't fulfil the social contract.  We may not
do so in the near future, but that does not make it impossible, or make
working towards it any less desirable.

> It's fair to ask whether interpreting "software" to not cover all sorts
> of other things we distribute is a sensible thing to do, [...]

The social contract does not cover other things that we distribute.
It covers software and should cover all software in the distribution.
The discussions about what aims should cover other things (like money)
are still on-going in other threads.

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

There are people interested.  I think us mere mortals have been hindered
by the slowness of the DPL and SPI on these topics.  We could GR it,
but there doesn't seem much objection - just inaction.  If this DPL
states clearly he will not work on this, I'll propose a GR in a bit,
but I've been flamed before for suggesting uncontroversial GRs.

IIRC, Mako has proposed trademark terms, and Greg Pomerantz(sp!) has
posted a draft licence to spi-trademark, probably in 2005.  Next on the
trademark, it needs SPI board to approve the terms, but I guess they
want to deal with the long-running Spain trademark problem first.
(How many months does it take SPI to talk to a lawyer?  Tune in next
year and find out.)

On the logo copyright, the DPL needs to instruct SPI to change the
licence.  The last discussion I can find is in 2004-10-05 minuted in
where it was deferred to 2004-11, but it doesn't appear on 
nor did I find it being referred to debian-legal in 2004-10.

Past DPL Branden Robinson wrote "I think we should leave the Open Use logo
basically unencumbered by copyright" in
but didn't fix it during his DPL term AFAICT.

So, would this DPL like to be the one to take active leadership and
fix the dumb debian logo bug?

Here's hoping,
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct

Reply to: