Re: Firmware & Social Contract: GR proposal
On Tue, Sep 05, 2006 at 08:04:59PM +1000, Anthony Towns wrote:
> If you consider our ideals to be the original social contract, applied
> to programs not images and firmware, we've been meeting and improving
> upon our ideals every year and every release.
The reason why your proposal is fundamentally broken, is that firmwares are
programs, even though some would hypocritically deny it.
You cannot name a piece of software which runs on a mips or arm core on a
peripheral processor anything but a program.
> If you consider our ideals to be the current social contract, we've been
> violating them and compromising them and apologising for not meeting
> them every year and every release since we adopted it.
Indeed. But the ideals are something higher that is worth working to achieve.
If you place the bar lower, you will end up not reaching that either, and in
the end will have to go lower again and so on.
> > > 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.
>
> AFAICS, Steve's proposal is a permanent exception to DFSG#2 for images and
Steve's proposal is as flawed as yours, in the way it does things.
> firmware that's not tied to etch's release; Joss's is temporary, tied to
> the the development of "technical measures" that will allow firmware to be
> separated; Don's isn't an exception at all, and won't allow us to release
> etch on time without a further proposal; and Frederik's is an exception
> just for etch, in the same way the last reversion was an exception just
> for sarge: one that may well be repeated next time if nothing getsdone.
Frederik's proposal is a common position from the kernel team and the release
team, as it was originally drafted with input from various people of that
team, and predated all the other proposals by a couple of weeks.
It explicitly gives an exception for etch only, because we are confident that
the issue can be solved in the etch+1 timeframe. if we really wanted (and had
two man-month of full time paid work for example), we could probably even
achieve the whole thing for the etch timeframe, with proper cooperation from
the respective teams, altough it would delay d-i testing beyond what the d-i
team is confortable with.
> > So, why do you want to reopen the debate about it ?
>
> Because I don't think we ever had a debate on it, and I don't think it's
We did indeed have a debate on this during the last of the sarge non-free GRs.
> working out for us. The ballot that chose the current social contract
> didn't have any alternatives included, and was conducted immediately
> following the constitutional amendment to allow voting on non-free
> removal, the non-free removal debate itself and then the DPL elections,
> with only minimal discussion on -vote, most of which occurred prior to
> the non-free vote.
It was ratified by a large majority though, and i clearly remember 4-5 options
on that ballot.
> > 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.
>
> There are two social contract texts we have a reasonable understanding
> of -- the original one we had, and the new one we've got. Both have
> significant flaws, in my opinion, but I'd much rather have one that we
> can meet and exceed than one that we've repeatedly demonstrated we can't.
Well, i believe that both of them basically said the same thing. I seriously
doubt that if folk had thought about non-free firmware all those years ago,
they would have decided differently (altough i was not there, but from the
position of those who where, like Manoj, i think this was indeed the case).
Also, you seem to conveniently forget all the keep-non-free GR and discussion
preceding it, which largely discussed non-free kernel drivers and firmwares.
> > 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.
>
> I think:
>
> (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.
And the rest is what ? Hardware ?
> is pretty direct, even if it's not your preferred definition of the word.
Well, it leaves a elephantesk sized hole for any kind of abuse and
misinterpretation.
> But yes, discussing the relative priority of having various things in
> main is exactly what we should be doing, so that we can decide to devote
> energy to fixing logo licenses, or making d-i handle non-free udebs,
> or whatever else.
Indeed, then way come back on the software vs program thingy, and retriger
another 3+ month of discussion and voting ?
Is this some clever plan to delay etch because we would lose time discussing
Grs and issues, so your position on the release management thread is justified
? :)
> > 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, [...]
>
> Yes, I completely agree. The fact that "contrib" and "non-free" are
> specifically named in the social contract makes that somewhat hard,
> though. Is it against the social contract to create an area that includes
> non-free stuff called "restricted", eg? After all, the SC says that we
> created the "non-free area" for those works...
No, we have a subsection of non-free called non-free/distributable or
non-free/firmware or something such. No need to go into ubuntuesk vocabulary
redefinition or something such.
> > > 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 ?
>
> Each of those logos are covered by a restrictive copyright license,
> instead-of/as-well-as a restrictive trademark license.
Ok.
> If you take one of those logos, and change it completely so it doesn't
> look similar to the original at all, you're not infringing the trademark,
> but you are infringing copyright -- which makes it non-free...
Indeed. One would claim that if you change it completely, so that there is no
semblance to the original, you might just as well start from scratch :) Or
more to the point, that nobody can prove in court that the new logo is indeed
a derivative work of the original one.
We really would need real legal advice on this kind of stuff, instead of just
guesses coming from our mostly-program-code experience.
> > > 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.
>
> My original mail was a bit strong, so I'm not really surprised. It's
> hard not to get worked up about this after so long, at least for me.
Yeah, but given my situation these last months, i prefer to state it clearly,
as to avoid misunderstandings.
Friendly,
Sven Luther
Reply to: