Como evitar ser levado ao esquecimento por um colaborador mais poderoso?

115

Como reportado recentemente aqui :

Xamarin has forked Cocos2D-XNA, a 2D/3D game development framework, creating a cross-platform library that can be included in PCL projects.

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

The purpose of the MIT license is to unencumber your fair use. Not to encourage you to take software, rebrand it as your own, and then "take it in a new direction" as you say.

While not illegal, it is unethical.

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

Então, minhas perguntas são:

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

Espero que esta seja uma questão wiki ou que haja algumas respostas objetivas baseadas na ética / filosofia moderna do OSS.

    
por Den 20.08.2014 / 22:10
fonte

7 respostas

71

Was Xamarin's action and the way the action was done ethical or not?

Bem, vamos perguntar a um especialista - a lista da Open Source Initiative da MIT License , com a licença citada em sua totalidade :

The MIT License (MIT)

Copyright (c)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Se alguém - individual ou empresa - lançar o software / código-fonte com uma licença MIT, isso 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 são capazes de fazer o que quiserem.

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

1) Free Redistribution - The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

3) Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

5) No Discrimination Against Persons or Groups - The license must not discriminate against any person or group of persons.

6) No Discrimination Against Fields of Endeavor - The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Para minha leitura, isso parece muito claro: lançar algo como código aberto, especialmente com a licença do MIT, permite que alguém leve o software livremente, altere-o, empacote-o e venda praticamente qualquer pessoa que ele queira, contanto que eles não removem seu aviso de direitos autorais e afirmam que ele é seu próprio único trabalho.

Como autor, você está explicitamente desistindo do direito de ser exigente e exigente. Você não consegue decidir quem ou o que pode se beneficiar do seu software ou usá-lo, e você não consegue decidir por que ele está sendo usado. Você explicitamente desiste desse direito.

A idéia é que você está contribuindo para o bem maior renunciando explicitamente a qualquer direito legal que você tenha de controlar e restringir o uso e a mudança do que você fez. Se a Microsoft quiser desembolsar o seu projeto FluffBall e vendê-lo por $ 2k por assento como WindowsSpongeCake, eles podem. Não foi permitido que as pessoas fizessem o que queriam em toda a parte do seu projeto em primeiro lugar?

Is it possible to avoid such a situation if you are a single developer or a small unfunded group of developers?

Mais ou menos! Primeiro, use uma licença adequada a você e às metas e desejos de sua organização. Se você não quer que ninguém o use de uma forma que você não aprova, você provavelmente não deveria lançá-lo como Open Source - e, francamente, você talvez não devesse lançá-lo! Se você não quer que ninguém use um trabalho derivado (como uma bifurcação) em um projeto comercial, você provavelmente deve escolher uma versão copyleft de a GPL . Se você deseja uma licença não comercial, provavelmente deve obter um advogado de direitos autorais / licença para aconselhar, porque isso muitas vezes não é considerado um software de "código aberto" e não há nenhuma licença pré-gravada para suportar esse caso.

O problema com a Xamarin e o kerfuffle Coco não é uma questão de ética ou legalidade - trata-se de uma luta na internet entre algumas pessoas que se importunam umas com as outras. 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 de como o projeto deve ser tratado.

Assim, a outra forma de defesa é estar aberto à colaboração e mudança, mas entenda que, se não der certo e as visões divergirem ... bem, essa é a razão para a opção de 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.

Bottom-line, seja claro sobre seus objetivos quando estiver decidindo uma licença e entenda suas implicações para o seu futuro controle e direção do projeto. Se você quer doar para o bem maior, o código aberto é o caminho a percorrer. Se você deseja controlar seu projeto com mais rigor e ter propriedade e, pelo menos, um caso legal, se alguém tentar comercializar seu projeto ou absorvê-lo (em parte ou totalmente), você precisará de uma licença diferente e provavelmente precisará resolva isso com um advogado.

    
por 20.08.2014 / 23:26
fonte
119

A liberação de um projeto sob a licença do MIT está dando às pessoas permissão para desembolsar 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 quer que as pessoas façam isso, não use a licença do MIT. Você não pode reclamar quando as pessoas usam o código de acordo com os termos da licença que você forneceu.

Garfos são algo bastante normal para acontecer na comunidade de software livre. Parece que os desenvolvedores do fork tentaram contribuir com o projeto original e não concordaram, por isso eles contribuíram com 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ê está se beneficiando das contribuições de outras pessoas, contribuições que talvez não tenha recebido se estivesse sob uma licença diferente. Se você aceitar contribuições sob uma licença, você mesmo deve respeitar os termos da licença.

