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 legality. 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 unacceptable.) 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 standpoint. 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. Cheers, FJP
Attachment:
pgprjtHxnifkY.pgp
Description: PGP signature