2013/12/4 Kevin Kofler <kevin.kofler@chello.at>
Sune Vuorela wrote:
> On 2013-12-03, Philipp A. <flying-sheep@web.de> wrote:
>> up until now, the code was bascically the same as now, just that jslint
>> was an external dependency. it downloaded nonfree code without user
>> agreement or notification.
>
> Urgh.

Yeah, that's clearly not an acceptable solution.

>> should i just return to the downloading begavior for JSLint and show the
>> user a license agreement when they first try to use JSLint? or should i
>> remove JSLint and only leave JSHint (which is plain MIT licensed)
>
> I'd remove the traces of any files of Douglas Crockford origin. He does
> not produce free nor opensource software and his work should not be
> promoted.

+1

js_utils really needs to do away with JSLint and JSHint support. Please look
into the alternatives I listed at:
https://bugzilla.redhat.com/show_bug.cgi?id=1028819#c1
To the best of my knowledge, those are all acceptably licensed and not
derived from JSLint or any other encumbered code (though it wouldn't hurt to
audit them before deciding to use them).

I see only 3 possible solutions, in decreasing order of preference:
1. replace "check with JSLint/JSHint" by one of the above Free Software
alternatives,
2. remove "check with JSLint/JSHint" from js_utils entirely,
3. remove js_utils altogether.


If jslint is an external dependence like the before solution is this a problem?

When Alejandro Blanco and I coded this feature we used a wrapper coded by him for this reason:

https://pypi.python.org/pypi/pyjslint

You can see here:

https://projects.kde.org/projects/kde/applications/kate/repository/revisions/5fc15c5da963d35ee8ec8d5a0f61b6a4af9b53b3/entry/addons/kate/pate/src/plugins/js_utils/jslint.py

I think that we should come back to something like it

Do you think about it?

Best Regards,

--

Pablo Martín