Portada
mis comunidades
otras secciones
![Dinero público, código fuente público: Muestra tu apoyo al software libre en Europa [ENG]](https://cdn.mnmstatic.net/cache/2b/79/media_thumb_2x-link-2849099.jpeg?1508905686)
#15:
#8 No, tu prefieres (poder) cobrar tu por las modificaciones que le hagas al software libre que sea y que se jodan los autores originales.
GPL es viral, sí. Si la administración B modifica el programa hecho/pagado por la administración A y liberado con licencia GPL, lo único que tiene que hacer es liberar el código modificado bajo la misma licencia. ¿De dónde sacas el lío de pagarse entre ellas?
Ahora, si viene la empresa C y quiere apropiarse de ese código, hacer sus modfiicaciones, y revenderlo a la administración D sin liberar el código, que se joda. Si libera el código no tiene problema, porque nada en la GPL le impide a la empresa C cobrarle a la administración D por las modificaciones. Lo que le impide es que no libere esas modificaciones y así quede con la administración D "captiva" (puesto que nadie más que C tendría la el código que D está usando). Esto es lo que permiten otras licencias como BSD.
Entiendo que tu prefieras código BSD/Apache, y tiene cierto sentido cuando son proyectos desarrollados enteramente por empresas privadas que "unen esfuerzos" para sacar una cosa común que les sirva a todas pero sin ceder su libertad de cerrar el código en el momento que les de la gana. Pero no, para código pagado por la gente tiene sentido que se respete la libertad de los usuarios (a tener siempre acceso al código, incluso de las versiones derivadas) en vez de la libertad de los desarrolladores a cerrar el código (son libertades enfrentadas, o tienes una o tienes la otra pero no puedes tener ambas a la vez).
GPL es viral, sí. Si la administración B modifica el programa hecho/pagado por la administración A y liberado con licencia GPL, lo único que tiene que hacer es liberar el código modificado bajo la misma licencia. ¿De dónde sacas el lío de pagarse entre ellas?
Ahora, si viene la empresa C y quiere apropiarse de ese código, hacer sus modfiicaciones, y revenderlo a la administración D sin liberar el código, que se joda. Si libera el código no tiene problema, porque nada en la GPL le impide a la empresa C cobrarle a la administración D por las modificaciones. Lo que le impide es que no libere esas modificaciones y así quede con la administración D "captiva" (puesto que nadie más que C tendría la el código que D está usando). Esto es lo que permiten otras licencias como BSD.
Entiendo que tu prefieras código BSD/Apache, y tiene cierto sentido cuando son proyectos desarrollados enteramente por empresas privadas que "unen esfuerzos" para sacar una cosa común que les sirva a todas pero sin ceder su libertad de cerrar el código en el momento que les de la gana. Pero no, para código pagado por la gente tiene sentido que se respete la libertad de los usuarios (a tener siempre acceso al código, incluso de las versiones derivadas) en vez de la libertad de los desarrolladores a cerrar el código (son libertades enfrentadas, o tienes una o tienes la otra pero no puedes tener ambas a la vez).
#63:
#56 Ok, pido disculpas por decir que ha mentido en vez de que está equivocado.
Es cierto que este tema me pone algo agresivo porque me fastidia mucho que se aleje a la gente de la GPL (una licencia pensada para beneficiar a la sociedad en su conjunto) en base a falsedades que se van repitiendo una y otra vez cada vez que sale el tema.
Es cierto que este tema me pone algo agresivo porque me fastidia mucho que se aleje a la gente de la GPL (una licencia pensada para beneficiar a la sociedad en su conjunto) en base a falsedades que se van repitiendo una y otra vez cada vez que sale el tema.
#61:
#53 Bueno ahora has salido por otros lares. Vale.
Está claro que GPL es una mala licencia para las empresas. En los últimos años muchísimas empresas se han puesto a desarrollar proyectos open source, sobretodo de software de infraestructura y demás (es decir, todo lo que no es único de su producto). Ahí estan facebook, google, netflix, amazon, etc. etc. sacando proyectos open source como churros. Tienen el dinero para hacerlo y los proyectos que sacan no se comen su nicho de mercado. Todo esto son muchísimos recursos invertidos, que terminan siempre en proyectos open source (que no free software) con licencias no-GPL porque lo que les interesa es compartir... hasta que decidan quedarse algo para ellos porque supone algun tipo de ventaja competitiva (pueden cerrar el código cuando quieran).
La licencia GPL lo que persigue es el beneficio de los usuarios finales: la gente. Para conseguirlo están las cláusulas de viralidad, etc. que están diseñadas justamente para evitar la posibilidad de cerrar el código. Como esto es una putada para las empresas, que no pueden quedarse con las ventajas competitivas que desarrollan (estan obligados a liberar), pues no apoyan este tipo de licencia. Hasta aquí todo razonable y comprensible no?
La misma gente de black duck ha publicado informes hablando del crecimiento del open source en las empresas [1]. Es decir, la cantidad de recursos dedicados a producir open source, con licencias no-GPL-like no ha parado de crecer en tiempos recientes. Por tanto, GPL está perdiendo "market share", no porque los desarrolladores que antes usaban GPL ahora prefieran otra cosa, sino porque hay muchísimos más proyectos no-GPL ahora, financiados por empresas. Las licencias ni son buenas ni malas ni mejores ni peores, son lo que son y sirven para lo que sirven.
Finalmente, estamos hipotetizando sobre qué licencia sería mejor si la administración adoptara la política de usar solo open source / software libre. Yo defiendo que GPL precisamente para blindar las administraciones (que aquí jugarían el papel de usuarios finales, no de desarrolladores) porque creo que la licencia nos defendería mejor a los contribuyentes. Si tu crees otra cosa arguméntalo, pero eso de decir "no porque el software GPL se acaba pagando" no es un argumento válido y ya te he explicado antes por qué.
[1] https://www.blackducksoftware.com/2016-future-of-open-source
Está claro que GPL es una mala licencia para las empresas. En los últimos años muchísimas empresas se han puesto a desarrollar proyectos open source, sobretodo de software de infraestructura y demás (es decir, todo lo que no es único de su producto). Ahí estan facebook, google, netflix, amazon, etc. etc. sacando proyectos open source como churros. Tienen el dinero para hacerlo y los proyectos que sacan no se comen su nicho de mercado. Todo esto son muchísimos recursos invertidos, que terminan siempre en proyectos open source (que no free software) con licencias no-GPL porque lo que les interesa es compartir... hasta que decidan quedarse algo para ellos porque supone algun tipo de ventaja competitiva (pueden cerrar el código cuando quieran).
La licencia GPL lo que persigue es el beneficio de los usuarios finales: la gente. Para conseguirlo están las cláusulas de viralidad, etc. que están diseñadas justamente para evitar la posibilidad de cerrar el código. Como esto es una putada para las empresas, que no pueden quedarse con las ventajas competitivas que desarrollan (estan obligados a liberar), pues no apoyan este tipo de licencia. Hasta aquí todo razonable y comprensible no?
La misma gente de black duck ha publicado informes hablando del crecimiento del open source en las empresas [1]. Es decir, la cantidad de recursos dedicados a producir open source, con licencias no-GPL-like no ha parado de crecer en tiempos recientes. Por tanto, GPL está perdiendo "market share", no porque los desarrolladores que antes usaban GPL ahora prefieran otra cosa, sino porque hay muchísimos más proyectos no-GPL ahora, financiados por empresas. Las licencias ni son buenas ni malas ni mejores ni peores, son lo que son y sirven para lo que sirven.
Finalmente, estamos hipotetizando sobre qué licencia sería mejor si la administración adoptara la política de usar solo open source / software libre. Yo defiendo que GPL precisamente para blindar las administraciones (que aquí jugarían el papel de usuarios finales, no de desarrolladores) porque creo que la licencia nos defendería mejor a los contribuyentes. Si tu crees otra cosa arguméntalo, pero eso de decir "no porque el software GPL se acaba pagando" no es un argumento válido y ya te he explicado antes por qué.
[1] https://www.blackducksoftware.com/2016-future-of-open-source
#33:
#12, #17 La seguridad por oscuridad (ocultación del codigo, documentación etc) no es seguridad. Un sistema seguro, lo es si esta bien diseñado, que puedas ver el codigo fuente no implica que tengas acceso al sistema, si este esta bien diseñado e implementado. De hecho cuanta mas gente vea el codigo, más probable es que se detecte y solucione un problema de seguridad.
Como ejemplo: El codigo fuente de la mayoria de algoritmos criptograficos es bien conocido y no implica que puedas romperlos, porque no son mas que un sistema matemático bien diseñado.
Como ejemplo: El codigo fuente de la mayoria de algoritmos criptograficos es bien conocido y no implica que puedas romperlos, porque no son mas que un sistema matemático bien diseñado.
#24:
#14 Tu primer párrafo es simple y llanamente mentira. La licencia GPL solo te obliga a entregar el código (si te lo piden) a quién distribuyas la aplicación. Por tanto, si tu aplicación solo se usa entre empresas del mismo grupo, lo único que tienes que hacer es darles el código a los de la otra empresa del grupo si te lo piden. No tienes por qué liberar nada de nada al público en general.
Tu segundo párrafo no tiene sentido. El autor original del código (licenciado en GPL para el público en general) puede venderte el mismo código bajo otra licencia porque el código es suyo. En el momento en que tu contribuyes una sola línea de código al proyecto, el autor original deja de ser el único autor de ese código y por tanto ya no puede relicenciarlo como lo de la gana. Para ello te tendría que hacer firmar un acuerdo en el que tu le regalas ese código a él en concreto. Es decir, podrías defender el no contribuir a proyectos GPL en los que el autor te obliga a firmar una concesión del código contribuido, pero defender el no contibuir a proyectos GPL en general por ese motivo es una tonteria.
Finalmente, si no te gusta que "el dueño [autor original] monetice cada línea de tu código", ¿por qué te da igual que cualquiera pueda monetizar cada línea de tu código, incluso sin haber contribuido él absolutamente nada a ese proyecto? Eso es lo que permiten las licencias como BSD...
Tu segundo párrafo no tiene sentido. El autor original del código (licenciado en GPL para el público en general) puede venderte el mismo código bajo otra licencia porque el código es suyo. En el momento en que tu contribuyes una sola línea de código al proyecto, el autor original deja de ser el único autor de ese código y por tanto ya no puede relicenciarlo como lo de la gana. Para ello te tendría que hacer firmar un acuerdo en el que tu le regalas ese código a él en concreto. Es decir, podrías defender el no contribuir a proyectos GPL en los que el autor te obliga a firmar una concesión del código contribuido, pero defender el no contibuir a proyectos GPL en general por ese motivo es una tonteria.
Finalmente, si no te gusta que "el dueño [autor original] monetice cada línea de tu código", ¿por qué te da igual que cualquiera pueda monetizar cada línea de tu código, incluso sin haber contribuido él absolutamente nada a ese proyecto? Eso es lo que permiten las licencias como BSD...
#14:
#9 #10 El problema es cuando trabajas en una gran empresa que es grupo de entidades, lo que es totalmente normal en multinacionales. Eso significa que si una entidad del grupo (la que hace software) hace un producto para otra del mismo grupo, legalmente hay una distribución (no tienen el mismo CIF aunque sean la misma empresa), con lo que te obliga a, cualquier software que hagas para tu propia compañía, pagar todo GPL. Un ejemplo, si tienes una empresa llamémosla Meneillo, y tiene entidad comercial en España y en Portugal (Meneillo Spain y Meneillo Portugal) y en España una entidad para hacer el software (Meneillo Tech), cualquier software que haga Meneillo Tech para Meneillo Spain o Meneillo Portugal, si incluye un sólo GPL, tienes dos opciones: hacer el software de tu propia empresa GPL, porque la licencia es vírica, o contactar con el autor y lograr una licencia comercial para la distribución.
Al principio de los tiempos el concepto de GPL estaba bien: al ser vírico, todo el que lo use tiene que ser GPL. Pero esto llevó a crear formas de monetización, una especie de chantaje: si haces software privado con GPL... páganos y te hacemos una licencia personalizada con casinos y furcias. Esto estaría bien si no chocase con otro concepto: en open source la gente contribuye. Y da gustico colaborar en proyectos MIT, Apache o incluso ICU. Pero colaborar en un GPL y saber que por detrás el dueño monetiza cada línea de tu código... no te hace desear contribuir precisamente.
Al principio de los tiempos el concepto de GPL estaba bien: al ser vírico, todo el que lo use tiene que ser GPL. Pero esto llevó a crear formas de monetización, una especie de chantaje: si haces software privado con GPL... páganos y te hacemos una licencia personalizada con casinos y furcias. Esto estaría bien si no chocase con otro concepto: en open source la gente contribuye. Y da gustico colaborar en proyectos MIT, Apache o incluso ICU. Pero colaborar en un GPL y saber que por detrás el dueño monetiza cada línea de tu código... no te hace desear contribuir precisamente.
#6:
#5 De que me dedico a esto y me conozco bien las licencias. Todo lo que programo open source es MIT salvo algún Apache 2.0, y contribuyo precisamente para devolver a la comunidad igual que tomo de ella. Cuando sin embargo hablamos de temas del trabajo, si tengo que usar un open source, tengo que fijarme bien en las licencias, y tengo ya los cojones pelaos de contactar con autores de GPL para pedir el precio e incluirlo en el presupuesto de lo que hago. Siempre que vayas a distribuir el software claro.
P.D. Si estás usando GPL en algo comercial y no has pagado, si te pillan en una auditoría ya te dirán ya...
P.D. Si estás usando GPL en algo comercial y no has pagado, si te pillan en una auditoría ya te dirán ya...
#16:
#8 Entiendo que el único problema que ves es que no se puede usar código GPL en tu proyecto cerrado y comercial, porque aunque sea comercial, si publicas el código fuente de nuevo con GPL no tienes ningún problema como te han dicho ya en #7.
Cual es exactamente el problema de esto? es precisamente una ventaja, para el avance en general claro, para la sociedad, no para el particular que se quiere aprovechar del conocimiento ajeno sin publicar el conocimiento propio derivado.
El software desarrollado con dinero público debería ser GPL, para que cualquiera pueda hacer uso de él, evolucionarlo o venderlo como quiera, pero el resultado obtenido debe ser público también, puesto que parte de una base pública y pagada por todos, y para que la sociedad se beneficie de algo en lo que ha contribuido con su dinero.
Y no sólo debe suceder con software, tambien con investigaciones científicadas apoyadas en parte en su totalidad por financiación pública, y con empresas privadas con subvenciones millonarias de I+D, si no quieren publicar el conocimiento obtenido gracias a nuestro dinero, que no usen nuestro dinero.
Cual es exactamente el problema de esto? es precisamente una ventaja, para el avance en general claro, para la sociedad, no para el particular que se quiere aprovechar del conocimiento ajeno sin publicar el conocimiento propio derivado.
El software desarrollado con dinero público debería ser GPL, para que cualquiera pueda hacer uso de él, evolucionarlo o venderlo como quiera, pero el resultado obtenido debe ser público también, puesto que parte de una base pública y pagada por todos, y para que la sociedad se beneficie de algo en lo que ha contribuido con su dinero.
Y no sólo debe suceder con software, tambien con investigaciones científicadas apoyadas en parte en su totalidad por financiación pública, y con empresas privadas con subvenciones millonarias de I+D, si no quieren publicar el conocimiento obtenido gracias a nuestro dinero, que no usen nuestro dinero.
#1:
En política intencionadamente, que esto va del dinero de todos.
Comentarios
#6 GPL no obliga a pagar a nadie por uso comercial. Obliga a liberar el código fuente, nada más. Puedes hacer todo el uso comercial que quieras, eso sí, el fuente de tu software también es GPL.
#7 Es una licencia vírica. De forma que cuando quieres usarla en un software privativo comercial y distribuirlo, o bien tu software te viraliza o bien contactas con el autor para pedir la licencia comercial, pagando. Te lo digo en serio, un ejemplo claro lo tienes en ghostscript, si vas a su web verás que es AGPL pero te ofrecen versión comercial, aquí fácil ya lo contemplas pagas y punto. Ahora vete a openalpr y en el propio github verás una issue pidiendo la licencia comercial, a mí me tocó contactar con el autor por mail y desenvolsar 5000 lereles que es lo que te dice amablemente el señor por correo. Yo solamente contribuyo con cosas con licencia no viral. Y procuro usar cosas sin licencia viral. A mí contribuir en el opensource de alguien para que éste cobre por mi trabajo y yo no... no me mola. Prefiero que no cobre nadie y lo puedan usar todos.
#7 #8 la autoría del código sigue estando en manos del creador del proyecto, entiendo, por lo que nada le impide relicenciar el código para que alguien lo use en su producto privado. ¿Van por ahí los tiros, no?
#9 #10 El problema es cuando trabajas en una gran empresa que es grupo de entidades, lo que es totalmente normal en multinacionales. Eso significa que si una entidad del grupo (la que hace software) hace un producto para otra del mismo grupo, legalmente hay una distribución (no tienen el mismo CIF aunque sean la misma empresa), con lo que te obliga a, cualquier software que hagas para tu propia compañía, pagar todo GPL. Un ejemplo, si tienes una empresa llamémosla Meneillo, y tiene entidad comercial en España y en Portugal (Meneillo Spain y Meneillo Portugal) y en España una entidad para hacer el software (Meneillo Tech), cualquier software que haga Meneillo Tech para Meneillo Spain o Meneillo Portugal, si incluye un sólo GPL, tienes dos opciones: hacer el software de tu propia empresa GPL, porque la licencia es vírica, o contactar con el autor y lograr una licencia comercial para la distribución.
Al principio de los tiempos el concepto de GPL estaba bien: al ser vírico, todo el que lo use tiene que ser GPL. Pero esto llevó a crear formas de monetización, una especie de chantaje: si haces software privado con GPL... páganos y te hacemos una licencia personalizada con casinos y furcias. Esto estaría bien si no chocase con otro concepto: en open source la gente contribuye. Y da gustico colaborar en proyectos MIT, Apache o incluso ICU. Pero colaborar en un GPL y saber que por detrás el dueño monetiza cada línea de tu código... no te hace desear contribuir precisamente.
#14 Tu primer párrafo es simple y llanamente mentira. La licencia GPL solo te obliga a entregar el código (si te lo piden) a quién distribuyas la aplicación. Por tanto, si tu aplicación solo se usa entre empresas del mismo grupo, lo único que tienes que hacer es darles el código a los de la otra empresa del grupo si te lo piden. No tienes por qué liberar nada de nada al público en general.
Tu segundo párrafo no tiene sentido. El autor original del código (licenciado en GPL para el público en general) puede venderte el mismo código bajo otra licencia porque el código es suyo. En el momento en que tu contribuyes una sola línea de código al proyecto, el autor original deja de ser el único autor de ese código y por tanto ya no puede relicenciarlo como lo de la gana. Para ello te tendría que hacer firmar un acuerdo en el que tu le regalas ese código a él en concreto. Es decir, podrías defender el no contribuir a proyectos GPL en los que el autor te obliga a firmar una concesión del código contribuido, pero defender el no contibuir a proyectos GPL en general por ese motivo es una tonteria.
Finalmente, si no te gusta que "el dueño [autor original] monetice cada línea de tu código", ¿por qué te da igual que cualquiera pueda monetizar cada línea de tu código, incluso sin haber contribuido él absolutamente nada a ese proyecto? Eso es lo que permiten las licencias como BSD...
#24 Pues te paso el teléfono de nuestra gente de legal y se lo explicas
En cuanto a lo de que el segundo párrafo no tiene sentido: OpenALPR tiene 54 contributors, y son de la comunidad, no todos son de la compañía. Es más, puedes ver los PRs en el repo. Te invito a contactar con Steve Lewis y preguntarle por la licencia comercial
#30 En el repositorio de OpenALPR hay un bonito archivo CONTRIBUTING.md, que te manda a firmar esto [1] para "poder contribuir". Fíjate en este bonito párrafo:
Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to OpenALPR and to recipients of software distributed by OpenALPR a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
Es decir, te hacen firmar que les regalas tu código, justo como he dicho yo que tenían que hacer si luego lo querían vender con otra licencia para su propio beneficio.
¿Que no quieres contribuir en este proyecto? Me parece genial. También puedes hacer un fork (es un solo click con github) y publicar tus mejoras en él. Si no firmas el acuerdo de mierda este, la gente de OpenALPR no podrá coger tus modificaciones y revenderlas (legalmente claro).
En cuanto a tu gente de legal... igual podrías pedirles que hagan su puto trabajo y se enteren de cómo funciona el tinglado, en vez de desinformar a la gente por internet porque los abogados de tu empresa son unos putos vagos.
Entiendo que te ha jodido sobremanera encontrarte con una gente que usa la licencia GPL sin seguir su espíritu (eso de obligar a los demás a que te regalen su código para que puedas venderlo relicenciado va claramente en contra del espíritu de la GPL), pero eso es culpa de la gente de este proyecto, no de la licencia.
[1] https://cla-assistant.io/openalpr/openalpr
#34 Pero como puedes comprobar, se puede. Es decir, que GPL de ser el precioso "y todo será abierto!" ha pasado a ser "¡Y así lo cobramos!".
Meh. Lo siento, me quedo con mi MIT.
#35 Quédate con lo que quieras, pero no mientas. Con el código MIT los autores pueden hacer exactamente lo mismo que lo que han hecho los de OpenALPR si quieren. La licencia no protege de nada en este caso, da igual qué licencia sea!
#4. GPL = (General Public License) = Software Libre.
'Licencia Pública General de GNU (GPL).'
https://www.gnu.org/licenses/licenses.es.html (CC #3 #5)
#42. Open Source no es Software Libre y el Software Libre no tiene porque ser gratis a condición siempre de mantenerse libre.
#43 Lo importante de la GPL en este caso, son los trabajos derivados
#42 No encuentro la mentira en ningún sitio. En la MIT es básicamente "haz lo que quieras". No hay ningún MIT que monetice con licencia. Con GPL empezó siendo algo guay y ahora es la base legal para cobrar por el open source.
#44 Has estado mintiendo por todo el hilo diciendo que la GPL implica varias cosas que son mentira y te he explicado por qué. Sigues mintiendo con eso de que "ahora es la base legal para cobrar por el open source", y te quedas tan ancho. ¿Cuánta gente ha pagado por usar linux en dispositivos comerciales? ¿Y por usar gcc? ¡Nadie!
Has tenido una mala experiencia con un grupo concreto (OpenALPR) y has decidido montar una cruzada contra una licencia que ese grupo NO USA (cuando te vende una versión comercial de ese software) en vez de contra el grupo. Lo siento pero llegados a este punto eres más troll que otra cosa.
#50 Eh, he mencionado OpenALPR porque es el último con el que he lidiado. Y no es mi cruzada... Te adjunto las gráficas según Black Duck, la del 2014 y la de este año, puedes visitar los datos numéricos aquí: https://www.blackducksoftware.com/top-open-source-licenses
En el 2014 GPL 2.0 era la licencia más utilizada, en 3 años hemos pasado a esta cifra:
1. MIT License 32%
2. GNU General Public License (GPL 2.0) 18%
3. Apache License 2.0 14%
4. GNU General Public License (GNU) 3.0 7%
5. BSD License 2.0 (3-clause, New or Revised) License 6%
Si es mi cruzada solamente, lo debo estar haciendo de puta madre para que miles de proyectos open source me den la razón.
#53 Bueno ahora has salido por otros lares. Vale.
Está claro que GPL es una mala licencia para las empresas. En los últimos años muchísimas empresas se han puesto a desarrollar proyectos open source, sobretodo de software de infraestructura y demás (es decir, todo lo que no es único de su producto). Ahí estan facebook, google, netflix, amazon, etc. etc. sacando proyectos open source como churros. Tienen el dinero para hacerlo y los proyectos que sacan no se comen su nicho de mercado. Todo esto son muchísimos recursos invertidos, que terminan siempre en proyectos open source (que no free software) con licencias no-GPL porque lo que les interesa es compartir... hasta que decidan quedarse algo para ellos porque supone algun tipo de ventaja competitiva (pueden cerrar el código cuando quieran).
La licencia GPL lo que persigue es el beneficio de los usuarios finales: la gente. Para conseguirlo están las cláusulas de viralidad, etc. que están diseñadas justamente para evitar la posibilidad de cerrar el código. Como esto es una putada para las empresas, que no pueden quedarse con las ventajas competitivas que desarrollan (estan obligados a liberar), pues no apoyan este tipo de licencia. Hasta aquí todo razonable y comprensible no?
La misma gente de black duck ha publicado informes hablando del crecimiento del open source en las empresas [1]. Es decir, la cantidad de recursos dedicados a producir open source, con licencias no-GPL-like no ha parado de crecer en tiempos recientes. Por tanto, GPL está perdiendo "market share", no porque los desarrolladores que antes usaban GPL ahora prefieran otra cosa, sino porque hay muchísimos más proyectos no-GPL ahora, financiados por empresas. Las licencias ni son buenas ni malas ni mejores ni peores, son lo que son y sirven para lo que sirven.
Finalmente, estamos hipotetizando sobre qué licencia sería mejor si la administración adoptara la política de usar solo open source / software libre. Yo defiendo que GPL precisamente para blindar las administraciones (que aquí jugarían el papel de usuarios finales, no de desarrolladores) porque creo que la licencia nos defendería mejor a los contribuyentes. Si tu crees otra cosa arguméntalo, pero eso de decir "no porque el software GPL se acaba pagando" no es un argumento válido y ya te he explicado antes por qué.
[1] https://www.blackducksoftware.com/2016-future-of-open-source
#61 Bueno, en este caso te doy la razón. Pero ten en cuenta que no todas las empresas son públicas, y que las privadas deben devolver a la comunidad open source, lo que la comunidad les da. Y deben invertir, ahí tienes el ejemplo de las fundaciones y cómo cada vez más invierten, no solamente en hacer Open Source, sino en el proceso de evangelización, con sus ingenieros promoviendo la realización de open source, o dando charlas y cursos.
Pero precisamente, hay más empresas privadas que entidades públicas, y si quieres buscar su colaboración en módulos y librerías, no te queda otra que hacerlos MIT o similares.
Pero es que, es lo que hay. De todas maneras, y aunque he firmado, en España el problema no lo veo tanto en la licencia, sino en lo que explico en #22
#53 Una estadística de uso? en serio? para demostrar qué?
#50 ¿De verdad que la gente no puede estar equivocada? ¿Forzosamente está mintiendo?
De verdad, no sé si es el hecho de ser anónimo, de que es Menéame o qué, pero algunas personas son MUY agresivas. Please, un poco de relax, que yo puedo estar equivocado sin estar mintiendo a sabiendas, y las cosas se pueden discutir sin tener que ofender al interlocutor, en serio…
Incluso, muchas cosas son interpretables, o tienen matices, o aspectos que puedes no haber tenido en cuenta, pero se explica, se discute con calma, con amabilidad, con algo de paciencia, y puede que hasta hagas un amigo, y uno que tenga, además, afinidad con lo que haces, en vez de crearte un enemigo de entrada, de buenas a primeras, porque le has llamado embustero en algo que puede ser un matiz o una equivocación.
En serio…
#56 Ok, pido disculpas por decir que ha mentido en vez de que está equivocado.
Es cierto que este tema me pone algo agresivo porque me fastidia mucho que se aleje a la gente de la GPL (una licencia pensada para beneficiar a la sociedad en su conjunto) en base a falsedades que se van repitiendo una y otra vez cada vez que sale el tema.
#63 Y para eso estás tú y gente como tú, que sabe del tema, para puntualizar cuestiones y hacer que todos, sobre todo los que somos ignorantes del tema y sólo lo conocemos por encima, tengamos más ideas del mismo De todos modos, no estaría de más que le hicieras llegar las disculpas al interesado, mencionando alguno de sus comentarios, para que las vea.
He de decir que, como desconocedor del tema, que me ha sorprendido que un autor de código GPL pueda añadir una clausula a la oficial de GPL en la que diga que el código añadido por un contribuidor externo pasa a ser de su propiedad, ni que sea firmado por el colaborador, como bien indica #8 o remarcas tú en #34. ¿Es legal que una licencia pueda ser GPL, que, básicamente, hace que la fuente sea distribuible de manera gratuita ("Free as a free beer"), que la fuente de cualquier añadido o programa derivado sea, obligatoriamente, GPL, de libre distribución si usa un código GPL, y al mismo tiempo, incluya una clausula en la que regalas tu código al autor?
Puedo entender que haya gente que quiera usar cosas de GPL (librerías, etc.) sin tener que convertir su código en "libre distribución" porque quiere sacarle rentabilidad comercial, y entonces que pida el software con otra licencia al autor, pero no entiendo que un código pueda ser GPL y, al mismo tiempo, "robe" (de manera "legal", se entiende) el código a quien contribuya.
#72 #22 Te extiendo la disculpa Fluffy.
En cuanto a lo de que el autor del código pueda modificar la GPL para añadir una cláusula sobre las contribuciones: no, la cosa no funciona así (claro que no se puede hacer eso bajo el paraguas de la GPL, tal como pensabas).
El propietario del código (porque lo ha hecho o porque se lo han cedido) puede hacer lo que quiera con él. Puede liberarlo con licencia GPL, pero eso no significa que renuncie a su autoría. Por tanto, tras haberlo liberado como GPL, puede seguir vendiéndolo con la licencia que quiera (incluso una licencia privativa).
Si tu contribuyes a su projecto (por ejemplo, haces un fork del OpenALPR este y cuelgas tus cambios en github) ahora esa versión sigue siendo GPL sin que tú digas ni firmes nada. El autor original por lo tanto no puede coger esta versión y venderla con una licencia privativa, porque estaría vendiendo tu código que solo puede usar bajo las condiciones de la GPL (entre las que no está la posibilidad de re-licenciar tu código como le salga de los cojones).
El truco que usan estos autores (y que me parece fatal) es el siguiente: tú si quieres haz tu fork y publícalo. Yo (el autor) en ese caso simplemente ignoraré tus cambios, es decir, no los meteré en mi versión. Como tu eres un matado al que no conoce nadie y yo soy el autor original, la gente viene a buscar mi versión, no la tuya, así que tus cambios quedarán perdidos en el olvido githubero. Ahora bien, si quieres que integre tus cambios, tienes que literamente regalarme tu código. Entonces lo integraré pero ahora yo soy el propietario de todo el código, incluido tu trabajo, y por tanto puedo seguir vendiéndolo (vendiendo una versión con licencia privativa) a quién me de la gana y por el precio que quiera.
Obviamente esta treta va en contra del espíritu de la licencia. No obstante, no es que la GPL permita eso, sino que los autores usan una vía completamente separada de la GPL para vender versiones comerciales. Lo mismo que hacen con GPL lo podrían hacer con cualquier otra licencia, ya sea una licencia free software, open source, o lo que sea!
#76 Y esa treta no siempre funciona... vease OpenOffice y LibreOffice....
#50 En cuanto a lo de troll... ¿a nadie más le resulta curioso que el autor sea ccguy y el que le defiende sea aiguy y que la cuenta huela a nuevo que tira para atrás? Eso sí parece troll a saco
Por otro lado, a cualquiera de por aquí del que me fíe, sabe quién soy, y tiene acceso a mis repos y sabe lo que hago. Si tú me enseñas tus maravillosos repos y tus contribuciones yo te enseño las mías
#58 Y ahora hombre de paja.
No tengo ni idea de quién es el autor. Por mi parte, si te fijas verás que la cuenta la creé (tras mucho tiempo lurkeando) para responder en un hilo que alguien mandó aquí de un artículo mío [1] que mandé a hacker news [2]. Como eres informático, no te costará saber cuál suele ser mi user, que no pude utilizar aquí porque ya estaba pillado. Luego lo metes en github y verás mis respositorios y a qué he contribuido o dejado de contribuir.
[1] http://la3.org/~kilburn/blog/catalan-government-bypass-ipfs/
[2] https://news.ycombinator.com/item?id=15367531
#67 Pues te he agregado de amigui, agrégame y te mando cositas por privi para que veas que no soy un troll. P.D. Hablé de tu publicación por nótame: @2898666
#58 Joder, te. piden disculpas aún teniendo razón, y sales con lo de troll.....
#3 #44 MIT es una licencia compatible con GPL.
#44 MIT permite monetizar la licencia exactamente igual que la GpL
#44 No hombre, no.....
#42 Es más si el software original del que parten es GPL y no tienen su propiedad, esa clausula NO es. válida.
#35 Esa clausula se la pueden añadir a cualquier licencia. Ese software simplemente NO es GPL.
#35 GPL sigue siendo el precioso "y todo será abierto!".
El problema es que tú (o tu empresa) no quieres que todo sea abierto y por lo tanto no puedes usar la GPL.
#30 Yo que tu cambiaba de asesores legales. La licencia lo pone todo mucho más que claro.
OJO. Por supuesto que te pueden pedir dinero por software GPL.
#24
Es el "Copyright holder" el que puede relicenciarlo. Si hay un contribuyente que no se registra como Copyright holder está simplemente cediendole los derechos al que aparece como poseedor legal de los derechos.
Pasó por ejemplo con Nexuiz y fue el motivo de que muchos empezasen paralelamente el projecto Xonotic. Una empresa contactó a las personas que aparecian como poseedores de los derechos y les facilitaron que se relicenciase, sin tener que consultar a todos y cada uno de los contribuidores que cambiaron cada linea. Se cabrearon y hicieron un fork, pero el cambio de licencia legal sí que fue.
Por eso es que los de la FSF siempre recomiendan que se ponga a la FSF como copyright holder, porque así ninguna persona física puede cambiar la licencia, y desde la FSF se comprometen a mantenerla.
#14 Por lo que entendí en su momento, si coges código GPL, y mejoras y vendes tu aplicación mejorada de ese código GPL, estás obligado a que tu código sea GPL nada más. Sólo tienes que pagar si no quieres publicar tu nuevo código o mejora. Este detalle creo que no afectaría entre administraciones, una genera A, otra modifica teniendo A', nadie copia a nadie, sólo que le código de A y A' debe o debiera ser público con GPL.
Otra cosa es que quieras vender tu producto sin publicar las mejoras que ahí si que veo muy justificado que el creador original se lleve su parte.
Otra cosa es que se use una librería y aquí ya entra LGPL etc..
#31 No, "sólo tienes que pagar"... ¿ y que pasa si cuando contactas con el autor original te dice que no, que no lo licencia de otra forma que no sea GPL ?
#39 Que tienes tres opciones:
1) Basas tu producto en ese código y liberas tu propio código (o lo modularizas y liberas los módulos que usen ese proyecto).
2) Bastas tu producto en otro proyecto que tenga una licencia más conveniente para tí.
3) Picas todo tu código tú mismo.
#52 Obviously. Pero ojo con eso de modularizar, que no sería la primera vez que alguien se pilla los dedos con eso. En pincipio modularizar se puede siempre o casi siempre, pero luego también depende de si es GPL normal o LGPL y como se hace la derivación de ese "trozo" de código.
Pero claro, en el caso 3) es vuelta al punto de partida, pa eso es como si no tienes el código. Luego esta también el hecho, digamos "troll"/"trampa" del código GPL. Que si estas en el caso 3), como al final es muy probable que picar el código para algo de lugar a un algoritmo similar al de ese código GPL ( lo hayas visto o no, pero si lo has visto es más fácil que pase ), puedes tener problemas con acusaciones de que has "copiado". Sí, se que es algo pillado con pinzas, pero el peligro está ahí. Yo, desdeluego, desde el punto de vista altruista, prefiero BSD, MIT u otras, que son libres de verdad, sin trampas.
#66 Hombre, la parte troll/tampa esa me parece un poco forzada. ¿Cuántos casos conoces en que haya sucedido eso? Yo no conozco ninguno, y dudo que exista algún caso así que haya llegado a alguna parte (es decir, dónde un juez haya dictaminado que el código era copiado y por lo tanto condenado al "copiador").
Por otro lado, eso de libre de verdad, sin trampas, es algo tendencioso. Stallman es un personaje que puede resultar hasta desagradable, pero eso lo explica(ba?) muy bien: hay dos libertades que están fundamentalmente enfrentadas:
1) La libertad del usuario a disponer del código de los programas que usa (ya sean comprados o regalados)
2) La libertad del desarrollador de crear versiones derivadas privativas
No puedes tener ambas a la vez. Si tienes la 2, eso significa que el usuario al que vendas/regales tu versión derivada privada no tendrá acceso al código, y por tanto no tendrá la libertad 1. Si eliges la 1 no puedes tener la 2 por el razonamiento contrario.
GPL elige la 1, mientras que BSD/MIT/Similares eligen la 2. A partir de aquí ya que cada uno haga su elección.
#74 heh, donde el juez haya dictaminado no, pero ya te metes en litigios, perdida de tiempo y pasta. Esos costes "ocultos" del tema.
Mi elección, ya digo, sería la 2.
#75 Entiendo perfectamente que elijas la 2 si piensas en que eres un desarrollador (ya sea freelance o empresa).
Lo que pasa es que aquí hablamos de la administración, y por tanto discrepo contigo (para este caso): yo creo que deberíamos elegir la 1) cuando pensamos en que esto serían proyectos pagados con la pasta del contribuyente
#77 Como he dicho antes, si esto se paga con dinero de todos, la licencia con la que abrir ese código tendríamos que decidirlo todos. Aunque viendo como se aplica la decisión de uso del dinero público hoy día, me da que...
#77 Y si todo el mundo elige 2.... adios software libre. Teoría xe Juegos
#160 Hombre, yo culparía al Estado si licencia su software bajo BSD y permite que luego las empresas extorsionen para que haya que pagar con dinero público por funcionalidades extra que el Estado no pueda usar sin pagarles o que se las tengan que ingeniar para usar una implementación alternativa que a lo mejor no sea tan correcta/eficiente.
Eso de que la BSD sea 100% libre es tendencioso, como explicaba #74, sólo es más libre para quien tenga pretensión de limitar la libertad del software derivado. Lo cual es un poco contradictorio. Libertad de eliminar libertad no es libertad. Con ese argumento esclavitud por contrato debería ser legal.
#93 Con BSD si una derivada implementa algo y lo publica con distinta licencia tirar al código original no sirve de nada porque no puedes usar el mismo algoritmo que la otra versión licenciada, porque sería considerado plagio. La BSD tiene trampa/troll también.
Lo mismo que comentabas en #66 vaya, excepto que aquí el que se Jode es el que quiera código abierto de verdad 100%, mientras que con la GPL el que se Jode es el que quiere aprovecharse del trabajo de otros para beneficio privado y no público
#39 Que te jodes. Usa otro software de base
#97 Pues eso.
#39 Pues que no lo puedes distribuir. A ver si vamos a tener que especificar cada uno de todos los posibles casos, jejeje.
#31 Ni pagando podrás cambiar la licencia si el propietario original o alguno de. los que contribuyeron no acceden de modo explícito
#31 Si no publicas tu código ni tu aplicación, no solo no tienes que pagar nada, es que la licencia resulta irrelevante.
#9 Eso si. El propietario de kos derechos puede relicenciar lo que quiera. Pero lo publicado como GPL sigue suendo GPL
#88 no entiendo a qué te refieres, aquí la publicación poco importa.
Tú usas código que está bajo los derechos de un autor, por lo que ese autor puede decidir otorgarte una licencia comercial, que no te obliga a distribuir el código, al no ser GPL (a esto me refería con relicenciar)
La gente que use ese mismo código, pero sin contactar con el autor, estará sujeta a la licencia de publicación del mismo, que en su caso sería la GPL, obligándoles a su vez a publicar el código donde lo utilicen (la viralidad)
Hay proyectos de software libre donde te piden explícitamente que renuncies a todos los derechos sobre el código (creo que a la autoría no se puede renunciar), precisamente por eso, para luego poder relicenciarse ellos mismos (normalmente una empresa) comercialmente el código, permitiendo incluirle mejoras que no se publicarán si ellos no quieren.
#8 Técnicamente, eso que comentas se puede resolver de muchas formas. No hace falta liberar todo el código o pagar.
Por ejemplo puedes trabajar por módulos y liberar los que estén usando bibliotecas GPL.
Hay ejemplos de apps comerciales que han liberado su motor o ciertos componentes y el resto del sistema sigue siendo propietario.
Creo que es un caso bastante beneficioso porque anima a que ciertas partes del código útil de un app no quede en el olvido.
También se puede utilizar códgio GPL en el sistema de tu empresa de forma privada sin incurrir en ningún delito siempre y cuando no sea un programa distribuido.
#8 Gracias por la info
Es un tema que mucha gente desconoce en profundidad, las licencias del Softare Libre cuando se incluye código o partes en "softare comercial", casos etc
#8 No, tu prefieres (poder) cobrar tu por las modificaciones que le hagas al software libre que sea y que se jodan los autores originales.
GPL es viral, sí. Si la administración B modifica el programa hecho/pagado por la administración A y liberado con licencia GPL, lo único que tiene que hacer es liberar el código modificado bajo la misma licencia. ¿De dónde sacas el lío de pagarse entre ellas?
Ahora, si viene la empresa C y quiere apropiarse de ese código, hacer sus modfiicaciones, y revenderlo a la administración D sin liberar el código, que se joda. Si libera el código no tiene problema, porque nada en la GPL le impide a la empresa C cobrarle a la administración D por las modificaciones. Lo que le impide es que no libere esas modificaciones y así quede con la administración D "captiva" (puesto que nadie más que C tendría la el código que D está usando). Esto es lo que permiten otras licencias como BSD.
Entiendo que tu prefieras código BSD/Apache, y tiene cierto sentido cuando son proyectos desarrollados enteramente por empresas privadas que "unen esfuerzos" para sacar una cosa común que les sirva a todas pero sin ceder su libertad de cerrar el código en el momento que les de la gana. Pero no, para código pagado por la gente tiene sentido que se respete la libertad de los usuarios (a tener siempre acceso al código, incluso de las versiones derivadas) en vez de la libertad de los desarrolladores a cerrar el código (son libertades enfrentadas, o tienes una o tienes la otra pero no puedes tener ambas a la vez).
#8 #15
(*15)
Ahí está una muy buena cuestión, gracias por el aporte
#8 Entiendo que el único problema que ves es que no se puede usar código GPL en tu proyecto cerrado y comercial, porque aunque sea comercial, si publicas el código fuente de nuevo con GPL no tienes ningún problema como te han dicho ya en #7.
Cual es exactamente el problema de esto? es precisamente una ventaja, para el avance en general claro, para la sociedad, no para el particular que se quiere aprovechar del conocimiento ajeno sin publicar el conocimiento propio derivado.
El software desarrollado con dinero público debería ser GPL, para que cualquiera pueda hacer uso de él, evolucionarlo o venderlo como quiera, pero el resultado obtenido debe ser público también, puesto que parte de una base pública y pagada por todos, y para que la sociedad se beneficie de algo en lo que ha contribuido con su dinero.
Y no sólo debe suceder con software, tambien con investigaciones científicadas apoyadas en parte en su totalidad por financiación pública, y con empresas privadas con subvenciones millonarias de I+D, si no quieren publicar el conocimiento obtenido gracias a nuestro dinero, que no usen nuestro dinero.
#16 Lo siento, pero no soy igual de optimista. Hace ya años, en el 2007, me tocó hacer el software judicial para dos comunidades autónomas. Si algo aprendí, es que si se hubieran puesto de acuerdo entre ellas, se habrían ahorrado muchos euros de los ciudadanos. Y si se hubieran puesto de acuerdo las 51 comunidades autónomas, el ahorro habría sido mayor.
No por ser GPL significa que entre ellas se vayan a ahorrar dinero, igual que no por ser privativo se vaya a ahorrar. Esto es un tema de presupuestos: cada comunidad tiene autonomía para ciertas cosas y presupuesto para llevarlas a cabo, y no colaboran entre ellas. Así que da igual la licencia que pongas, no sería más que uno de los requisitos del contrato para el proveedor: "Mira proveedor X, que te doy el dinero de siempre para hacer lo de siempre, pero hay un requisito de que lo hagas GPL... que para ti mejor así el repo te sale gratis en github". Y encima por ser GPL, a la hora de distribuir o usar, la administración se llevaría un pellizco, y ningún proyecto open source podría usarlo sin viralizarse.
Lo mismo para sanidad: ¿alguien ve normal que cada comunidad tenga su software? ¡51 proyectos de softwares diferentes para hacer lo mismo! Y encima lo que se consigue es que el expediente sanitario de un español, no esté disponible en cada comunidad.
Así que, menos forzar GPL, y más forzar a las comunidades a colaborar en lugar de que cada una se lleve su "mordida". Y si hacen algo, pues que sea MIT, y así los demás podemos hacer cosas.
#22
Totalmente de acuerdo y así con todo...
Sólo un hecho, que da que pensar, porque no tenemos la infraestructura universitaria de repositorios de tesis, papers, doctorados y publicaciones de revistas científicas hacia un espejo (mirror ) único que facilite el intercambio, incluso via redes P2P (respetando autoría, con hash (identificador), y checksum (suma de verificación)
Y diría más, hay que hacerlo, para empezar para evitar "enlaces muertos" (link rot, error 404), "censura" y para potenciar sinergia de investigación.
Eso me parece totalmente relevante, algo con lo que habría que ponerse ya
Insertar aquí, porque para "planes de acción" concretos como este, tenemos que esperar 4 años (si con suerte sale el partido que lo "lleva en el programa" o lo quiere hacer
PD: Y luego algunos dicen "el Sistema de Partidos funciona", pues NO, yo digo que NO nos funciona, y no es útil, es lento, es una carga y un estorbo y no admite pluralidad ni agilidad en gestión de nada (o se rebate o nada)
#22 Estoy totalmente de acuerdo en que el problema de base es la falta de colaboracón.
De todos modos, me parece que sería un buen comienzo el forzar como mínimo código abierto para todo lo que ataña a las administraciones. ¿Por qué? Bien, porque colaborar cuando el beneficio es real y tangible (nos ahorramos hacer todo esto porque ya está hecho, aquí, míralo!) que cuando primero hay que ponerse de acuerdo y luego ya se verá el resultado....
En cuanto a GPL/MIT pues no estoy del todo de acuerdo.
Entiendo que en algunas cosas estaría bien el uso de licencias open source. Por ejemplo, en librerías para comunicarse con servicios ofrecidos por las administraciones, que podrían usar tanto otras administraciones como programas empresariales que no quieren ser "viralizados".
No obstante, para la mayoría de sistemas (los que no sean de "interface") creo que sería mejor una licencia de software libre, que protegería a las administraciones ante cualquier posibilidad de cierre del código por parte de futuros desarrolladores.
#70 Para eso está la LGPL
#22 No mezcles cosas.....
Aunque sea GPL, los demás podeis "hacer cosas". Lo que no podeis hacer es cerrar el código, cosa que perjudica a todos los ciudadanos.
#16
completamente de acuerdo
"Y no sólo debe suceder con software, tambien con investigaciones científicadas apoyadas en parte en su totalidad por financiación pública => amén
"empresas privadas con subvenciones millonarias de I+D, si no quieren publicar el conocimiento obtenido gracias a nuestro dinero, que no usen nuestro dinero." ... ">
=> Cualquier desarrollo con dinero público tendría que obligar a utilizar partes de código libre o la totalidad (ya hay desarrollos avanzados en muchos temas, sin tener que reinventar la rueda) además favorecería la integración sencilla, el desarrollo colaborativo y la "Transparencia" tan importante en el "Sector Publico".
gracias por tu comentario, así todos aprendemos.
#8 La licencia MIT permite la inclusión de tu código en software privativo (alguien gana dinero con tu trabajo altruista y relicencia tu código, sin ser tú), ese es uno de los puntos por los que la GPL es fuerte y vírica. En el caso de proyectos con mezcla de software privativo y libre, lo ideal es que el software libre sea una librería con licencia LGPL.
#8 Cierto, si tienes software privativo no puedes meter código GPL. Normal.
Pero, puedes tener software comercial con GPL. Si tú quieres cerrar el código, pues es normal que no puedas usar la GPL.
Y a mi me parece la licencia ideal para el código fuente de las entidades públicas.
Y si quieres usarlo de manera comercial en un software privativo, pues me parece perfecto que te toque pagar para una licencia comercial, si quieres cerrarlo.
¿Qué es eso de regalar el código para que luego lo puedas cerrar? A mi me parece la mejor licencia, Copyleft, puro.
#21 El código que era libre se sigue manteniendo libre, si tú haces modificaciones en él, tú eliges si haces esas modificaciones públicas o no.
#54 Si usas código libre y lo modificas, también lo debes liberar. Me parece lo más lógico del mundo.
Si a ti te va el rollo BSD del cual te puedes aprovechar, bien. Aunque los sistemas operativos BSD me gustan, sus licencias no son tan libres como parecen. Ya que permiten aprovecharte del código comunitario y cerrarlo.
La GPL mantiene esa libertad.
Sí soy de la mentalidad de la Free Software Foundation no del consorcio Open Source.
#55 Creo que te entiendo pero, el código que siempre ha sido libre, sigue siendo libre. Luego, compañías como Red Hat hacen sus propias optimizaciones y modificaciones, y tienen su versión con la que obtienen grandes beneficios económicos. Pero a Red Hat le interesa que el kernel de Linux se mejore y se optimice, y por este motivo colaborará económicamente para que esto suceda.
Luego están todos los voluntarios que aportan trabajo voluntario a la optimización del kernel (e del GNU), algo que se puede hacer gracias a que es software libre.
#54 No con la GPL. "Modificaciones" quiere decir que te aprivechas del trabajo de otros.
#8 Tienes un cacao guapo.
Es una. licencia vírica porque se propaga de modo automático a todo el software derivado
#8 Claro eso es verdad, es una licencia vírica que obliga a liberar el código, mientras que MIT/Apache son licencias susceptibles de ser cancerosas que permiten que el código se use para propositos que pueden ser contraproducentes para el autor original.
Estaría bonito que alguien coja el código de la administración de licencia MIT, implemente algo que el gobierno quiere tener, pero que libere el código bajo una licencia privativa que no permita a la administración usar ese código sin pagar a la persona que lo desarrolló.
La administración para no tener que pagar tendría que ingeniarselas para implementar lo mismo de forma distinta, aunque a lo mejor sea menos eficiente...si es que es posible/viable.
#7 Obliga a liberar el codigo fuente... segun como lo uses, puede que pa poder usar 1000 líneas, si no lo haces bien ( y ojo que no siempre es fácil ), puede que tengas que liberar 100000 lineas. Ahí está el diablo.
#38 No veo el. problema: No las uses.
#7 El fuente y el ejecutable.
No solo libre. Debería ser GPL
#3 ¿Por? Es decir, ¿por qué quieres que se cobre su uso comercial? Eso en España sería caos, piensa que lo elaboraría una administración y las demás tendrían que pagar por su uso, así que se facturarían entre ellas por algo que ya hemos pagado los ciudadanos.
#4 ¿de dónde sacas que GPL dice eso?
#5 De que me dedico a esto y me conozco bien las licencias. Todo lo que programo open source es MIT salvo algún Apache 2.0, y contribuyo precisamente para devolver a la comunidad igual que tomo de ella. Cuando sin embargo hablamos de temas del trabajo, si tengo que usar un open source, tengo que fijarme bien en las licencias, y tengo ya los cojones pelaos de contactar con autores de GPL para pedir el precio e incluirlo en el presupuesto de lo que hago. Siempre que vayas a distribuir el software claro.
P.D. Si estás usando GPL en algo comercial y no has pagado, si te pillan en una auditoría ya te dirán ya...
#3 Si es con el dinero de todos, tendremos derecho todos a decidir cual es su licencia, ¿ no ? Yo por ejemplo prefiero las licencias no víricas, que son 100% libres, no un 99% libre con un 1% que hace que su uso no solo no sea libre si no que para mantener ese 99% en próximas generaciones te mete el diablo entre lineas (
#37 Pues yo prefiero las viricas estilo GPL porque garantizan mejor la libertad del siftware. Entre otras cosas garantiza la libertad de las siguientes versiones, cosa que no hace BSD por ejemplo
#84 Con BSD hay trazabilidad para saber de donde viene y puedes tirar al padre siempre que quieras.
#93 Pero no quiero el. padre. La GPL me garantiza el poder usar los descendientes
#6 Para conocer bien las licencias estás bastante equivocado. Una cosa es que tu empresa no quiera redistribuir su código como GPL y otra es que para usar GPL en algo comercial tengas que pagar. Estás mezclando conceptos. Sin ir más lejos hay cientos de aparatos que usan Linux (proyecto GPL por excelencia) y adivina: no los dan gratis!
#6 Pues no debes conocerlas tan bien... por ejemplo el Kernel de Linux ES GPL.
De lo que hablas es de software con licencia dual. Con GPL simplemente no puedes hacer software privativo. Pagues lo que pagues.
Leete la licencia.
#4 #6 Si conoces las licencias deberías saber que precisamente es la GPL la que pone restricciones (en el sentido de que exige que el código sea siempre abierto y no lo cierren).
MIT y Apache 2.0 permiten todo tipo de venta descarada y egoísta de cualquiera permitiendo que el código se oculte en cualquier versión modificada que otra empresa haga del software producido con dinero público. Tu software liberado bajo MIT puede ser usando por otro sin darte ningún tipo de retribución y además puede competir contra el tuyo injustamente ya que todas las funcionalidades tuyas las puede tener él pero tú no puedes incluir las suyas si su código es cerrado o bajo otra licencia.
#3 Por mí como si usan la licencia http://www.wtfpl.net/about/
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
Version 2, December 2004
Copyright (C) 2004 Sam Hocevar
Everyone is permitted to copy and distribute verbatim or modified
copies of this license document, and changing it is allowed as long
as the name is changed.
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. You just DO WHAT THE FUCK YOU WANT TO.
#41 Pues mira, yo prefiero que sean GPL.
#3 O compatible
Firmado
#2 El enlace para firmar es aquí:
https://publiccode.eu/openletter/
En política intencionadamente, que esto va del dinero de todos.
¿Cuantos paises o empresas entonces invertirian recursos en desarrollar ellos si pueden esperar que otros gobiernos hagan los proyectos que necesitan y luego modificarlos? ¿quien seria el pais que iniciaria un desarrollo en vez de esperar a algo y hacerle un fork? En todo casl tendria sentido si el fondo para IT fuera global
#11 eso decían al principio las empresas. Luego ves quién está contribuyendo a Linux y la mayoría de personas están a sueldo de sus respectivas empresas.
#27.... y no pueden cerrar su kernel por 'culpa' de la GPL...
#11 Y mientras la administración está "esperando" a que los otros hagan el trabajo ¿qué pasa, la administración simplemente se queda sin funcionar? Las administraciones deben proveer unos servicios, y si no existe un software que cumpla con sus requisitos tendrían que desarrollarlo/contratarlo igual que hacen ahora. La única diferencia sería que luego otra administración podría reaprovecharlo y ya está.
#11 Todos los paises, si pudieran a. su vez utilizar las mejoras de los demás. Por eso GPL si y BSD no.
#11 Cualquiera si les garantizan que ellos a su vez pueden utilizar las modificaciones para lo que estiem oportuno. Así lleva avanzando la ciencia cientos de años y paradójicamente para eso nacieron las patentes
Alguien se imagina algo como la chapuza de LexNET, en un entorno con Software Libre, Transparencia y Auditoría (con recompensas?), porque a mi me cuesta imaginarlo, y es lo más gordo que recientemente me ha marcado (Por lo que implica)
PD: LexNet estaba hecho así a propósito, no voy a creer lo contrario, son burros, pero antes son corruptos
Un saludo,
#0 Duplicada: Decenas de organizaciones internacionales exigen que el dinero público sólo financie software libre [ENG]
Decenas de organizaciones internacionales exigen q...
publiccode.euLa EFF tiene un enlace a la página original: https://publiccode.eu
Esto debería ser extensible a cualquier producto hecho con subvenciones públicas/dinero público. No solo al software.
Salu2
#59 A ver, partamos de la base de que puedes solicitar el código de algo y no necesariamente hacerlo publico. Desconozco por completo los procedimientos de compra para temas militares, pero desde el sentido común, entiendo que lo razonable es querer auditar el codigo de un arma que compres si esta lleva partes muy sensibles implementadas por software, no vaya a ser que venga con un comando "que_soy_compañero_coño" que en caso de guerra convierta el arma en una maquina completamente inutil. Y si, estamos de acuerdo con que se confunde abierto y libre.
Para los que quieran firmar y no encuentren el enlace: https://publiccode.eu/#action
Si tiene implicaciones de seguridad, (safety/security), creo que no deberia ser publico..
#12 #17 La seguridad debe estar en mantener los secretos (las claves), no en el sistema. Lo contrario se llama "seguridad por oscuridad" [1] y es una postura ámpliamente criticada por todos los expertos en seguridad.
[1] https://es.wikipedia.org/wiki/Seguridad_por_oscuridad
#32 #33 Teneis toda la razon del mundo.
#33 #32 me refiero a sistemas sw donde hay inteligencia de toma de decisiones sensibles... Como cuando lanzar automáticamente contramedidas aéreas al detectar un misil tierra aire.
Por otro lado, las negociaciones sobre la propiedad intelectual del desarrollo son muy duras. Si me quedo la propiedad intelectual del sw doy un precio x, si se la queda el cliente doy 2x y si es libre doy 3x. En la valoración económica de un sw puedo vender barato porque en el retorno esperado incluyo futuras ventas a otros clientes, mantenimientos, personalizaciones... Si baja la probabilidad de conseguir esos ingresos tengo que subir el precio.
De todas formas siempre se confunde codigo abierto, con codigo libre...
#59 Espero que no existan muchos sistemas de ese calado, la verdad. En cualquier caso, el software podría seguir siendo libre porque nadie obliga ni al desarrollador ni al cliente a poner el código a disposición del público general (solo obliga al desarrollador a darle el código al cliente a quién le vende esa aplicación).
Sobre las negociaciones de propiedad intelectual: tienes razón, pero te quedas en lo inmediato. Como bien dices, si vendes "barato" es porque esperas ganar más a largo plazo. Es decir, en realidad esperas que -a la sociedad en su conjunto- le acabe costando lo mismo o más dinero que lo que cobrarías por el software liberado. Si piensas en la administración como "representante de la sociedad" ... debería salir mejor económicamente comprar el software liberado y ya, ¿no? De no ser así, las empresas que venden software privativo están haciendo el panoli...
#12, #17 La seguridad por oscuridad (ocultación del codigo, documentación etc) no es seguridad. Un sistema seguro, lo es si esta bien diseñado, que puedas ver el codigo fuente no implica que tengas acceso al sistema, si este esta bien diseñado e implementado. De hecho cuanta mas gente vea el codigo, más probable es que se detecte y solucione un problema de seguridad.
Como ejemplo: El codigo fuente de la mayoria de algoritmos criptograficos es bien conocido y no implica que puedas romperlos, porque no son mas que un sistema matemático bien diseñado.
#12 El software libre es más seguro que el software privado, precisamente porque el código en el software libre es público.
En Black Mesa usamos Windows Millenium.
#25 Luego, no sería extraño, que vuelva a petar todo pronto, no?
Al menos tendrá McAfee (al humano)
Una escopeta más nunca viene mal (insertar aquí imagen McAfee shotgun)
No tengo una opinión muy formada (aunque de primeras estoy mas en contra que a favor) sobre esta propuesta a nivel genérico... Lo que si tengo claro es que en los sectores sensibles a la seguridad no es una opción.
Los que seguis mas el tema ¿podriais decirme si estas propuestas incluyen excepciones?
#17 Si partimos de base que estan demostradas las puertas traseras de la CIA y NSA, sí es una opción muy válida salir de windows y iOS/OX
#17 Justamente en seguridad es donde es más necesario el código abierto, hasta el punto de que mucha gente considera incompatible un código cerrado con ser seguro. Sólo una pregunta, ¿qué código te parece más seguro, el que sólo ha sido analizado por media docena de desarrolladores, o el que ha estado sometido a escrutinio público de millones de personas?
Ojalá se cumpla!
Tengo sentimientos encontrados con esta iniciativa. Por un lado siempre he sido partidario del software libre, pero por otro, ahora soy reacio a compartir el código que desarrollo por varios motivos. Estoy en una plaza predoctoral desarrollando un simulador de transprote electrónico para dispositivos basados en grafeno; gran parte del impacto de mi trabajo se basa en desarrollar un modelo escrito con un código eficiente y que a la vez contenga la mayor cantidad de física posible.
Los inconvenientes de publicar el código me parecen los siguientes:
* En un escenario en el que existe competencia entre distintos grupos (a nivel internaciona), publicar el código supondría renunciar a los logros conseguidos (y poder explotar la línea de investigación correspondiente) y cederlos al resto de la comunidad científica.
* Nuestro código suele estar en constante desarrollo y no existen "versiones estables" lo suficientemente fiables, documentadas y finales como para publicarlas. En realidad ni siquiera pensamos en publicarlo (ni siquiera de forma propietaria), sino en usarlo estrictamente de forma interna.
Claro, estos inconvenientes son bajo un supuesto de publicación del código en la fase de desarrollo y investigación. Por otra parte, sí que veo muy didáctico publicar un código final una vez la línea de investigación quede cerrada, o abandonada, tanto para constatar la reproducibilidad de los resultados, como para que funcione como un herramienta pedagógica en sí misma.
#45 Es que liberar el codigo NO es una solución universal para todos los casos. En tu caso es obvio que el código representa tu know-how y por tanto tu inversión en I+D y no la quieres entregar grátis. Pero en el caso que discutimos, que es el de la administración pública dudo que haya ninguna innovación puntera que nos deje en alguna desventaja comercial, sino más bien, todo lo contrario, son procesos administrativos...no creo que hayamos inventado la polvora a nivel administrativo.
Imagina los beneficios: Administraciones que hacen los mismo procesos y pagan a distintas empresas para hacer distintos sistemas con distintos problemas... administraciones necesitan crear desde 0 un proceso que ya otros habian creado e informatizado, etc. Deberia ser simplemente obligatorio recurrir a un repositorio común de software antes de intentar contratar nuevos servicios.
#45 Yo estoy en una situación similar a la tuya, pero para mí la decisión está clara. La publicación de todo el software como software libre con licencia vírica es lo que más beneficios puede reportarme a mí de forma individual, a mi grupo de investigación, y a la comunidad científica. Con respecto a los inconvenientes que comentas:
1. Que otros grupos de investigación empleen tu método para obtener resultados es lo mejor que te puede pasar en términos de impacto para tus publicaciones. Esto repercute muchísimo en la posibilidad de obtener becas y proyectos posteriores, tanto para ti como para tu grupo de investigación. La posibilidad de convertirte en una referencia en el campo es algo a lo que nunca deberías renunciar, por razones obvias. Con respecto la "competencia", parece claro que ningún grupo de investigación va a tener la capacidad de desarrollar y mejorar el método mejor de lo que lo harías tú, por lo que la "competición" siempre estará sesgada a tu favor. Si no fuese así, ellos también estarían obligados a liberar el código, por lo que el beneficio será para la comunidad científica en general.
2. Lo de que no existan "versiones estables" es muy relativo. Siempre puedes mantener un repositorio en GitHub actualizado de forma más o menos regular (mensualmente, trimestralmente...) y etiquetar aquellas versiones concretas que se utilizaron en alguna publicación, por ejemplo. De esta forma mejorarás la reproducibilidad de vuestros resultados, y al mismo tiempo seguirás con el modelo de desarrollo que más os conviene.
#65 Y para todo eso... es imprescindible una licencia tipo GPL
#45 Si lo usas de manera interna y no tienes intención de publicarlo que más te da que licencia se use. La licencia solo sería aplicable si quieres distribuir tu código. Si no lo vas a distribuir el tema de la licencia no es aplicable.
La licencia libre, sea GPL o cualquiera no te obliga a distribuir tu código. La licencia lo que pone es unas reglas a como distribuyes tu código cuando lo haces público.
Por lo tanto, si estás en el escenario 2, ni te debería preocupar esa ley.
Pero como toda investigación, en algún momento lo tendrás que publicar, y entonces sí que os puede interesar hacer un "full disclosure" y entonces y la contribución a la comunidad científica sería plena (más si los otros equipos que trabajan en lo mismo, también sacan sus resultados) por lo que podríais hacer mejoras para cada lado.
#45 Que alguien pueda coger tu código y usarlo no quita para que la propiedad siga siendo tuya. Y si hay ahí algo novedoso y digno de patentarse, los derechos son tuyos, y podrías reclamar tu parte de la tajada a quien se beneficie de ello. Por ejemplo, hace unos años se filtró el código fuente de Windows en algún círculo piratilla, y a uno de los gurús del kernel Linux le preguntaron si le había echado un ojo, a lo que contestó que no, que ni jarto de vino porque si no después podían venir los abogados de Microsoft a decir que el código que escribía él se había "inspirado" en el código de Windows.
Pero bueno, como te han comentado por ahí, las licencias GPL y compañía se refieren a la distribución del software. Si haces uso interno, no se aplican.
Es un tema que mucha gente desconoce en profundidad, las licencias del Software Libre cuando se incluye código o partes en "software comercial", casos concretos, copyleft, proyectos académicos, GPL, MIT, Apache, etc
Es más el Software Libre "nuclear" (core) como el que hace Apache Foundation y de ahí las licencias Apache, en su origen, es un buen modelo porque se centra en componentes "esenciales".
En el sector académico muchas veces interesa, utilizar GPL, para que si se utiliza en proyectos comerciales, retorne un apoyo económico al desarrollo académico en cuestión (R, Weka, por ejemplo), cosa que me parece bien.
Y el debate en el software (incluido el Software Libre) sobre "valor" "retorno" y "propiedad intelectual" es un debate profundo e interesante, para mí toca muchos temas que son claves en le Economía del siglo XXI.
#18
En entorno académico, más que el retorno económico, lo más importante es el retorno de conocimiento. El avance es exponencial...