Contratos IP amigáveis ​​de código aberto para freelancers

Estou prestes a entrar no mundo da consultoria pela primeira vez e estou tendo que escrever meu primeiro contrato. Um problema que tenho é sobre trabalho de código aberto e propriedade intelectual. Adoro trabalhar em projetos de código aberto, seja um projeto existente ou um projeto que inicio por conta própria.

A questão é: como posso escrever meu contrato para acomodar as seguintes situações:

1. No decorrer do trabalho no projeto do cliente, quero abrir parte do código de código-fonte para a comunidade com meu próprio nome.
2. No decorrer do trabalho no projeto do cliente, estou fazendo uso de alguns dos meus projetos de código aberto existentes e fazendo melhorias neles.
3. No decorrer do trabalho nos projetos do cliente, faço melhorias nos projetos de código aberto de terceiros e os contribuo de volta.
4. No decorrer do trabalho no projeto do cliente, decidimos abrir parte do código-fonte com o nome do cliente.

Quais são os precedentes para isso, se houver?

Atualização: eu adicionei um item na lista acima (item # 3).

Além disso, a IANAL - por isso, recomendo consultar um advogado que entenda ou se especialize especificamente em questões de propriedade intelectual de software .

Mas acho que a resposta é bastante direta: 1. Não acho necessário discutir o termo "código aberto" com o cliente (leia antes de formar uma opinião sobre essa afirmação) 2. No seu contrato, você claramente precisa declarar o seguinte: a. Qualquer trabalho que você criar para o cliente que você É JOINTLY PRÓPRIO e cada um pode criar produtos de trabalho derivados. Isso significa que cada um pode usá-lo como achar melhor, inclusive contribuindo para um projeto de código aberto (consulte os requisitos de IP do projeto de código aberto, é claro). b. Você mantém a propriedade de qualquer produto de trabalho preexistente que você pode incluir gratuitamente e emite uma licença irrestrita ao seu cliente para usar esse código perpetuamente, incluindo a criação de trabalhos derivados c.

Você também quer garantir que a DAMN TENHA nunca assinar nenhum contrato com uma cláusula de Cessão de Invenções que não seja extremamente limitada (eles nunca o são) - ou você pode ser legalmente SOL. Observe que existem vários estados (ou seja, Califórnia) que limitam (mas não eliminam) isso por lei, independentemente do que o contrato diz. Isso é esperado em um contrato de trabalho (mas é possível negociar limites), mas o IMHO não deve ser concedido para um contrato de empreiteiro independente.

Seu maior desafio será levá-los a aceitar a propriedade conjunta do código-fonte. Isso entra em conflito com a doutrina "Trabalho feito para locação", que é um idioma específico que é frequentemente usado em contratos de desenvolvimento de software ao usar contratados.

Se eles entendem IP, eles podem não concordar com isso - mas acho que esses não são os tipos de clientes com os quais você está lidando. Posso dizer com certeza que existe pelo menos uma empresa de software extremamente grande que faz isso para qualquer código de consultoria / personalizado escrito para qualquer cliente - e se eles não concordam com isso, não o fazem - ponto ( mas eles os encaminham para um parceiro).

Se você possui uma propriedade conjunta, você deve ser bem em IP para contribuir com esse código para um projeto de código aberto, sujeito a quaisquer restrições feitas por esse projeto.

Você também quer ser seletivo no que abre seu código-fonte. Você faria um desserviço ao cliente se abrir um código específico do setor de origem que seja útil para seus concorrentes diretos. Seu cliente também ficará satisfeito se perceber que o aplicativo inteiro que eles pagaram para você escrever por eles está disponível gratuitamente - e pode até pensar que você o instalou em vez de escrevê-lo do zero. Você também diminuiu o valor percebido dos seus serviços.

Eu acho que isso cobre suas perguntas 1,2 e 4.

A questão 3 pode ser um problema - dependendo do modelo de licenciamento do projeto de código-fonte aberto a partir do qual você está criando um trabalho derivado, o cliente certamente pode pagar por isso, mas eles podem não ter a propriedade completa ou mesmo a propriedade desse código por o modelo de licenciamento do projeto de código aberto. Isso não quer dizer que você não possa fazê-lo - mas convém cobrir isso com uma cláusula adicional em seu contrato - e executá-lo por um advogado de PI - ou fazê-lo somente depois que um cliente solicitar que você faça isso - e poderá cobrar os custos de um advogado revisar uma adenda ao seu contrato que cubra essa situação.

Sério, as duas respostas começaram com IANAL - acho que você precisa parar de pensar em escrever um contrato e conversar com um advogado antes de prosseguir. Você não perguntaria ao seu advogado como refatorar partes do seu código.

Também - @Pete Wilson está certo, suas estipulações provavelmente não serão muito boas para o seu cliente.

A IANAL usual se aplica, ou seja, consulte um advogado real.

Dito isto, minha opinião seria:

1. ... é difícil. É improvável que um cliente esteja disposto a pagar por um software que você irá abrir de código imediatamente. Você pode perguntar, e se eles concordarem, estabelecer um contrato de acordo, mas meu palpite é que isso não vai acontecer.

2. ... também é bastante improvável, mas com um contrato bem elaborado que defina claramente os limites e concordar que você não será pago pelo trabalho em seus próprios projetos de código aberto (esteja usando o código ou não) pode ser aceitável para os clientes. Você pode até convencê-los a contribuir financeiramente para o seu projeto, mas, em qualquer caso, é necessário um esforço considerável para estabelecer um bom contrato.

3. ... fica a critério do cliente. Geralmente, um cliente deseja a vantagem pela qual está pagando, o que significa que ele não vê nenhum benefício em abrir o código de propriedade, mas pode haver casos em que você os convença a fazê-lo, adicionando um pouco de atraso para manter a vantagem ou publicar sob um modelo de licença dupla.