Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware
Frans Pop <elendil@planet.nl> wrote: [...]
> I still don't see what d-vote has to do with this. Distributability IMO is
> an issue that is the province of package maintainer and FTP masters.
Given a GR can reverse decisions of FTP masters about it, which is a sort
of negative instruction, I think it's fine (although maybe unnecessary)
to issue a position statement about the developer body wishes to tackle
it, a sort of positive expectation.
> If someone has evidence that some package or part of a package is not
> properly licenced, I see the following rough procedure:
> - file an RC bug asking for removal from the archive (note: not from main
> to non-free, but total removal) of the offending material;
> - maintainer will judge the BR; if he agrees, takes action; if not, he
> will probably consult with upstream (and maybe other distributions)
> about the issue;
"Probably consult with upstream"? Experience suggests that some
maintainers will probably close the bug with no further action if the
submitter cannot give a full rationale *and* show reasonable backing for
it. Even worse, some will take it personally and abuse the submitter.
One motivation for a position statement GR is to show reluctant
maintainers a hopefully-clear rationale with reasonable support.
If anyone objects to that, then please help those who are trying to
retrain maintainers who close bugs badly, and that motivation will
diminish.
> - if upstream says there is no problem and can support that with legal
> arguments, the BR should probably be closed;
> - if the submitter disagrees he can try asking for advice (d-legal, fsf)
> and possibly appeal to TC.
That seems a bit warped. The *maintainer* is told to ask debian-legal if
in doubt. It shouldn't be left to submitters to consult d-l.
Why could the technical committee overrule on a non-technical problem
like copyright? I think the appeal route would be to delegates like
ftpmasters first, and then maybe to the developers, hoping for an
delegate-overruling GR. Sadly, this becomes ineffective if ftpmasters
are too overworked to answer mails promptly: it's a weakness in the
debian system that it can be hard to address non-decision.
I'm not surprised that appeal to TC is suggested: IIRC, technical and
policy decision processes have been confused under this DPL and it allows
some disputes to continue longer than they should, which is part of why
I support his recall.
> Compliance with licences is something based on facts, not votes. And this is
> the point that both Steve Langasek and Anthony Towns have made several
> times in this discussion.
Sadly, that point is incorrect. It is based on both facts and votes.
The facts of what is written in the licence, but the votes of the
licensors and the courts about what it means. Even the votes of
legislators have a role.
> To me it seems very strange that Debian should have a totally different take
> on this than other distros.
As I'm sure you know, it's different in other ways too. This is not
an argument in itself.
> Only *after* having determined that the material is distributable do we need
> to decide whether or not it is suitable for main. This is where the DFSG
> comes in, where the opinion of the project counts and where you can solve
> differences of opinion or changes in policy by GR.
*We* cannot *determine* whether material is distributable. That will
be determined by legal systems, should it get that far. We can only
estimate, and then decide whether or not *we* distribute it. Sometimes
our estimate will be pretty sure, as near as determined as one can get,
such as for common licences in main, yet not totally determined.
[...]
> > > 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.
> >
> > On past experience, I have no confidence in this being done well in
> > secret. I note that we have agreed that we will not hide problems. This
> > should be done in public as far as possible.
>
> In endless flamewars that fail to reach any real result? Of course the
> delegates should work openly, but they should also be allowed to prepare
> their position statement in relative quiet before submitting it (probably
> in concept) for general discussion. And of course their reasoning needs to
> be documented and supported by evidence.
In the text of the proposal marked '> > >' above, the position statement
was going straight to the vote. I welcome the change to allow general
discussion. I suggest it would be a good idea for that discussion to
start before expensive (in time if not money) expert legal advice is
obtained. We may not be able to bullet-proof legal argument, but we
might spot some obvious boners.
There need not be endless inconclusive flamewars, but the "I am a
lighthouse. Your move" non-discussion debating style of some must change.
> [...]
> > > This is still an interpretation of the intention of the GPL, not a
> > > legal standpoint.
> >
> > What is the difference between an interpretation and a legal standpoint?
> > Years in law school and a lack of personal investment in the problem?
> [...] I do feel that claims of non-compliance should be backed by
> evidence and verifiable expert (legal) opinion especially if it is a claim
> that is not supported by the FOSS community at large.
I agree it should have evidence, but that has little to do with whether
it is a legal standpoint or not. The "verifiable expert (legal) opinion"
is just an educated interpretation and is not strictly required, but may
help. Most importantly, counter-argument should address the argument,
rather than attack the lack of expert names expressing support, or the
forum used for the argument.
For example, I do not agree that "the preferred from of modification
[...] is whatever the [copyright holder] chose to distribute it as"
because if we know that even the copyright holder does not modify that
form, then it's clearly untrue.
Even so, I think we need something stronger than a suspicion that a
block of code is not some hand-crafted assembler and data before we
decide not to believe such a claim. After all, we are denying that
we have a valid permission, which seems to punish us (as a licensee)
for the licensor not following the licence. However, to do otherwise
would be to punish our users by breaking our promise to give them free
software, which has source code, without warning.
If we have no such claim from the licensor, we should try to get
clarification about what is source code there. Do we have any such
claims for the disputed firmwares?
Hope that explains,
--
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: