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

Bug#839570: Browserified javascript and DFSG 2 (reopening)




Dear joseph:

This message will be hurried: I'm on a train and approaching my stop.


Thanks for your detailed message.  I don't agree with all of it, but I
find it a lot easier to interact with than some of the requests we've
gotten related to this issue.

Here are some factors to consider:

1)  It's not clear to several TC members that the FTP team has decided
on this question.  It seems fairly clear how they would decide if they
did decide, but from a process standpoint, it's important to have a
formal dialogue with them before they are overruled.

2) It's not clear constitutionally that the TC can overrule the ftp
team's decision regarding whether something is DFSG-free.  Even if we
could, it's not clear that is a technical decision in our scope.
So, asking the TC to overrule such a decision is asking for the hardest
political choice possible in such a situation--a really hard sell within
the project and the TC.

3) We'd need a rationale for overruling someone.  That might not be a
strict requirement, but if we're going to say that "browserified
javascript" is DFSG-free, what exactly are we saying?  There was a
discussion of what is source code, with a number of different
considerations brought up.  Something that was responsive to that part
of the discussion would be a lot more likely to move things forward than
simply an assertion.  I don't even have a clear enough understanding of
what browserified means to have any understanding of what a ruling based
on those terms would mean.  Put another way, the TC is more comfortable
acting when it's building a coherent policy that fits together.  To gain
traction, a ruling almost certainly needs to fit into some intellectual
framework about what source means.  It's quite unlikely that we'd decide
something was source simply because it would be inconvenient for us and
our users if it were not source.
User convenience is something we're likely to consider, but "source is
what we need source to be so things work well for users," is going to be
a really improbable sell.


Reply to: