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

Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware

On Thursday 05 October 2006 17:19, Frank Küster wrote:
> I can understand that.  However, I'd rather have that discussion before
> the GR than after it, when it turns out that people do *not* agree about
> the meaning of it...  

Sure. However it makes no sense having a discussion about individual blobs 
or, even worse, about whether these are distributable under the GPL at all. 
As Steve has pointed out repeatedly, that last responsibility lies with the 
maintainer (the kernel team) and the FTP masters, not with debian-vote.

All that was asked for (at least after AJ withdrew his initial proposal) was 
to allow the RMs (in collaboration with the kernel team and maybe the d-i 
team) to decide what was acceptable and practical for the Etch release and 
what not. And from the fact that Steve was the first person to spot 
the "regression" in the kernel packaging that previously excluded firware 
was being included again I feel that the project would have done well to 
trust their judgement.
This whole discussion on vote has gone off on absurd tangents with (several) 
people who are not lawyers making even more absurd statements about 

How the hell do you expect a list discussion between non-qualified people 
_ever_ come to a conclusion instead of degenerating into flamewars?

I have two times proposed to postpone the detailed analysis of the firmware 
situation until after the release, and I still feel that that is where it 
belongs: not on the list, but with a (delegated) team of developers who 
have access to proper legal advice and can study the implementation issues 
surrounding it in relative quiet and can prepare a position statement (with 
alternatives) that can _then_ be voted on.

> And I know that Sven Luther is able to rise high 
> emotions, but still it seems to me that what he says *is* reasonable.

Sorry, my comments were general and aimed at several persons participating 
in the discussion. (Though it would be foolish to deny that Sven was one of 
them. And it is also no secret that I find Sven's total domination (as 
evidenced by the sheer volume of mail he sends, his endless repetition, his 
tendency to take disagreement as a personal insult of his intelligence, his 
apparent inability to properly read and really consider arguments from 
others before fiering off a reply and his apparent need to always have the 
last word) of any discussion which he remotely cares about totally 

The crazy part is where people _say_ they are seeking consensus, but instead 
keep firing off amendments that draw further and further away from the 
original goal of the GR and only serve to confuse the vast majority of 
people why try to follow the discussion.

> > So, no, I will not support the current proposal (though I may vote for
> > it). And, no, I am no longer interested in participating in the
> > discussion, seeing as it is completely dominated by people I don't
> > agree with anyway, who don't seem to be able to listen to arguments nor
> > have any sense of what the majority of the project actually wants.
> I also have a feeling like "Oh, well, nearly everybody wants the same,
> let's just do it without bothering about the wording".  And I would be
> surprised if after the vote someone among the relevant teams would step
> up and say "Hey, sorry to tell you, but these drivers (A, B, and C)
> cannot be kept in etch according to my understanding of the GR, and my
> investigation of their details".  However, I do not think we can be
> sure, and since I do *not* want to be surprised, I'd rather have a
> proper discussion before the vote.

That's exactly why the wording should be general and the final decision 
should *not* be bound down in the GR, but should lie with people who can be 
expected to take that responsibility seriously (RMs). If they make a 
decision you do not agree with, you can always still email them (or file a 
BR) and say "sorry, but for the following reasons I think you made a 
mistake there...".

> The problem is that there are individual drivers/firmware for which that
> is in doubt.  For example, Larry Doolittle said recently:
> ,----
> | I am not perfect, but I have plenty of experience using and writing
> | firmware of many kinds.  I would be very surprised if any of the
> | listed firmware is not derived from a human-legible design file of
> | one form or another.
> `----

This is still an interpretation of the intention of the GPL, not a legal 
My, just as amateurish, standpoint is: the preferred from of modification of 
code for firmware blobs included in a driver that is otherwise coded in C 
(or assembler or whatnot) - and for that matter for images, video and even 
documentation - is whatever the licenceholder chose to distribute it as.
This does not mean that it is the optimal form from a Free Software point of 
view, it also does not mean that if someone chooses to reimplement the 
firmware that he could not choose another form. What it does mean is that 
it is rather pointless to second guess the licenceholder unless there are 
very clear indications that they or the person accepting the code into the 
kernel have been careless.
The party primarily responsible for making the judgement what can be 
included in the kernel under the GPL are the upstream kernel developers.

> and even suspected that in some cases the firmware might just be
> sniffed.  I am confident that this will have no legal consequences.  But
> what if 2 days after the GR some kernel contributor steps up and says:
> "Well, to be honest, I got this from a guy who owned the device and told
> me he had sniffed it"?  Will we exclude this firmware or have an other
> GR?

No, licence problems should _never_ be the subject of a GR. Only DFSG 
freeness of "software" can be.

> > The current discussion in no way helps the release of Etch.
> Why not *name* the drivers that get an exception?  This way, anybody who
> *really* can contribute more than general doubt has to do it now, before
> the vote.

Because we are not qualified to classify them.


Attachment: pgpsLw85pQKiZ.pgp
Description: PGP signature

Reply to: