ti-enxame.com

O licenciamento de código aberto meu código me limita mais tarde?

Suponha que eu desenvolva uma biblioteca útil e decida publicá-la como código aberto. Algum tempo depois, tive uma necessidade comercial de fazer algo que não estaria de acordo com a licença de código aberto. Posso fazer isso?

Como devo publicar o software de forma a manter a propriedade e não me bloquear de usar a biblioteca no futuro?

Lembre-se de que, pelo menos em teoria, outros desenvolvedores podem decidir contribuir com meu projeto de código aberto. Posso especificar em uma licença que eu, como desenvolvedor original, também tenho a propriedade de suas contribuições? Não me interpretem mal aqui, eu não estou tentando ser mau e obter a propriedade do trabalho de outros - eu só quero manter a propriedade do meu, e se alguém postar uma correção de bug importante, eu poderia ser incapaz de usar o código original, a menos Eu uso o trabalho dele também.

29
configurator

Você sempre mantém a propriedade sob licenças de código aberto. O trabalho que você criou é sua propriedade, e você pode fazer o que quiser com ele (dentro dos limites legais, é claro), incluindo permitir outras pessoas usá-lo nos termos de um - licença de origem. Se você deseja usá-lo para um projeto proprietário, pode fazê-lo, a menos que tenha cedido completamente os direitos a outra pessoa por contrato. Mas não é isso que as licenças de código aberto fazem. Eles tratam de compartilhar a utilidade, não sobre abrir mão da propriedade.

As coisas ficam um pouco complicadas quando outras pessoas começam a contribuir. Portanto, é trabalho deles, não seu, e você precisa obter a permissão deles. Uma coisa que você pode fazer é publicar sua biblioteca sob uma licença dupla. Isso é o que Sam Lantinga, o principal criador e mantenedor do SDL , faz. Porque Apple não gosta de bibliotecas de vínculo dinâmico para iOS e estar em conformidade com a LGPL em um aplicativo vinculado estaticamente é mais problemático do que vale a pena, ele publica SDL sob a LGPL e uma licença comercial para aplicativos estáticos do iPhone. Quando alguém envia um patch, ele pede explicitamente permissão para implantar o patch na biblioteca de ambas as licenças e, se não gostar disso, ele não o adiciona à base de código.

EDITAR: Meu exemplo não é mais preciso. Um tempo atrás, Sam mudou o modelo (não tenho certeza por que; talvez ele apenas se cansou dos aborrecimentos da administração) e agora licencia o SDL sob uma licença altamente permissiva do tipo zlib. Mas ele costumava fazer assim.

44
Mason Wheeler

Não sou advogado e este não é um conselho jurídico. Se precisar de garantia legal, contrate um advogado.

Você absolutamente pode licenciar seu software com duas licenças - a Trolltech fez isso por muitos anos com o Qt e a Linden Lab com o cliente SecondLife.

Você pode usar qualquer licença que desejar. Algumas licenças são compatíveis com ambientes comerciais fechados, como Mozilla MPL, licenças MIT e BSD) e (eu acredito) CDDL da Sun e licenças Apache.

No entanto, se você precisa de flexibilidade para lançar seu software tanto como um projeto de código aberto quanto como um produto de código fechado, você está absolutamente autorizado a fazer isso como autor original. O único problema é a questão das contribuições do usuário. Você não pode incorporar as contribuições de outros em sua versão comercial do software a menos que eles liberem legalmente o Copyright para você. GNU faz isso pela única razão de que eles irão atualizar suas licenças no futuro.

Observe que os usuários e especialmente contribuidores provavelmente não gostarão disso, então afetará a comunidade em torno do seu projeto, provavelmente de forma adversa.

Novamente, consulte um advogado para obter detalhes.

5
greyfade

Eu também não sou advogado, mas ...

Além das licenças restritivas (que o forçam a abrir o código-fonte de cada projeto que as utiliza) como GPL, também existem licenças não restritivas (o que significa que você pode usar tal software em um projeto comercial) como Lesser GPL ou Apache License (2.0 ?). Então, talvez você possa simplesmente lançar seu software sob termos não restritivos.

2
Paweł Dyda