El desarrollador de dos de las librerías open source más populares de NodeJS ha decidido corromperlas, afectando a millones de usuarios

Con 25 millones de descargas cada semana, Colors.js y Faker.js son dos de las librerías NPM más populares. De la noche a la mañana miles de proyectos han dejado de funcionar al depender de estas librerías. El desarrollador agregó un commit que añadía cinco línea de código. Tres líneas para un 'console.logs' donde se mostraba una cadena con el mensaje de ‘LIBERTY, LIBERTY, LIBERTY’ y un archivo Léeme donde enlazaba a información sobre el proyecto 'Qué le pasó a Aaron Swartz'.

[#7 meneandro]

Aquí la razón: http://web.archive.org/web/20210704022108/https://github.com/Marak/faker.js/issues/1046

[#9 rafran]

#7 Y con toda la razón del mundo... qué grande

[#10 hijomotoss]

El nombre de la libreria ya lo dice todo. Faker.js
#7 Malditos chupocteros. No tienen la suficiente pasta para contratar a un desarrollador para hacer eso?

[#14 meneandro]

#10 Es lo típico de las grandes empresas. Cogen una librería que les resuelve la vida, y luego se mosquean si no les implementas las funcionalidades que necesitan o les arreglas los bugs al momento. Este tío estará hasta los cojones de que los pocos que le ayuden con el código sean independientes no afiliados y que también trabajen por amor al arte.

[#68 Desactivado]

#14 Un pequeño secreto: Las grandes empresas contratan de las cárnicas a gente que programara por el menos precio posible. Estos utilizan librerías abiertas porque no serian capaces de pedir el uso de librerías propietarias, o peor, promover que se paguen para su desarrollos. Vamos, yo le apoyo, pero las compañías lo único que van a hacer es pasarle la culpa a los desarrolladores baratos y decirles que se busquen la vida, que seguramente sera buscando alguna otra librería open source que cumpla la misma funcionalidad o hacer algún freeze a una versión anterior mientras esperan a que alguno haga un fork gratuitamente para "la fama".

Y estos desarrolladores baratas no quiere decir que sean malos, simplemente son la consecuencia de un sector que esta sobrepoblado mientras las compañías siguen aclamando que hay falta de talento con los imbéciles que lo creen / apoyan.

[#93 meneandro]

#77 No, lo que quiere es que si lo usas, le eches una mano. Hay muchísimas cosas que hacer, basta ponerse en contacto con el creador/mantenedor y ofrecerte, o si lo que necesitas es una funcionalidad o que corrija un bug rápido, al menos pagarle.

#7 Software libre no es lo mismo que software gratis... y el esfuerzo y dedicación de un programador hay que recompensarlo. Y las grandes empresas, eso de apoyar a los pequeños creadores... si encima tenía problemas, ya sea financieros o de otro cariz, pues...

#68 Si, claro, es una práctica muy extendida. El problema de npm, pip y demás, es que tú no ves quién está detrás de las librerías y su situación. La añades y te olvidas. El problema es que encima te pongas con exigencias si hay algo en ellas que no te gusta o que necesitas y ni siquiera te ofreces de ningún modo para ayudar, eso quema mucho.

[#17 anjeludo]

#10 Faker es una librería que provee simulación de datos. Es muy útil, por ejemplo, para testing.

[#20 Penetrator]

#10 chupópteros

[#69 XQNO]

#7 Parece que llevaba tiempo jodido

[#77 Desactivado]

#7 no lo entiendo, si no quiere que se use libremente para proyectos comerciales que lo ponga en la licencia

[#2 pkreuzt]

Y que den gracias de que no le haya dado por añadir algún código malicioso.

[#11 carademalo]

#2 Habría sido redundante tratándose de javascript, ¿no?

[#38 Desactivado]

#11 Solo cuando se genera automaticamente desde Kotlin

[#48 carademalo]

#38 Buen zasca. Se nota que eres modenno.

[#34 Desactivado]

#29 ¿Y cual es la alternativa? ¿Reescribirlo todo cada vez que iniciemos un nuevo proyecto? ¿Y donde está el límite? porque ya puestos inventemos un nuevo lenguaje cada vez que empecemos y piquemos un nuevo SO, total... El desarrollo de software se cimenta así, a base de módulos, bibliotecas etc etc. Otra cuestión es el uso prematuro a diestro y siniestro de ciertas funcionalidades. No es comparable un proyecto con cientos de colaboradores a una biblioteca llevada a cabo y mantenida por un solo tío. Jamás debió adquirir ese grado de importancia y la culpa es de las grandes tecnológicas que no invierten en tener precisamente esas bibliotecas publicas sustentadas por un equipo y no por una persona. 

[#49 sadcruel]

#34 Aunque no sea sea 100% seguro, creo que el límite sería el ir investigando qué librerías son fiables (y, como dicen arriba: establecer una versión y hacer pasar los test al actualizar).

Los tutoriales que cita #29 son un oda al uso sin criterio de cualquier librería, todo por una productividad cortoplacista, que estorban mucho a una hipotética consolidación de un conjunto robusto de librerías y recursos para el programador.

[#56 chavi]

#34 El problema viene de aprovecharse del trabajo ajeno sin aportar nada.

El.Soft es suyo y se lo folla como quiere

[#81 ytuqdizes]

#34 Te comento mi alternativa: En mi empresa no uso librerías externas, sino que tengo mi propia librería que utilizo desde los distintos proyectos que desarrollo. Se cumple lo que tu dices, "El desarrollo de software se cimenta así, a base de módulos, bibliotecas etc", sólo que soy yo el que las programa. ¿sabes por qué? Porque sé programarlas. El problema de base no es que los programadores de hoy en día usen bibiotecas, es que la mayoria no saben hacer la puta O con un canuto.

[#83 zULu]

#81 Amén

[#87 davids]

#81 puede que haya gente que no construya sus propias bibliotecas para todas y cada una de las funcionalidades que van más allá de lo que ofrece el lenguaje, es un motivo plausible. Otro motivo igualmente válido es la reducción de costes, ya que el tiempo de programación hoy en día está caro, y hay soluciones de código abierto que te pueden ayudar a ahorrar mucho tiempo y dinero. Si bien es cierto que hay que ser cuidadoso con qué dependencias de terceros se incluyen, existen librerías y frameworks muy sólidos, escritos por gente que incluso programa mejor que uno mismo

[#91 ytuqdizes]

#87 La verdad, todo lo que dices es correcto. No te cambiaría ni media coma. Como digo, no creo que el problema sea la existencia de bibliotecas, sino la falta de habilidad de los programadores; y no porque los juniors de ahora no sean competentes, sino porque el modelo de cárnicas es mucho de contratar recién titulados que saben poco y cobran menos para que el margen se lo lleve el Peter de siempre. Si le pides a un junior que haga algo que no sabe y que lo haga rápido, ¿que hará? pues eso...

[#89 mcfgdbbn3]

#34: Me refiero a los tutoriales en plan "aprende a implementar visión computerizada en 5 minutos", y son básicamente unas pocas líneas de código que copias y pegas, pero no llegas a aprender eso, como mucho aprendes a usar la biblioteca y dependes de ella, pero sigues sin saber casi nada de visión artificial tras esos 5 minutos.

[#1 Desactivado]

Es lo que tiene depender de librerías externas

[#24 Waves]

#1 #4 Basta que fijes la dependencia a una versión específica, con su correspondiente comprobación de su código SHA.

...que es lo que hay que hacer siempre sin excepción.

(Bueno, si has integrado la dependencia en tu proyecto, entonces no hace falta, por motivos obvios.)

editado:

Justo lo que dice #18.

[#26 court]

#24 Aunque hagas eso, las dependencias de las dependencias no tienen por qué estar fijadas (de hecho rara vez lo están), ídem con las dependencias de las dependencias de las dependencias... y así. Es fácil perder el control.

Puedes usar un archivo lock con npm o yarn para congelar todo el árbol de dependencias e incluirlo en tu proyecto, pero no todo el mundo lo hace y los que lo hacen no siempre entienden por qué. Eso sí, cuando quieras actualizar una sola de tus dependencias igual te encuentras cientos de subdependencias nuevas o actualizadas, suerte revisándolas de nuevo...

[#30 alexwing]

#26 aún así es infinitamente mejor que el puto maven de Java.

[#31 hablador_pasivo]

#30 querrás decir infinitamente peor?

[#36 Desactivado]

#31 Es 2022, muerte a node y npm viva deno no ? cc #30 #26 #24

[#79 hablador_pasivo]

#36 Ojala, pero veo a npm demasiado metido en todas partes, va a ser duro de matar.

[#54 pendejo1983]

#30 por?

[#52 hasta_los_cojones]

#26 https://docs.npmjs.com/cli/v8/commands/npm-ci

[#28 Emosido_engañado]

#24 me pasó algo similar y aprendí la lección, no uso jamás librerías externas. Sin excepción. Lo integro todo.

[#25 Shinu]

#1 xkcd hizo una viñeta muy acertada sobre el tema:
https://xkcd.com/2347/

[#76 ingenieril]

#25 Normalmente toda esa dependencia hace que esa libreria se siga manteniendo (de una forma u otra).

[#82 kaostias]

#76 Bueno, ahí tienes el bug de log4j2, que destapó que medio internet era vulnerable y además que un proyecto súper importante era mantenido por 3 personas

[#29 mcfgdbbn3]

#1: Se lo podemos dedicar a todos esos tutoriales que explican cómo hacer virguerías de todo tipo en base a escribir un "import ___ from ___" con Python o JavaScript y dos o tres líneas de código más.

[#40 Whitefox]

#29 "Tranquilos, ya os explicaré luego para qué sirve".

Como esta parodia

[#37 Desactivado]

#1 No, es lo que tiene parasitar un ecosistema sin apoyar a los desarrolladores.

[#71 soberao]

#37 Es la tendencia entre las grandes empresas, usar licencias MIT, BSD y similares donde puedes usar el código sin aportar nada, incluso cerrarlo en tu propia versión. La GPL obliga a usar la misma licencia y a publicar los cambios aunque sea pagando, y esos cambios están también bajo licencia GPL.

[#64 ninefingers]

#1 añado, en librerías externas que una sola persona ha desarrollado en su tiempo libre.

[#74 Desactivado]

#1 es lo que tiene no dejar fijas las versiones en el package.json

[#75 ingenieril]

#1
Es que no te queda mas huevos que depender de librerias externas(salvo que quieras reinventar ruedas por tu cuenta).

Por fortuna depender de librerías externas opensource permite que se puedan corregir estos problemas rápidamente. Ya sea por el propio developer o por los forks de los usuarios.

Teniendo en cuenta la cantidad de fallos que me he topado en este tipo de librerías (y que religiosamente he commiteado parches y mejoras), no me quiero imaginar en un mundo de librerías cerradas. El concepto opensource es imparable precisamente porque cualquiera puede retomar, arreglar y mejorar el proyecto original.

[#13 Nova6K0]

El suicidio de Aaron Swartz y la demostración de la puta basura que es la propiedad intelectual, como puro negocio. Hay que darle las "gracias" al MIT.

Saludos.

[#15 ACEC]

Fue arrestado por tener material para fabricar explosivos tras un incendio en su casa hace un tiempo
https://nypost.com/2020/09/16/resident-of-nyc-home-with-suspected-bomb-making-materials-charged/

[#42 Jakeukalane]

#15 Está todo relacionado. (Supuestamente) Perdió muchas cosas en ese incendió lo que le motivó a pedir dinero para seguir desarrollando varios programas y de ahí...

[#85 Sandevil]

#42 Es relativamente mas complejo ya que es un cripto-bro. Parece que tuvo la suerte de ser un early adopter y realmente lleva unos años retirado como desarrollador activo. Cuando se quemo su casa, intento vender/ceder sus proyectos a empresas, pero sinceramente, una librería de creación de datos falsos para testing y otra para poner colorinchis y fuentes a los logs, si bien son útiles no son imprescindibles.

Son útiles? si. Aportan funcionalidades de gran valor a los proyectos? Me cuesta concebir ese escenario.

En su twitter, tiene un post donde anuncia que vendió su casa hace un par de meses para comprar NFTs. Así que todo parece una rabieta tras ver como todo lo que tiene invertido ha perdido valor en el ultimo mes y descubrir que su código mas usado no tiene realmente valor para las empresas.

[#12 Desactivado]

Desde la ignorancia, ¿cargan una librería directamente desde el repositorio?, a mi no se me ocurriría, me la descargo en mi servidor, la pruebo y si va bien la paso a producción, si se actualiza lo mismo.

[#16 cosmonauta]

#12 Probablemente no trabajas con javascript. Un proyecto pequeño lleva fácilmente cientos de librerías externas, incluso antes de empezar a picar nada. Es imposible tener el control.

[#19 eduardor2k]

#16 ni cualquier lenguje moderno, PHP utiliza lo mismo

[#22 cosmonauta]

#19 Es cierto, pero aún asi, hay diferencias por ecosistemas. Ahora mismo estoy en un proyecto golang con 70 dependencias. En php o javascript arrancas con 500 de saque.

Y 70 dependencias, en go, ya son muchas. Es normal ver proyectos por debajo de 30.

[#23 eduardor2k]

#22 eso es porque son mas modulares, me imagino que go a medida que madure le pasara lo mismo

[#59 chavi]

#22 No tienes una herramienta que se las descargue?

[#60 Peka]

#22 Optimización de código brutal

[#57 chavi]

#16 Cargar las librerías directamente desde el repositorio sigue siendo un despropósito si no tienes el control del mismo.

[#18 Desactivado]

#12 Tienes un listado de dependencias las cuales puedes tener fijadas en una versión o como latest. Lo suyo es tener una versión, y si quieres actualizar la pruebas primero, que pase los tests, etc.

[#39 Desactivado]

#18 Dependabot is your friend

[#21 Pablosky]

#12 Hoy en día si está todo bien montado los desarrolladores tienen Test unitarios, test de integración y test funcionales. Y además de todo eso hay un ¿equipo de Devops? (o algo) que te monta un sistema de integración continua o despliegue continuo o similar.

Si todo está bien montado se supone que en alguno de los entornos previos los tests saltarían por los aires y el Jenkins (o la herramienta que fuera) diría que el build ha sido fallido y que esto no pasa a producción ni empujando.

Pero claro, en muchos sitios se creen que por tener a un DevOps ya lo tienen todo hecho y no hay ni un puto test en ninguna parte, entonces llega el código, pasa por el estado de "build", no peta, el Jenkins ciego perdido lo da por bueno, pasa a producción y luego......

[#27 sisi]

#12 SI, ahora se trabaja así, defines los paquetes que quieres instalar en la definición del proyecto y la herramienta de construcción va a buscar las librerias del proyecto a su origen. Maven lo permite y NPN tambien.
Son herramientas muy comodas que simplifican el trabajo de mantener las dependencias. Ahora bien, tambien tienen sus peligros.
De todas formas una vez tienes descargada la libreria, queda en el repositorio local y no tienes que volver a descargarla de nuevo.

[#61 Peka]

#12 Este es el primer error en la industria de la programación. El segundo es tener todos los servidores fuera de la empresa a miles de kilómetros.

Algún día habrá una sorpresita para todos.

[#46 montaycabe]

El día que casque twoplustwo.js la mitad de webs no podrán calcular 2 más 2 y se irá medio internet a la mierda

[#4 clavícula]

Depender de librerías externas en JS es la segunda manera más fácil de inyectar malware, tras la de dejar un USB con código malicioso en el parking de una empresa.

[#5 pkreuzt]

#4 La forma más fácil de inyectar malware es montar un instalador de un programa muy buscado pero con regalito, y subirlo a cualquier foro de descargas. A ver si no como los juankers rusos obtienen millones de zombis.

[#6 clavícula]

#5 Vale

[#8 pkreuzt]

#6 Eso si, es un perfil de infección distinto. Infectando un programa de uso común obtienes acceso a una máquina con datos de una persona y ancho de banda limitado. Infectando un servidor pones en peligro cuentas de mucha gente y tienes un ancho de banda mucho mayor para usar en otros ataques.

[#63 TonyStark]

#4 es lo que pasa cuando las empresas invierten 0 € y se aprovechan del trabajo de los demás, fliparías la cantidad de proyectos tirando de código open source con todo el morro del mundo y sacando sus beneficios claro, beneficios que no repercuten de ninguna manera en los que mantienen ese código...

[#45 provotector]

Siempre que aparece un fallo en Wordpress hay comentarios de "programadores full stack" diciendo que ellos con node.js lo hacen mejor. Lo bonito de Wordpress es que todo está testeado y es estable con cada actualización, hecha por cierto todo un equipo de gente profesional pagada a sueldo. No por gente altruista que no cobra y que llegados a un punto se pueden ver en situaciones como esta de que dicen "ya estoy hasta las pelotas y por aquí no paso más" y te petan la librería.

[#78 ingenieril]

#45 Mezclas churras con merinas.
¿Que tiene que ver el lenguaje (Node.js) frente a un equipo profesional pagado a sueldo?
Una cosa es el stack tecnológico y otra el soporte/forma de trabajo.
Nosotros trabajamos con Nest.js que es una puta maravilla y somos una empresa con gente profesional con sueldo. Cada vez que la cagamos nos encontramos gente de PHP diciendo que ellos en PHP lo pueden hacer mejor...meeh.

[#33 TitereConCabeza]

Hoy en día el mundo del software libre está controlado por las grandes tecnológicas, bancos y otras grandes entidades tipo BlackStone, fijaos en quienes son los que más dinero invierten en los proyectos por ejemplo en la Linux Software Foundation.

Normal que a algún desarrollador se le hinchen las pelotas y la lie parda.

[#44 DenisseJoel]

Interesantes apreciaciones en su Twitter. En Menéame este hombre llevaría tiempo baneado por sus opiniones.

http://web.archive.org/web/20220109230848/https://twitter.com/marak/status/1478597733028179969

[#3 Desactivado]

CPAN >>>>>>>>>>>>>> NPM.

[#35 XXguiriXX]

#3 ¿Cómo va todo en el año 2000?

[#43 Desactivado]

#35 en SDF, texto-plano y las tildes DPM.

http://sdf.org/

https://wiki.texto-plano.xyz/doku.php?id=pubnix

[#65 ninefingers]

#35 La verdad es que mejor.

[#47 Desactivado]

Pues muy sencillo, que las empresas que usaban la librería programen internamente algo parecido y tema solucionado...

[#50 Ehorus]

#47 más sencillo aún.. que las empresas paguenj a los desarrolladores como este, y dejen de lucrarse por trabajo ajeno

[#66 ninefingers]

#47 Y si resulta que es una librería, que usa una librería, que usa una librería, que usa una librería que usa esa librería?

[#70 Fernando_x]

#66 ¿en un bucle cerrado? ¿Es eso siquiera posible?

[#86 ninefingers]

#70 No entiendo a qué te refieres con un bucle cerrado, pero es normal que la gente use dependencias que tienen otras dependencias y así sucesivamente, con lo que llevar un tracking de todas las librerías de las que realmente depende tu aplicación puede ser muy complejo.

[#88 Fernando_x]

#86 Igual te he entendido mal, me pareció que hacías una broma con una serie de dependencias de librerías, de la forma: la librería A, que usa la librería B, que usa la librería C, que usa la librería A. Y no sé realmente si algo así es posible.

[#92 ninefingers]

#88 No, más bien hablaba de dependencias en forma de árbol, donde fácilmente no vas a darte cuenta de todas las dependencias de las librerías que usas.

[#51 samsaga2]

Conozco más de un programador web que para ir a cagar tiene que añadir una nueva dependencia. Los llamo programadores tente porque no saben programar, lo único que hacen es juntar piezas como en un tente.

[#55 Desactivado]

#51 para qué perder el tiempo con algo que ya está hecho?

[#67 ninefingers]

#55 A veces no hace falta una librería adicional para sumar 1 + 1.

[#80 ingenieril]

#51 Me encanta lo de programadores “tente”. Yo a los programadores que se tiran 4 meses escribiendo un plugin para Paypal los llamo programadores “tontos”. Si te pillas la dependencia tienes una libreria testeada por millones de proyectos, mantenida por gente constantemente, y que tiene en cuenta cosas (por madurez) que tu “reinvención de rueda” no va a tener en cuenta.
Los desarrolladores son precisamente eso, desarrolladores “tente” que saben elegir las mejores librerias de entre las decenas que hay disponibles para lo mismo. Despues Glue entre las librerias, buenas prácticas y buena arquitectura (que son los conceptos realmente importantes).

[#32 Chinaskii]

Joder, pero entonces…¿ Qué le pasó a Aaron Swartz?

[#90 SiCk]

#32 No lo he visto, pero: https://archive.org/details/LaHistoriaDeAaronSwartzElHijoDeInternet

[#95 Chinaskii]

#90 Gracias! Justo subieron hoy un post sobre el colega. ( https://www.meneame.net/go?id=3609341)

[#73 emdi]

ES lo que tiene el modelo del software libre. Que es libre. Y libre en muchas ocasiones es aprovecharse de el o acabar hasta los cojones de hacerlo por amor al arte. De verdad preferis el modelo de software privativo aunque haya muchos jetas con mucho dinero que se aprovechen?
No se vosotros pero yo he podido aprender "informatica" gracias a que no he tenido que pagar licencias por usar mi SO, contenedores, maquinas virtuales, IDE, lenguje de programacion, librerias, servidor de BBDD, etc. etc, etc

[#41 DenisseJoel]

¿La corrupción de las librerías consiste en que ha puesto 3 console.log? ¿Y eso provoca que las aplicaciones basadas en estas librerías fallen? No sé, no me cuadra del todo. Pero bueno, es Xataka. ¿Qué podemos esperar?

[#53 hasta_los_cojones]

#41 Si tienes una herramienta de análisis de logs, te puede joder bastante.

[#94 DenisseJoel]

#53 Pues Xataka se ha quedado a un párrafo de que su artículo tuviera sentido.

[#84 Sandevil]

#41 y un bucle infinito por medias, aunque tuvo que realizar un segundo commit al poner un ; donde no tocaba.

[#62 Desactivado]

Hablando sobre Aaron Swartz, deberían preguntarle a Steve Huffman y cuanto contribuyo a su depresión la perspectiva de alguien que solo iba detrás del dinero y posiblemente algunos encuentros que Ghislaine Maxwell organizo para los grandes lideres de Silicon Valley.

[#58 maxxcan]

A ver este desarrollador es imbécil y tanto él como aquí parece que nadie tiene ni idea de cómo funcionan las licencias de software o la diferencia entre software libre y open source y así nos va. Si este señor no queria que usasen sus librerías gratis por qué usó una licencia MIT? Y por qué no eligió una GPL en vez de MIT? Cuando uno usa una licencia en su software debe ser consecuente como somos los adultos y no comportarse como un niño pequeño. Una demanda mínimo es lo que se merece este señor.

[#72 zancudo]

#58 ¿Una demanda por modificar algo que es SU propiedad intelectual? No creo que hayas pensado lo que has escrito.

[#96 maxxcan]

#72 no hombre la demanda no es por modificar SU código, es por ser imbécil. A ver si me entero. este tipo crea una librería con licencia MIT, que no GPL u otras similares, las pone en un servidor que NO es SUYO, porque es GRATIS, y pide dinero por sus huevos morenos. Como no le dan dinero pues decide hacer esto. Por cierto, si su usas una licencia MIT el código ya no es TUYO completamente porque han colaborado muchas otras personas. Si quieres hacer una librería y que nadie la use gratis, le pones una licencia cerrada, te lo pones en TU servidor que TÚ te montas o lo alquilas y ya verás como no tienes problemas.

[#97 zancudo]

#96 Sostenella y no enmendalla. No voy a dedicarle mucho tiempo más a esto porque ya hay mucha gente comentando en la noticia y me conozco y termino con discusiones bizantinas interminables.

No puedes demandar a nadie por ser imbécil. Menos aún si lo único que haces es modificar un código que te pertenece. Porque sí, le pertenece, no pierdes la autoría ni pierdes los derechos sobre tu código por mucha licencia MIT que le pongas. Él SIEMPRE va a poder modificar su código porque es SU código. Evidentemente si han contribuido más personas, esas personas son las que tienen la propiedad intelectual del código con el que han contribuido, a no ser que hayan acordado una cesión del mismo (como sucede en las empresas de desarrollo de software) y en este caso las personas que han contribuido lo han hecho bajo licencia MIT, por lo que él tiene derecho a modificar ese código también. La FSF solía pedir por carta la cesión de derechos a aquellos que contribuyeran con más de diez líneas de código al proyecto para curarse en saludo y ahorrarse problemas de los que tú comentas: la aceptación implícita de la licencia del proyecto en el que colaboras. En resumen: que puede hacer lo que quiera con SU código.

Que tú puedas copiar el código, modificarlo, mejorarlo o regalarlo no quita nada de lo que he dicho. Las empresas que se benefician de su código y el resto de los usuarios pueden hacer lo que les permita la licencia que él ha elegido, nada más y nada menos. Y como ya he comentado en otros comentarios, parece que se equivocó al elegir la licencia visto el enfado (podría haber pensado en tener una doble licencia o publicar sólo versiones antiguas y las modernas que fueran de pago o haber elegido una licencia privativa o la GPL). Pero es que tiene derecho a su enfado y a su pataleo, igual que las empresas tiene derecho legal a usar su trabajo sin pagarle un café (la moral ni está ni se le espera visto lo visto).

El que el servidor sea gratis o no es irrelevante, el repositorio podría estar en una raspberry pi en su casa y no cambiaría nada (es que ni siquiera sé por qué lo dices, menos aún por qué lo dices con vehemencia). No influye en nada. Tú no pierdes tus derechos de propiedad intelectual por subirlo a Github (hasta ahí podía llegar la tontería), sólo les cedes a ellos el derecho a publicarlo. Punto. Es con la licencia MIT con la que cedes otros derechos como son el de copia, modificación o distribución.

Y por supuesto que puede pedir el dinero que quiera, enfadarse, modificar su código, cerrar su repositorio o encerrarse en su casa y dejar de respirar durante diez segundos. No le debe un mantenimiento gratuito del código a nadie.

Hasta luego