Re: Bug#839570: Browserified javascript and DFSG 2 (reopening)
On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>...
> 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.
In other words, the best way forward for getting any decision would be
an RC bug against perl claiming that the Configure script is not DFSG-free.
If anyone disputes that perl is not DFSG-free due to the Configure
script, "Is the perl Configure script DFSG-free?" would be a clear
question that could be escalated to FTP/TC/GR.
This is also a case where it would be easier for you to get a clear
understanding.
The relevant part of #762638 is:
Clearly perl isn't going to be kicked out of Debian because of this,
but a less important package might well be.
That is exactly the problem here - browserified javascript is
not important enough, so FTP team and TC are getting away with
not making a decision.
Pirate Praveen is simply doing the wrong thing by pursuing a path
where everyone is just trying to avoid making a an explicit decision,
sustaining an implicit decision against him.
perl is important enough that noone would get away with not making a
decision, and the only realistic way forward for browserified javascript
would be to force a decision whether or not the perl Configure script is
DFSG-free.
After forcing a decision on perl, there will be decisions that would
also settle the main questions regarding browserified javascript.
If anyone thinks that this hardball approach would not be necessary,
please describe to Pirate Praveen a better way for getting an explicit
decision in time for stretch.
If you want to build a coherent policy for that, that policy would of
course equally apply to other similar cases like the perl Configure
or SQLite, so there is nothing bad about starting the process with
the perl Configure.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: