Jshint: Please change jshint.js license, remove bad or evil

I don't know is this can ever happen, as the "bad or evil" licence is the original software licence for JSLint.

I also think this should happen as soon as possible as this is a major obstacle to shipping also other pieces of software.

Se as an example this very sad thread on the debian bug reporter: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727.

This isn't possible without removing all Crockford code from JSHINT. It can definitely happen though.

I need input from someone who understands legal. (I don't)

I'm pretty sure @goatslacker is correct. You could ask Crockford to change his license :)

@goatslacker where can I find a reference to all the code written by Crockford part of this repository?

@hellais you can run a diff against the first commit to jshint (which would have been where the fork started), to the current HEAD

Git tells me this:

web/jshint - [master] » git log --author="Douglas Crockford" --oneline --shortstat
40e3f73 It
 1 file changed, 1 insertion(+), 1 deletion(-)
7c327bf Tolerate stupid blockless blocks.
 1 file changed, 21 insertions(+), 13 deletions(-)
8d1c4eb clarification
40e3f73 It
 1 file changed, 1 insertion(+), 1 deletion(-)
7c327bf Tolerate stupid blockless blocks.
 1 file changed, 21 insertions(+), 13 deletions(-)
8d1c4eb clarification
 1 file changed, 3 insertions(+), 3 deletions(-)
5675d2c http://tech.groups.yahoo.com/group/jslint_com/message/1730
 5 files changed, 2752 insertions(+), 2847 deletions(-)
73c2fe3 indent
 1 file changed, 4 insertions(+), 3 deletions(-)
d41c211 http://tech.groups.yahoo.com/group/jslint_com/
 1 file changed, 2 insertions(+)
d7896b2 step_in step_out
 1 file changed, 18 insertions(+), 5 deletions(-)
85c95ac for var
 1 file changed, 4 insertions(+), 5 deletions(-)
caa8885 use strict
 2 files changed, 5 insertions(+), 4 deletions(-)
1da55dd http://www.yuiblog.com/blog/2010/12/14/strict-mode-is-coming-to-town/
 2 files changed, 7 insertions(+), 8 deletions(-)
b6d8b25 use strict
 4 files changed, 25 insertions(+), 25 deletions(-)
dc4a013 JSON escape v
 1 file changed, 5 insertions(+), 2 deletions(-)
80a2252 JSON escape single quote
 1 file changed, 5 insertions(+), 1 deletion(-)
bdd3576 k
 4 files changed, 8 insertions(+), 6 deletions(-)
6735394 Cleanup.
 2 files changed, 159 insertions(+), 167 deletions(-)
00d8d1f option.predef
 1 file changed, 2 insertions(+), 2 deletions(-)
6af839a option.predef
 2 files changed, 91 insertions(+), 66 deletions(-)
c933206 Warn on new Array(NUMBER)
 1 file changed, 2 insertions(+), 17 deletions(-)
f73d206 Add fullinit_ui.js, an ADsafe widget
 3 files changed, 159 insertions(+), 5 deletions(-)
523956b Removing rhino.js and wsh.js. Other projects are providing better alternatives.
 4 files changed, 4 insertions(+), 67 deletions(-)
d98f753 dangerous comments
 1 file changed, 1 insertion(+), 1 deletion(-)
35ec4a5 groove
 5 files changed, 95 insertions(+), 203 deletions(-)
d4a0702 More css colors
 1 file changed, 99 insertions(+), 64 deletions(-)
eb939e7 Use charAt instead of [] in line 1786.
 2 files changed, 0 insertions(+), 0 deletions(-)
7800939 Add README
 1 file changed, 20 insertions(+)
ca120a7 first commit
 6 files changed, 7011 insertions(+)

Should not be that much...

What @dcramer said. It won't be very useful, though, since I switched from spaces to tabs along the way. So you will need to do something like that:

1. Checkout first JSHint commit. Convert it to tabs.
2. Checkout latest JSHint commit.
3. Diff (1) and (2) using a normal diff tool.

Lexer was rewritten completely, parser was changed substantially and, to be honest, I don't think @douglascrockford is going to sue me if I change the license. But, still, I don't want to be a douchebag. :-)

@antonkovalyov I think a regular diff will not work either because the code structure has drastically changed. I am looking into a possible way of determining which portions of the code are from the original author.

Exploring possibilities such as simian or checkstyle http://checkstyle.sourceforge.net/config_duplicates.html.

After extracting all the JS code from this head: 40e3f73 (the last commit by git log --author="Douglas Crockford") and comparing that with all the js under the src/*.js root of the current master.

Running the two through the following similarity analyser:

Similarity Analyser 2.3.34 - http://www.harukizaemon.com/simian
Copyright (c) 2003-2013 Simon Harris.  All rights reserved.
Simian is not free unless used solely for non-commercial or evaluation purposes.

And extracting the lines of code that appear to be present in both 40e3f73 and current master it appears these are the only lines of code left in this repository that were written by Douglas Crockford:

                lbp: p,
                value: s
            };
        }
        return x;
    }

    function delim(s) {
        return symbol(s, 0);
    }


----------------------
----------------------
        identifier: true,
        nud: function () {
            var v = this.value,
                s = scope[v],
                f;

            if (typeof s === "function") {

----------------------
----------------------
        member = {};
        membersOnly = null;
        implied = {};
        inblock = false;
        lookahead = [];
        warnings = 0;
        unuseds = [];

----------------------
----------------------
    confirm: false,
    console: false,
    Debug  : false,
    opera  : false,
    prompt : false
};


----------------------
----------------------
        }

        if (!a) {
            a = [line];
            implied[name] = a;
        } else if (a[a.length - 1] !== line) {
            a.push(line);
        }
    }

----------------------
----------------------
                char = this.peek(index);
                if (!isDecimalDigit(char)) {
                    break;
                }
                value += char;
                index += 1;
            }
        }

----------------------
----------------------
    }

    function warningAt(m, l, ch, a, b, c, d) {
        return warning(m, {
            line: l,
            from: ch
        }, a, b, c, d);
    }

    function error(m, t, a, b, c, d) {
        warning(m, t, a, b, c, d);
    }

----------------------
----------------------
        };
        return x;
    }

    function type(s, f) {
        var x = delim(s);
        x.type = s;
        x.nud = f;
        return x;
    }


----------------------
----------------------
                                    case '<':
                                        if (xmode === 'script') {
                                            c = s.charAt(l);
                                            if (c === '!' || c === '/') {
                                                warningAt(
"HTML confusion in regular expression '<{a}'.", line, from + l, c);
                                            }
                                        }

----------------------
----------------------
            Object              : false,
            parseInt            : false,
            parseFloat          : false,
            RangeError          : false,
            ReferenceError      : false,
            RegExp              : false,
            String              : false,
            SyntaxError         : false,

----------------------
----------------------
            Function            : false,
            hasOwnProperty      : false,
            isFinite            : false,
            isNaN               : false,
            JSON                : false,
            Math                : false,
            Number              : false,
            Object              : false,

----------------------
----------------------
    Boolean            : false,
    Date               : false,
    decodeURI          : false,
    decodeURIComponent : false,
    encodeURI          : false,
    encodeURIComponent : false,
    Error              : false,
    "eval"             : false,
    EvalError          : false,

----------------------
----------------------
            onbeforeunload  : true,
            onblur          : true,
            onerror         : true,
            onfocus         : true,
            onload          : true,
            onresize        : true,
            onunload        : true,
            open            : false,
            opener          : false,
            Option          : false,

----------------------
----------------------
        }
    }

    // We need a peek function. If it has an argument, it peeks that much farther
    // ahead. It is used to distinguish
    //     for ( var i in ...
    // from
    //     for ( var i = ...

    function peek(p) {
        var i = p || 0, j = 0, t;

        while (j <= i) {
            t = lookahead[j];
            if (!t) {
                t = lookahead[j] = lex.token();
            }
            j += 1;
        }
        return t;
    }

    // Produce the next token. It looks for programming errors.

    function advance(id, t) {
        switch (state.tokens.curr.id) {
        case "(number)":

----------------------
----------------------
            Option          : false,
            parent          : false,
            print           : false,
            removeEventListener: false,
            resizeBy        : false,
            resizeTo        : false,
            screen          : false,
            scroll          : false,
            scrollBy        : false,
            scrollTo        : false,
            setInterval     : false,
            setTimeout      : false,

----------------------
----------------------
            loadClass   : false,
            print       : false,
            quit        : false,
            readFile    : false,
            readUrl     : false,
            runCommand  : false,
            seal        : false,
            serialize   : false,
            spawn       : false,
            sync        : false,
            toint32     : false,
            version     : false
        },


----------------------
----------------------
                    name: n,
                    line: implied[n]
                });
            }
        }

        if (implieds.length > 0) {
            data.implieds = implieds;
        }

        if (urls.length > 0) {
            data.urls = urls;
        }

        globals = Object.keys(scope);
        if (globals.length > 0) {
            data.globals = globals;
        }

        for (i = 1; i < functions.length; i += 1) {
            f = functions[i];
            fu = {};

            for (j = 0; j < functionicity.length; j += 1) {
                fu[functionicity[j]] = [];
            }


----------------------

This is a quite trivial quantity.

I do not know what is the best way to proceed here. I think it may be the case to ask a professional lawyer for help.

BTW those are 195 lines of code in a project that has over 9000 lines of code.

I may have no idea what's going on here, but I can't imagine that jshint rewrote 8800 lines of jslint

I re-ran simian with a threshold of 2 (this means blocks of fewer similar lines will also be displayed) and I got 708 duplicate lines.

@dcramer what would you suggest doing regarding refactoring out Crockford's code from jshint or getting the license changed?

@hellais I'd suggest talking to a lawyer as I think anything else is likely to be pointing a gun squarely at some feet.

The easy answer to this is that we would need to move away from the pratt parser to esprima.

You know, you could just have a conversation with Douglas and find out his
thoughts on the matter, instead of trying to remove all of his code.

It would be significantly easier and would introduce zero risk to the
codebase. Trying to refactor the code because of a silly little phrase in a
license seems a little excessive.
On Aug 22, 2013 7:01 PM, "Josh Perez" [email protected] wrote:

The easy answer to this is that we would need to move away from the pratt
parser to esprima.

—
Reply to this email directly or view it on GitHubhttps://github.com/jshint/jshint/issues/1234#issuecomment-23135309
.

I'm fairly sure that Douglas has been asked about it before and has refused to re-license it. Looking it up I've found him joking about how he gets letters from lawyers about a similar clause in the JSON license http://dev.hasenj.org/post/3272592502/ibm-and-its-minions. It appears also someone from Debian legal has emailed him to ask about it and his response was if you don't like the license don't use it: http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html

It's jsut a "silly little phrase" to you, but that silly little phrase can be the determining factor if the software is usable or not. Licenses are legally binding documents and given that there's no legal definition of what is and isn't evil it practically means that it is impossible to know whether any particular use of the code is allowed under the license. Because you can't know if it's ok to use the code as licensed companies (and organizations like Debian) will simply opt not to use it.

This is unfortunately a common issue, and too bad, because I think that
people willing to do evil won't care about the license....

However, sometimes, author accept to change his mind, mainly if we explain
him it blocks many other software using his software.

Last request seems to be a few years ago, maybe that trying again and
again....

2013/8/23 Donald Stufft [email protected]

I'm fairly sure that Douglas has been asked about it before and has
refused to re-license it. Looking it up I've found him joking about how he
gets letters from lawyers about a similar clause in the JSON license
http://dev.hasenj.org/post/3272592502/ibm-and-its-minions. It appears
also someone from Debian legal has emailed him to ask about it and his
response was if you don't like the license don't use it:
http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html

It's jsut a "silly little phrase" to you, but that silly little phrase can
be the determining factor if the software is usable or not. Licenses are
legally binding documents and given that there's no legal definition of
what is and isn't evil it practically means that it is impossible to know
whether any particular use of the code is allowed under the license.
Because you can't know if it's ok to use the code as licensed companies
(and organizations like Debian) will simply opt not to use it.

—
Reply to this email directly or view it on GitHubhttps://github.com/jshint/jshint/issues/1234#issuecomment-23143534
.

gpg key id: 4096R/326D8438 (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438

Oh, the old Good / Evil... IANAL, but this makes sense to me -> http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40728.html

You can't argue about good / evil in any court if the terms ain't defined.

https://plus.google.com/118095276221607585885/posts/13shsS2bAEY

@douglascrockford why not put that last bit in license instead; "...this software may not be used in the investigation, torture, and murder of patriots who dare to resist tyrants." <- from a shared http://good/considered_evil.txt
:+1: form me!

@douglascrockford have you actually ever tried suing somebody that has used your software for evil?

I bet the NSA uses JSHINT for their javascript projects and I think they are doing quite an amount of evil. It seems like your license has not been very effective at stopping them from doing so though...

The easy answer to this is that we would need to move away from the pratt parser to esprima.

At this point JSHint covers more JavaScript (stable parts of ES6, Mozilla-specific extensions) and is more fail tolerant than Esprima so the switch isn't going to happen in near future.

I bet the NSA uses JSHINT for their javascript projects

:-)

@hellais Did you read his link?

It is not effective at all, but it at least states my intention.

haha

Anyway, I sent an email to @douglascrockford asking for an explicit permission to remove that clause from JSHint. If he grants one, I'll remove it. If he doesn't, Debian people will have to install JSHint through NPM or do some other workaround.

To be honest, I'm getting tired of these not-true-open-source talks. Out of all things I need to do with JSHint this issue is probably the least important one.

@OscarGodson The link seems purposefully inaccessible publicly. I get a Google+ error page ("This post could not be found"), which is its approximation for a 404.

Case closed, license shall remain the same:

Anton, there are other ways to work around this that will allow Debian to carry a package containing JSHint and without creating extra effort for you. Other developers may also volunteer to help do this work for your project.

As an example, if you wanted to, you could request a Google Summer of Code (GSoC0 student in 2014 and the student could refactor this code in a clean way. Debian and other big projects have plenty of experience with schemes like GSoC and as your project is good for all our other JavaScript you would have a very credible case for this.

The first thing that needs to be cleared up is how much code really is common between JSHint and JSLint? For example, when you did refactoring, did you copy and paste whole chunks of code from JSLint into other source files? Or were the other source files developed independently without using cut-and-paste? If you did use the cut-and-paste approach, then you need to include the @douglascrockford "no evil" terms in the license text of all those other files too and they will all need to credit him as a contributor.

If it is only JSHint.js, then it may be possible for other people to re-write sections of the file. As a bare minimum, you may want to avoid making any more changes to that file and do any new code in a separate file, so the new code won't be tainted by the "no evil" clause and it will be easier for some volunteer working on it in future as there will be less "no evil" code for them to refactor.

The bottom line is that @douglascrockford has to decide whether it is genuinely important to him to have his work recognised and have projects like Debian and JSHint propagate his well-founded concerns about coding style. The alternative is that people simply act as if his project doesn't exist and eventually something will emerge to replace it entirely and his ideas fade away (it has certainly happened to bigger projects, just think about how quickly WordPerfect or Lotus 123 disappeared)

@dpocock > The first thing that needs to be cleared up is how much code really is common between JSHint and JSLint?

https://github.com/jshint/jshint/issues/1234#issuecomment-23129904

The alternative is that people simply act as if his project doesn't exist and eventually something will emerge to replace it entirely and his ideas fade away

@antonkovalyov would obviously know better, but overall, I highly doubt this is a big problem for the project. Out of the 1,244 issues I can only seem to find this ticket that says it's a problem.

On 26/08/13 18:28, Oscar Godson wrote:

@dpocock > The first thing that needs to be cleared up is how much code really is common between JSHint and JSLint?

https://github.com/jshint/jshint/issues/1234#issuecomment-23129904

The alternative is that people simply act as if his project doesn't exist and eventually something will emerge to replace it entirely and his ideas fade away

@antonkovalyov would obviously know better, but overall, I highly doubt this is a big problem for the project. Out of the 1,244 issues I can only seem to find this ticket that says it's a problem.

It is widely known that "no evil" licenses are not considered free:

http://www.gnu.org/licenses/license-list.html#JSON

The fact that there is only one ticket about this simply means that
those of us who are concerned about it are not stupid enough to spam you
with 100 tickets about the same issue

It has repercussions for the rest of your project:

a) if it is not packaged, it has less exposure. If it is packaged in
Debian and Fedora, it becomes a lot more prominent than competing
solutions. This may attract more contributors to your project and help
you resolve some of those other 1244 issues.

b) some other contributors may be deterred from contributing to a
project with a non-standard license for fear that their work is not
truly useable to everybody else in the normal way

c) bigger projects (e.g. somebody making an all-in-one IDE or something)
can't safely include your code unless they copy those license terms into
their overall product license. These potential users may also be
potential contributors: but they may well invest their effort in similar
projects with more standard licenses (or even re-inventing the wheel),
so there is more duplication and fragmentation

I started a petition to ask Crockford to change his license, please sign it: https://www.change.org/petitions/douglas-crockford-remove-the-not-evil-clause-from-your-license-because-it-is-evil-itself

@thkoch2001 https://github.com/jshint/jshint/issues/1234#issuecomment-23187063

the master (3.x) branch seems to have a rewritten jshint.js, so can we say it’s no longer deriviate work?

The Eclipse Orion project has been using a copy of jslint where Doug has given us permission to use a license that does not have the "The Software shall be used for Good, not Evil." clause.

We have jslint snapshots available for 2010-04-06, 2010-12-14, and 2011-12-21.

Looking at the history of jshint you used -- 2011-01-09 so there might be a good possibility of finding what you want.

https://github.com/eclipse/orion.client/tree/master/lib/jslint

Thanks @skaegi!

Those apparently were a busy 25 days...
It might take a bit of time (a week or so) but let me see if we can get a perfect version match reviewed to help make this a ton easier.

On 25/09/14 22:03, Simon Kaegi wrote:

The Eclipse Orion project has been using a copy of jslint where Doug has
given us permission to use a license that does not have the "The
Software shall be used for Good, not Evil." clause.

We have jslint snapshots available for 2010-04-06, 2010-12-14, and
2011-12-21.

Looking at the history of jshint you used -- 2011-01-09 so there might
be a good possibility of finding what you want.

https://github.com/eclipse/orion.client/tree/master/lib/jslint

Can you please forward a copy of Doug's email giving this authorization
or check it in to your repository?

Thanks @dpocock -- Yes I'm trying to make sure that we're doing everything correctly here so this might take a bit of time. I believe it's worth it though as this issue has cost me personally many wasted hours. (see http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s )

I'm not sure what I can share however I will verify with the Eclipse Foundation's IP attorneys to make sure everything is above board and report back.

On 26/09/14 20:05, Simon Kaegi wrote:

Thanks @dpocock https://github.com/dpocock -- Yes I'm trying to make
sure that we're doing everything correctly here so this might take a bit
of time. I believe it's worth it though as this issue has cost me
personally many wasted hours. (see
http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s
)

I'm not sure what I can share however I will verify with the Eclipse
Foundation's IP attorneys to make sure everything is above board and
report back.

Ideally, it would be a link to a post on a mailing list or a copy of a
direct email from Mr Crockford with all the headers, etc.

The Eclipse Orion project has been using a copy of jslint where Doug has given us permission to use a license that does not have the "The Software shall be used for Good, not Evil." clause.

well, IBM just got the permission to use it for evil. if you can give us a version of it that is really just MIT, we can rebase this project on it, throw out that joke clause, and everything is well in the world.

@flying-sheep yes that's the plan

Update -- The Eclipse foundation has approved my project distributing JSLint 2011-01-09 -- (See https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2011-01-09.js)

The agreement between Doug and the Eclipse foundation is private and so not something I am privy to or can share. I did however work directly with the Eclipse Foundation IP team for this approval describing what I was trying to do and again asked for re-confirmation that the Eclipse distribution is permitted to amend the license removing the following phrase - "The Software
shall be used for Good, not Evil". The request was considered and approved. I trust the foundation has done their due diligence here. (More info here https://www.eclipse.org/org/#IP%20Management)

At this point I believe that JSHint or any project should be able to use this copy for good, evil, or whatever their heart desires as it has legally been amended according to an agreement with the copyright holder and effectively distributed under the MIT license which most would agree is a legitimate open source license.

@skaegi thanks again for your work on this :)

Damn, @skaegi, :muscle:

@skaegi If the Eclipse Foundation publishes a copy of the jslint.js source file with a genuine open source license text at the top of the file (either a pure MIT license or an Eclipse license text) then nobody needs to know the terms of the agreement between @douglascrockford and the Eclipse Foundation, people can just take that file as distributed by Eclipse and distribute it in their own projects without poisoning their own licenses.

People distributing it like that should probably include a comment in the file with the URL they obtained it from on the Eclipse site.

Just pointing to a project that Eclipse approved containing a copy of the file is not the same - it is quite possible that it was just overlooked by mistake. The same thing has happened from time to time in Debian, Ubuntu and Fedora and then the offending package has been removed as soon as somebody noticed it.

Thanks @dpocock that's good feedback. The mistake you describe has happened at Eclipse too and is messy to deal with.

If developers want an Eclipse Foundation URL to include in a comment to make it clear where this copy came from they can use:
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js

This URL should be stable as the file is a snapshot of what was approved. I'd prefer people used this first URL over http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js?id=bfe8b59bd463de6bc330d797f0fbf29856178364 which is a link to the specific commit but that's also a possibility.

To alleviate any concern that this was a mistake or overlooked one should reference Eclipse CQ 8747 (where CQ is Contribution Questionnaire) which is where the request to distribute and discussion with the Eclipse IP team is recorded. Because some of the CQ requests might contain "bad" IP they are only made visible to Eclipse committers however the associated URL for this particular request is http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 and the final status approved. Beyond that any concerns over the validity of the distribution and IP process is probably best taken up with Eclipse Foundation's IP team.

Does that cover your points? Can you think of anything else?

@skaegi the url https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 is behind a login

man. woooo. this is awesome.

@rwaldron yes, unfortunately you need to be an Eclipse commiter to access that link (That's what I was trying to say in the comment above). It probably was not terribly helpful to share that link, so sorry.

The CQ was not controversial -- I asked for approval to use the specific snapshot of jslint and attached the code, explained why I wanted this version and also asked for re-confirmation that we were allowed to amend the license. To be doubly sure I also talked with the Eclipse IP team to make sure everything was in order which is also documented in the CQ. A few days later the request was approved.

@skaegi I was just trying to rebase our codebase on top of the Free Software version you shared, but I think I found a problem. Anton initially forked JSHint from the version of JSLint published on 2011-01-09 (view the commit here). After making some changes, he re-applied the changes to the version of JSLint published on 2010-12-16 (view the commit here). This means we really need to start with a Free Software version of the code as published on December 16. Do you have such a version that you can share?

We do not have 2010-12-16 but do have 2010-12-14.
Eclipse -- http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2010-12-14.js
Github (mirror) -- https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2010-12-14.js

This is missing the one commit shown here --https://github.com/douglascrockford/JSLint/commit/caa8885a37afd6895e522409f7889d9333ff6dec

It would be good to know if that logic is even relevant anymore as if it is not then I would suggest re-basing on 2010-12-14 and be done with it.

We also have the 2011-01-09 distribution (mentioned above) which has the above logic.
https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2011-01-09.js#L2711
https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2011-01-09.js#L2712

So, you could create a legit derivative that uses both versions as sources but it feels like we're playing games at that point. I can go back and ask for approval for 2010-12-16 but this will probably take a bit more time than it did last time. I do think its worth it though if that's what we need.

So @jugglinmike , please try re-basing on 2010-12-14 but if that simply is not going to work I'll start the process on the Eclipse side to get a distribution for 2010-12-16.

Just adding a URL to a stable branch at github with the source above as we're now not using jslint in the current release and pruning it from master.

https://github.com/eclipse/orion.client/tree/stable_20150803/lib/jslint

Alrighty, I've completed the rebase; it's available on the master-free branch of my fork.

Talking with @skaegi, I learned that Eclipse maintains a dynamic Intellectual Property log at this URL: https://www.eclipse.org/projects/ip_log.php?projectid=eclipse.orion

This shows the status of the referenced CQs: CQ 4745 [JSLint 2010-12-15]and CQ 8747 [JSLint 2011-01-09].

The Orion project will be releasing verion 7.0 on this coming Wednesday October 29th. Simon has offered to see that a static document is published for this release. My questions for the maintainers are: should we wait for the publication of this document? If so, would you like me to rebase again at that time in order to reference the static IP Log URL from the relevant commits?

Overview

I inserted three commits into JSHint's history:

• Revert codebase to JSHint 2010-12-14 version
• Substitute JSHint for Free Software version
• Incorporate upstream change

The tip of each branch only differ in the license:

$ git diff master
diff --git a/src/jshint.js b/src/jshint.js
index d31a2b1..53f49f1 100644
--- a/src/jshint.js
+++ b/src/jshint.js
@@ -1,8 +1,9 @@
 /*!
  * JSHint, by JSHint Community.
  *
- * This file (and this file only) is licensed under the same slightly modified
- * MIT license that JSLint is. It stops evil-doers everywhere:
+ * Licensed under the MIT license.
+ *
+ * JSHint is a derivative work of JSLint:
  *
  *   Copyright (c) 2002 Douglas Crockford  (www.JSLint.com)
  *
@@ -16,8 +17,6 @@
  *   The above copyright notice and this permission notice shall be included
  *   in all copies or substantial portions of the Software.
  *
- *   The Software shall be used for Good, not Evil.
- *
  *   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  *   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  *   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

...and (of course) all tests pass:

$ npm test

(reporter output intentionally omitted)

OK: 648 assertions (8769ms)

Process Details

Rebase operations are difficult to audit because they rewrite history (instead of amending it). In the interest of transparency, I'll document my process below.

Anton included code from JSLint two times after the initial fork--these commits apply just before the last time he did this. The commit in the master branch today is titled "Reverted JSLint codebase to the 2010-12-16 edition and re-applied my changes". In my fork, I have modified that commit to include _only_ the re-application of JSHint-specific changes and updated the subject line accordingly.

So the relevant history in master looks like this:

28c5235 2011-01-23 21:23:34 -0800 Anton Kovalyov Reverted JSLint codebase to the 2010-12-16 edition and re-applied my changes
026aaf8 2011-01-23 18:51:20 -0800 Anton Kovalyov Added JSHint Community to the license block

...contrasted the related history in master-free:

dc95c3b 2011-01-23 21:23:34 -0800 Anton Kovalyov Re-applied my changes
945e169 2014-10-21 11:15:49 -0400 Mike Pennisi   Incorporate upstream change
e10eef6 2014-10-21 10:55:41 -0400 Mike Pennisi   Substitute JSHint for Free Software version
707b0d8 2014-10-21 10:54:25 -0400 Mike Pennisi   Revert codebase to JSHint 2010-12-14 version
026aaf8 2011-01-23 18:51:20 -0800 Anton Kovalyov Added JSHint Community to the license block

Merge conflicts did arise in commits that modified the presentation of the license. This includes:

• "Add the license to README"
  master
master-free,
• "Added LICENSE and CONTRIBUTING. Updated README"
  master
master-free
• "Convert all spaces to tabs."
  master
master-free
• "No issue: tabs to spaces"
  master
master-free

This was achieved by "training" git's rerere tool using the rerere-train.sh script and running the following command:

$ git rebase --keep-empty --preserve-merges newbase

If there is anything I am forgetting, please let me know. And feel free to browse the history to help me verify that the rebase was technically accurate.

:boom:

Here's a link to the Orion 7.0 Review and IP Log -- an exciting read.
https://projects.eclipse.org/projects/eclipse.orion/releases/7.0/review
https://projects.eclipse.org/sites/default/files/eclipse.orion-7.0-iplog_0.html

It shows that CQ 4745 [JSLint 2010-12-15] and CQ 8747 [JSLint 2011-01-09] where an approved part of our release which hopefully closes the loop.

Any movement on this getting merged in?

@dragorosson This is more than a technical problem; ensuring everying is above board is taking some time. Thanks for your interest.

Thank you very much for working on this issue, I want to get this in Fedora. What exactly still needs to be done?

The best way to confirm that we're still working on this is to check my master-free branch -- I certainly wouldn't be keeping that in sync if I didn't intend to use it!

@piotr1212 Currently, we need to confirm the change with some of the previous contributors. It sounds like you're an RPM maintainer--is that correct?

Thanks you for the update. I'll just wait paintently ;)
And yes, I am a package maintainer for Fedora/EPEL, There are many nodejs modules which depend on jshint and can't be packaged now...

I'm with @piotr1212 - this has blocked some tools into Debian that I want to see. let's get this nonfree clause removed!

I would like to promote this issue and call on all contributors to not forget our government employees inside the NSA or GCHQ that maintain parts of the pervasive surveillance system written in JavaScript. Clean code for everybody!

I've signed the CLA and encourage others to do the same.

As a curiosity, I once had and took the opportunity to ask Howard Zinn to define evil. He, however, snapped back at me, claiming that if I didn't know what evil was by my age, then, for sure, I never would. After years of reflection on that statement, Zinn, of course, was right – and to be errantly good has remained the best I can hope for.

Is this license going to be updated as well? https://github.com/jshint/jshint/blob/master/src/jshint.js#L19

@thejameskyle That is the only license that needs changing. We'll be sure to update it as soon as we can

Just found an older copy of jshint.js that made its way into a Drupal project. I'm having trouble following this issue. Is the "Good, not Evil" clause being removed? The activity in https://github.com/webjars/webjars/issues/1127 makes me think that clause will remain.

The best way to confirm that we're still working on this is to check my master-free branch -- I certainly wouldn't be keeping that in sync if I didn't intend to use it!

@jugglinmike I read that response the first time you posted it in response to @piotr1212 back in January, but I wasn't sue why someone would be working on getting the AND operator working properly in POM if you were merging this... so I asked. I was really hoping for > update and < snark.

As part of Drupal's Licensing Working Group, we deal with licensing issues for a community with thousands of projects and contributors. I understand how frustrating it can be to get these resolved... and how thankless.

SO THANK YOU! Unenforceable, non-standard licensing clauses like that are incredibly unproductive.

While I'm guilty of my share of responses like this, you should be aware of how off putting this is for someone who isn't familiar with your project.

Since there is nothing in the branch's README.md, description, an open PR with comments or in this issue indicating what still needs to be done, people are going to continue to periodically ask until this gets merged.

If you are going to use a boilerplate response to anyone who asks, I'd suggest some changes. "I didn't intend to use it!" is != "we didn't intend to merge it". It would be less off putting to say something like...

_If https://github.com/jugglinmike/jshint/tree/master-free is being updated, we are actively working on resolving this. Limited resources prevent us from posting status updates as often we'd like, but this issue will remain open until the "Good, not Evil" clause is removed._

This file wasn't essential to the Drupal project so it was removed, but this issue is becoming a great case study in the ripple effect modifying a truly open and vetted license can have. Let me know if there is anything I can do to help get this resolved.

I did not intend to be passive aggressive. I interpreted, "I'm having trouble following this issue" as, "I missed your response among all the other discussion". I appreciate your suggestion for a more complete explanation, and I agree that it is an improvement. I'll follow up with a more visible comment dedicated to that message.

As for the issue you referenced: I think there's value for that project to be robust in its parsing of SPDX regardless of any specific project's current configuration. So it would make sense to resolve that issue generally... to me, anyway!

Checking the Status of this Effort

If https://github.com/jugglinmike/jshint/tree/master-free is being updated, we are actively working on resolving this. Limited resources prevent us from posting status updates as often we'd like, but this issue will remain open until the "Good, not Evil" clause is removed.

@jugglinmike its about 11 months since the last comment. I'd like to know the current status of this issue.

Seriously? Another "Good, not Evil." license? What is the point of this? Please pick a real FSF approved or OSI approved license.

@andreicristianpetcu: you're unnecessarily antagonistic because you're uninformed.

do you know what jshint was forked off? once you do, carefully read this thread, then please apologize for the previous comment.

@flying-sheep I read the thread. Sorry for the spam.

Any progress on this issue? It's preventing us from including it in Fedora.

Thanks for your interest, @eclipseo. I'd love for JSHint to be included in Fedora! Right now, we're trying to re-write a few targeted sections of the codebase. I cannot contribute directly due to my familiarity with the non-Free code. The same goes for many of our prior contributors, so I've been searching for new people with a passion for free software and a penchant for JavaScript. If you (or anyone else following along) know of anyone that fits the bill, please ask them to contact me (either on this thread or via my personal e-mail address).

Well.... if it's written from scratch it does not matter who writes it. This is a copyright issue, not a patent issue.

We are not currently attempting to re-write from scratch. I tried to communicate this in my previous response with the phrase, "a few targeted sections of the codebase."

What is the current status ?

The same goes for many of our prior contributors, so I've been searching for new people with a passion for free software and a penchant for JavaScript. If you (or anyone else following along) know of anyone that fits the bill, please ask them to contact me (either on this thread or via my personal e-mail address).

Just came across this issue -- are you still looking for help?

@ajakaja I am! Could you e-mail [email protected] ?

I approve of the author remaining true to his original commitment. If this was my creative work (or a derivative of it) I would also hold the Not Evil clause to the end.
The clause is open to interpretation (and certainly won't hold in court, nor was the author's intend that it ever could, I'm sure) for a reason. And the reason might be a moral one, a sense of humor, or probably a mixture of both.

Now if some distro can't include the software in its repos because the definition of "free software" they insist to abide to is excessively strict - _or shall I say narrow-minded_, that is just too bad.

Good job @douglascrockford and project maintainers.

Edit: I must say that I technically _agree_ that the license is non-free as it undoubtly imposes a restriction on what the software may be used for, even if an almost satirical one. The fact that distros don't include the sofware in their official repos on these grounds is just silly.

Good news, everyone! We've just published JSHint 2.12.0, the first version to be completely licensed under the MIT Expact license. Details about the process are available on the project website.

If anyone is still interested in packaging JSHint for a software repository, I'll be happy to help!