DESARROLLADOR

Cómo JSHint aprendió de la manera difícil sin usar licencias de fuente ética

Comentario: ¿Le preocupa que alguien use su software para hacer el mal? Si es así, esa no es una buena razón para aplicarle una licencia de «no hacer daño».

open source
Imagen: Getty Images/iStockphoto

Las llamadas licencias «morales», como licencia hipocrática Parece una buena idea. Estas licencias prohíben que las personas usen software con licencia si «ponen en peligro, dañan o amenazan de manera activa y consciente el bienestar físico, mental, económico o general de personas o grupos vulnerables». Bloquear el malware para que no acceda a un gran software es algo muy bueno, ¿verdad?

Incorrecto. O, al menos, la aplicación está mal. Aunque he estado diciendo esto por un tiempo, probablemente sea más persuasivo escuchar a alguien tratando de aplicar términos de licencia «éticos» a su software, y encontrándolos tan mal concebidos por las malas como bien intencionados.

aquí estás, Mike Pennisi de JSHint.

Mirar: Cómo construir una carrera de desarrollador exitosa (PDF gratuito) (República tecnológica)

Resulta que detener el mal es difícil

JSHint existe desde 2011, y una estipulación en su licencia de código abierto es bastante indiscutible: «Software para el bien, no para el mal». Curiosamente, Pennisi quiere deshacerse de la licencia no libre «no hacer el mal», pero tomó siete años a partir de esa determinación para volver a obtener la licencia del código bajo la licencia MIT Expat. Durante ese tiempo, JSHint perdió su estatus como la herramienta más popular de su tipo, «La mayoría de los desarrolladores de hoy lo consideran obsoleto», dijo Pennessey.

moneda. ¿Cómo perjudicó la cláusula de licencia moral a la comunidad y por qué tomó tanto tiempo cambiar las cosas?

LEER  ¿Sin innovación en la nube?volverse real

El primer problema con la licencia es la ambigüedad. El licenciante puede saber exactamente lo que quiere decir con «maldad» (aunque sospecho que la mayoría de los puntos de vista de línea dura luchan por proporcionar una guía clara para los casos extremos), pero el licenciatario no lo sabe. Pennisi escribió en su publicación JSHint: Watching the Ship Sink:

Debido a esto [“Good, not Evil”] Términos, las personas que respetan las prácticas de licenciamiento de software simplemente no pueden usar JSHint. Si no eres experto en asuntos legales, esto puede parecer una limitación extraña. Al rechazar JSHint, ¿las personas están admitiendo que quieren hacer cosas malas? ¿Es la cláusula realmente aplicable de todos modos?

La respuesta a la segunda pregunta es «no», lo que ayuda a responder la primera pregunta. Los opositores legalmente conscientes no traicionaron sus propios motivos viles. Se negaron a celebrar contratos ambiguos. En otras palabras: en lugar de decir «soy un villano», dicen «no entiendo lo que quieres». Esta consideración impide que JSHint se incluya en varios contextos.

tl; dr? «Menos gente [using this] Extrañamente dificulta el linter de JavaScript», señala Pennisi. Para un proyecto como JSHint, dijo Pennisi, las personas que usan el código son las personas que tienen la capacidad de mejorar el código, y perder usuarios significa perder colaboradores. Esto a su vez hace que JSHint a quedarse atrás de Alternativas a los constructores de JavaScript. A su vez, continuó: «La reducción en la base de usuarios/colaboradores es un círculo vicioso. Si bien el movimiento puede haber comenzado con personas conscientes de las licencias, todos sintieron el dolor del ciclo de liberación por igual y su éxodo exacerbó el problema. »

Una vez más, esta no es la intención equivocada. Es solo que cosas como esta son difíciles (léase: imposibles) de aplicar en la práctica.como Maish Saidel-Keesing escribió«¿Qué es inmoral?» es una pregunta difícil de responder, «o más precisamente, aún más difícil de ponerse de acuerdo».

Mirar: Comandos de Linux para la gestión de usuarios (República Tecnológica Premium)

Independientemente de sus puntos de vista políticos o éticos, su mejor oportunidad para hacer que su proyecto de código abierto sea excelente y, por lo tanto, se utilice para grandes cosas es utilizar Licencia estándar de código abiertoEl código debe ser lo más importante, no la licencia. Si utiliza una licencia desconocida e impopular, llama la atención sobre el aspecto (posiblemente) menos importante del software. No hagas eso. Concentre la atención del desarrollador en qué tan bueno es su software, no en qué tan bien está obstaculizado por licencias éticas.

Divulgación: trabajo para AWS, pero las opiniones expresadas aquí son mías y no reflejan necesariamente las opiniones de mi empleador.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba