Jshint: Cambie la licencia de jshint.js, elimine el mal o el mal

No sé si esto puede suceder alguna vez, ya que la licencia "mala o mala" es la licencia de software original de JSLint.

También creo que esto debería suceder lo antes posible, ya que es un obstáculo importante para enviar también otras piezas de software.

Vea como ejemplo este hilo muy triste sobre el reportero de errores de Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727.

Esto no es posible sin eliminar todo el código Crockford de JSHINT. Sin embargo, definitivamente puede suceder.

Necesito información de alguien que entienda lo legal. (Yo no)

Estoy bastante seguro de que @goatslacker tiene razón. Podrías pedirle a Crockford que cambie su licencia :)

@goatslacker, ¿ dónde puedo encontrar una referencia a todo el código escrito por Crockford que forma parte de este repositorio?

@hellais puede ejecutar una diferencia contra la primera confirmación de jshint (que habría sido donde comenzó la bifurcación), al HEAD actual

Git me dice esto:

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

No debería ser tanto ...

Lo que dijo @dcramer . Sin embargo, no será muy útil, ya que cambié de espacios a pestañas en el camino. Entonces necesitarás hacer algo como eso:

1. Verifique la primera confirmación JSHint. Conviértalo en pestañas.
2. Verifique la última confirmación JSHint.
3. Diferencia (1) y (2) usando una herramienta de diferenciación normal.

Lexer se reescribió por completo, el analizador se cambió sustancialmente y, para ser honesto, no creo que @douglascrockford vaya a demandarme si cambio la licencia. Pero, aún así, no quiero ser un idiota. :-)

@antonkovalyov Creo que una diferencia regular tampoco funcionará porque la estructura del código ha cambiado drásticamente. Estoy buscando una forma posible de determinar qué partes del código son del autor original.

Explorando posibilidades como simian o checkstyle http://checkstyle.sourceforge.net/config_duplicates.html.

Después de extraer todo el código JS de este encabezado: 40e3f73 (la última confirmación por git log --author="Douglas Crockford" ) y comparar eso con todos los js bajo la raíz src / *. Js del maestro actual.

Ejecutando los dos a través del siguiente analizador de similitudes:

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.

Y extrayendo las líneas de código que parecen estar presentes tanto en 40e3f73 como en el maestro actual, parece que estas son las únicas líneas de código que quedan en este repositorio que fueron escritas por 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]] = [];
            }


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

Ésta es una cantidad bastante trivial.

No sé cuál es la mejor forma de proceder aquí. Creo que puede ser el caso de pedir ayuda a un abogado profesional.

Por cierto, esas son 195 líneas de código en un proyecto que tiene más de 9000 líneas de código.

Puede que no tenga idea de lo que está pasando aquí, pero no puedo imaginar que jshint reescribió 8800 líneas de jslint

Volví a ejecutar simian con un umbral de 2 (esto significa que también se mostrarán bloques de menos líneas similares) y obtuve 708 líneas duplicadas.

@dcramer, ¿qué sugeriría hacer con respecto a la refactorización del código de Crockford desde jshint o al cambio de licencia?

@hellais Sugeriría hablar con un abogado, ya que creo que es probable que cualquier otra cosa sea apuntar con un arma directamente a algunos pies.

La respuesta fácil a esto es que tendríamos que pasar del analizador pratt a esprima.

Sabes, podrías tener una conversación con Douglas y averiguar su
pensamientos sobre el asunto, en lugar de intentar eliminar todo su código.

Sería significativamente más fácil e introduciría un riesgo cero para el
base de código. Tratando de refactorizar el código debido a una pequeña frase tonta en un
La licencia parece un poco excesiva.
El 22 de agosto de 2013 a las 7:01 p.m., "Josh Perez" [email protected] escribió:

La respuesta fácil a esto es que tendríamos que alejarnos del pratt
analizador a esprima.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Estoy bastante seguro de que se le ha preguntado a Douglas al respecto antes y se ha negado a volver a licenciarlo. Al buscarlo, lo encontré bromeando sobre cómo recibe cartas de abogados sobre una cláusula similar en la licencia JSON http://dev.hasenj.org/post/3272592502/ibm-and-its-minions. También parece que alguien del departamento legal de Debian le ha enviado un correo electrónico para preguntarle al respecto y su respuesta fue que si no le gusta la licencia, no la use: http://www.mail-archive.com/debian-legal%40lists. debian.org/msg40718.html

Es sólo una "pequeña frase tonta" para usted, pero esa pequeña frase tonta puede ser el factor determinante si el software es utilizable o no. Las licencias son documentos legalmente vinculantes y, dado que no existe una definición legal de lo que es y no es malo, prácticamente significa que es imposible saber si la licencia permite un uso particular del código. Porque no puede saber si está bien usar el código, ya que las empresas con licencia (y organizaciones como Debian) simplemente optarán por no usarlo.

Desafortunadamente, este es un problema común y una lástima, porque creo que
a las personas dispuestas a hacer el mal no les importará la licencia ...

Sin embargo, a veces, el autor acepta cambiar de opinión, principalmente si explicamos
él bloquea muchos otros programas usando su programa.

La última solicitud parece ser de hace unos años, tal vez intentarlo de nuevo y
de nuevo....

2013/8/23 Donald Stufft [email protected]

Estoy bastante seguro de que a Douglas se le ha preguntado al respecto antes y ha
se negó a volver a licenciarlo. Al buscarlo, lo encontré bromeando sobre cómo
recibe cartas de abogados sobre una cláusula similar en la licencia JSON
http://dev.hasenj.org/post/3272592502/ibm-and-its-minions. Aparece
también alguien del departamento legal de Debian le ha enviado un correo electrónico para preguntarle al respecto y su
La respuesta fue si no le gusta la licencia, no la use:
http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40718.html

Es sólo una "pequeña frase tonta" para ti, pero esa pequeña frase tonta puede
ser el factor determinante si el software es utilizable o no. Las licencias son
documentos legalmente vinculantes y dado que no existe una definición legal de
lo que es y lo que no es malo, prácticamente significa que es imposible saber
si la licencia permite algún uso particular del código.
Porque no puede saber si está bien usar el código como empresas con licencia.
(y organizaciones como Debian) simplemente optarán por no usarlo.

-
Responda a este correo electrónico directamente o véalo en Gi
.

ID de clave gpg: 4096R / 326D8438 (keyring.debian.org)

Huella dactilar clave = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438

Oh, el viejo Bien / Mal ... IANAL, pero esto tiene sentido para mí -> http://www.mail-archive.com/debian-legal%40lists.debian.org/msg40728.html

No se puede discutir sobre el bien o el mal en ningún tribunal si los términos no están definidos.

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

@douglascrockford, ¿ http: //good/considered_evil.txt compartido
: +1: ¡formame!

@douglascrockford, ¿alguna vez ha intentado demandar a alguien que haya usado su software para el mal?

Apuesto a que la NSA usa JSHINT para sus proyectos de javascript y creo que están haciendo bastante mal. Sin embargo, parece que su licencia no ha sido muy efectiva para evitar que lo hagan ...

La respuesta fácil a esto es que tendríamos que pasar del analizador pratt a esprima.

En este punto, JSHint cubre más JavaScript (partes estables de ES6, extensiones específicas de Mozilla) y es más tolerante a fallas que Esprima, por lo que el cambio no sucederá en un futuro próximo.

Apuesto a que la NSA usa JSHINT para sus proyectos de JavaScript

:-)

@hellais ¿

No es efectivo en absoluto, pero al menos declara mi intención.

ja ja

De todos modos, envié un correo electrónico a @douglascrockford solicitando un permiso explícito para eliminar esa cláusula de JSHint. Si me concede uno, lo quitaré. Si no lo hace, la gente de Debian tendrá que instalar JSHint a través de NPM o hacer alguna otra solución.

Para ser honesto, me estoy cansando de estas charlas de código abierto que no son verdaderas. De todas las cosas que necesito hacer con JSHint, este problema es probablemente el menos importante.

@OscarGodson El enlace parece inaccesible públicamente a propósito. Recibo una página de error de Google+ ("No se pudo encontrar esta publicación"), que es su aproximación para un 404.

Caso cerrado, la licencia seguirá siendo la misma:

Anton, hay otras formas de solucionar esto que permitirán a Debian llevar un paquete que contenga JSHint y sin crear un esfuerzo adicional para usted. Otros desarrolladores también pueden ofrecerse como voluntarios para ayudar a hacer este trabajo para su proyecto.

Como ejemplo, si quisiera, podría solicitar un Google Summer of Code (estudiante GSoC0 en 2014 y el estudiante podría refactorizar este código de una manera limpia. Debian y otros grandes proyectos tienen mucha experiencia con esquemas como GSoC y como su El proyecto es bueno para todos nuestros otros JavaScript, tendría un caso muy creíble para esto.

Lo primero que debe aclararse es ¿cuánto código es realmente común entre JSHint y JSLint? Por ejemplo, cuando hizo la refactorización, ¿copió y pegó fragmentos completos de código de JSLint en otros archivos fuente? ¿O los otros archivos de origen se desarrollaron de forma independiente sin usar cortar y pegar? Si usó el enfoque de cortar y pegar, entonces debe incluir los términos de @douglascrockford "no evil" en el texto de la licencia de todos esos otros archivos también y todos deberán acreditarlo como colaborador.

Si solo es JSHint.js, es posible que otras personas vuelvan a escribir secciones del archivo. Como mínimo, es posible que desee evitar realizar más cambios en ese archivo y hacer cualquier código nuevo en un archivo separado, de modo que el nuevo código no se vea afectado por la cláusula "sin maldad" y será más fácil para algunos Voluntario trabajando en él en el futuro ya que habrá menos código "sin maldad" para que ellos refactoricen.

La conclusión es que @douglascrockford tiene que decidir si es realmente importante para él que su trabajo sea reconocido y que proyectos como Debian y JSHint propaguen sus preocupaciones fundadas sobre el estilo de codificación. La alternativa es que la gente simplemente actúe como si su proyecto no existiera y eventualmente surgirá algo para reemplazarlo por completo y sus ideas se desvanecen (ciertamente ha sucedido con proyectos más grandes, solo piense en la rapidez con la que WordPerfect o Lotus 123 desaparecieron)

@dpocock > Lo primero que debe aclararse es ¿cuánto código es realmente común entre JSHint y JSLint?

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

La alternativa es que la gente simplemente actúe como si su proyecto no existiera y eventualmente surgirá algo que lo reemplazará por completo y sus ideas se desvanecerán.

@antonkovalyov obviamente lo sabría mejor, pero en general, dudo mucho que esto sea un gran problema para el proyecto. De los 1244 números, parece que solo puedo encontrar este boleto que dice que es un problema.

El 26/08/13 18:28, Oscar Godson escribió:

@dpocock > Lo primero que debe aclararse es ¿cuánto código es realmente común entre JSHint y JSLint?

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

La alternativa es que la gente simplemente actúe como si su proyecto no existiera y eventualmente surgirá algo que lo reemplazará por completo y sus ideas se desvanecerán.

@antonkovalyov obviamente lo sabría mejor, pero en general, dudo mucho que esto sea un gran problema para el proyecto. De los 1244 números, parece que solo puedo encontrar este boleto que dice que es un problema.

Es bien sabido que las licencias "sin maldad" no se consideran gratuitas:

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

El hecho de que solo haya un boleto sobre esto simplemente significa que
Aquellos de nosotros que estamos preocupados por eso no somos lo suficientemente estúpidos como para enviarle spam.
con 100 tickets sobre el mismo tema

Tiene repercusiones para el resto de tu proyecto:

a) si no está empaquetado, tiene menos exposición. Si está empaquetado en
Debian y Fedora, se vuelve mucho más prominente que competir
soluciones. Esto puede atraer a más colaboradores a su proyecto y ayudar
resuelve algunos de esos otros problemas 1244.

b) algunos otros contribuyentes pueden verse disuadidos de contribuir a una
proyecto con una licencia no estándar por temor a que su trabajo no sea
realmente útil para todos los demás de la manera normal

c) proyectos más grandes (por ejemplo, alguien que hace un IDE todo en uno o algo así)
no puede incluir su código de forma segura a menos que copie esos términos de licencia en
su licencia de producto general. Estos usuarios potenciales también pueden ser
contribuyentes potenciales: pero bien pueden invertir su esfuerzo en similares
proyectos con licencias más estándar (o incluso reinventar la rueda),
por lo que hay más duplicación y fragmentación

Comencé una petición para pedirle a Crockford que cambiara su licencia, fírmela: https://www.change.org/petitions/douglas-crockford-remove-the-not-evil-clause-from-your-license-because- es-el-mal-mismo

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

la rama master (3.x) parece tener un jshint.js reescrito, entonces, ¿podemos decir que ya no es un trabajo derivado?

El proyecto Eclipse Orion ha estado usando una copia de jslint donde Doug nos ha dado permiso para usar una licencia que no tiene el "El software se usará para el bien, no para el mal". cláusula.

Tenemos instantáneas de jslint disponibles para 2010-04-06, 2010-12-14 y 2011-12-21.

Mirando el historial de jshint que usó - 2011-01-09, puede haber una buena posibilidad de encontrar lo que busca.

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

¡Gracias @skaegi!

Esos aparentemente fueron 25 días ocupados ...
Puede llevar un poco de tiempo (una semana más o menos), pero déjame ver si podemos obtener una versión perfecta revisada para ayudar a que esto sea mucho más fácil.

El 25/09/14 22:03, Simon Kaegi escribió:

El proyecto Eclipse Orion ha estado usando una copia de jslint donde Doug ha
nos dio permiso para usar una licencia que no tiene el "El
El software se utilizará para el bien, no para el mal ".

Tenemos instantáneas de jslint disponibles para 2010-04-06, 2010-12-14 y
2011-12-21.

Mirando el historial de jshint que usó - 2011-01-09, podría haber
ser una buena posibilidad de encontrar lo que buscas.

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

¿Puede reenviar una copia del correo electrónico de Doug dando esta autorización
o registrarlo en su repositorio?

Gracias @dpocock . Sí, estoy tratando de asegurarme de que estamos haciendo todo correctamente aquí, por lo que esto puede llevar un poco de tiempo. Creo que vale la pena, ya que este problema me ha costado personalmente muchas horas perdidas. (consulte http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s)

No estoy seguro de qué puedo compartir, sin embargo, verificaré con los abogados de propiedad intelectual de la Fundación Eclipse para asegurarme de que todo esté correcto e informar.

El 26/09/14 20:05, Simon Kaegi escribió:

Gracias @dpocock https://github.com/dpocock - Sí, estoy tratando de hacer
asegúrese de que estamos haciendo todo correctamente aquí, por lo que esto puede llevar un poco
de tiempo. Creo que vale la pena, ya que este problema me ha costado
personalmente muchas horas desperdiciadas. (ver
http://www.youtube.com/watch?v=-C-JoyNuQJs&feature=player_detailpage#t=2480s
)

No estoy seguro de qué puedo compartir, sin embargo, lo verificaré con Eclipse.
Los abogados de propiedad intelectual de la Fundación para asegurarse de que todo esté correcto y
informar.

Idealmente, sería un enlace a una publicación en una lista de correo o una copia de una
correo electrónico directo del Sr. Crockford con todos los encabezados, etc.

El proyecto Eclipse Orion ha estado usando una copia de jslint donde Doug nos ha dado permiso para usar una licencia que no tiene el "El software se usará para el bien, no para el mal". cláusula.

bueno, IBM acaba de obtener el permiso para usarlo para el mal. Si nos puede dar una versión que sea realmente MIT, podemos volver a basar este proyecto en él, descartar esa cláusula de broma y todo estará bien en el mundo.

@ oveja voladora si ese es el plan

Actualización: la fundación Eclipse aprobó mi proyecto de distribución de JSLint 2011-01-09 - (consulte https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2011-01-09 .js)

El acuerdo entre Doug y la fundación Eclipse es privado y, por lo tanto, no es algo que yo sepa ni pueda compartir. Sin embargo, trabajé directamente con el equipo de IP de la Fundación Eclipse para obtener esta aprobación, describiendo lo que estaba tratando de hacer y nuevamente pedí una nueva confirmación de que la distribución de Eclipse puede modificar la licencia eliminando la siguiente frase: "El software
se utilizará para el bien, no para el mal ". La solicitud fue considerada y aprobada. Confío en que la fundación haya hecho su debida diligencia aquí. (Más información aquí https://www.eclipse.org/org/#IP%20Management)

En este punto, creo que JSHint o cualquier proyecto debería poder usar esta copia para el bien, el mal o lo que su corazón desee, ya que ha sido enmendada legalmente de acuerdo con un acuerdo con el titular de los derechos de autor y distribuida efectivamente bajo la licencia del MIT que la mayoría estaría de acuerdo en que es una licencia legítima de código abierto.

@skaegi, gracias de nuevo por tu trabajo en esto :)

Maldita sea, @skaegi,: músculo:

@skaegi Si la Fundación Eclipse publica una copia del archivo fuente jslint.js con un texto de licencia de código abierto genuino en la parte superior del archivo (ya sea una licencia MIT pura o un texto de licencia Eclipse), nadie necesita conocer los términos del acuerdo entre @douglascrockford y la Fundación Eclipse, la gente puede simplemente tomar ese archivo distribuido por Eclipse y distribuirlo en sus propios proyectos sin envenenar sus propias licencias.

Las personas que lo distribuyen de esa manera probablemente deberían incluir un comentario en el archivo con la URL de la que lo obtuvieron en el sitio de Eclipse.

No es lo mismo señalar un proyecto que Eclipse aprobó que contiene una copia del archivo; es muy posible que se haya pasado por alto por error. Lo mismo ha sucedido de vez en cuando en Debian, Ubuntu y Fedora y luego el paquete ofensivo ha sido eliminado tan pronto como alguien lo notó.

Gracias @dpocock, esa es una buena respuesta. El error que describe también sucedió en Eclipse y es complicado lidiar con él.

Si los desarrolladores quieren que se incluya una URL de la Fundación Eclipse en un comentario para dejar en claro de dónde vino esta copia, pueden usar:
http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js

Esta URL debe ser estable, ya que el archivo es una instantánea de lo que se aprobó. Preferiría que la gente usara esta primera URL en lugar de http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2011-01-09.js? id = bfe8b59bd463de6bc330d797f0fbf29856178364 que es un enlace a la confirmación específica, pero también es una posibilidad.

Para aliviar cualquier preocupación de que esto fue un error o se pasó por alto, se debe hacer referencia a Eclipse CQ 8747 (donde CQ es Cuestionario de contribución), que es donde se registra la solicitud de distribución y la discusión con el equipo de IP de Eclipse. Debido a que algunas de las solicitudes de CQ pueden contener IP "incorrecta", solo se hacen visibles para los confirmadores de Eclipse; sin embargo, la URL asociada para esta solicitud en particular es http://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 y la estado final aprobado. Más allá de eso, cualquier inquietud sobre la validez de la distribución y el proceso de IP probablemente se aborde mejor con el equipo de IP de la Fundación Eclipse.

¿Eso cubre tus puntos? ¿Puedes pensar en algo más?

@skaegi la URL https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8747 está detrás de un inicio de sesión

hombre. woooo. esto es asombroso.

@rwaldron sí, desafortunadamente necesitas ser un confirmador de Eclipse para acceder a ese enlace (eso es lo que estaba tratando de decir en el comentario anterior). Probablemente no fue muy útil compartir ese enlace, lo siento.

El CQ no fue controvertido: pedí aprobación para usar la instantánea específica de jslint y adjunté el código, expliqué por qué quería esta versión y también solicité una nueva confirmación de que se nos permitía modificar la licencia. Para estar doblemente seguro, también hablé con el equipo de IP de Eclipse para asegurarme de que todo estaba en orden, lo que también está documentado en el CQ. Unos días después se aprobó la solicitud.

@skaegi Solo estaba tratando de reajustar nuestra base de código sobre la versión de software libre que compartiste, pero creo que encontré un problema. Anton inicialmente bifurcó JSHint de la versión de JSLint publicada el 2011-01-09 ( vea la confirmación aquí ). Después de realizar algunos cambios, volvió a aplicar los cambios a la versión de JSLint publicada el 2010-12-16 ( vea la confirmación aquí ). Esto significa que realmente necesitamos comenzar con una versión de software libre del código que se publicó el 16 de diciembre. ¿Tiene una versión que pueda compartir?

No tenemos 2010-12-16 pero sí 2010-12-14.
Eclipse: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/tree/lib/jslint/jslint-2010-12-14.js
Github (espejo) - https://github.com/eclipse/orion.client/blob/master/lib/jslint/jslint-2010-12-14.js

A esto le falta el compromiso que se muestra aquí: https://github.com/douglascrockford/JSLint/commit/caa8885a37afd6895e522409f7889d9333ff6dec

Sería bueno saber si esa lógica ya es relevante, ya que si no lo es, sugeriría volver a basar en 2010-12-14 y terminar con eso.

También tenemos la distribución 2011-01-09 (mencionada anteriormente) que tiene la lógica anterior.
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

Entonces, podría crear un derivado legítimo que use ambas versiones como fuentes, pero parece que estamos jugando juegos en ese momento. Puedo volver atrás y pedir aprobación para el 2010-12-16, pero esto probablemente llevará un poco más de tiempo que la última vez. Sin embargo, creo que vale la pena si eso es lo que necesitamos.

Entonces @jugglinmike , intente volver a basar en 2010-12-14, pero si eso simplemente no va a funcionar, comenzaré el proceso en el lado de Eclipse para obtener una distribución para 2010-12-16.

Simplemente agregando una URL a una rama estable en github con la fuente anterior, ya que ahora no usamos jslint en la versión actual y la eliminamos de master.

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

Muy bien, he completado el rebase; está disponible en la rama master-free de mi bifurcación .

Hablando con @skaegi , me enteré de que Eclipse mantiene un registro dinámico de propiedad intelectual en esta URL: https://www.eclipse.org/projects/ip_log.php?projectid=eclipse.orion

Esto muestra el estado de las CQ a las que se hace referencia: CQ 4745 [JSLint 2010-12-15] y CQ 8747 [JSLint 2011-01-09].

El proyecto Orion lanzará la versión 7.0 el próximo miércoles 29 de octubre. Simon se ha ofrecido a ver que se publique un documento estático para esta versión. Mis preguntas para los mantenedores son : ¿debemos esperar la publicación de este documento? Si es así, ¿le gustaría que vuelva a basarme en ese momento para hacer referencia a la URL de registro de IP estática de las confirmaciones relevantes?

Visión general

Inserté tres confirmaciones en el historial de JSHint :

• Revertir la base de código a la versión JSHint 2010-12-14
• Sustituir JSHint por la versión de software libre
• Incorporar el cambio aguas arriba

La punta de cada rama solo se diferencia en la licencia:

$ 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

... y (por supuesto) todas las pruebas pasan:

$ npm test

(reporter output intentionally omitted)

OK: 648 assertions (8769ms)

Detalles del proceso

Las operaciones de cambio de base son difíciles de auditar porque reescriben el historial (en lugar de modificarlo). En aras de la transparencia, documentaré mi proceso a continuación.

Anton incluyó código de JSLint dos veces después de la bifurcación inicial; estas confirmaciones se aplican justo antes de la última vez que hizo esto. La confirmación en la rama master hoy se titula "Se revirtió la base de código JSLint a la edición 2010-12-16 y se volvieron a aplicar mis cambios". En mi bifurcación, modifiqué ese compromiso para incluir _sólo_ la reaplicación de cambios específicos de JSHint y actualicé la línea de asunto en consecuencia .

Entonces, el historial relevante en master ve así:

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

... contrastó el historial relacionado en 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

Surgieron conflictos de fusión en confirmaciones que modificaron la presentación de la licencia. Esto incluye:

• "Agregar la licencia a README"
  master
master-free ,
• "LICENCIA agregada y CONTRIBUYENTE. Léame actualizado"
  master
master-free
• "Convertir todos los espacios en pestañas".
  master
master-free
• "No hay problema: de tabuladores a espacios"
  master
master-free

Esto se logró "entrenando" la herramienta rerere git usando el script rerere-train.sh y ejecutando el siguiente comando:

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

Si hay algo que me estoy olvidando, hágamelo saber. Y siéntase libre de navegar por el historial para ayudarme a verificar que la rebase fue técnicamente precisa.

:auge:

Aquí hay un enlace a Orion 7.0 Review and IP Log: una lectura emocionante.
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

Muestra que CQ 4745 [JSLint 2010-12-15] y CQ 8747 [JSLint 2011-01-09] fueron una parte aprobada de nuestro lanzamiento que, con suerte, cierra el ciclo.

¿Algún movimiento sobre esta fusión?

@dragorosson Esto es más que un problema técnico; asegurarse de que todo esté por encima de la mesa está tomando algo de tiempo. Gracias por tu interés.

Muchas gracias por trabajar en este tema, quiero tener esto en Fedora. ¿Qué es exactamente lo que queda por hacer?

