Como evitar ser esquecido no esquecimento por um colaborador mais poderoso?

Conforme relatado recentemente aqui :

A Xamarin criou o Cocos2D-XNA, uma estrutura de desenvolvimento de jogos 2D / 3D, criando uma biblioteca de plataforma cruzada que pode ser incluída em projetos PCL.

No entanto, o fundador do projeto que foi bifurcado diz :

O objetivo da licença do MIT é liberar o uso justo. Para não encorajá-lo a usar o software, renomeie-o como seu e depois "leve-o para uma nova direção", como você diz.

Embora não seja ilegal, é antiético.

Parece que a página GitHub do novo projeto nem indica que é uma bifurcação da maneira típica do GitHub, optando por uma seção de histórico facilmente removível (veja a parte inferior).

Então, minhas perguntas são:

1. A ação de Xamarin foi e a maneira como a ação foi realizada ética ou não?
2. É possível evitar essa situação se você é um desenvolvedor único ou um pequeno grupo de desenvolvedores sem financiamento?

Espero que isso possa ser uma pergunta do wiki ou que haja respostas objetivas baseadas na ética / filosofia OSS moderna.

A ação de Xamarin foi e a maneira como a ação foi realizada ética ou não?

Bem, vamos perguntar a um especialista - a lista da Licença MIT da The Open Source Initiative , com a licença citada na íntegra:

A licença do MIT (MIT)

Direitos autorais (c)

A permissão é concedida, gratuitamente, a qualquer pessoa que obtenha uma cópia deste software e dos arquivos de documentação associados (o "Software"), para negociar no Software sem restrições, incluindo, sem limitação, os direitos de uso, cópia, modificação, fusão , publicar, distribuir, sublicenciar e / ou vender cópias do Software e permitir que as pessoas a quem o Software é fornecido o façam, sob as seguintes condições:

O aviso de direitos autorais acima e este aviso de permissão devem ser incluídos em todas as cópias ou partes substanciais do Software.

O SOFTWARE É FORNECIDO "TAL COMO ESTÁ", SEM GARANTIA DE QUALQUER TIPO, EXPRESSA OU IMPLÍCITA, INCLUINDO MAS NÃO SE LIMITANDO A GARANTIAS DE COMERCIALIZAÇÃO, ADEQUAÇÃO A UMA FINALIDADE ESPECÍFICA E NÃO INFRACÇÃO. EM NENHUM CASO OS AUTORES OU TITULARES DE DIREITOS AUTORAIS SERÃO RESPONSÁVEIS POR QUALQUER REIVINDICAÇÃO, DANOS OU OUTRA RESPONSABILIDADE, SEJA EM AÇÃO DE CONTRATO, TORT OU OUTRA FORMA, proveniente, fora ou em conexão com o software ou o uso ou outros acordos no PROGRAMAS.

Se alguém - individual ou empresa - lança software / código-fonte com uma licença MIT, significa que qualquer outra pessoa - indivíduo ou empresa pode "negociar no Software sem restrições". Desde que o aviso de direitos autorais permaneça intacto, eles poderão fazer o que quiserem.

Este é um daqueles casos em que ética e legalidade são praticamente iguais. Se uma pessoa ou grupo não entendeu a licença ou suas implicações, eles falharam em fazer a devida diligência. A Open Source Initiative fornece muitos outros recursos interessantes para nos ajudar a entender licenças como a variante do MIT. Vejamos algumas cláusulas de sua definição de código aberto:

1) Redistribuição gratuita - A licença não deve restringir nenhuma parte da venda ou doação do software como componente de uma distribuição agregada de software contendo programas de várias fontes diferentes. A licença não exigirá royalties ou outras taxas para essa venda.

3) Trabalhos Derivados - A licença deve permitir modificações e trabalhos derivados, e deve permitir que eles sejam distribuídos sob os mesmos termos da licença do software original.

5) Não Discriminação Contra Pessoas ou Grupos - A licença não deve discriminar nenhuma pessoa ou grupo de pessoas.

6) Sem discriminação contra campos de atuação - A licença não deve restringir ninguém de fazer uso do programa em um campo específico de atuação. Por exemplo, ele não pode restringir o programa de ser usado em uma empresa ou de pesquisa genética.

Para minha leitura, isso parece bastante claro: liberar algo como código aberto, especialmente com a licença do MIT, permite que alguém pegue o software livremente, troque-o, empacote-o e venda-o praticamente de quem quiser, desde que não t remover o aviso de direitos autorais e afirmam que ele seja seu próprio critério trabalho.

Como autor, você está explicitamente desistindo do direito de ser exigente e exigente. Você não decide quem ou o que pode se beneficiar do seu software ou faz uso dele, e não decide por que eles o estão usando. Você desiste explicitamente desse direito.

A idéia é que você esteja contribuindo para um bem maior renunciando explicitamente a quaisquer direitos legais que você tem para controlar e restringir o uso e a alteração do que você fez. Se a Microsoft quiser bifurcar seu projeto FluffBall e vendê-lo por US $ 2 mil por assento como WindowsSpongeCake, eles poderão. Deixar as pessoas fazerem o que elas querem, em primeiro lugar?

É possível evitar essa situação se você é um desenvolvedor único ou um pequeno grupo de desenvolvedores sem financiamento?

Mais ou menos! Primeiro, use uma licença apropriada para você e os objetivos e desejos da sua organização. Se você não quer que ninguém o use de uma maneira que não aprova, provavelmente não deve lançá-lo como código aberto - e, francamente, talvez você não deva lançá-lo! Se você não quer que ninguém use um trabalho derivado (como um garfo) em um projeto comercial, provavelmente deve optar por uma versão copyleft da GPL . Se você deseja uma licença não comercial, provavelmente deve aconselhar um advogado de direitos autorais / licença, porque isso geralmente não é considerado um software de "código aberto" e não há nenhuma licença pré-escrita importante para apoiar esse caso.

O problema com o Xamarin e Coco kerfuffle não é uma questão de ética ou legalidade - trata-se de uma briga na Internet entre algumas pessoas que brigam entre si. Somos todos humanos, acontece. Parece ser o resultado de ser incapaz de colaborar / cooperar, provavelmente devido a um conflito de personalidade ou visões incompatíveis sobre como o projeto deve ser tratado.

Portanto, a outra maneira de defesa está sendo aberta à colaboração e à mudança, mas entenda que, se não der certo e as visões divergirem ... bem, essa é a razão da opção de se bifurcar e ter seu próprio projeto separado.

É muito humano e compreensível que os sentimentos de propriedade e popularidade tornem os projetos de software muito, muito complicados. Mas o objetivo do código aberto é tentar transcender isso e permitir que o melhor software esteja disponível gratuitamente para todos.

Resumindo, seja claro sobre seus objetivos ao decidir uma licença e entenda as implicações para seu controle e direção futuros do projeto. Se você apenas deseja doar para o bem maior, o código aberto é o caminho a seguir. Se você deseja controlar seu projeto com mais rigidez e possuir propriedade e, pelo menos, um processo legal, se alguém tentar comercializá-lo ou absorvê-lo por conta própria (em parte ou totalmente), você precisará de uma licença diferente e provavelmente precisará resolva isso com um advogado.

A liberação de um projeto sob a licença do MIT está dando às pessoas permissão para bifurcar o projeto. Parte da filosofia por trás do software livre é dar aos usuários e desenvolvedores o direito de usar, modificar e liberar o software de maneiras que normalmente não seriam permitidas. Se você não quiser que as pessoas façam isso, não use a licença MIT. Você realmente não pode reclamar quando as pessoas usam código sob os termos da licença que você deu a eles.

Forks são uma coisa bastante normal que acontece na comunidade de software livre. Parece que os desenvolvedores do fork tentaram contribuir com o projeto original e não concordaram, então eles contribuíram para o seu próprio projeto. O software livre incentiva isso para que os desenvolvedores não sejam impedidos de modificar o software porque os proprietários não gostam de suas alterações.

Além disso, ao liberar algo sob uma licença de software livre, você se beneficia das contribuições de outras pessoas, contribuições que talvez você não recebesse se estivesse sob uma licença diferente. Se você aceitar contribuições sob uma licença, deverá respeitar os termos da licença.

Uma maneira de manter o controle sobre uma versão oficial é confiar em coisas como marcas registradas. A Mozilla Corporation, por exemplo, possui uma marca registrada no Firefox, que lhes permite ditar o que as pessoas podem fazer com o Firefox, mesmo que seja de código aberto (consulte Iceweasel para obter informações detalhadas).

Outras licenças como LGPL ainda permitem garfos, mas mantêm o código aberto. Dessa forma, você pode incorporar pelo menos quaisquer alterações do fork no projeto original e se beneficiar do desenvolvimento do fork. O código LGPL pode usar qualquer código licenciado pelo MIT; portanto, se você quiser ter mais controle sobre o projeto, poderá usar o LGPL.

Eu não chamaria isso de antiético. Eu chamaria isso de antidesportivo. Há uma expectativa não-escrita de que você fará um esforço de boa fé para melhorar a versão original antes de decidir bifurcar-se, e parece que o autor original sente que o esforço de boa fé não foi feito.

Dito isto, a melhor maneira de evitar que seu software seja bifurcado é responder às solicitações dos clientes de maneira que seu software tenha um apelo o mais amplo possível. Ninguém vai apoiar um garfo se souberem que o original é superior. Além disso, sua única proteção é alterar os termos da licença.

• A ação de Xamarin foi e a maneira como a ação foi realizada ética ou não?

Muitas pessoas estão confundindo a situação legal e ética. A licença X11 permite que qualquer pessoa "use, copie, modifique, mescle, publique, distribua, sublicencie e / ou venda cópias do Software e permita que pessoas a quem o Software é fornecido o façam", portanto isso é definitivamente legal .

Ético, porém, é mais complicado. Em comunidades de código aberto, geralmente é considerado preferível melhorar o software original em vez de criar um fork. No link que você deu , Miguel de Icaza diz:

Como você sabe, contribuímos extensivamente para o Cocos2D-XNA e simplesmente não pudemos continuar trabalhando juntos.

Quando chegamos a um ponto em que não podíamos colaborar juntos, decidi levar o projeto na direção que desejava à custa da compatibilidade com versões anteriores.

Não está claro por que eles "não puderam colaborar juntos", mas parece que a Xamarin fez um esforço razoável para trabalhar no projeto original antes de decidir usá-lo.

• É possível evitar essa situação se você é um desenvolvedor único ou um pequeno grupo de desenvolvedores sem financiamento?

Legalmente, você pode optar por usar uma licença que não permita bifurcação, impedindo a redistribuição do código-fonte (neste momento, não seria "software livre"). Outra opção é deixar o código livre, mas não permita a redistribuição de ativos estáticos, como imagens ou texto sem código (alguns jogos têm licenças como essa).

Socialmente, você pode impedir a bifurcação:

• Facilitando que as pessoas contribuam com mudanças no seu projeto.
• Revendo patches rapidamente.
• Permitindo alterações que não o beneficiam diretamente.
• Ser educado. Um número surpreendente de garfos deve-se ao fato de os colaboradores não estarem mais dispostos a trabalhar um com o outro.

Software de bifurcação é muito trabalhoso, e a maioria das pessoas sãs não fará isso se tiver uma opção mais fácil. Se eles não tiverem outra opção, impedi-los de criar seu código apenas forçará a bifurcar o código de outra pessoa ou a reescrever seu software do zero. Isso pode atrasá-los, mas na verdade não ajuda muito.

Além disso, o uso de uma licença mais restritiva tornará algumas pessoas menos propensas a contribuir. O Xamarin aparentemente "contribuiu extensivamente para o Cocos2D-XNA", e duvido que eles teriam feito isso se a licença não permitisse que eles a redistribuíssem.

O que Xamarin fez é legal e ético ... quase.

Vamos dar uma olhada na correção de consolidação da licença e correções de erros diversos no leia - me :

LicenseAndCredit.txt (diff)

-Copyright (c) 2010-2012 cocos2d-x.org
-
-Copyright (c) 2008-2010 Ricardo Quesada
-Copyright (c) 2011      Zynga Inc.
-Copyright (c) 2011-2012 openxlive.com
-Copyright (c) 2012      Totally Evil Entertainment, LLC
-Copyright (c) 2012      Gena Minchuk
-Copyright 2012 Xamarin Inc
+Copyright (c) The Cocos2D-XNA Team

Há apenas um requisito em toda a licença do MIT:

O aviso de direitos autorais acima e este aviso de permissão devem ser incluídos em todas as cópias ou partes substanciais do Software.

E Xamarin fez exatamente a coisa proibida. A Xamarin pode pensar que torna a licença "mais bonita" ter menos avisos de direitos autorais no topo, mas eles não têm permissão (legal ou ética) para remover a "redundância".

Obviamente, se eles corrigirem o arquivo de licença, estarão novamente na área jurídica. O autor da biblioteca original pode não concordar, mas ele fez a escolha da licença e não pode culpar ninguém por eles terem feito o que a licença permite explicitamente.

Seria obscuro permitir que as pessoas tirassem conclusões incorretas sobre a autoria de qualquer código fornecido pela bifurcação, mesmo que as legalidades sejam cobertas fornecendo os avisos necessários e o histórico de revisões para quem optar por olhar atentamente. Talvez a apresentação de Xamarin seja antiética, talvez não, mas acho que essa é a base para julgá-la: ela engana?

A licença concede permissão para usar o código e um requisito para incluir avisos de direitos autorais relevantes com cópias do código. Isso é tudo em um nível bastante baixo. Ele não discute como você deve resumir publicamente quem contribuiu com o quê, mas apenas porque isso está fora do escopo da licença e não faz parte do contrato legal , não significa que tudo é eticamente . A ética varia, mas dar crédito honesto onde o vencimento é um princípio amplamente aceito, portanto é fácil ver por que não fazer isso ofenderá.

Como todo mundo diz que não há intenção na licença do MIT de evitar garfos, então isso não é antiético por si só. Se "renomear como o seu" é o código para "fazer reivindicações de crédito públicas que você não merece", certifique-se de que seria antiético se verdadeiro.

Quanto a impedir que isso aconteça com você: se você quiser evitar a situação de outra pessoa insinuando que o seu código é dele, precisará de uma voz alta ao reivindicar crédito. Se você quiser evitar a situação de alguém criando uma bifurcação do seu código que possa se provar mais popular do que o original (devido aos recursos maiores ou apenas ao se concentrar nas necessidades "corretas" do usuário)), acho que você está fora de sorte no OSS. Você não pode simplesmente decidir estar certo se outro grupo quiser recursos diferentes no software do que deseja e se (na visão dos usuários) você estiver errado, então você deve perder, independentemente de estar lá primeiro. Isso é uma conseqüência do princípio primário do código aberto (ou, adequadamente, do software livre), de que o autor não controla o software, as pessoas que o administram.

Uma expansão do tópico da marca registrada:

Na Apache Software Foundation, todo o código é AL. E, como na licença BSD em discussão aqui, é perfeitamente claro que o AL permite garfos. Período. Fim de discussão. De fato, conforme discutido em outras respostas, todas as verdadeiras licenças de código aberto permitem bifurcações. Tudo o que eles controlam é a licença / uso do código bifurcado.

A fundação Apache optou por registrar e defender marcas comerciais. Se alguma entidade que não seja um projeto de fundação forquilha, oh, 'Apache Tomcat', eles estão bem ... mas não podem chamá-lo de Apache Tomcat e, quando podemos defender a marca, eles não podem chamar de Tomcat .

O problema aqui é que as marcas registradas não são para os fracos de coração. Se você é um pequeno grupo de pessoas, sem estrutura legal e sem financiamento, praticamente não pode usar a lei de marcas registradas para proteger seu nome.

No final, esse tipo de coisa é uma das razões para as várias fundações por aí.

Do ponto de vista ético, bem, se houver uma fissão interna entre os contribuidores, quem dirá quem 'merece' manter o nome? Se, por outro lado, alguém de fora forca, provavelmente não é a coisa mais ética do mundo para deixar o nome inalterado. Também não é um ato hediondo.

O Github está cheio de garfos . Às vezes, as pessoas alteram o nome, o pacote Java ou o que for - principalmente se desejam publicar na central do Maven. Freqüentemente não, e os usuários ficam navegando em um labirinto de confusão. Não é o ideal, mas esse é o rompimento com a anarquia.