- El cambio en las condiciones de entrega del código fuente de RHEL por parte de Red Hat debe verse dentro de la larga historia de Unix, GNU, Linux e IBM; IBM/Red Hat sostienen que cumplen con el principio de la GPL de “entregar el código fuente a quienes reciben los binarios”
- Al principio, el software era creado y compartido por investigadores y usuarios según sus necesidades, pero desde la década de 1980 se reforzaron el copyright y las licencias, y se separaron caminos como los EULA, los contratos de código fuente, las licencias permisivas y la GPL
- GNU y Linux crecieron gracias al código fuente abierto y a las contribuciones de la comunidad; IBM, tras anunciar una inversión de 1.000 millones de dólares en Linux, fortaleció la confianza del ecosistema contratando desarrolladores y respondiendo a la demanda de SCO
- RHEL es un producto de servidor empresarial que usa Fedora como base experimental, y Red Hat busca recuperar mediante licencias de clientes los costos de soporte, QA, documentación, ingeniería de lanzamientos y una estructura global de soporte
- Los usuarios de clones de RHEL pueden elegir otras distribuciones de Linux, pero para quienes crean clones sería más productivo construir una distribución que compita con RHEL que limitarse a copiarlo
Postura básica ante los cambios de Red Hat
- Los recientes cambios en las condiciones de venta de Red Hat generaron debate, pero el punto central es la forma de entregar el código fuente a los clientes que reciben binarios de RHEL
- La esencia de la GPL es garantizar el acceso al código fuente y la posibilidad de modificarlo para que quien recibe los binarios pueda corregir errores y ampliar el sistema operativo
- IBM/Red Hat entregan a los clientes bajo contrato el código fuente y la información necesaria para construir la distribución, y se considera que siguen enviando upstream los cambios al código GPL
- No es fácil agrupar todos los intereses solo con la palabra “comunidad”, y quienes no necesitan el mismo nivel de ingeniería y soporte pueden elegir otra distribución de Linux
Del intercambio de software a la era de las licencias
- Alrededor de 1969, la programación era principalmente algo que investigadores, profesores e ingenieros hacían para su propio trabajo, y la profesión de “programador profesional” no era común
- Grupos de usuarios como DECUS distribuían software escrito por clientes a un costo cercano al de la copia, y muchos usuarios publicaban código en dominio público
- En esa época, la aplicación de copyright o patentes al software era limitada, por lo que para proteger el código había que depender de secretos comerciales, derecho contractual y distribución binaria
- A comienzos de la década de 1980, cuando empezó a aplicarse con fuerza la doctrina del copyright a binarios y código fuente, los desarrolladores necesitaron licencias que explicaran los derechos de los usuarios
- Para los usuarios finales aparecieron los EULA
- Para los desarrolladores se aplicaron por separado contratos de código fuente
La base creada por Unix, BSD y GNU
- Unix comenzó en 1969 en Bell Labs y luego se difundió a universidades de investigación como UC Berkeley, MIT, Stanford y CMU
- BSD Unix de UC Berkeley ofrecía memoria virtual con paginación por demanda, TCP/IP nativo y una amplia colección de utilidades, y se convirtió en la base de varios proveedores tempranos de Unix
- Productos como SunOS, Ultrix y HP/UX adoptaron una base BSD
- El comentario de John Lions sobre Unix Version 6 tuvo bloqueada durante mucho tiempo su publicación oficial, pero mediante copias enseñó a muchísimos programadores de Unix la estructura del kernel y el pensamiento de diseño
- Las licencias de código fuente de Unix de AT&T eran caras y restrictivas, por lo que algunas empresas optaron por contratos de redistribución para vender sistemas tipo Unix solo en binario
- Richard M. Stallman, tras encontrarse con distribuciones de Unix que solo entregaban binarios, inició el proyecto GNU a partir de la conciencia del problema de que los usuarios no podían hacer las modificaciones que necesitaban
- El objetivo de GNU era crear un sistema operativo libre en el que quien distribuyera binarios garantizara a los receptores el código fuente y la posibilidad de modificarlo
- Primero se creó software directamente útil para programadores, como emacs, una suite de compiladores y utilidades
Diferencias entre las licencias permisivas y la GPL
- Universidades como MIT y UC Berkeley querían distribuir código de investigación más que venderlo, pero después de que empezó a aplicarse el copyright necesitaron licencias que incluyeran condiciones de uso y limitaciones de responsabilidad
- Esas licencias luego pasaron a conocerse como licencias permisivas del open source
- Los desarrolladores pueden crear distribuciones solo en binario
- No necesitan revelar a los usuarios finales cambios distintos del código fuente que recibieron originalmente
- La GPL se consolidó como una licencia restrictiva que obliga a que los usuarios finales que reciben binarios puedan ver los cambios
- Al principio hubo varios malentendidos sobre la GPL
- Algunas personas pensaban que los binarios creados con el compilador de GNU también quedaban cubiertos por la GPL
- Otras pensaban que no se podía vender código GPL, pero RMS refutó esa idea
- Empresas como Walnut Creek y Prime Time Freeware for Unix vendían varios códigos open source agrupados en CD-ROM y DVD
La presión sobre el mercado Unix y el auge de Linux
- Proveedores de sistemas como DEC, HP, Sun e IBM crearon sistemas operativos tipo Unix basados en AT&T System V o en ramas BSD, y para eso contrataron ingenieros, redactores técnicos, personal de QA y gerentes de producto
- Se considera que, para crear un sistema tipo Unix competitivo, cada empresa gastaba aproximadamente entre 1.000 y 2.000 millones de dólares al año
- Microsoft vendía el mismo sistema operativo independientemente del fabricante de la PC y, al subir al mercado de sistemas operativos para servidores, presionó a los proveedores de Unix
- El proyecto del kernel Linux comenzó a fines de 1991 por la convergencia de varias condiciones, y para fines de 1993 varias distribuciones ya estaban en una etapa de crecimiento
- Ya existía software de GNU, MIT, BSD y proyectos independientes
- Había mucha información en Internet sobre el interior de los sistemas operativos
- Internet de alta velocidad empezaba a llegar a los hogares
- Se popularizaron procesadores de bajo costo capaces de memoria virtual con paginación por demanda
- Hubo suerte y oportunidad
- Había un líder de proyecto obstinado y carismático
- Aparecieron distribuciones como Soft Landing Systems, Yggdrasil, Debian, Slackware y Red Hat; algunas empezaron como distribuciones comerciales y otras como proyectos comunitarios
Linux y el modelo comunitario
- Una de las razones por las que Linux recibió atención masiva antes que BSD fue que BSD estaba atrapado en la demanda “Unix Systems Labs vs BSDi”
- La GPL produjo un efecto dinámico al obligar a distribuir el código fuente junto con los binarios, y como cualquiera podía iniciar un proyecto de distribución sin pedir permiso, surgieron cientos de distribuciones
- X Window System salió del MIT Project Athena, y Kerberos también salió del mismo proyecto
- El desarrollo de X Window System se trasladó más allá de MIT y Project Athena al X Consortium, que abrió en 1993 y cerró en 1996
- OSF se creó para establecer estándares de código fuente y API para sistemas Unix, y en 1996 se fusionó con X/Open para convertirse en Open Group
- Varios consorcios al principio tenían mucho financiamiento, pero siguieron el patrón de quedarse sin fondos cuando las empresas participantes se retiraban pensando que “otra empresa pagará los costos”
El problema de sostenibilidad del desarrollo FOSS
- En los primeros tiempos del FOSS, un pequeño número de desarrolladores trabajaba con pasión para un pequeño número de usuarios, muchas veces sin recibir remuneración
- A medida que el número de usuarios creció más rápido que el número de desarrolladores, aumentó la presión de mantenimiento
- La falta de desarrolladores se hizo especialmente evidente en áreas “poco sexys” como QA, ingeniería de lanzamientos, documentación y traducción
- Algunos desarrolladores se sentían incómodos con que otros ganaran dinero usando código que ellos habían aportado gratis, pero la postura es que Linux solo podía avanzar rápidamente si las empresas podían ganar dinero con Linux
- Con el tiempo, la comunidad pasó a incluir no solo a quienes escribían código, sino también a quienes se encargaban de documentación, traducción y promoción; más tarde también aumentó la cantidad de personas que solo usaban software gratis y no entendían el software de libertad
Piratería de software y el costo del software libre
- La piratería de software consiste en copiar y usar software ilegalmente, en contra de la licencia
- Algunos integrantes de la comunidad FOSS toman a la ligera la propiedad intelectual o el copyright, pero sin copyright también se pierde el control sobre el software
- En una conferencia en Brasil, cuando se dijo “hay que usar Free Software”, el público respondió “todo nuestro software es free”
- En aquel momento, casi el 90% del software de escritorio en Brasil era pirateado
- En esa situación, se pierde parte de la ventaja del bajo costo del Free Software
- Se considera que, si todas las personas que usan el kernel Linux pagaran apenas 1 dólar por plataforma de hardware, se podría financiar fácilmente la mayor parte del desarrollo FOSS
La participación de IBM en Linux
- Dentro de IBM había personas que creían en el FOSS y trabajaban en proyectos en su tiempo libre, y Daniel Frye intentó reunirlas en una organización FOSS interna de IBM para impulsar Linux
- Se recuerda que Lou Gerstner, de IBM, envió una carta con la idea de que antes se adoptaba open source solo cuando había una razón de negocio, pero que en adelante solo se iría a código cerrado cuando hubiera una razón de negocio
- En esa época IBM anunció que invertiría 1.000 millones de dólares en Linux, lo que causó un gran impacto
- Luego IBM contrató desarrolladores de Linux para que trabajaran a tiempo completo en varias áreas relacionadas con Linux, y también pagó salarios a desarrolladores en áreas como Apache Web Server
- Aproximadamente un año después, IBM recuperó la primera inversión de 1.000 millones de dólares y anunció que invertiría otros 1.000 millones
- IBM vendió su negocio de laptops y desktops a Lenovo y adquirió Price Waterhouse Cooper, orientándose como una empresa de soluciones de negocio
- A partir de entonces, las soluciones de negocio pudieron dejar de estar atadas solo al hardware y software de IBM
- Open Source pasó a tratarse como un elemento que permitía a los proveedores de soluciones de IBM crear mejores soluciones a menor costo
El papel de IBM en la demanda de SCO
- Santa Cruz Operations creó una distribución Unix basada en el código de AT&T y luego fue vendida a Caldera Group
- Caldera cambió su nombre a SCO y adoptó una estrategia de demandas contra proveedores de Linux, alegando que Linux contenía código fuente de AT&T y violaba condiciones de licencia
- Gran parte de la comunidad Linux consideraba falsa esa afirmación, y por experiencia leyendo los contratos entre AT&T y Novell, también era difícil creer que Santa Cruz Operations poseyera el copyright del código de AT&T
- IBM, Novell, Red Hat y otros participaron en la batalla legal, y se resume que finalmente el tribunal concluyó que SCO solo podía plantear un problema de un contrato desaparecido con IBM, pero que Linux no tenía problemas
- En este proceso, el hecho de que Big Blue participara en la batalla legal dio a proveedores y usuarios de Linux confianza en que las cosas saldrían bien
El modelo de negocio de Red Hat y RHEL
- Red Hat nació como una pequeña empresa de Raleigh con fuerte capacidad técnica pero débil en negocios y marketing, y Bob Young se sumó para ayudar a definir las políticas y la dirección de la compañía
- Bob Young usó la analogía de convertir a Red Hat en el “ketchup Heinz de Linux”, y Red Hat ganó dinero con un modelo de venta de servicios
- Con el tiempo, Red Hat se concentró en un negocio empresarial centrado en RHEL
- El desktop solo era importante como plataforma de desarrollo de RHEL, y el desarrollo de desktop quedó en manos de Fedora
- Fedora cumple el rol de base de pruebas para ideas nuevas que luego podrían entrar en RHEL
- Los clientes de RHEL son organizaciones como empresas y gobiernos que requieren sistemas “mission critical” y “always on”, y con frecuencia operan miles de sistemas, no decenas o cientos
- Estos clientes manejan condiciones de servicio y cláusulas de penalización como MTTF, MTTR y 99,999% de tiempo de actividad, y esperan soporte de segundo y tercer nivel, no soporte general de primer nivel
- Red Hat invierte en soporte empresarial, QA, documentación, certificación e ingeniería de lanzamientos, y los clientes pagan por ello
Empresas full-stack y la lógica de IBM para adquirir Red Hat
- El caso de Oracle al adquirir la propiedad intelectual de Sun Microsystems se trata como una estrategia full-stack, que controla hardware, sistema operativo y aplicaciones
- Una empresa full-stack puede modificar toda la pila para beneficiar a las aplicaciones, y puede probar toda la pila para encontrar ineficiencias y debilidades
- IBM y Apple se clasifican como empresas full-stack, y aunque sus productos son más caros, muchos clientes serios pagan ese costo
- IBM necesitaba una solución full-stack basada en Linux para usar en su negocio de soluciones empresariales, y RHEL de Red Hat contaba con la reputación y la ingeniería de una solución empresarial
Clones de RHEL y cambios en las condiciones de Red Hat
- Con el tiempo, algunos clientes desarrollaron el patrón de comprar solo unos pocos sistemas RHEL y usar en el resto de sus sistemas otra distribución compatible con Red Hat bug-for-bug
- Este enfoque reducía los costos para el cliente, pero también reducía los ingresos de Red Hat pese a hacer la misma cantidad de trabajo, y Red Hat quedó bajo presión para subir el precio de las licencias, reducir personal o abandonar otros proyectos
- IBM/Red Hat tomó la decisión de negocio de distribuir el código fuente y la información de compilación solo a clientes que compren licencias para todos los sistemas que ejecutan RHEL
- Se considera que esta condición coincide con el núcleo de la GPL
- Quien recibe binarios puede recibir el código fuente para corregir errores y ampliarlo
- Red Hat e IBM siguen enviando upstream los cambios al código GPL
- También continúa el intercambio de ideas con la comunidad más amplia
- No se llama “freeloader” a los desarrolladores de clones, pero se considera que los usuarios que usan clones sin devolver nada a la comunidad de ninguna forma están cerca del freeloading
Propuesta: crear competencia en lugar de clones
- Tras los cambios de Red Hat, varias distribuciones dijeron que seguirían creando “not RHEL”, lo que puede confundir aún más a los usuarios comunes sobre qué distribución deberían usar
- La postura es que, en lugar de crear varios clones por separado, sería mejor construir juntos una buena distribución o crear un verdadero competidor de RHEL
- Se evalúa positivamente que SuSE haya dicho que invertirá 10 millones de dólares para crear un competidor de RHEL
- Sin embargo, no es barato contar con los mismos canales de negocio, equipos de soporte globales y estructura de soporte empresarial
- 10 millones de dólares pueden ser un punto de partida
- Los clientes de RHEL deben elegir viendo el valor del soporte que ofrecen Red Hat/IBM y sus socios de canal
- Si IBM ya no quiere hacer negocios con clientes que compran una sola copia de RHEL y operan el resto con distribuciones gratuitas, esos clientes deberían buscar otro proveedor de Linux empresarial que pueda atender ese tipo de caso
Conclusión personal
- Jon “maddog” Hall afirma que viene publicando código fuente y entregando código fuente a clientes desde antes de que existieran Open Source, la Free Software Foundation y el proyecto GNU
- Las contribuciones a la comunidad no se limitan a escribir código, documentación o reportes de bugs
- Se puede promover el Free Software en escuelas, empresas y gobiernos
- Se puede crear un Linux Club o ayudar en actividades Upgrade to Linux
- Mientras las empresas no violen licencias, pueden definir sus condiciones de negocio, y los clientes pueden aceptarlas o rechazarlas
- Es desequilibrado retratar a Red Hat e IBM como “malvados” y al mismo tiempo no mirar a empresas que, basadas en licencias permisivas, no garantizan el código fuente a los usuarios finales o solo ofrecen licencias de código cerrado y no permiten clones
- Para investigadores, estudiantes, aficionados y personas con muy poco dinero, existen cientos de distribuciones de Linux que incluso soportan arquitecturas que RHEL no cubre
1 comentarios
Comentarios de Hacker News
Desde finales de los 90 he usado Red Hat Linux (al principio Caldera Linux, un clon de los 90), Fedora, RHEL y sus clones (Scientific, CentOS, Rocky) para uso personal, educativo y laboral, y también los he recomendado para escritorios y servidores.
Solía decir que, si querías usar Linux, las dos opciones estables y bien soportadas eran Red Hat y Debian, pero considero que Red Hat murió recientemente. RIP.
Ahora no estoy seguro de que Fedora vaya a seguir siendo un proyecto open source activo. Si IBM está matando ahora a los clones de RHEL, ¿por qué habría que arriesgarse a pensar que Fedora no será la siguiente?
Sé que dicen “RHEL se deriva de Fedora” y “Fedora es un proyecto open source separado”, pero hoy RHEL se deriva de CentOS Stream. Entonces me pregunto para qué hace falta Fedora y por qué Red Hat debería aportar ingeniería e infraestructura a Fedora.
Es cierto que Fedora es un proyecto separado, pero la mayoría de las contribuciones las hacen empleados de Red Hat. Si mañana IBM decide que CentOS Stream es suficiente y deja de pagar los costos de Fedora, ¿podría Fedora sostenerse de forma independiente?
Puede que esto sea simple miedo, incertidumbre y duda (FUD), pero ya no confío en una distribución Linux propiedad de IBM. Ya pasé mis equipos personales a Debian y en el trabajo también recomiendo Debian. Me parece irresponsable que una organización que personaliza mucho sus instalaciones de Linux elija una distribución basada en Red Hat/IBM, con incertidumbre, en lugar de un proyecto completamente open source y sin condiciones. Si me engañan una vez, la culpa es del otro; si me engañan dos veces, es mía, y no dejaré que IBM me vuelva a hacer lo mismo.
Fedora sigue funcionando como campo de pruebas para todo lo de CentOS y, por lo tanto, para todo lo de RHEL. Me pregunto qué argumento hay contra una forma de desarrollo que modela futuros lanzamientos de RHEL usando una “distribución del futuro” como Fedora.
Para quienes no siguen de cerca el kernel de Linux, maddog es una figura legendaria.
Su perspectiva es muy interesante y se agradece mucho, especialmente por la forma en que plantea el tema a partir de la historia. Conocer la historia realmente ayuda a entender el contexto. El texto original es largo, pero vale la pena leerlo.
Soy unos 30 años más joven que Jon Hall, así que no pude conocer directamente sus logros salvo por relatos orales o escritos. Tampoco dejó un libro superventas ni software que yo pudiera usar (bueno, existe Linux for Dummies), así que seguía viendo que la gente lo llamaba leyenda, pero no entendía por qué.
Al final pregunté en la comunidad del kernel de Linux y me explicaron el alcance de sus contribuciones. En cierto sentido, fue mentor de Linus. Cuando se conocieron en 1994, Linus era un estudiante de 25 años y Jon era un gerente de marketing de DEC de 44. Suelo imaginar su conversación como una escena del tipo: “Mira, muchacho, escúchame bien. Esto es lo que tienes que hacer ahora”.
Pensando en eso, llama la atención una frase de la biografía de Jon Hall en Wikipedia. Dice que, durante su etapa en Digital, se interesó por primera vez en Linux y tuvo un papel importante para conseguir el equipo y los recursos que permitieron a Linus Torvalds hacer el primer port a la plataforma Alpha de Digital.
Una línea de su experiencia en LinkedIn muestra la misma perspectiva. Senior Marketing Manager, DEC, 1983-1998: en 1994 conoció a Linus Torvalds, reconoció el valor comercial de Linux y consiguió financiamiento para portar Linux al procesador Alpha de 64 bits, abriendo una línea de negocio de miles de millones de dólares en supercomputadoras de alto rendimiento basadas en Linux.
WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)
LI: https://www.linkedin.com/in/maddog/
Estoy de acuerdo con la frase de que “considero ‘polizones’ a quienes usan estos clones sin devolver nada a la comunidad de ninguna forma”, pero eso es algo que, en cierta medida, siempre se ha aceptado en el software libre. Dar algo gratis también significa que no todos van a devolver algo, o nada en absoluto
La diferencia con algo como Oracle Awesome Linux es que ellos venden como servicio el trabajo de valor agregado y el ecosistema de Red Hat. En la práctica es algo como: “si quieres soporte junto con nuestros otros productos, compra esto. Lo distribuimos tal como lo entrega Red Hat”
A mi parecer, el cambio de Red Hat apunta más a encarecer la creación de modelos de negocio propietarios tipo “Oracle Red Hat for X”. Quienes no podían costear RHEL para infraestructura académica de alto rendimiento siguen sin poder hacerlo y simplemente eligen otra cosa
Ponerse a graznar aquí sobre Fedora no tiene mucho sentido. Fedora es un proyecto con fines comerciales que satisface las necesidades de la empresa, y existirá hasta el día en que deje de existir
Red Hat no es Microsoft. Todo el mundo reconoce que hay muchas distribuciones, y que varias son excelentes. Podrías empezar una distribución hoy mismo. Pero “bueno, entonces uso Debian y ya” tampoco es una respuesta necesariamente válida. Debian es un gran proyecto y producto, pero si elegiste Red Hat por razones distintas a haber recibido un CD adjunto a una revista en 1998, es probable que Debian no sea ideal sin mucho trabajo. Al final es una cuestión de dinero entre el costo de que la gente haga el trabajo manualmente y el costo de encargárselo a Red Hat para que esas personas se dediquen a otras cosas
Me recuerda a cuando antes donábamos servidores y hosting al proyecto Fedora. Mientras configurábamos los servidores, le pregunté al responsable: “Supongo que querrán correr RHEL, ¿no?” Me dijo que “sí”, y cuando pregunté “¿tienen alguna clave de licencia que puedan usar?”, respondió: “podemos conseguir una, pero da flojera; mejor instala CentOS”
El instructor recomendó usar CentOS para practicar después de la clase (antes de que CentOS fuera adquirido). Más adelante, en uno de los proyectos terminamos usando Red Hat
Después de eso fueron CentOS y clones, y durante un tiempo parecía que cuando la gente decía RHEL en realidad se refería a CentOS
Con Qt pasa algo parecido. Aunque casi todo el software dependa de Qt, se quedan en Qt 4.x para no pagarle a Digia
Como empleado de Red Hat, agradezco la perspectiva de maddog. Ojalá otras personas pudieran ver con esa misma amplitud lo que las empresas hacen por el código abierto
Ver desde dentro cómo se crean las cosas cambia la perspectiva. Ojalá pudiera explicarle a la gente qué es lo que realmente vendemos. No vendemos software ni licencias de software
No estamos evadiendo licencias de código abierto ni cambiándolas. Intentamos que nuestra gente, que hace trabajo valioso para los clientes, pueda seguir trabajando. Mucho de lo que hacemos sube a los proyectos upstream y se comparte con competidores, la comunidad y los usuarios
Me gusta escuchar estas excelentes historias históricas de maddog. Cuando hizo una de esas visitas a Austin que menciona en el texto, yo trabajaba en LTC y tuve la oportunidad de conversar con él durante el almuerzo. Fue hace unos 20 años
Siempre es interesante escuchar qué considera una persona de 70 y tantos como “punto de inflexión” en su carrera. También me impresiona especialmente cómo sus puntos de inflexión se entrelazan con los míos
Yo estuve en medio de todo el alboroto de SCO, pero no sé si puedo hablar de algunas partes. Tal vez a estas alturas los abogados de la empresa ya se hayan jubilado o muerto lo suficiente como para poder decir lo que quiera. Si me dan ganas
Me alegra que maddog siga compartiendo sus historias. A medida que envejezco, cada vez me interesa menos compartir algo con cualquiera en internet. Las conversaciones que me importan hoy casi siempre ocurren en persona, así que no parece valer mucho la pena compartir o involucrarme con gente que no conozco personalmente
La empresa donde trabajo quería poner RHEL en el equipo servidor de alto rendimiento que fabricamos, pero nos cotizaron alrededor de 1 millón de dólares por licencia y no era negociable. Eso habría encarecido demasiado nuestro producto
Así que terminamos yéndonos a CentOS y luego migramos a Rocky, y contratamos a un equipo de unas 30 personas para gestionarlo (junto con otros proyectos). Respeto a Red Hat y su derecho a administrar el software de la forma que quieran, pero por nuestra experiencia de los últimos años, da la impresión de que están tratando de exprimir la marca al máximo. Me pregunto qué pasará en los próximos 5 años
En la parte donde dice “empecé a programar en 1969” y “en realidad, no solo era difícil vender software, sino que tampoco se le podía aplicar copyright”, me da curiosidad si en 1969 la situación legal realmente era así. ¿Era cierto que no se podía aplicar copyright al software?
Que el autor creyera eso en 1969 suena totalmente plausible, pero me pregunto si esa creencia era legalmente correcta.
Yo no ejercía derecho en esa época, pero según lo que tengo entendido de oídas, no estaba claro si el copyright se aplicaría al software ni, de aplicarse, cómo lo haría. Aun así, los actores astutos en general anticipaban que surgiría alguna forma de protección para el software escrito, más allá del secreto comercial.
Había todo tipo de preguntas, teorías y propuestas sobre si eso ocurriría bajo la ley de copyright o mediante un régimen específico para software. La respuesta de Estados Unidos quedó clara cuando “computer program” se incluyó en la definición del alcance de la ley de copyright. Incluso hoy, cuando se discuten los temas pendientes, se sigue citando a CONTU, la comisión que impulsó esa recomendación.
https://en.wikipedia.org/wiki/Software_copyright#History
Es raro que no quieras creerle a Jon Hall, pero sí a cualquier desconocido de redes sociales.
Conocí a maddog en un evento que coorganicé en París alrededor del año 2000. Le hicimos muchas preguntas y él nos dio respuestas muy perspicaces. A veces las envolvía en historias largas, como en el artículo enlazado.
Lo que más recuerdo es esto. “Pregunta: ¿Cómo podemos ayudar a que Linux gane participación de mercado en el escritorio más allá de los pocos puntos porcentuales que ya tiene?”
“Respuesta: No se puede. Busquen un mercado que hoy no use computadoras, creen un producto que resuelva las necesidades de ese mercado y hagan que ese producto use Linux. Por ejemplo, piensen en los smartphones”.
Me alegra ver que maddog sigue participando activamente en FOSS.
A fines de los 90, más o menos, en COMDEX en Chicago, una vez nos convenció a un amigo y a mí de atender su stand durante unas horas para que él pudiera recorrer la exposición. No recuerdo si era LPI, LI u otra organización relacionada con Linux. Creo que repartimos CDs de distribuciones y le explicamos a la gente sobre Linux.
Era una época loca en la que Linux estaba arrasando en el mundo de la PC, y Tux estaba por todas partes.