Bug#681676: repackaged upstream tarball solution?
On 04/09/13 14:33, Paul Tagliamonte wrote:
> On Wed, Sep 04, 2013 at 02:15:40PM +0200, Daniel Pocock wrote:
>> A lot of upstreams use this tool or jshint during their build,
>> particularly due to systems like grunt encouraging it in their docs
> Yep. I like jshint. In fact, I co-work with the guy that wrote grunt.
> Which is why I had this ITP open.
>
>> To save time for other maintainers, why not package a repackaged
>> upstream tarball?
>>
>> Just strip out everything with the "no evil" clause
> The thing is, jshint *it's self* is under that license. If you strip it
> out, there's no code :)
>
>> None of the logic is mandatory for a build process anyway, this is just
>> a QA tool
> D'oh :)
>
> Perhaps check the terms of the jshint library.
JSHint is just as difficult to work with
They refactored the code but it seems like they did so in ignorance of
this issue, cutting and pasting code that is under the "no evil"
license, and Mr Crockford has them over a barrel:
https://github.com/jshint/jshint/issues/1234#issuecomment-23187063
>
>> If there are no warnings left at all, then I suppose the tool could just
>> spit out a message like the following:
>>
>> Warning: your build script depends on a non-free tool. Please stop
>> calling jslint or set JSLINT_EVIL_IGNORE=1 to make this message go away
>>
>> If Mr Crockford really wants people to consider the advice that his tool
>> gives about JavaScript coding practices, then he will release the code
>> under a free software license and then all the other stuff will work the
>> way he wants it to.
> He gives talks about how stupid everyone is for wanting a tool that does
> evil. He's not going to change his mind.
I never suggested it was guaranteed to work. Maybe once he realises how
effectively everybody is working around this he will change his mind to
try and regain some ground, maybe not.
However, just displaying such a warning to users of the tool would help
illuminate the wider community about the dangers of poor licensing and
hopefully other people won't end up like the JSHint team
> There's a jshint-ng that's under MIT/Expat under development. I've not
> checked on it in a while, but perhaps it's nice now?
>
> This might also be good for non-free, I just didn't have the time to
> play with non-free code (or maintain it)
>
Can you comment how you think packages should use the tool to make it as
convenient as possible for maintainers not to care which one is on a
given system?
E.g. have a virtual package jslint which is provided by all of:
jslint-nonfree (in nonfree)
jshint (in nonfree)
jshint-ng (eventually in main)
jslint-one-warning (which just gives the warning described above)
Reply to: