Creación de trabajos derivados de software de código abierto [cerrado]

Question

Esta pregunta siempre ha estado en mi cabeza.

¿Alguien puede crear un nuevo producto basado en un proyecto de código abierto existente?

Digamos que desea crear un " Apaxe webserver " eso es básicamente Apache con algunos complementos adicionales (por ejemplo, soporte para ASP o algo similar)

¿Es esto posible?

¿Sería capaz de crear un producto de código cerrado (gratuito o con licencia)

En cuanto a GPL parece claro, no es posible porque la fuente debe estar abierta. Pero, ¿qué pasa con la licencia de Apache, BSD y otros & Quot; corporativo amigable & Quot;

¿El precio (gratis para la mayoría del proyecto), las correcciones de errores y contar con el equipo de desarrollo central son lo único que impide que otros comercialicen esos productos de SO?

¿Qué pasa con: Khrome, un producto comercial basado en Chrome con soporte ActiveX (quién se atrevería a hacer tal cosa: P)

EDIT

Gracias a todos por sus respuestas.

Entonces, de nuevo

¿Qué impide que productos similares (clonados) aparezcan en el mercado?

:)

NOTA: Sé que no somos abogados, y podríamos leer todas las licencias de OSS aquí http: //www.opensource .org / licensias .

Answer 1

Nada impide que los productos clon aparezcan en el mercado. Mire todas las diversas distribuciones de Linux, por ejemplo. El proyecto X.org se bifurcó de XFree86. Y así sucesivamente.

Sin embargo, ocurre con poca frecuencia, por un par de razones:

• El proyecto original tiene la primera ventaja en el mercado
• El original generalmente se entrega gratis

Entonces, a menos que su versión sea significativamente mejor que la original, no obtendrá mucha aceptación ni hará mucho dinero con ella. Si su versión es significativamente mejor, ¡adelante!

Desde el punto de vista del desarrollador original, el poder de la GPL es que obliga a dichos clones a compartir cualquier mejora con el resto del mundo, para que puedan incorporarse nuevamente al original.

Answer 2

Generalmente, mi lectura de las licencias es:

1. Puede hacer un trabajo derivado de cualquier proyecto basado en una de las licencias populares (es decir, GPL, LGPL, Apache, MIT, BSD).
2. Puede cobrar dinero por al menos la distribución & amp; embalaje de su trabajo derivado.
3. Dependiendo de la licencia, es posible que también deba distribuir sus modificaciones en forma de fuente y / o incluir avisos en su distribución.

Entonces, a su pregunta sobre Apaxe: sí, puede hacer esto hasta donde yo sé. Creo que el servidor Oracle HTTPD en realidad se deriva de Apache, ¡y definitivamente no es gratis!

Answer 3

Aquí está mi vista de 10,000 pies de licencias de código abierto:

" Real " licencias de código abierto (por ejemplo: MIT, BSD, Apache, creo, etc.): Puede hacer lo que quiera con trabajos derivados de licencias. Puede cerrarse, abrirse, etc. La licencia no impone restricciones a su licencia de obras derivadas.

" Restringido " licencias de código abierto (por ejemplo: GPL, LGPL): Los trabajos derivados deben incluir restricciones de licencia específicas; por ejemplo, la GPL requiere que los trabajos derivados sean editados con GPL. Esencialmente, sus derechos están restringidos para trabajos derivados.

El cobro por productos es independiente de cualquiera de estos; ninguno de los tipos restringe el cobro de productos, aunque algunas licencias imponen restricciones a los derechos que puede retener y / o debe transmitir a los receptores de su software (es decir, las " licencias " restringidas).

Espero que esto ayude.

Editar: cambiado por original " DRM " término para licencias de tipo GPL a " Restringido " ;, porque algunas personas adjuntan connotaciones negativas a DRM y / o no pueden comprender cómo la GPL restringe sus derechos para trabajos derivados de una manera casi idéntica a cualquier otro tipo de DRM (es decir, controlar lo que puede hacer con él). En serio, puedes ser un seguidor de la FSF y aún entender el concepto de que la GPL es más restrictiva que & "; Real &"; licencias de código abierto. La pregunta no es sobre qué tipo es correcto o incorrecto, sino sobre cuál es la diferencia.

Answer 4

Red Hat (y la mayoría de los otros proveedores de Linux) cobran por el soporte, no por su software, que es principalmente cómo las empresas pueden ganar dinero con el código con licencia GPL.

Answer 5

Realmente depende de la licencia que use el proyecto de código abierto.

Descargo de responsabilidad: no soy abogado; siempre debe leer la licencia para obtener todos los detalles.

Si un proyecto está bajo la GPL, entonces todo lo que derive de él también debe ser liberado bajo la GPL (o una licencia compatible, y si está liberado). Todavía se le permite cobrar dinero por ello, pero a cualquiera que lo compre se le debe proporcionar la fuente completa, y no puede evitar que también lo vendan o lo regalen gratuitamente.

Si un proyecto está bajo la licencia BSD, puede hacer casi cualquier cosa con él, incluso incorporarlo en un producto patentado de código cerrado. ¡Hay código BSD dentro de Windows!

Otras licencias caen en algún punto intermedio.

Answer 6

mira MyEclipse, es realmente solo eclipse + plugins gratuitos + plugins de myeclipse y cuesta algo de dinero.

Answer 7

  

¿Qué impide que productos similares (clonados) aparezcan en el mercado?

Nada. La pregunta real es: ¿cómo puede un producto clonado similar hacerse más popular que el producto original?

Algunos casos en los que alguien puede clonar / bifurcar un proyecto:

• Recoger un proyecto de código abierto muerto y continuar su desarrollo. Si el nuevo producto derivado se mantiene regularmente y recibe más actualizaciones que la versión original, entonces las personas comenzarán a usar la nueva versión. Este es uno de los grandes beneficios del código abierto: un buen software no necesita morir, solo porque los desarrolladores originales dejan de desarrollarlo, pero alguien más puede continuar desde donde lo dejaron. Un ejemplo de dicho proyecto (que he usado) es que el desarrollo de Turck MMCache se había extinguido en 2003, por lo que eAccelerator lo bifurcó y continuó su desarrollo en 2004. Estoy seguro de que hay muchos otros ejemplos.

• Hay un desacuerdo en la comunidad de desarrolladores de un proyecto de código abierto, y el proyecto se divide en dos. Es por eso que es mejor luchar por un entendimiento común en proyectos de código abierto, para que la comunidad no se divida innecesariamente. Si un proyecto se divide, los proyectos pueden seguir vivos si logran atraer suficientes desarrolladores y usuarios, pero de lo contrario pueden morir lentamente. En general, se debe evitar la división, porque hace que la comunidad esté más fragmentada y más débil. IIRC, en las presentaciones de video de Produciendo software de código abierto (¡bueno!) Mencionaron un caso en el que el desarrollador original de algún proyecto quería tomar una dirección completamente nueva en el desarrollo, pero la comunidad de otros desarrolladores quería mantener la antigua dirección. El resultado fue que el desarrollador original fue expulsado del proyecto, por lo que creó una bifurcación del proyecto, mientras que el resto de la comunidad continuó el desarrollo del proyecto original.

• Un derivado comercial de código cerrado de un proyecto de código abierto que se lanzó bajo una licencia permisiva (por ejemplo, BSD). El producto derivado necesitaría ser considerablemente mejor en características o soporte que el producto original. De lo contrario, las personas preferirán usar el producto abierto y gratuito original.

Answer 8

¿No es eso esencialmente lo que hace Red Hat? A pesar de que tienen fedora, están cobrando dinero por su distribución de Linux. De acuerdo, han escrito mucho código para ello, todavía se basa en código abierto.