Devo me incluir como autor depois de modificar o código de terceiros?


17

É prática comum fazer alguns ajustes ou correções no código de terceiros (seja uma essência simples ou uma biblioteca inteira). Mas também é comum que muitos desses códigos tenham suas próprias regras de licenciamento e, eventualmente, um cabeçalho em cada arquivo com informações de direitos autorais.

Depois de fazer essas modificações, qual é o procedimento correto a seguir? Mantenha as informações da licença intocáveis ​​ou tente atualizá-las, incluindo algo como @authorou @revisiontags?

Outro problema comum é alterar o espaço para nome / pacote de terceiros para ajustá-lo às convenções do seu projeto. Alguns tipos de licença incluem esse tipo de informação em seu bloco de licença. Posso alterá-lo livremente?

Sei que a resposta para essas perguntas depende de cada tipo de licença, para tornar minha pergunta mais específica ...

Considerando as regras gerais de licença (geralmente elas são diferentes em aspectos menores, certo?), É ético (ou pelo menos permitido) que eu adicione informações livremente ao bloco de licenças sobre minhas modificações e talvez também modifique como me refiro a isso no meu código (por exemplo, use YACorp.YALibas Utils.YALib)?


2
Depende da licença e das práticas estabelecidas do projeto. Alguns projetos creditam todos os autores no texto da licença; outros colocam os autores no Github e se referem ao projeto pelo nome na licença. Algumas licenças requerem atribuição, outras não.
Robert Harvey

@RobertHarvey Você está certo, mas estou tentando definir algumas diretrizes gerais para essas situações. Eu atualizei a pergunta.
Kbtz

Sua edição soa como um garfo. Se você está criando o projeto, pode fazer o que quiser (você é o dono do garfo). Mas eu não estaria procurando nomes de bibliotecas a menos que você seja o proprietário do projeto.
Robert Harvey


1
Esta questão parece estar fora de tópico, porque se refere à afirmação e atribuição de direitos autorais. As questões de direitos autorais são questões legais fora dos conhecimentos da comunidade e pouco adequadas ao site. É difícil responder corretamente a essa pergunta, pois há muitos fatores envolvidos, como jurisdição local, bem como a propriedade de licenciamento e direitos autorais do programa original.

Respostas:


9

Depois de fazer essas modificações, qual é o procedimento correto a seguir? Mantenha as informações da licença intocáveis ​​ou tente atualizá-las, incluindo as tags @author ou @revision?

Acho que você está confundindo a licença do software e qualquer prólogo que possa fazer parte do software.

A licença é onde os proprietários dos direitos autorais do programa especificam os termos de uso (a licença) para outras pessoas. Algumas licenças são muito permissivas, outras são muito mais restritivas.

O prólogo é onde os autores inserem @authore @revisionmarcam para fornecer uma maneira de rastrear alterações no código-fonte. Em alguns casos, tornar-se autor de uma adição não trivial ao código pode reivindicar os direitos autorais sobre essa seção do código. Desvendar questões de direitos autorais pode ser espinhoso e é melhor tratado pelos advogados. No entanto, você declarou especificamente que não está preocupado com esse aspecto, então vou seguir em frente.

Outro problema comum é alterar o espaço para nome / pacote de terceiros para ajustá-lo às convenções do seu projeto. Alguns tipos de licença incluem esse tipo de informação em seu bloco de licença. Posso alterá-lo livremente?

Isso realmente depende das convenções do projeto.

Se você bifurcar o projeto, poderá fazer o que quiser.

Se você planeja contribuir com suas mudanças de volta ao projeto, deve seguir a convenção estabelecida. Se houver um motivo convincente para alterar o espaço para nome, você precisará apresentá-lo à comunidade do aplicativo.

Considerando as regras gerais de licença (geralmente elas são diferentes em aspectos menores, certo?),

é ético (ou pelo menos permitido) que eu adicione informações livremente ao bloco de licenças sobre minhas modificações e talvez também modifique como me refiro a elas no meu código (por exemplo, use YACorp.YALib como Utils.YALib)?

Não mude a licença!

Primeiro, você provavelmente não tem os direitos legais para alterar a licença. Segundo, todas as alterações feitas provavelmente atrapalharão a licença. Deixe as alterações de licença para os advogados.

Na atualização do prólogo, isso depende das normas do projeto. Alguns projetos não querem um prólogo porque usam o controle de origem para rastrear isso. Outros projetos fazem. Siga as convenções do projeto.

Atualmente, minhas preocupações são mais com "respeito à comunidade" do que com aspectos legais. Estou perguntando mais sobre o quanto podemos "enlouquecer" mantendo a ética se nosso projeto puder ser considerado privado ou pessoal.

Se você está mantendo suas alterações, por que se importa com o que os outros pensam? Algo que você usa apenas para si mesmo e nunca distribui para outras pessoas não tem impacto no projeto original. Então eles não se importam com o que você faz.

Se você planeja distribuir suas alterações ou contribuí-las de volta para o projeto, é necessário avaliar as convenções desse projeto. Alguns projetos não querem ser bifurcados e terão uma licença em vigor impedindo isso. Outros chegam ao ponto de dizer "faça o que quiser" e você recebe carta branca para fazer o que achar melhor. Por fim, a resposta aqui depende do projeto específico que você está olhando.


Como eu esperava, as respostas são quase óbvias, mas foi um alívio ver todos falando o que pensavam. Obrigado a todas as respostas!
Kbtz

Existem projetos que aceitam contribuições, mas não permitem bifurcação? Ou você quer dizer coisas como bibliotecas comerciais que também vêm com seu código-fonte?
svick

@svick - Ambos seriam aplicáveis ​​neste caso. Existem alguns projetos de código quase aberto que (tentam) impedir a bifurcação. Pense nos projetos em que eles estão tentando reservar a capacidade de comercializar em algum momento no futuro. As bibliotecas comerciais existentes impediriam a bifurcação pelos termos da licença.

@ GlenH7 Eu pensei que esses projetos (por exemplo, MySQL) geralmente exigem que os direitos autorais das contribuições que vão para a versão oficial sejam atribuídos à organização governante. Em seguida, a versão de código aberto é lançada sob uma licença de código aberto comum (como GPL), mas eles também podem ter uma versão comercial de código fechado. Mas isso não impede os garfos da versão de código aberto (consulte MariaDB).
svick

5

Eu adicionaria um comentário, em parte para sinalizar ao leitor que o arquivo não é "baunilha", com links para qualquer documentação relevante ou um sistema de rastreamento de problemas.

Edit: Portanto, esta situação me lembra quando uma distribuição Linux empacota, por exemplo, uma biblioteca. O Debian tem diretrizes e padrões sobre como os pacotes devem ser construídos e nomeados, o que pode variar de como a biblioteca é normalmente distribuída pré-construída.

Eu não acho que você deveria ter vergonha de nomear / criar / modificar uma biblioteca, pois acho que você não distribuirá o resultado para o mundo inteiro? Nesse caso, eu incluiria um README junto com a fonte que descreve quais alterações você fez e por quê. Por exemplo, README. $ {CompanyName} .changes


Eu faria algo assim também, mas minha pergunta se refere mais ao que é considerado correto do ponto de vista da 3ª parte e / ou regras gerais de licenciamento.
Kbtz

2

Você precisará consultar a regra de licenciamento do código.

Em geral, muitos aplicativos front-end de código aberto (por exemplo, Firefox, OpenOffice) consideram o nome e o logotipo do aplicativo como uma marca comercial; portanto, se você lançar uma versão modificada do aplicativo, não poderá usar as marcas registradas / trajes originais (como IceWeasel, Torbrowser, LibreOffice).

No entanto, a maioria das bibliotecas de programação geralmente se preocupa menos com as marcas registradas, desde que seja bastante claro quem faz o quê (geralmente isso pode ser encontrado nos metadados do controle de versão).

As informações do autor têm dois propósitos:

  1. Dar crédito onde é devido
  2. Culpar onde merece

Este último se torna mais importante à medida que suas alterações se tornam maiores. As informações reais de autoria geralmente podem ser encontradas no controle de versão, mas alguns projetos creditam formalmente um conjunto de autores em um arquivo separado. O ponto de corte em que as pessoas seriam formalmente creditadas varia para cada projeto; entre em contato com os autores originais em caso de dúvida.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.