O licenciamento de código aberto do 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, tenho uma necessidade comercial de fazer algo que não esteja em conformidade com a licença de código aberto. Posso fazer isso?

Como publicar o software de uma maneira que mantenha a propriedade e não me impeça de usar a biblioteca no futuro?

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

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

As coisas ficam um pouco erradas quando outras pessoas começam a contribuir. É o trabalho deles, então, não 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 que Sam Lantinga, principal criador e mantenedor do SDL , faz. Como a Apple não gosta de bibliotecas de vínculo dinâmico para iOS e o cumprimento da 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 solicita explicitamente permissão para implantar o patch na biblioteca sob as duas licenças e, se eles não gostam disso, ele não o adiciona à base de código.

EDIT: Meu exemplo não é mais preciso. Um tempo atrás, Sam mudou o modelo (não sei por que; talvez ele tenha se cansado das dificuldades administrativas) e agora licencia o SDL sob uma licença altamente permissiva no estilo zlib. Mas ele costumava fazer assim.

Não sou advogado e isso não é aconselhamento jurídico. Se você precisar de garantia legal, contrate um advogado.

Você absolutamente pode licenciar seu software de maneira dupla - a Trolltech fez isso por muitos anos com a Qt, e a Linden Lab fez com o cliente SecondLife.

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

No entanto, se você precisar da flexibilidade de lançar seu software como um projeto de código aberto e como um produto de código fechado, você poderá 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 outras pessoas em sua versão comercial do software, a menos que elas liberem legalmente os direitos autorais para você. O GNU faz isso pela única razão de que eles atualizarão suas licenças no futuro.

Observe que os usuários e principalmente os colaboradores provavelmente não irão gostar disso, portanto isso afetará a comunidade em torno do seu projeto, provavelmente adversamente.

Mais uma vez, consulte um advogado para obter detalhes.

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

Além de licenças restritivas (que o forçarão a Open Source a cada projeto que as usar) como GPL, também existem licenças não restritivas (o que significa que você pode usar esse 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.