La mejor manera de confirmar que todavía estamos trabajando en esto es verificar mi rama master-free ; ¡ciertamente no lo mantendría sincronizado si no tuviera la intención de usarlo!

@ piotr1212 Actualmente, necesitamos confirmar el cambio con algunos de los colaboradores anteriores. Parece que eres un mantenedor de RPM, ¿es correcto?

Gracias por la actualización. Esperaré dolorosamente;)
Y sí, soy un mantenedor de paquetes para Fedora / EPEL, hay muchos módulos nodejs que dependen de jshint y no se pueden empaquetar ahora ...

Estoy con @ piotr1212 ; esto ha bloqueado algunas herramientas en Debian que quiero ver. ¡Eliminemos esta cláusula que no es libre!

Me gustaría promover este tema y pedir a todos los colaboradores que no olviden a nuestros empleados gubernamentales dentro de la NSA o GCHQ que mantienen partes del sistema de vigilancia generalizado escrito en JavaScript. ¡Código limpio para todos!

He firmado el CLA y animo a otros a hacer lo mismo.

Como curiosidad, una vez tuve y aproveché para pedirle a Howard Zinn que definiera el mal. Él, sin embargo, me respondió bruscamente, afirmando que si no sabía qué era el mal a mi edad, entonces, seguro, nunca lo sabría. Después de años de reflexión sobre esa declaración, Zinn, por supuesto, tenía razón, y ser errantemente bueno sigue siendo lo mejor que puedo esperar.

¿Esta licencia también se actualizará? https://github.com/jshint/jshint/blob/master/src/jshint.js#L19

@thejameskyle Esa es la única licencia que debe cambiarse. Nos aseguraremos de actualizarlo tan pronto como podamos.

Acabo de encontrar una copia anterior de jshint.js que se abrió paso en un proyecto de Drupal. Tengo problemas para seguir este problema. ¿Se está eliminando la cláusula "Bueno, no malo"? La actividad en https://github.com/webjars/webjars/issues/1127 me hace pensar que esa cláusula se mantendrá.

La mejor manera de confirmar que todavía estamos trabajando en esto es verificar mi rama master-free ; ¡ciertamente no lo mantendría sincronizado si no tuviera la intención de usarlo!

@jugglinmike Leí esa respuesta la primera vez que la publicaste en respuesta a @ piotr1212 en enero, pero no me preguntaba por qué alguien estaría trabajando para que el operador AND funcionara correctamente en POM si estuvieras fusionando esto ... Yo pregunté. Realmente esperaba> actualización y <snark.

Como parte del Grupo de trabajo de licencias de Drupal, nos ocupamos de los problemas de licencias para una comunidad con miles de proyectos y colaboradores. Entiendo lo frustrante que puede ser resolverlos ... y lo ingrato.

¡ASÍ QUE GRACIAS! Cláusulas de licencia no estándar y que no se pueden hacer cumplir como esas son increíblemente improductivas.

Si bien soy culpable de mi parte de respuestas como esta, debes ser consciente de lo desagradable que es esto para alguien que no está familiarizado con tu proyecto.

Dado que no hay nada en el README.md de la sucursal, la descripción, un PR abierto con comentarios o en este número que indique lo que aún se debe hacer, la gente continuará preguntando periódicamente hasta que esto se fusione.

Si va a utilizar una respuesta repetitiva a cualquiera que pregunte, le sugiero algunos cambios. "¡No tenía la intención de usarlo!" is! = "no teníamos la intención de fusionarlo". Sería menos desagradable decir algo como ...

_Si se está actualizando https://github.com/jugglinmike/jshint/tree/master-free , estamos trabajando activamente para resolverlo. Los recursos limitados nos impiden publicar actualizaciones de estado con la frecuencia que nos gustaría, pero este problema permanecerá abierto hasta que se elimine la cláusula "Bueno, no malo".

Este archivo no era esencial para el proyecto Drupal, por lo que se eliminó, pero este problema se está convirtiendo en un gran estudio de caso en el efecto dominó que puede tener la modificación de una licencia verdaderamente abierta y examinada. Avíseme si hay algo que pueda hacer para ayudar a resolver este problema.

No tenía la intención de ser pasivo-agresivo. Interpreté, "Tengo problemas para seguir este tema" como, "Me perdí tu respuesta entre todas las demás discusiones". Agradezco tu sugerencia de una explicación más completa y estoy de acuerdo en que es una mejora. Seguiré con un comentario más visible dedicado a ese mensaje.

