From kwrite-devel Wed Dec 04 07:38:13 2013 From: =?ISO-8859-1?Q?J=2E_Pablo_Mart=EDn_Cobos?= Date: Wed, 04 Dec 2013 07:38:13 +0000 To: kwrite-devel Subject: Re: Non-free file in pate js_utils plugin Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=138614270717455 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============6811667922857734215==" --===============6811667922857734215== Content-Type: multipart/alternative; boundary=001a11c265a0d9bfbe04ecb07ea7 --001a11c265a0d9bfbe04ecb07ea7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/4 Kevin Kofler > Sune Vuorela wrote: > > On 2013-12-03, Philipp A. wrote: > >> up until now, the code was bascically the same as now, just that jslin= t > >> 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 t= he > >> 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=3D1028819#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/revision= s/5fc15c5da963d35ee8ec8d5a0f61b6a4af9b53b3/entry/addons/kate/pate/src/plugi= ns/js_utils/jslint.py I think that we should come back to something like it Do you think about it? Best Regards, -- Pablo Mart=EDn --001a11c265a0d9bfbe04ecb07ea7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/12/4 Kevin Kofler <kevin.kofler@chello.at&g= t;
Sune Vuorela wrote:
> On 2013-12-03, Philipp A. <f= lying-sheep@web.de> wrote:
>> up until now, the code was bascically the same as now, just that j= slint
>> was an external dependency. it downloaded nonfree code without use= r
>> agreement or notification.
>
> Urgh.

Yeah, that's clearly not an acceptable solution.

>> should i just return to the downloading begavior for JSLint and sh= ow the
>> user a license agreement when they first try to use JSLint? or sho= uld i
>> remove JSLint and only leave JSHint (which is plain MIT licensed)<= br> >
> 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 loo= k
into the alternatives I listed at:
https://bugzilla.redhat.com/show_bug.cgi?id=3D1028819#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 hu= rt 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 So= ftware
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 soluti= on is this a problem?

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


You can see h= ere:


I think that we should come back to something like it

Do you think about it?

Bes= t Regards,

--

Pablo= Mart=EDn
--001a11c265a0d9bfbe04ecb07ea7-- --===============6811667922857734215== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KWrite-Devel mailing list KWrite-Devel@kde.org https://mail.kde.org/mailman/listinfo/kwrite-devel --===============6811667922857734215==--