Uma maneira de manter o controle sobre uma versão oficial é confiar em itens como marcas registradas. A Mozilla Corporation, por exemplo, tem uma marca registrada no Firefox que permite que eles ditem o que as pessoas podem fazer com o Firefox, mesmo que seja de código aberto (veja Iceweasel para essa bússola).

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

    
por 20.08.2014 / 22:43
fonte
18

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

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

    
por 21.08.2014 / 00:10
fonte
12

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

Vamos dar uma olhada no reparo da licença e nas correções de erros de miscagem no arquivo 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

Existe apenas um requisito em toda a licença MIT:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

E Xamarin fez exatamente a coisa proibida. 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".

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

    
por 21.08.2014 / 20:53
fonte
11
  • Was Xamarin's action and the way the action was done ethical or not?

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

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

As you know, we contributed extensively to Cocos2D-XNA and we just could not continue to work together.

Once we reached a point where we could not collaborate together, I decided to take the project in the direction that I desired at the expense of backwards compatibility.

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

  • Is it possible to avoid such a situation if you are a single developer or a small unfunded group of developers?

Legalmente, você pode optar por usar uma licença que não permita bifurcar, proibindo a redistribuição do código-fonte (neste ponto, não seria "software livre"). Outra opção é deixar o código desimpedido, mas não permitir 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 evitar o bifurcação:

  • Facilitar a contribuição das pessoas para o seu projeto.
  • Revendo patches rapidamente.
  • Permitir alterações que não beneficiem você diretamente.
  • Ser educado. Um número surpreendente de garfos se deve ao fato de os colaboradores não estarem mais dispostos a trabalhar um com o outro.

O software de bifurcação é muito trabalhoso, e as pessoas mais sensatas não farão isso se tiverem uma opção mais fácil. Se não tiverem outra escolha, impedi-los de bifurcar seu código apenas forçá-los a bifurcar o código de outra pessoa ou a reescrever seu software do zero. Isso pode atrasá-los, mas isso não vai te ajudar muito.

Além disso, o uso de uma licença mais restritiva dificultará a contribuição de algumas pessoas. Xamarin aparentemente "contribuiu extensivamente para o Cocos2D-XNA", e eu duvido que eles teriam feito isso se a licença não lhes permitisse redistribuí-lo.

    
por 21.08.2014 / 22:13
fonte
4

Seria obscuro permitir que as pessoas tirassem conclusões incorretas sobre a autoria de qualquer código que o fork, mesmo se as legalidades forem cobertas, fornecendo os avisos e o histórico de revisão necessários para qualquer pessoa que escolha examinar de perto. Então talvez a apresentação de Xamarin seja antiética, talvez não seja, mas acho que é a base sobre a qual julgá-la: isso engana?

A licença estabelece 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 nada seja eticamente . A ética varia, mas dando crédito honesto onde o devido é um princípio amplamente aceito, então é fácil entender por que não fazer isso ofenderá.

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

Quanto a evitar que isso aconteça com você: se você quiser evitar a situação de outra pessoa insinuando que seu código é deles, então você precisa de uma voz alta ao reivindicar crédito. Se você quiser evitar a situação de alguém criando uma bifurcação de seu código que eventualmente pode se tornar mais popular que seu original (seja devido a seus maiores recursos ou apenas por sua focalização nas necessidades "certas" dos usuários), então eu acho que você está fora de sorte em OSS. Você não pode simplesmente decidir estar certo se outro grupo quer recursos diferentes no software do que você quer, e se (na visão dos usuários) você estiver errado, então você deve perder, independentemente de estar lá primeiro. Isto é uma consequência do princípio primário de código aberto (ou apropriadamente, o princípio do software livre) de que o autor não controla o software, as pessoas que o executam.

    
por 21.08.2014 / 01:40
fonte
2

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

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

A fundação Apache escolheu registrar e defender marcas registradas. Se alguma entidade diferente de um projeto de fundação forjar, oh, 'Apache Tomcat', eles estão bem ... mas eles não podem chamar de Apache Tomcat , e, quando podemos defender a marca, eles não podem chamar o 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, você não pode, praticamente, 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 existe uma fissão interna entre os colaboradores, quem deve dizer quem 'merece' manter o nome? Se, por outro lado, um outsider forks, provavelmente não é a coisa mais ética do mundo deixar o nome inalterado. Não é um ato hediondo também.

O Github está cheio de garfos . Às vezes as pessoas mudam o nome, ou o pacote Java, ou o que for - especialmente se eles querem publicar no Maven central. Muitas vezes eles não, e os usuários são deixados navegando em um labirinto de confusão. Não é o ideal, mas são as quebras da anarquia.

    
por 24.08.2014 / 18:02
fonte