En cuanto al problema al que hizo referencia: creo que es valioso que ese proyecto sea sólido en su análisis de SPDX independientemente de la configuración actual de cualquier proyecto específico. Entonces, tendría sentido resolver ese problema en general ... ¡para mí, de todos modos!

Comprobación del estado de este esfuerzo

Si https://github.com/jugglinmike/jshint/tree/master-free se está actualizando, estamos trabajando activamente para resolverlo. Los recursos limitados nos impiden publicar actualizaciones de estado con la frecuencia que nos gustaría, pero este problema permanecerá abierto hasta que se elimine la cláusula "Bueno, no malo".

@jugglinmike Han pasado aproximadamente 11 meses desde el último comentario. Me gustaría saber el estado actual de este problema.

¿Seriamente? Otro "Bien, no mal". ¿licencia? ¿Cual es el punto de esto? Elija una licencia real aprobada por FSF o aprobada por OSI.

@andreicristianpetcu : eres innecesariamente antagónico porque no estás informado.

¿Sabes qué jshint se bifurcó? Una vez que lo hagas, lee atentamente este hilo y luego discúlpate por el comentario anterior.

@ oveja voladora leí el hilo. Perdón por el spam.

¿Algún progreso en este tema? Nos impide incluirlo en Fedora.

Gracias por tu interés, @eclipseo. ¡Me encantaría que JSHint se incluyera en Fedora! En este momento, estamos intentando reescribir algunas secciones específicas del código base. No puedo contribuir directamente debido a mi familiaridad con el código que no es gratuito. Lo mismo ocurre con muchos de nuestros colaboradores anteriores, por lo que he estado buscando gente nueva con pasión por el software libre y afición por JavaScript. Si usted (o cualquier otra persona que lo siga) conoce a alguien que se ajuste a sus necesidades, pídales que se pongan en contacto conmigo (ya sea a través de este hilo o mediante mi dirección de correo electrónico personal).

Bueno ... si está escrito desde cero, no importa quién lo escriba. Este es un problema de derechos de autor, no de patentes.

Actualmente no estamos intentando reescribir desde cero. Traté de comunicar esto en mi respuesta anterior con la frase "algunas secciones específicas del código base".

¿Cuál es el estado actual?

Lo mismo ocurre con muchos de nuestros colaboradores anteriores, por lo que he estado buscando gente nueva con pasión por el software libre y afición por JavaScript. Si usted (o cualquier otra persona que lo siga) conoce a alguien que se ajuste a sus necesidades, pídales que se pongan en contacto conmigo (ya sea a través de este hilo o mediante mi dirección de correo electrónico personal).

Acabo de encontrar este problema. ¿Sigues buscando ayuda?

@ajakaja ¡ Lo soy! ¿Podría enviar un correo electrónico a [email protected] ?

Apruebo que el autor se mantenga fiel a su compromiso original. Si este fuera mi trabajo creativo (o un derivado de él), también mantendría la cláusula Not Evil hasta el final.
La cláusula está abierta a interpretación (y ciertamente no se mantendrá en los tribunales, ni fue la intención del autor que alguna vez pudiera hacerlo, estoy seguro) por una razón. Y la razón puede ser moral, sentido del humor o probablemente una mezcla de ambos.

Ahora bien, si alguna distribución no puede incluir el software en sus repositorios porque la definición de "software libre" que insisten en cumplir es excesivamente estricta, o debería decir de mente estrecha, es una lástima.

Buen trabajo @douglascrockford y mantenedores de proyectos.

Editar: Debo decir que técnicamente _estoy de acuerdo_ en que la licencia no es gratuita, ya que indudablemente impone una restricción sobre para qué se puede usar el software, incluso si es casi satírica. El hecho de que las distribuciones no incluyan el software en sus repositorios oficiales por estos motivos es una tontería.

¡Buenas noticias para todos! Acabamos de publicar JSHint 2.12.0, la primera versión con licencia completa bajo la licencia MIT Expact. Los detalles sobre el proceso están disponibles en el sitio web del proyecto.

Si alguien todavía está interesado en empaquetar JSHint para un repositorio de software, ¡estaré encantado de ayudar!