Re: Sun Java available from non-free
Adam Warner <lists@consulting.net.nz> writes:
> On Sun, 21 May 2006 23:25:28 -0700, Russ Allbery wrote:
>> Adam Warner <lists@consulting.net.nz> writes:
>>> You're correct. So can you give reasonable and legitimate reasons why
>>> "one might not wish to follow" the "you must" guidelines in this
>>> instance?
>> Two, actually. One for the advantage of PR with the timing of the
>> release, which while it's a reason that I can see people not agreeing
>> with and it isn't important to me personally, I think it's a reasonable
>> one.
> Later in the reply you state, "*I* think the license is murky,
> potentially problematic, and borderline for non-free. Looks like a hard
> call. Good thing I don't have to make it. Many thanks to the people
> who do that work."
> I don't see how Debian acting as Sun's public relations poodle on such a
> murky, potentially problematic and borderline decision is reasonable.
I don't see how those two things are related to each other, and I also
don't think that users of Debian are going to see this as us helping Sun.
It's not like Java wasn't previously available on Debian. The existence
or not of Java in Debian non-free is really pretty much irrelevant to the
spread of Java. People who need to run Java applications already do so in
Debian using the existing (excellent) packaging tools and Java packages
that they get from local archives.
All this does is *potentially* make installing Sun's Java distribution
more convenient for Debian users, something that's irrelevant for free
software but which may help with running commercial software on Debian, By
doing this quickly, Debian potentially gains the appearance of being
responsive, something that Debian has had serious PR problems with in the
past. The commercial software vendors hardly care; all their software
already says that they only support Red Hat.
I can understand this not working. I can understand a disagreement with
this as a tactical approach. I can certainly understand not caring, or
arguing that the existing make-jpkg solution was perfectly sufficient (I'm
quite happy with it personally, for those applications we have to run at
Stanford that require Sun's Java). But to say that trying to gain some
good PR for being responsive is *unreasonable* is really stretching it.
Unreasonable means more than just that you disagree with the decision; it
means that you can't even understand why a reasonable person would want to
do things that way.
>> Do you think that this package would have ever gone into non-free
>> without dissent? An ITP would have resulted in the exact same
>> discussion we just had, and if the ftp-masters had then approved it
>> after concluding that the arguments presented weren't strong enough,
>> people would have been just as upset if not more so.
> Postulating that the same decision would be made if appropriate
> processes had been followed does not excuse their short-circuiting. I
> suspect the outcome would have been different because a public process
> would have removed PR deadline pressure.
Well, I doubt it. But it's not a useful place to have a debate.
What I *don't* agree with is your contention that the process wasn't
followed, and that comes back again to my disagreement with you that there
is any sort of public license review in Debian's package acceptance
*process*. There is a *convention* to do public review as input to the
ftp-master decision, but the only *process* we have for license review is
ftp-master review. They are the people responsible for doing license
review, full stop.
As long as you don't agree with this view of how Debian functions as an
organization, I doubt we're going to reach any agreement on this,
particularly since I consider the clear line of responsibility for who
does license review and approval to be a feature worth defending. I don't
consider public consensus to be a useful method of reviewing legal
documents, although a public discussion can sometimes (and sometimes not)
be useful as *input* into the review process.
> The murky, potentially problematic and borderline decision was made
> under the pressure of a public relations deadline.
I don't see any evidence to indicate that pressure had anything to do with
the decision, and a lot of reason to believe it didn't. I therefore don't
consider this line of reasoning at all convincing (and frankly, it seems a
little insulting to the ftp-masters).
>> *I* think the license is murky, potentially problematic, and borderline
>> for non-free. Looks like a hard call. Good thing I don't have to make
>> it. Many thanks to the people who do that work. Now, I should really
>> go look at libpam-krb5 bugs, as those are my responsibility.
> May I take this moment to thank you for your work for Debian.
Well... I wasn't digging for compliments or anything, but thank you. My
point wasn't about what I do or don't, but more about division of labor
and responsibility.
>> As with anything else, if one's decision is horribly bad or one isn't
>> doing one's job, it can be overturned by the project, through a number
>> of formal mechanisms. In this case, that's a GR. If you think this
>> decision is so egregiously bad that it warrants overturning the
>> decision of the people whose job it is to make those decisions, go for
>> it. Personally, I'll vote against any such GR on the grounds that I
>> don't see anything in the license clearly and obviously bad enough to
>> overturn the decision of the people responsible for doing that job.
> This seems backwards. The status quo was subverted by hastily uploading
> the packages to non-free.
This statement doesn't make any sense to me; in fact, it seems exactly
backwards. The status quo is that ftp-masters decide what is and is nto
acceptable in non-free, which is what they did. The argument that
ftp-masters should not be able to make this decision on their own would be
a reversal of the status quo as I see it.
> Now the decision has to be "so egregiously bad" that you'll vote against
> it.
Right. I would apply exactly the same criteria that I would apply to any
GR to overturn the decision of a Debian delegate, namely that I will vote
against any such resolution unless there is clear and compelling evidence
that the decision was egregiously wrong *and* that reversing the decision
is the best way of correcting the mistake.
I've seen no evidence that this situation reaches that standard.
> Before the decision had to be in the interests of Debian. Now it merely
> has to miss an "obviously bad enough" threshold.
The only way that I can understand these statements is if you believe that
license review is the job of the project as a whole through a public
consensus process, which is, as stated above, completely contrary to my
understanding of how Debian works and my belief about how Debian *should*
work.
Legal evaluations are exactly the sort of place where I think public
consensus discussion has significant flaws, namely a subject where many
people have strong but ill-informed opinions, expertise is rare and
requires significant training, and popular opinion frequently arrives at
incorrect conclusions.
> If there is a General Resolution I hope you will consider voting on the
> basis of what would have been the initially correct decision.
No, that is not the standard that I personally will apply to GRs to
overturn delegate decisions. I think the ability of a delegate to do
their job unmolested is more important than overturning the occasional
debatable decision, and therefore will only vote to overturn delegate
decisions if they're truly intolerable, not simply different than what I
personally would have done.
You are, of course, free to apply a different standard to your own GR
votes. This is my personal stance, not something that's part of Debian's
bylaws.
> Anyway, best wishes for fixing those libpam-krb5 bugs.
Thanks. :)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: