Jshint: Bitte ändern Sie die jshint.js-Lizenz, entfernen Sie böse oder böse

Ich weiß nicht, ob dies jemals passieren kann, da die "schlechte oder böse" Lizenz die ursprüngliche Softwarelizenz für JSLint ist.

Ich denke auch, dass dies so schnell wie möglich geschehen sollte, da dies ein großes Hindernis für den Versand auch anderer Software darstellt.

Siehe als Beispiel diesen sehr traurigen Thread zum Debian-Bugreporter: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727.

Dies ist nicht möglich, ohne den gesamten Crockford-Code aus JSHINT zu entfernen. Es kann aber definitiv passieren.

Ich brauche Input von jemandem, der sich mit Recht auskennt. (Ich nicht)

Ich bin mir ziemlich sicher, dass @goatslacker richtig ist. Sie könnten Crockford bitten, seine Lizenz zu ändern :)

@goatslacker wo finde ich einen Verweis auf den gesamten Code, der von Crockford in diesem Repository geschrieben wurde?

@hellais Sie können einen Diff gegen den ersten Commit zu jshint (wo der Fork gestartet wäre) zum aktuellen HEAD ausführen

Git sagt mir das:

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(+)

Sollte nicht so viel sein...

Was @dcramer sagte. Es wird jedoch nicht sehr nützlich sein, da ich unterwegs von Leerzeichen zu Tabs gewechselt habe. Sie müssen also so etwas tun:

1. Checkout den ersten JSHint-Commit. Konvertieren Sie es in Registerkarten.
2. Checken Sie den neuesten JSHint-Commit aus.
3. Diff (1) und (2) mit einem normalen Diff-Tool.

Lexer wurde komplett neu geschrieben, der Parser wurde grundlegend geändert und um ehrlich zu sein glaube ich nicht, dass

@antonkovalyov Ich denke, ein reguläres Diff wird auch nicht funktionieren, da sich die

Erkundung von Möglichkeiten wie Simian oder Checkstyle http://checkstyle.sourceforge.net/config_duplicates.html.

Nachdem Sie den gesamten JS-Code aus diesem Kopf extrahiert haben: 40e3f73 (der letzte Commit von git log --author="Douglas Crockford" ) und das mit allen js unter dem src/*.js-Root des aktuellen Masters verglichen.

Führen Sie die beiden durch den folgenden Ähnlichkeitsanalysator:

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.

Und wenn man die Codezeilen extrahiert, die sowohl in 40e3f73 als auch im aktuellen Master vorhanden zu sein scheinen, sind dies die einzigen Codezeilen in diesem Repository, die von Douglas Crockford geschrieben wurden:

                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]] = [];
            }


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

Dies ist eine recht triviale Größe.

Ich weiß nicht, wie ich hier am besten vorgehen soll. Ich denke, es kann der Fall sein, einen professionellen Anwalt um Hilfe zu bitten.

Übrigens, das sind 195 Codezeilen in einem Projekt mit über 9000 Codezeilen.

Ich habe vielleicht keine Ahnung, was hier vor sich geht, aber ich kann mir nicht vorstellen, dass jshint 8800 Zeilen von jslint neu geschrieben hat

Ich habe Simian mit einem Schwellenwert von 2 erneut ausgeführt (das bedeutet, dass auch Blöcke mit weniger ähnlichen Zeilen angezeigt werden) und ich habe 708 doppelte Zeilen erhalten.

@dcramer was würden Sie vorschlagen, um Crockfords Code aus jshint zu refaktorisieren oder die Lizenz zu ändern?

@hellais Ich würde vorschlagen, mit einem Anwalt zu sprechen, da ich denke, dass alles andere wahrscheinlich eine Waffe direkt auf einige Fuß richtet.

Die einfache Antwort darauf ist, dass wir vom Pratt-Parser zu esprima übergehen müssten.

Weißt du, du könntest dich einfach mit Douglas unterhalten und seinen herausfinden
Gedanken zu diesem Thema, anstatt zu versuchen, seinen gesamten Code zu entfernen.

Es wäre erheblich einfacher und würde kein Risiko für die
Codebasis. Der Versuch, den Code aufgrund eines dummen kleinen Satzes in a . umzugestalten
Lizenz scheint ein wenig übertrieben.
Am 22. August 2013 um 19:01 Uhr schrieb "Josh Perez" [email protected] :

Die einfache Antwort darauf ist, dass wir uns vom Pratt entfernen müssten
Parser zu esprima.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/jshint/jshint/issues/1234#issuecomment -23135309
.

Ich bin mir ziemlich sicher, dass Douglas schon einmal danach gefragt wurde und sich geweigert hat, es erneut zu lizenzieren. Beim Nachschlagen habe ich festgestellt, dass er Witze darüber machte, wie er Briefe von Anwälten über eine ähnliche Klausel in der JSON-Lizenz http://dev.hasenj.org/post/3272592502/ibm-and-its-minions bekommt http://www.mail-archive.com/debian-legal%40lists. debian.org/msg40718.html

Es ist für Sie nur eine "alberne kleine Phrase", aber diese dumme kleine Phrase kann der entscheidende Faktor sein, ob die Software verwendbar ist oder nicht. Lizenzen sind rechtsverbindliche Dokumente und da es keine gesetzliche Definition dafür gibt, was böse ist und was nicht, bedeutet dies praktisch, dass es unmöglich ist zu wissen, ob eine bestimmte Verwendung des Codes unter der Lizenz erlaubt ist. Weil Sie nicht wissen können, ob es in Ordnung ist, den Code zu verwenden, da lizenzierte Unternehmen (und Organisationen wie Debian) sich einfach dafür entscheiden, ihn nicht zu verwenden.

Dies ist leider ein häufiges Problem und schade, denn ich denke, dass
Leute, die bereit sind, Böses zu tun, werden sich nicht um die Lizenz kümmern....

Manchmal akzeptiert der Autor jedoch, seine Meinung zu ändern, hauptsächlich wenn wir es erklären
Ihm blockiert es viele andere Software, die seine Software verwendet.

Die letzte Anfrage scheint ein paar Jahre her zu sein, vielleicht versucht es das noch einmal und
wieder....

2013/8/23 Donald Stufft [email protected]

Ich bin mir ziemlich sicher, dass Douglas schon einmal danach gefragt wurde und hat
weigerte sich, es erneut zu lizenzieren. Als ich es nachgeschlagen habe, habe ich festgestellt, dass er Witze darüber macht, wie er
bekommt Briefe von Anwälten über eine ähnliche Klausel in der JSON-Lizenz
http://dev.hasenj.org/post/3272592502/ibm-and-its-minions. Es erscheint
auch jemand von Debian Legal hat ihm eine E-Mail geschickt, um nach ihm und ihm zu fragen
Antwort war, wenn Ihnen die Lizenz nicht gefällt, verwenden Sie sie nicht:
http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html

Für dich ist es nur ein "alberner kleiner Satz", aber dieser dumme kleine Satz kann
der entscheidende Faktor sein, ob die Software verwendbar ist oder nicht. Lizenzen sind
rechtsverbindliche Dokumente und da es keine gesetzliche Definition von gibt
was böse ist und was nicht, bedeutet praktisch, dass es unmöglich ist zu wissen
ob eine bestimmte Verwendung des Codes unter der Lizenz erlaubt ist.
Weil Sie nicht wissen können, ob es in Ordnung ist, den Code als lizenzierte Unternehmen zu verwenden
(und Organisationen wie Debian) werden sich einfach dafür entscheiden, es nicht zu verwenden.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/jshint/jshint/issues/1234#issuecomment -23143534
.

gpg-Schlüssel-ID: 4096R/326D8438 (keyring.debian.org)

Schlüsselfingerabdruck = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438

Oh, das alte Gut / Böse... IANAL, aber das macht für mich Sinn -> http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40728.html

Sie können vor keinem Gericht über Gut / Böse streiten, wenn die Begriffe nicht definiert sind.

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

@douglascrockford, warum nicht stattdessen das letzte Stück in die Lizenz http://good/considered_evil.txt
:+1: Bilde mich!

@douglascrockford haben Sie jemals versucht, jemanden zu verklagen, der Ihre Software für das Böse verwendet hat?

Ich wette, die NSA verwendet JSHINT für ihre Javascript-Projekte und ich denke, sie tun ziemlich viel Böses. Es scheint, dass Ihre Lizenz nicht sehr effektiv war, um sie davon abzuhalten, dies zu tun ...

Die einfache Antwort darauf ist, dass wir vom Pratt-Parser zu esprima übergehen müssten.

An dieser Stelle deckt JSHint mehr JavaScript (stabile Teile von ES6, Mozilla-spezifische Erweiterungen) ab und ist fehlertoleranter als Esprima, sodass der Wechsel nicht in naher Zukunft erfolgen wird.

Ich wette, die NSA verwendet JSHINT für ihre Javascript-Projekte

:-)

@hellais Hast du seinen Link gelesen?

Es ist überhaupt nicht effektiv, aber es sagt zumindest meine Absicht aus.

Haha

Wie auch immer, ich habe eine E-Mail an @douglascrockford gesendet und um eine ausdrückliche Erlaubnis gebeten, diese Klausel aus JSHint zu entfernen. Wenn er einen gewährt, werde ich ihn entfernen. Wenn dies nicht der Fall ist, müssen Debian-Leute JSHint über NPM installieren oder eine andere Problemumgehung durchführen.

Um ehrlich zu sein, habe ich diese nicht wirklichen Open-Source-Gespräche satt. Von allen Dingen, die ich mit JSHint tun muss, ist dieses Problem wahrscheinlich das am wenigsten wichtige.

@OscarGodson Der Link scheint

Fall abgeschlossen, Lizenz bleibt gleich:

Anton, es gibt andere Möglichkeiten, dies zu umgehen, die es Debian ermöglichen, ein Paket mit JSHint zu transportieren, ohne zusätzlichen Aufwand für Sie zu verursachen. Andere Entwickler können sich ebenfalls freiwillig melden, um diese Arbeit für Ihr Projekt zu übernehmen.

Wenn Sie möchten, können Sie beispielsweise einen Google Summer of Code anfordern (GSoC0-Student im Jahr 2014 und der Schüler kann diesen Code sauber umgestalten. Debian und andere große Projekte haben viel Erfahrung mit Schemata wie GSoC und als Ihr Projekt gut für alle unsere anderen JavaScripts ist, hätten Sie dafür einen sehr glaubwürdigen Fall.

Das erste, was geklärt werden muss, ist, wie viel Code wirklich zwischen JSHint und JSLint gemeinsam ist. Haben Sie beispielsweise beim Refactoring ganze Codeblöcke aus JSLint kopiert und in andere Quelldateien eingefügt? Oder wurden die anderen Quelldateien unabhängig ohne Ausschneiden und Einfügen entwickelt? Wenn Sie den Ausschneiden-und-Einfügen-Ansatz verwendet haben, müssen Sie die @douglascrockford- Begriffe "kein Übel" auch in den Lizenztext all dieser anderen Dateien aufnehmen, und sie müssen ihn alle als Mitwirkenden

Wenn es sich nur um JSHint.js handelt, können andere Personen möglicherweise Abschnitte der Datei neu schreiben. Als absolutes Minimum sollten Sie keine weiteren Änderungen an dieser Datei vornehmen und neuen Code in einer separaten Datei erstellen, damit der neue Code nicht durch die "No Evil"-Klausel verunreinigt wird und es für einige einfacher wird Freiwillige, die in Zukunft daran arbeiten, da es weniger "No-Evil"-Code geben wird, den sie umgestalten können.

Unterm Strich muss @douglascrockford entscheiden, ob es ihm wirklich wichtig ist, dass seine Arbeit anerkannt wird und Projekte wie Debian und JSHint seine begründeten Bedenken bezüglich des Programmierstils verbreiten. Die Alternative ist, dass die Leute einfach so tun, als ob sein Projekt nicht existiert und irgendwann etwas auftaucht, das es vollständig ersetzt und seine Ideen verschwinden (das ist sicherlich bei größeren Projekten passiert, denken Sie nur daran, wie schnell WordPerfect oder Lotus 123 verschwunden sind).

@dpocock > Das erste, was geklärt werden muss, ist, wie viel Code wirklich zwischen JSHint und JSLint gemeinsam ist.

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

Die Alternative ist, dass die Leute einfach so tun, als ob sein Projekt nicht existiert und irgendwann etwas auftaucht, das es vollständig ersetzt und seine Ideen verschwinden

@antonkovalyov würde es natürlich besser wissen, aber insgesamt bezweifle ich stark, dass dies ein großes Problem für das Projekt ist. Von den 1.244 Ausgaben kann ich nur dieses Ticket finden, das besagt, dass es sich um ein Problem handelt.

Am 26.08.13 18:28 schrieb Oscar Godson:

@dpocock > Das erste, was geklärt werden muss, ist, wie viel Code wirklich zwischen JSHint und JSLint gemeinsam ist.

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

Die Alternative ist, dass die Leute einfach so tun, als ob sein Projekt nicht existiert und irgendwann etwas auftaucht, das es vollständig ersetzt und seine Ideen verschwinden

@antonkovalyov würde es natürlich besser wissen, aber insgesamt bezweifle ich stark, dass dies ein großes Problem für das Projekt ist. Von den 1.244 Ausgaben kann ich nur dieses Ticket finden, das besagt, dass es sich um ein Problem handelt.

Es ist allgemein bekannt, dass Lizenzen des Typs „kein Böses“ nicht als kostenlos gelten:

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

Dass es dazu nur ein Ticket gibt, bedeutet einfach, dass
Diejenigen von uns, die sich darüber Sorgen machen, sind nicht dumm genug, um dich zu spammen
mit 100 Tickets zum gleichen Thema

Dies hat Auswirkungen auf den Rest Ihres Projekts:

a) wenn es nicht verpackt ist, ist es weniger exponiert. Wenn es verpackt ist
Debian und Fedora, es wird viel prominenter als die Konkurrenz
Lösungen. Dies kann mehr Mitwirkende für Ihr Projekt gewinnen und helfen
Sie lösen einige dieser anderen 1244-Probleme.

b) einige andere Mitwirkende können davon abgehalten werden, zu a . beizutragen
Projekt mit einer nicht standardmäßigen Lizenz aus Angst, dass ihre Arbeit es nicht ist
wirklich für alle anderen auf die normale Weise nutzbar

c) größere Projekte (zB jemand, der eine All-in-One-IDE erstellt oder so)
kann Ihren Code nicht sicher einfügen, es sei denn, sie kopieren diese Lizenzbedingungen in
ihre gesamte Produktlizenz. Diese potenziellen Nutzer können auch
potenzielle Mitwirkende: aber sie können durchaus ihre Bemühungen in ähnliches investieren
Projekte mit mehr Standardlizenzen (oder sogar das Rad neu erfinden),
es gibt also mehr Duplizierung und Fragmentierung

Ich habe eine Petition gestartet, um Crockford zu bitten, seine Lizenz zu ändern. Bitte unterschreibe sie: https://www.change.org/petitions/douglas-crockford-remove-the-not-evil-clause-from-your-license-because- es-ist-selbst

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

Der Zweig master (3.x) scheint eine neu geschriebene jshint.js zu haben. Können wir also sagen, dass es sich nicht mehr um eine abgeleitete Arbeit handelt?

Das Eclipse-Orion-Projekt verwendet eine Kopie von jslint, wobei Doug uns die Erlaubnis zur Verwendung einer Lizenz erteilt hat, die nicht die Angabe "Die Software soll zum Guten, nicht zum Bösen verwendet werden." Klausel.

Wir haben jslint-Snapshots für 2010-04-06, 2010-12-14 und 2011-12-21 verfügbar.

Wenn Sie sich die Geschichte von jshint ansehen, die Sie verwendet haben -- 2011-01-09 , könnte es eine gute Möglichkeit geben, das Gewünschte zu finden.

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

Danke @skaegi!

Das waren anscheinend 25 arbeitsreiche Tage...
Es kann ein bisschen dauern (eine Woche oder so), aber lassen Sie mich sehen, ob wir eine perfekte Versionsübereinstimmung überprüfen können, um dies zu vereinfachen.

Am 25.09.14 22:03 schrieb Simon Kaegi:

Das Eclipse Orion-Projekt hat eine Kopie von jslint verwendet, wo Doug
uns die Erlaubnis erteilt, eine Lizenz zu verwenden, die nicht das "The
Software soll zum Guten, nicht zum Bösen verwendet werden."-Klausel.

Wir haben jslint-Snapshots für 2010-04-06, 2010-12-14 und
2011-12-21.

Schauen Sie sich die Geschichte von jshint an, die Sie verwendet haben -- 2011-01-09, also könnte es sein
eine gute Möglichkeit zu finden, was Sie wollen.

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

Können Sie bitte eine Kopie von Dougs E-Mail mit dieser Autorisierung weiterleiten?
oder in Ihr Repository einchecken?

Danke @dpocock -- Ja, ich versuche sicherzustellen, dass wir hier alles richtig machen, daher kann dies etwas dauern. Ich glaube, es lohnt sich jedoch, da mich dieses Problem persönlich viele verschwendete Stunden gekostet hat. (Siehe http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s )

Ich bin mir nicht sicher, was ich mitteilen kann, aber ich werde mich mit den IP-Anwälten der Eclipse Foundation vergewissern, dass alles in Ordnung ist, und Bericht erstatten.

Am 26.09.14 20:05 schrieb Simon Kaegi:

Danke @dpocock https://github.com/dpocock -- Ja, ich versuche es zu machen
sicher, dass wir hier alles richtig machen, also kann das etwas dauern
von Zeit. Ich glaube, es lohnt sich, denn dieses Problem hat mich gekostet
persönlich viele vergeudete Stunden. (sehen
http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s
)

Ich bin mir nicht sicher, was ich teilen kann, aber ich werde es mit der Eclipse überprüfen
IP-Anwälte der Stiftung, um sicherzustellen, dass alles in Ordnung ist und
zurückmelden.

Idealerweise ist es ein Link zu einem Post auf einer Mailingliste oder eine Kopie einer
direkte E-Mail von Herrn Crockford mit allen Kopfzeilen usw.

Das Eclipse-Orion-Projekt verwendet eine Kopie von jslint, wobei Doug uns die Erlaubnis zur Verwendung einer Lizenz erteilt hat, die nicht die Angabe "Die Software soll zum Guten, nicht zum Bösen verwendet werden." Klausel.

Nun, IBM hat gerade die Erlaubnis bekommen, es zum Bösen zu benutzen. Wenn Sie uns eine Version davon geben können, die wirklich nur MIT ist, können wir dieses Projekt darauf aufbauen, diese Scherzklausel streichen und alles ist gut in der Welt.

@flying-sheep ja das ist der Plan

Update -- Die Eclipse Foundation hat mein Projekt genehmigt, das JSLint 2011-01-09 verteilt -- (Siehe https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2011-01-09 .js)

Die Vereinbarung zwischen Doug und der Eclipse-Stiftung ist privat und daher nicht etwas, in das ich eingeweiht bin oder teilen kann. Ich habe jedoch direkt mit dem IP-Team der Eclipse Foundation zusammengearbeitet, um diese Genehmigung zu erhalten, in der beschrieben wurde, was ich zu tun versuchte, und bat erneut um eine erneute Bestätigung, dass die Eclipse-Distribution die Lizenz ändern darf, indem ich den folgenden Satz entfernte - "Die Software".
soll zum Guten, nicht zum Bösen verwendet werden". Der Antrag wurde geprüft und genehmigt. Ich vertraue darauf, dass die Stiftung hier ihre Sorgfaltspflicht erfüllt hat.

An dieser Stelle glaube ich, dass JSHint oder jedes andere Projekt in der Lage sein sollte, diese Kopie zum Guten, Bösen oder was auch immer ihr Herz begehrt, zu verwenden, da sie gemäß einer Vereinbarung mit dem Urheberrechtsinhaber rechtlich geändert und unter der MIT-Lizenz, die am meisten verbreitet ist, effektiv verteilt wurde würde zustimmen, ist eine legitime Open-Source-Lizenz.

@skaegi danke nochmal für deine Arbeit dazu :)

Verdammt, @skaegi , :muscle:

@skaegi Wenn die Eclipse Foundation eine Kopie der jslint.js-Quelldatei mit einem echten Open-Source-Lizenztext am Anfang der Datei veröffentlicht (entweder eine reine MIT-Lizenz oder ein Eclipse-Lizenztext), muss niemand die Bedingungen der Vereinbarung zwischen @douglascrockford und der Eclipse Foundation können die Leute diese Datei einfach so nehmen, wie sie von Eclipse verteilt wird, und sie in ihren eigenen Projekten verteilen, ohne ihre eigenen Lizenzen zu vergiften.

Leute, die es so verteilen, sollten wahrscheinlich einen Kommentar in die Datei mit der URL einfügen, von der sie es auf der Eclipse-Site erhalten haben.

Nur auf ein von Eclipse genehmigtes Projekt zu verweisen, das eine Kopie der Datei enthält, ist nicht dasselbe - es ist gut möglich, dass es einfach aus Versehen übersehen wurde. Dasselbe ist von Zeit zu Zeit in Debian, Ubuntu und Fedora passiert und dann wurde das beleidigende Paket entfernt, sobald es jemand bemerkte.

Danke @dpocock , das ist ein gutes Feedback. Der von Ihnen beschriebene Fehler ist auch bei Eclipse passiert und ist chaotisch zu handhaben.

Wenn Entwickler möchten, dass eine Eclipse Foundation-URL in einen Kommentar eingefügt wird, um deutlich zu machen, woher diese Kopie stammt, können sie Folgendes verwenden:
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js

Diese URL sollte stabil sein, da die Datei eine Momentaufnahme dessen ist, was genehmigt wurde. Ich würde es vorziehen, dass die Leute diese erste URL gegenüber http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js verwenden? id=bfe8b59bd463de6bc330d797f0fbf29856178364 Dies ist ein Link zu dem spezifischen Commit, aber das ist auch eine Möglichkeit.

Um Bedenken zu zerstreuen, dass dies ein Fehler war oder übersehen wurde, sollte auf Eclipse CQ 8747 verwiesen werden (wobei CQ für Beitragsfragebogen steht), wo die Anfrage zur Verteilung und Diskussion mit dem Eclipse-IP-Team aufgezeichnet wird. Da einige der CQ-Anfragen "schlechte" IP-Adressen enthalten können, werden sie nur für Eclipse-Committer sichtbar gemacht, die zugehörige URL für diese spezielle Anfrage lautet jedoch http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 und die Endstatus genehmigt. Darüber hinaus sollten Bedenken hinsichtlich der Gültigkeit des Verteilungs- und IP-Prozesses wahrscheinlich am besten mit dem IP-Team der Eclipse Foundation geklärt werden.

Deckt das Ihre Punkte ab? Fällt dir noch etwas ein?

@skaegi die URL https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 steckt hinter einem Login

Mann. wooooo. das ist fantastisch.

@rwaldron ja, leider müssen Sie ein Eclipse-Commiter sein, um auf diesen Link zuzugreifen (das habe ich im obigen Kommentar versucht zu sagen). Es war wahrscheinlich nicht sehr hilfreich, diesen Link zu teilen, also tut mir leid.

Die CQ war nicht umstritten – ich bat um die Genehmigung zur Verwendung des spezifischen Snapshots von jslint und fügte den Code hinzu, erklärte, warum ich diese Version wollte und bat auch um eine erneute Bestätigung, dass wir die Lizenz ändern durften. Um doppelt sicher zu sein, habe ich auch mit dem Eclipse-IP-Team gesprochen, um sicherzustellen, dass alles in Ordnung ist, was auch im CQ dokumentiert ist. Wenige Tage später wurde dem Antrag stattgegeben.

@skaegi Ich habe nur versucht, unsere Codebasis auf die von Ihnen freigegebene Freie Software-Version umzubasieren, aber ich glaube, ich habe ein Problem gefunden. Anton hat JSHint ursprünglich von der Version von JSLint abgespalten, die am 09.01.2011 veröffentlicht wurde ( sehen Sie sich den Commit hier an ). Nachdem er einige Änderungen vorgenommen hatte, wendete er die Änderungen erneut auf die Version von JSLint an, die am 16.12.2010 veröffentlicht wurde (siehe Commit hier ). Das bedeutet, dass wir wirklich mit einer Freie-Software-Version des Codes beginnen müssen, die am 16. Dezember veröffentlicht wurde. Haben Sie eine solche Version, die Sie teilen können?

Wir haben kein 2010-12-16, aber 2010-12-14.
Eclipse -- http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2010-12-14.js
Github (Spiegel) -- https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2010-12-14.js

Hier fehlt der eine Commit, der hier gezeigt wird -- https://github.com/douglascrockford/JSLint/commit/caa8885a37afd6895e522409f7889d9333ff6dec

Es wäre gut zu wissen, ob diese Logik überhaupt noch relevant ist, als ob sie es nicht ist, dann würde ich vorschlagen, auf 2010-12-14 umzubasieren und damit fertig zu sein.

Wir haben auch die 2011-01-09-Distribution (oben erwähnt), die die obige Logik hat.
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

Sie könnten also ein legitimes Derivat erstellen, das beide Versionen als Quellen verwendet, aber es fühlt sich an, als würden wir zu diesem Zeitpunkt Spiele spielen. Ich kann zurückgehen und um Genehmigung für 2010-12-16 bitten, aber das wird wahrscheinlich etwas länger dauern als beim letzten Mal. Ich denke, es lohnt sich, wenn wir das brauchen.

Also @jugglinmike , bitte versuche es auf

Fügen Sie einfach eine URL zu einem stabilen Zweig bei github mit der obigen Quelle hinzu, da wir jetzt in der aktuellen Version kein jslint verwenden und es vom Master bereinigen.

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

Okay, ich habe die Rebase abgeschlossen; es ist im master-free Zweig meiner Gabel verfügbar.

Im Gespräch mit @skaegi habe ich erfahren, dass Eclipse unter dieser URL ein dynamisches Protokoll zu geistigem Eigentum führt: https://www.eclipse.org/projects/ip_log.php?projectid=eclipse.orion

Dies zeigt den Status der referenzierten CQs: CQ 4745 [JSLint 2010-12-15]und CQ 8747 [JSLint 2011-01-09].

Das Orion-Projekt wird am kommenden Mittwoch, den 29. Oktober, Version 7.0 veröffentlichen. Simon hat angeboten, dafür zu sorgen, dass für diese Version ein statisches Dokument veröffentlicht wird. Meine Fragen an die Betreuer sind : Sollen wir auf die Veröffentlichung dieses Dokuments warten? Wenn ja, möchten Sie, dass ich zu diesem Zeitpunkt erneut ein Rebase mache, um auf die statische IP-Protokoll-URL aus den relevanten Commits zu verweisen?

Überblick

Ich habe drei Commits in den Verlauf von JSHint eingefügt :

• Codebasis auf JSHint 2010-12-14-Version zurücksetzen
• Ersetzen Sie JSHint durch die Freie Software-Version
• Integrieren Sie Upstream-Änderungen

Die Spitze der einzelnen Zweige unterscheiden sich nur in der Lizenz:

$ 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

...und (natürlich) alle Prüfungen bestehen:

$ npm test

(reporter output intentionally omitted)

OK: 648 assertions (8769ms)

Prozessdetails

Rebase-Vorgänge sind schwer zu überwachen, da sie den Verlauf neu schreiben (anstatt ihn zu ändern). Im Interesse der Transparenz werde ich meinen Prozess im Folgenden dokumentieren.

Anton fügte Code von JSLint zweimal nach dem ersten Fork ein - diese Commits gelten kurz vor dem letzten Mal, als er dies tat. Der heutige Commit im master Zweig trägt den Titel "JSLint codebase to the 2010-12-16 edition and re-applied my changes". In meinem Fork habe ich diesen Commit modifiziert, um _nur_ die erneute Anwendung von JSHint-spezifischen Änderungen einzuschließen und die Betreffzeile entsprechend aktualisiert .

Der relevante Verlauf in master sieht also so aus:

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

... kontrastierte die zugehörige Historie 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

Bei Commits, die die Darstellung der Lizenz veränderten, traten Merge-Konflikte auf. Das beinhaltet:

• "Lizenz zu README hinzufügen"
  master
master-free ,
• "LIZENZ und BEITRAG hinzugefügt. README aktualisiert"
  master
master-free
• "Alle Leerzeichen in Tabulatoren umwandeln."
  master
master-free
• "Kein Problem: Tabulatoren zu Leerzeichen"
  master
master-free

Dies wurde erreicht, indem das rerere Tool von git mit dem rerere-train.sh Skript "trainiert" wurde und der folgende Befehl ausgeführt wurde:

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

Wenn ich etwas vergesse, lass es mich wissen. Sie können auch gerne den Verlauf durchsuchen, um zu überprüfen, ob die Neubasis technisch korrekt war.

:Boom:

Hier ist ein Link zum Orion 7.0 Review und IP Log – eine spannende Lektüre.
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

Es zeigt, dass CQ 4745 [JSLint 2010-12-15] und CQ 8747 [JSLint 2011-01-09] ein genehmigter Teil unserer Veröffentlichung waren, der hoffentlich die Schleife schließt.

Irgendeine Bewegung dazu, sich einzumischen?

@dragorosson Dies ist mehr als ein technisches Problem; sicherzustellen, dass alles in Ordnung ist, dauert einige Zeit. Danke für Ihr Interesse.

Vielen Dank für die Arbeit an diesem Problem, ich möchte dies in Fedora bekommen. Was genau muss noch gemacht werden?

Der beste Weg, um zu bestätigen, dass wir noch daran arbeiten, besteht darin, meinen master-free -

@piotr1212 Derzeit müssen wir die Änderung mit einigen der vorherigen Mitwirkenden bestätigen. Es klingt, als wären Sie ein RPM-Maintainer - ist das richtig?

Danke für das Update. Ich warte einfach malend ;)
Und ja, ich bin ein Paketbetreuer für Fedora/EPEL. Es gibt viele nodejs-Module, die von jshint abhängen und jetzt nicht paketiert werden können...

Ich bin bei @piotr1212 - dies hat einige Tools in Debian blockiert, die ich sehen möchte. Lassen Sie uns diese unfreie Klausel entfernen!

Ich möchte dieses Thema fördern und alle Mitwirkenden auffordern, unsere Regierungsmitarbeiter innerhalb der NSA oder des GCHQ nicht zu vergessen, die Teile des in JavaScript geschriebenen allgegenwärtigen Überwachungssystems unterhalten. Sauberer Code für alle!

Ich habe die GAV unterzeichnet und ermutige andere, dasselbe zu tun.

Aus Neugier hatte und nutzte ich einmal die Gelegenheit, Howard Zinn zu bitten, das Böse zu definieren. Er fuhr mich jedoch an und behauptete, wenn ich in meinem Alter nicht wüsste, was das Böse ist, dann würde ich es mit Sicherheit nie tun. Nach Jahren des Nachdenkens über diese Aussage hatte Zinn natürlich Recht – und irrtümlich gut zu sein, ist das Beste geblieben, auf das ich hoffen kann.

Wird diese Lizenz auch aktualisiert? https://github.com/jshint/jshint/blob/master/src/jshint.js#L19

@thejameskyle Das ist die einzige Lizenz, die

Habe gerade eine ältere Kopie von jshint.js gefunden, die ihren Weg in ein Drupal-Projekt gefunden hat. Ich habe Probleme, diesem Problem zu folgen. Wird die Klausel „Gut, nicht Böse“ gestrichen? Die Aktivität in https://github.com/webjars/webjars/issues/1127 lässt mich denken, dass diese Klausel bestehen bleibt.

Der beste Weg, um zu bestätigen, dass wir noch daran arbeiten, besteht darin, meinen master-free -

@jugglinmike Ich habe diese Antwort gelesen, als Sie sie im Januar zum ersten Mal als Antwort auf @piotr1212 gepostet haben, aber ich war mir nicht sicher, warum jemand daran arbeiten würde, den UND-Operator in POM richtig zum Laufen zu bringen, wenn Sie dies zusammenführen ... also Ich fragte. Ich hatte wirklich auf > Update und < Snark gehofft.

Als Teil der Licensing Working Group von Drupal beschäftigen wir uns mit Lizenzproblemen für eine Community mit Tausenden von Projekten und Mitwirkenden. Ich verstehe, wie frustrierend es sein kann, diese zu lösen... und wie undankbar.

ALSO VIELEN DANK! Nicht durchsetzbare, nicht standardmäßige Lizenzklauseln wie diese sind unglaublich unproduktiv.

Ich bin zwar an meinem Anteil an solchen Antworten schuldig, aber Sie sollten sich bewusst sein, wie abschreckend dies für jemanden ist, der mit Ihrem Projekt nicht vertraut ist.

Da es in der README.md der Branche, in der Beschreibung, in einer offenen PR mit Kommentaren oder in dieser Ausgabe nichts gibt, was noch zu tun ist, werden die Leute weiterhin regelmäßig nachfragen, bis dies zusammengeführt wird.

Wenn Sie eine Boilerplate-Antwort für jeden verwenden möchten, der fragt, würde ich einige Änderungen vorschlagen. "Ich hatte nicht vor, es zu benutzen!" is != "wir wollten es nicht zusammenführen". Es wäre weniger abwegig, so etwas zu sagen wie...

_Wenn https://github.com/jugglinmike/jshint/tree/master-free aktualisiert wird, arbeiten wir aktiv daran, dies zu beheben. Begrenzte Ressourcen hindern uns daran, Statusaktualisierungen so oft wir möchten, zu veröffentlichen, aber dieses Problem wird so lange bestehen bleiben, bis die Klausel "Gut, nicht Böse" entfernt wird._

Diese Datei war für das Drupal-Projekt nicht unbedingt erforderlich, daher wurde sie entfernt, aber dieses Problem wird zu einer großartigen Fallstudie in Bezug auf den Welleneffekt, den eine wirklich offene und geprüfte Lizenz haben kann. Lassen Sie mich wissen, wenn ich etwas tun kann, um das Problem zu lösen.

Ich hatte nicht vor, passiv aggressiv zu sein. Ich interpretierte "Ich habe Probleme, diesem Thema zu folgen" als "Ich habe Ihre Antwort bei all den anderen Diskussionen übersehen". Ich freue mich über Ihren Vorschlag für eine umfassendere Erklärung und stimme zu, dass es sich um eine Verbesserung handelt. Ich werde mit einem sichtbareren Kommentar zu dieser Nachricht nachfassen.

Was das Problem angeht, auf das Sie verwiesen haben: Ich denke, es ist von Vorteil, wenn dieses Projekt unabhängig von der aktuellen Konfiguration eines bestimmten Projekts beim Parsen von SPDX robust ist. Es wäre also sinnvoll, dieses Problem allgemein zu lösen ... für mich jedenfalls!

Überprüfen des Status dieser Bemühungen

Wenn https://github.com/jugglinmike/jshint/tree/master-free aktualisiert wird, arbeiten wir aktiv daran, dies zu beheben. Begrenzte Ressourcen hindern uns daran, Statusaktualisierungen so oft wir möchten, zu veröffentlichen, aber dieses Problem wird so lange bestehen bleiben, bis die Klausel "Gut, nicht Böse" entfernt wird.

@jugglinmike seit dem letzten Kommentar sind es ungefähr 11 Monate. Ich würde gerne den aktuellen Stand dieses Problems erfahren.

Ernsthaft? Ein weiteres "Gut, nicht Böse". Lizenz? Was ist der Sinn davon? Bitte wählen Sie eine echte FSF-zugelassene oder OSI-zugelassene Lizenz.

@andreicristianpetcu : du bist unnötig antagonistisch, weil du nicht informiert bist.

Weißt du, was jshint abgezweigt wurde? Wenn Sie dies tun, lesen Sie diesen Thread sorgfältig durch und entschuldigen Sie sich bitte für den vorherigen Kommentar.

@flying-sheep Ich habe den Thread gelesen. Entschuldigung für den Spam.

Gibt es Fortschritte zu diesem Thema? Es hindert uns daran, es in Fedora aufzunehmen.

Vielen Dank für Ihr Interesse, @eclipseo. Ich würde mich freuen, wenn JSHint in Fedora enthalten wäre! Im Moment versuchen wir, einige gezielte Abschnitte der Codebasis neu zu schreiben. Ich kann nicht direkt beitragen, da ich mit dem nicht-freien Code vertraut bin. Dasselbe gilt für viele unserer früheren Mitwirkenden, daher habe ich nach neuen Leuten mit einer Leidenschaft für freie Software und einer Vorliebe für JavaScript gesucht. Wenn Sie (oder jemand, der Ihnen folgt) jemanden kennen, der in die Rechnung passt, bitten Sie ihn, mich zu kontaktieren (entweder über diesen Thread oder über meine persönliche E-Mail-Adresse).

Nun.... wenn es von Grund auf neu geschrieben ist, spielt es keine Rolle, wer es schreibt. Dies ist ein Urheberrechtsproblem, kein Patentproblem.

Wir versuchen derzeit nicht, von Grund auf neu zu schreiben. Ich habe versucht, dies in meiner vorherigen Antwort mit dem Satz "ein paar gezielte Abschnitte der Codebasis" zu kommunizieren.

Wie ist der aktuelle Stand?

Dasselbe gilt für viele unserer früheren Mitwirkenden, daher habe ich nach neuen Leuten mit einer Leidenschaft für freie Software und einer Vorliebe für JavaScript gesucht. Wenn Sie (oder jemand, der Ihnen folgt) jemanden kennen, der in die Rechnung passt, bitten Sie ihn, mich zu kontaktieren (entweder über diesen Thread oder über meine persönliche E-Mail-Adresse).

Ich bin gerade auf dieses Problem gestoßen - suchen Sie noch nach Hilfe?

@ajakaja ich bin! Könnten Sie eine E-Mail an [email protected] senden ?

Ich befürworte, dass der Autor seiner ursprünglichen Verpflichtung treu bleibt. Wenn dies meine kreative Arbeit (oder eine Ableitung davon) wäre, würde ich auch die Not Evil-Klausel bis zum Ende beibehalten.
Die Klausel ist aus einem bestimmten Grund interpretierbar (und wird sicherlich vor Gericht nicht gelten, und der Autor beabsichtigte auch nicht, dass dies jemals möglich wäre). Und der Grund könnte ein moralischer, ein Sinn für Humor oder wahrscheinlich eine Mischung aus beidem sein.

Wenn nun eine Distribution die Software nicht in ihre Repos aufnehmen kann, weil die Definition von "freier Software", die sie zu befolgen beharren, zu streng ist - _oder soll ich sagen engstirnig_, dann ist das einfach zu schade.

Gute Arbeit @douglascrockford und Projektbetreuer.

Bearbeiten: Ich muss sagen, dass ich technisch _stimme_, dass die Lizenz unfrei ist, da sie zweifellos eine Einschränkung auferlegt, wofür die Software verwendet werden darf, auch wenn sie fast satirisch ist. Die Tatsache, dass Distributionen die Software aus diesen Gründen nicht in ihre offiziellen Repos aufnehmen, ist einfach albern.

Gute Nachrichten, Leute! Wir haben gerade JSHint 2.12.0 veröffentlicht, die erste Version, die vollständig unter der MIT Expact-Lizenz lizenziert ist. Details zum Ablauf finden Sie auf der Projektwebsite.

Wenn noch jemand daran interessiert ist, JSHint für ein Software-Repository zu packen, helfe ich gerne!