diff --git a/documentation/content/pt-br/articles/bsdl-gpl/_index.adoc b/documentation/content/pt-br/articles/bsdl-gpl/_index.adoc index cbc736feaa..36c1d436ab 100644 --- a/documentation/content/pt-br/articles/bsdl-gpl/_index.adoc +++ b/documentation/content/pt-br/articles/bsdl-gpl/_index.adoc @@ -1,184 +1,184 @@ --- authors: - author: 'Bruce Montague' email: brucem@alumni.cse.ucsc.edu description: 'Por que você deve usar uma licença de estilo BSD em seu Projeto Open Source' -tags: '["bsdl", "gpl", "FreeBSD License"]' +tags: ["bsdl", "gpl", "FreeBSD License"] title: 'Por que você deve usar uma licença de estilo BSD em seu Projeto Open Source' -trademarks: '["freebsd", "intel", "general"]' +trademarks: ["freebsd", "intel", "general"] --- = Por que você deve usar uma licença de estilo BSD em seu Projeto Open Source :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: ''' toc::[] [[intro]] == Introdução Este documento apresenta argumentos para a utilização de uma licença de estilo BSD para software e dados; especificamente recomenda utilizar uma licença de estilo BSD no lugar de uma GPL. Também pode ser lido como uma introdução e resumo das licenças de Projeto Open Source, BSD versus GPL. [[history]] == Uma Breve História do Open Source Muito antes do termo "Open Source" ser utilizado, o software era desenvolvido por associações livres de programadores e os softwares eram livremente trocados ou negociados. A partir do início dos anos 50, organizações como a http://www.share.org[SHARE] e a http://www.decus.org[DECUS] desenvolviam grande parte do software que as empresas de hardware empacotavam em suas ofertas. Naquela época, as empresas de computadores estavam no negócio de hardware; qualquer coisa que reduzisse o custo do software e disponibilizasse mais programas tornava as empresas de hardware mais competitivas. Este modelo mudou nos anos 60. Em 1965, a ADR desenvolveu o primeiro produto de software licenciado e independente de uma empresa de hardware. A ADR estava competindo contra um pacote gratuito da IBM que foi originalmente desenvolvido por seus próprios clientes. A ADR patenteou seu software em 1968. Para interromper o compartilhamento de seu programa, eles forneceram seu software sob leasing de equipamento, na qual o pagamento foi distribuído durante a vida útil do produto. A ADR reteve a propriedade e pôde controlar a revenda e a reutilização. Em 1969, o Departamento de Justiça dos EUA acusou a IBM de destruir negócios e empresas com seu agrupamento de software livre e hardware IBM. Como resultado deste processo, a IBM separou seu software; isto é, os softwares tornaram-se produtos independentes e separados do hardware. Em 1968, a Informatics apresentou o primeiro software comercial revolucionário e rapidamente foi estabelecido o conceito do produto de software, da empresa de software e de taxas de retorno bem altas. A Informatics desenvolveu a licença perpétua que agora é comum em toda a indústria de computadores, onde a propriedade do software nunca é transferida para o cliente. [[unix-license]] == Unix de uma Perspectiva de Licenciamento BSD A AT&T, que detinha a implementação original do Unix, era um monopólio regulado publicamente e amarrado a um tribunal anti-trust; ela foi legalmente impossibilitada de vender um produto no mercado de software. Entretanto, ela podia fornece-lo a instituições acadêmicas pelo preço da mídia. As universidades adotaram rapidamente o Unix depois da divulgação de sua disponibilidade em uma conferência de Sistema Operacional. Foi extremamente útil o Unix rodar no PDP-11, um computador de 16 bits muito acessível na época, e que foi codificado em uma linguagem de alto nível, que era comprovadamente boa para a programação de sistemas. O DEC PDP-11 tinha, na verdade, uma interface de hardware aberta, projetada para tornar mais fácil para os clientes escreverem seus próprios sistemas operacionais, o que era comum. O famoso fundador da DEC, Ken Olsen, proclamou que "o software vem do céu quando você tem um bom hardware". O autor do Unix, Ken Thompson, retornou à Universidade da Califórnia de Berkeley (UCB) em 1975, e lecionou sobre o kernel linha por linha. Isso acabou resultando em um sistema evoluído conhecido como BSD (Berkeley Standard Distribution). A UCB converteu o Unix em 32 bits, adicionou memória virtual e implementou a stack TCP/IP, a qual foi essencialmente necessária para a construção da Internet. A UCB disponibilizou o BSD pelo custo da mídia, e isso ficou conhecido como "a licença BSD". Um cliente comprava o Unix da AT&T e depois comprava uma fita BSD da UCB. Em meados da década de 80, um processo anti-trust governamental contra a AT&T resultou no seu desmembramento. A AT&T ainda possuía o Unix e a partir daquele momento podia vendê-lo. Então a AT&T embarcou em um esforço agressivo de licenciamento e a maioria dos Unixes comerciais da época tornaram-se derivações do Unix AT&T. No início dos anos 90, a AT&T processou a UCB por violações de licenças relacionadas ao BSD. A UCB descobriu que a AT&T havia incorporado, sem reconhecimento ou pagamento, muitas melhorias nos produtos da AT&T originadas no BSD, e isso resultou em um longo processo judicial entre a AT&T e a UCB. Durante esse período, alguns programadores da UCB embarcaram em um projeto para reescrever todos os códigos AT&T que estavam associados ao BSD. Este projeto resultou em um sistema chamado BSD 4.4-lite (lite porque não era um sistema completo; faltavam 6 arquivos-chave AT&T). Uma longa série de artigos foram publicados um pouco depois disso na revista Dr. Dobbs, que descreviam uma versão do Unix derivada do BSD para PC 386, na qual os 6 arquivos que estavam faltando no 4.4 lite foram substituídos por arquivos de licença BSD. Este sistema, chamado 386BSD, foi devido ao ex programador da UCB, William Jolitz. Ele se tornou a base original de todos os BSD para PCs que estão atualmente em uso. Em meados da década de 90, a Novell comprou os direitos do Unix da AT&T e um acordo (então secreto) foi fechado para encerrar o processo. A UCB logo encerrou seu suporte para o BSD. [[current-bsdl]] == O Estado Atual das Licenças FreeBSD e BSD A chamada http://www.opensource.org/licenses/bsd-license.php[nova licença BSD] aplicada ao FreeBSD nos últimos anos é efetivamente uma afirmação de que você pode fazer qualquer coisa com o programa ou seu código fonte, mas você não tem nenhuma garantia e nenhum dos autores tem qualquer responsabilidade (basicamente, você não pode processar ninguém). Esta nova licença BSD destina-se a incentivar a comercialização de produtos. Qualquer código BSD pode ser vendido ou incluído em produtos proprietários, sem quaisquer restrições quanto à disponibilidade do seu código ou seu comportamento futuro. Não confunda a nova licença BSD com "domínio público". Enquanto um item no domínio público também é gratuito para todos, ele não possui um proprietário. [[origins-gpl]] == As origens da GPL Enquanto o futuro do Unix era tão confuso no final dos anos 80 e início dos anos 90, a GPL, um outro desenvolvimento com importantes considerações sobre licenciamento, surgiu. Richard Stallman, o desenvolvedor do Emacs, era membro da equipe do MIT quando seu laboratório mudou de sistemas domésticos para sistemas proprietários. Stallman ficou chateado quando descobriu que não podia adicionar legalmente pequenas melhorias ao sistema. (Muitos dos colegas de trabalho de Stallman tinham saído para formar duas empresas com base em software desenvolvido no MIT e licenciado pelo MIT; parece ter havido desacordo sobre o acesso ao código-fonte desse software). Stallman criou uma alternativa para a licença de software comercial e a chamou de GPL, ou "GNU Public License". Ele também fundou uma fundação sem fins lucrativos, a http://www.fsf.org[Free Software Foundation] (FSF), que pretendia desenvolver um sistema operacional completo, incluindo todos os softwares associados, e que não estaria sujeito a uma licença proprietária. Este sistema foi chamado de GNU, que significa "GNU is Not Unix". A GPL foi projetada para ser o oposto da licença proprietária padrão. Para este fim, quaisquer modificações que eram feitas a um programa GPL tinham que ser devolvidas à comunidade GPL (exigindo que o código fonte do programa fosse disponibilizado para o usuário) e que qualquer programa que utilizar ou linkar com código GPL, teria que estar sob a GPL. A GPL pretendia impedir que o software se tornasse proprietário. Como o último parágrafo da GPL afirma: "This General Public License does not permit incorporating your program into proprietary programs."<> A http://www.opensource.org/licenses/gpl-license.php[GPL] é uma licença complexa, então aqui estão algumas regras básicas ao usar a GPL: * você pode cobrar o quanto quiser para distribuir, dar suporte ou documentar o software, mas não pode vender o software em si. * a regra básica indica que, se um código fonte GPL for necessário para um programa compilar, então o programa deve estar sob a GPL. Linkar estaticamente a uma biblioteca GPL requer que um programa esteja sob a GPL. * a GPL exige que quaisquer patentes associadas ao software GPL sejam licenciadas para uso livre de todos. * simplesmente agregar softwares juntos, como quando vários programas são colocados em um disco, não conta como inclusão de programas GPL em programas não-GPL. * o que se resulta de um programa não conta como um trabalho derivado. Isso permite que o compilador gcc seja utilizado em ambientes comerciais sem problemas legais. * como o kernel do Linux está sob a GPL, qualquer código estaticamente linkado ao kernel do Linux deve ser GPL. Este requisito pode ser contornado ao linkar dinamicamente módulos carregáveis do kernel. Isso permite que as empresas distribuam drivers binários, mas geralmente tem a desvantagem de que eles só funcionarão para versões específicas do kernel do Linux. Devido em parte à sua complexidade, em muitas partes do mundo hoje as legalidades da GPL estão sendo ignoradas em relação ao Linux e softwares relacionados. As ramificações de longo prazo por causa disso não são claras. [[origins-lgpl]] == As origens do Linux e da LGPL Enquanto as guerras comerciais do Unix se intensificavam, o kernel do Linux foi desenvolvido como um clone do PC Unix. Linus Torvalds credita a existência do compilador GNU C e das ferramentas GNU associadas pela existência do Linux. Ele colocou o kernel do Linux sob a GPL. Lembre-se de que a GPL requer que qualquer software que seja estaticamente linkado a um código GPL, também seja colocado sob a GPL. O código fonte desse software deve ser disponibilizado ao usuário do programa. O link dinâmico, no entanto, não é considerado uma violação da GPL. A pressão para colocar aplicativos proprietários no Linux tornou-se esmagadora. Tais aplicativos geralmente precisavam se linkar a bibliotecas do sistema. Isso resultou em uma versão modificada da GPL chamada http://www.opensource.org/licenses/lgpl-license.php[LGPL] ("Library", e depois renomeado para "Lesser", GPL). A LGPL permite que o código proprietário faça link com à biblioteca GNU C, glibc. Você não precisa liberar o código fonte que foi linkado dinamicamente a uma biblioteca LGPL. Se você linkar estaticamente uma aplicação com a glibc, o que geralmente é necessário em sistemas embarcados, não será possível manter seu aplicativo proprietário, isto é, o código fonte deve ser liberado. Tanto a GPL quanto a LGPL requerem que qualquer software sob suas licenças liberem quaisquer modificações no código fonte. [[orphaning]] == Licenças Open Source e o Problema dos Softwares Orfãos Um problema sério associado ao software proprietário é conhecido como "orphaning". Isso ocorre quando um simples negócio falha ou quando uma mudança na estratégia de um produto faz com que uma cadeia de sistemas e empresas que dependiam deste produto, também falhem por motivos que estão fora de seus controles. Décadas de experiência mostraram que o tamanho ou o sucesso momentâneo de um fornecedor de software não é uma garantia de que seu software permanecerá disponível, pois as condições e estratégias atuais do mercado podem mudar rapidamente. A GPL tenta impedir o software órfão cortando o link para a propriedade intelectual proprietária. Uma licença BSD concede a uma pequena empresa o equivalente a um software-in-escrow sem quaisquer complicações ou custos legais. Se um programa licenciado pela BSD se torna órfão, uma empresa pode simplesmente assumir, de maneira proprietária, o programa do qual eles são dependentes. Uma situação ainda melhor ocorre quando uma base de código BSD é mantida por um pequeno consórcio informal, uma vez que o processo de desenvolvimento não depende da sobrevivência de uma única empresa ou de uma linha de produtos. A capacidade de sobrevivência da equipe de desenvolvimento quando eles estão mentalmente seguros é muito mais importante do que a simples disponibilidade física do código-fonte. [[license-cannot]] == O que uma licença não pode fazer Nenhuma licença pode garantir disponibilidade futura do software. Embora um detentor de direitos autorais possa tradicionalmente mudar os termos de um direito autoral a qualquer momento, a presunção na comunidade BSD é de que tal tentativa simplesmente faz com que o código fonte seja derivado (fork). A GPL proíbe explicitamente a revogação da licença. Ocorreu no entanto, que uma empresa (Mattel) comprou um copyright GPL (cphack), e revogou todo o direito autoral, foi a tribunal e conseguiu prevalecer <>. Ou seja, eles revogaram legalmente toda a distribuição e todos os trabalhos derivados com base nos direitos autorais. Se isso pode acontecer com uma distribuição maior e mais dispersa, fica uma questão em aberto; Há também alguma confusão sobre se o software estava realmente sob a GPL. Em outro exemplo, a Red Hat comprou a Cygnus, uma empresa de engenharia que havia assumido o desenvolvimento das ferramentas de compilação da FSF. A Cygnus foi capaz de fazer isso porque eles desenvolveram um modelo de negócios no qual eles vendiam suporte para o software GNU. Isso permitiu que eles empregassem cerca de 50 engenheiros e os orientassem na direção dos programas, contribuindo com a preponderância de modificações. Como afirma Donald Rosenberg, "projetos usando licenças como a GPL ... vivem sob constante ameaça de que alguém assuma o projeto produzindo uma versão melhor do código e fazendo isso mais rápido que os proprietários originais". <> [[gpl-advantages]] == Vantagens e Desvantagens da GPL Um motivo comum para usar a GPL é ao modificar ou criar extensões ao compilador gcc. Isso é particularmente apropriado quando se trabalha com CPUs especiais únicas em ambientes em que todos os custos de software provavelmente são considerados como despesas gerais, com expectativas mínimas de que outros usarão o compilador resultante. A GPL também é atraente para pequenas empresas que vendem CDs em um ambiente em que o "buy-low, sell-high" ainda pode dar ao usuário final um produto muito barato. Também é atraente para empresas que esperam sobreviver fornecendo várias formas de suporte técnico, incluindo documentação, para o mundo da propriedade intelectual GPL. Um uso menos divulgado e não intencional da GPL é que ela é muito favorável a grandes empresas que querem minar empresas de software. Em outras palavras, a GPL é bem adequada para uso como arma de marketing, reduzindo potencialmente o benefício econômico geral e contribuindo para o comportamento monopolista. A GPL pode representar um problema real para aqueles que desejam comercializar e lucrar com software. Por exemplo, a GPL aumenta a dificuldade que um estudante de pós-graduação terá em formar diretamente uma empresa para comercializar seus resultados de pesquisa, ou a dificuldade que um aluno terá em ingressar em uma empresa com a suposição de que um promissor projeto de pesquisa será comercializado. Para aqueles que precisam trabalhar com implementações linkadas estaticamente em vários modelos de software, a GPL é geralmente uma licença ruim, porque impede o uso de implementações proprietárias dos modelos. A GPL minimiza, assim, o número de programas que podem ser compilados usando o modelo GPL. A GPL tinha como objetivo não fornecer um mecanismo para desenvolver um padrão na engenharia de produtos proprietários. (Isso não se aplica a aplicativos Linux porque eles não usam links estáticos, em vez disso, usam uma trap-based API.) A GPL tenta fazer com que os programadores contribuam para um conjunto de programas em desenvolvimento, para então competir na distribuição e suporte deste conjunto. Essa situação não é realista para muitos dos padrões de sistema exigidos, que podem ser aplicados em ambientes amplamente diferentes, e que exigem personalização comercial ou integração com padrões legados sob licenças existentes (não-GPL). Os sistemas real-time usam frequentemente links estáticos, de modo que a GPL e a LGPL são definitivamente consideradas problemas potenciais por muitas empresas de sistemas embarcados. A GPL é uma tentativa de manter os trabalhos disponíveis, independentemente da demanda nos estágios de pesquisa e desenvolvimento. Isso maximiza os benefícios para pesquisadores e desenvolvedores, a um custo desconhecido para aqueles que se beneficiariam de uma distribuição mais ampla. A GPL foi projetada para impedir que os resultados de uma pesquisa sejam transferidos para produtos proprietários. Este passo é frequentemente considerado o último passo no pipeline tradicional de transferência de tecnologia e é geralmente o mais difícil mesmo sob as melhores circunstâncias; a GPL pretendia tornar isso impossível. [[bsd-advantages]] == Vantagens da licença BSD Uma licença de estilo BSD é uma boa opção para pesquisas de longa duração ou outros projetos que precisam de um ambiente de desenvolvimento que: * tem custo próximo a zero * irá evoluir durante um longo período de tempo * permite que qualquer pessoa mantenha a opção de comercializar os resultados finais com problemas legais mínimos. Esta consideração final pode muitas vezes ser a dominante, como foi quando o projeto Apache decidiu sua licença: "Este tipo de licença é ideal para promover o uso de um corpo de referência de código que implementa um protocolo para um serviço comum. Esta é outra razão pela qual a escolhemos para o grupo Apache - muitos de nós queriam que o HTTP sobrevivesse e se tornasse um verdadeiro padrão multipartidário, e não nos importaríamos nem um pouco se a Microsoft ou a Netscape escolhessem incorporar nosso mecanismo HTTP ou qualquer outro componente de nosso código em seus produtos, se isso ajudasse a manter o objetivo comum de manter o HTTP universal... Tudo isso significa que, estrategicamente falando, o projeto precisa manter ímpeto suficiente e que os participantes percebam um maior valor contribuindo com seu código para o projeto, mesmo código que teria valor se fosse mantido proprietário." Os desenvolvedores tendem a achar a licença BSD atrativa, pois ela mantém os problemas legais fora do caminho e permite que eles façam o que quiserem com o código. Em contraste, aqueles que esperam principalmente usar um sistema em vez de programá-lo, ou que esperam que outros evoluam o código, ou aqueles que não esperam ganhar a vida com seu trabalho associado ao sistema (como funcionários do governo), achem a GPL atraente, porque força o código desenvolvido por outros a ser dado a eles de volta e impede que os seus empregadores retenham os direitos autorais e, portanto, potencialmente "enterra" o problema de software órfão. Se você quiser forçar seus concorrentes a ajudá-lo, a GPL é atraente. Uma licença BSD não é simplesmente um presente. A pergunta "por que devemos ajudar nossos concorrentes ou deixá-los roubar nosso trabalho?" surge frequentemente em relação a uma licença BSD. Sob uma licença BSD, se uma empresa vier a dominar um nicho de produto que outros consideram estratégico, as outras empresas podem, com esforço mínimo, formar um mini consórcio visando restabelecer a paridade, contribuindo para uma variante BSD competitiva que aumente a competição e a justiça no mercado. Isso permite que cada empresa acredite que será capaz de lucrar com alguma vantagem que ela possa proporcionar, ao mesmo tempo em que contribui para a flexibilidade e eficiência econômica. Quanto mais rápido e fácil os membros cooperantes puderem fazer isso, maior sucesso eles terão. Uma licença BSD é essencialmente uma licença minimamente complicada que permite tal comportamento. Um efeito chave da GPL é fazer com que um sistema Open Source completo e competitivo seja amplamente disponibilizado ao custo de mídia, e isso é uma meta razoável. Uma licença no estilo BSD, em conjunto com consórcios ad-hoc de indivíduos, pode atingir essa meta sem destruir as premissas econômicas construídas em torno da implementação final do pipeline de transferência de tecnologia. [[recommendations]] == Recomendações Específicas para usar uma licença BSD * A licença BSD é preferível para a transferência de resultados de pesquisa de uma maneira que seja largamente implantada e que mais beneficie uma economia. Como tal, as agências de financiamento de pesquisa, como a NSF, ONR e DARPA, devem encorajar nas fases iniciais dos projetos de pesquisa financiados, a adoção de licenças de estilo BSD para software, dados, resultados e hardware aberto. Eles também devem incentivar a formação de padrões baseados em sistemas Open Source implementados e projetos Open Source em andamento. * A política do governo deve minimizar os custos e as dificuldades de passar da pesquisa para a implantação. Quando possível, os subsídios devem exigir que os resultados estejam disponíveis sob uma licença de estilo BSD amigável à comercialização. * Em muitos casos, os resultados de longo prazo de uma licença de estilo BSD refletem com mais precisão os objetivos proclamados na carta de pesquisa das universidades do que no que ocorre quando os resultados são protegidos por direitos autorais ou patenteados e sujeitos ao licenciamento universitário proprietário. Existem evidências casuais de que as universidades são financeiramente mais bem recompensadas a longo prazo, divulgando resultados de pesquisa e apelando para doações de ex-alunos de sucesso comercial. * As empresas há muito reconheceram que a criação de padrões de facto é uma técnica de marketing fundamental. A licença BSD serve bem a essa função se uma empresa tiver realmente uma vantagem exclusiva na evolução do sistema. A licença é legalmente atraente para o público mais amplo, enquanto a expertise da empresa garante o seu controle. Há momentos em que a GPL pode ser o veículo apropriado para uma tentativa de criar tal padrão, especialmente quando se tenta prejudicar ou cooptar outras pessoas. A GPL, no entanto, penaliza a evolução desse padrão, porque promove um conjunto em vez de um padrão comercialmente aplicável. O uso de tal conjunto constantemente sofre um aumento de problemas legais e comerciais. E pode não ser possível misturar padrões quando alguns estão sob a GPL e outros não. Um verdadeiro padrão técnico não deve obrigar a exclusão de outros padrões por razões não técnicas. * As empresas interessadas em promover um padrão em evolução, que pode se tornar o núcleo dos produtos comerciais de outras empresas, devem ter cuidado com a GPL. Independentemente da licença usada, o software resultante geralmente será transferido para quem realmente faz a maioria das alterações de engenharia e que mais entende o estado do sistema. A GPL simplesmente adiciona mais atrito legal ao resultado. * Grandes empresas, nas quais código Open Source é desenvolvido, devem estar cientes de que os programadores apreciam o Open Source porque ele deixa o software disponível para o funcionário quando ele mudar de empregador. Algumas empresas encorajam esse comportamento como uma vantagem de emprego, especialmente quando o software em questão não é diretamente estratégico. Trata-se, na verdade, de um benefício antecipado com possíveis custos de oportunidade perdidas, mas sem custos diretos. Incentivar os funcionários a trabalhar pela aclamação dos colegas fora da empresa é um benefício barato que uma uma empresa pode, por vezes, fornecer com desvantagem quase zero. * Pequenas empresas com projetos de software vulneráveis ao software órfão, devem tentar usar a licença BSD sempre que possível. Empresas de todos os portes devem considerar a formação de tais projetos Open Source quando for vantajoso manter mínimas as despesas legais e organizacionais associadas a um verdadeiro projeto Open Source de estilo BSD. * As organizações sem fins lucrativos devem participar de projetos Open Source sempre que possível. Para minimizar os problemas de engenharia de software, como a mistura de código sob diferentes licenças, as licenças no estilo BSD devem ser incentivadas. Desconfiar da GPL deve ser particularmente o caso de organizações sem fins lucrativos que interagem com o mundo de desenvolvimento. Em alguns locais onde a aplicação da lei se torna um exercício caro, a simplicidade da nova licença BSD, em comparação com a GPL, pode ser de considerável vantagem. [[conclusion]] == Conclusão Em contraste com a GPL, que é projetada para impedir a comercialização proprietária do código Open Source, a licença BSD impõe restrições mínimas sobre o comportamento futuro. Isso permite que o código BSD permaneça como código aberto ou se integre a soluções comerciais, à medida que as necessidades de um projeto ou empresa mudam. Em outras palavras, a licença BSD não se torna uma bomba-relógio legal em nenhum ponto do processo de desenvolvimento. Além disso, como a licença BSD não vem com a complexidade legal das licenças GPL ou LGPL, ela permite que desenvolvedores e empresas gastem seu tempo criando e promovendo um bom código, em vez de se preocupar se esse código viola algum licenciamento. [[addenda]] [bibliography] == Referências Bibliográficas * [[[one,1]]] http://www.gnu.org/licenses/gpl.html * [[[two,2]]] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ * [[[three,3]]] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, 2000. Quotes are from page 114, "Effects of the GNU GPL". * [[[four,4]]] In the "What License to Use?" section of http://www.oreilly.com/catalog/opensources/book/brian.html This whitepaper is a condensation of an original work available at http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm diff --git a/documentation/content/pt-br/articles/explaining-bsd/_index.adoc b/documentation/content/pt-br/articles/explaining-bsd/_index.adoc index cb76a33dc3..f8fbebfb0e 100644 --- a/documentation/content/pt-br/articles/explaining-bsd/_index.adoc +++ b/documentation/content/pt-br/articles/explaining-bsd/_index.adoc @@ -1,166 +1,166 @@ --- authors: - author: 'Greg Lehey' email: grog@FreeBSD.org description: 'Breve explicação sobre BSD' -tags: '["Explaining BSD", "BSD", "FreeBSD", "operating system"]' +tags: ["Explaining BSD", "BSD", "FreeBSD", "operating system"] title: 'Explicando o BSD' -trademarks: '["freebsd", "amd", "apple", "intel", "linux", "opengroup", "sun", "unix", "general"]' +trademarks: ["freebsd", "amd", "apple", "intel", "linux", "opengroup", "sun", "unix", "general"] --- = Explicando o BSD :doctype: article :toc: macro :toclevels: 1 :icons: font :sectnums: :sectnumlevels: 6 :source-highlighter: rouge :experimental: :toc-title: Índice :part-signifier: Parte :chapter-signifier: Capítulo :appendix-caption: Apêndice :table-caption: Tabela :figure-caption: Figura :example-caption: Exemplo [.abstract-title] Resumo No mundo do código aberto, a palavra "Linux" é praticamente sinônimo de "Sistema Operacional", mas ele não é o único sistema operacional UNIX(R) de código aberto. Então, qual é o segredo? Por que o BSD não é mais conhecido? Este artigo aborda esta e outras questões. Ao longo deste artigo, as diferenças entre BSD e Linux serão destacadas __desta forma__. ''' toc::[] [[what-is-bsd]] == O que é o BSD? BSD é a sigla para "Berkeley Software Distribution". É o nome do código fonte distribuído pela Universidade da Califórnia, Berkeley, que era originalmente uma extensão do UNIX(R) desenvolvido pela área de pesquisa da AT&T. Diversos projetos de sistemas operacionais de código aberto foram baseados em uma versão deste código, conhecido como 4.4BSD-Lite. Além disso, eles incluem vários pacotes de outros projetos de código aberto, com destaque para os do projeto GNU. O sistema operacional geralmente abrange: * O kernel BSD, que lida com o agendamento de processos, gerenciamento de memória, multi processamento simétrico (symmetric multi-processing ou SMP), drivers de dispositivos, etc. * A biblioteca C, a API base do sistema. + __A biblioteca C do BSD é baseada no código de Berkeley, não no projeto GNU.__ * Utilitários como shells, gerenciadores de arquivos, compiladores e linkers (conversores de arquivos compilados em executáveis). + __Alguns utilitários são derivados do projeto GNU, outros não são.__ * O sistema X Window, que gerencia a interface gráfica. + O sistema X Window usado na maioria das versões do BSD é mantido pelo http://www.X.org/[Projeto X.Org]. O FreeBSD permite ao usuário escolher a partir de uma variedade de ambientes de desktop, tais como o Gnome, KDE ou Xfce; e gerenciadores gráficos (gerenciadores de janelas) mais leves, como Openbox, Fluxbox ou Awesome. * Diversos outros programas e utilitários. [[what-a-real-unix]] == O que, um verdadeiro UNIX(R)? Os sistemas operacionais BSD não são cópias ou clones, mas sim derivações de código aberto do sistema operacional UNIX(R) da AT&T, que também é o ancestral do moderno UNIX(R) System V. Isto pode surpreendê-lo. Como isto é possível, uma vez que a AT&T nunca liberou seu código como código aberto? É verdade que o UNIX(R) da AT&T não é um sistema de código aberto e no sentido de licenciamento o BSD definitivamente _não é_ UNIX(R), mas por outro lado a AT&T importou fontes de outros projetos, principalmente do Grupo de Pesquisa de Ciências da Computação (Computer Sciences Research Group ou CSRG) da Universidade da Califórnia em Berkeley, CA. A partir de 1976, o CSRG começou a liberar fitas de seu software, chamando ele de _Berkeley Software Distribution_ ou __BSD__. As primeiras distribuições do BSD consistiam principalmente em programas de usuários mas isso mudou radicalmente quando o CSRG firmou um contrato com a Agência de Pesquisa de Projetos de Defesa Avançados (Defense Advanced Research Projects Agency ou DARPA) para atualizar os protocolos de comunicação de sua rede, a ARPANET. Os novos protocolos ficaram conhecidos como __Internet Protocols__, posteriormente _TCP/IP_ em virtude dos protocolos mais importantes. A primeira implementação amplamente distribuída foi parte do 4.2BSD, em 1982. Durante a década de 80 surgiram muitas empresas produtoras de estações de trabalho. A maioria preferiu licenciar o UNIX(R) ao invés de desenvolver seus próprios sistemas operacionais. Em particular, a Sun Microsystems licenciou o UNIX(R) e implementou uma versão do 4.2BSD, a qual eles chamaram de SunOS(TM). Quando a própria AT&T começou a comercializar o UNIX(R), eles começaram com uma implementação de certa forma simples chamada de System III, que logo transformou-se no System V. O código base do System V não incluía comunicação em rede, então todas as implementações incluíram software adicional do BSD, inclusive o software TCP/IP, e também utilitários como o shell _csh_ e o editor __vi__. Estes aprimoramentos ficaram conhecidos como __Berkeley Extensions__. As fitas do BSD continham código fonte da AT&T e portanto necessitavam da licença dos fontes do UNIX(R). Por volta de 1990, os recursos financeiros do CSRG's estavam acabando, e ele foi encerrado. Alguns membros do grupo decidiram liberar o código do BSD, que era código aberto, sem o código proprietário da AT&T. Isso finalmente aconteceu com a fita __Networking Tape 2__, também conhecida como __Net/2__. O Net/2 não era um sistema operacional completo: faltava cerca de 20% do código fonte do kernel. Um dos membros do CSRG, William F. Jolitz, escreveu o código que faltava e o liberou no início de 1992 sob o nome de __386BSD__. Ao mesmo tempo, um outro grupo de ex integrantes do CSRG formaram uma empresa comercial chamada http://www.bsdi.com/[Berkeley Software Design Inc.] e liberaram uma versão beta de um sistema operacional chamado http://www.bsdi.com/[BSD/386], o qual era baseado nos mesmos fontes. Mais tarde o nome deste sistema operacional foi alterado para BSD/OS. O 386BSD nunca chegou a ser um sistema operacional estável. Ao invés disso, dois outros projetos surgiram a partir dele em 1993: http://www.NetBSD.org/[NetBSD] e link:www.FreeBSD.org[FreeBSD]. Este dois projetos divergiam originalmente na questão da espera pelas melhorias no 386BSD: o pessoal do NetBSD iniciou no começo daquele ano, e a primeira versão do FreeBSD não ficou pronta antes do final do ano. Neste meio tempo o código base ficou diferente um do outro o suficiente para tornar difícil sua fusão. Além disso, os projetos tinham objetivos diferentes, como veremos adiante. Em 1996, o http://www.OpenBSD.org/[OpenBSD] surgiu a partir do NetBSD, e em 2003, o http://www.dragonflybsd.org/[DragonFlyBSD] surgiu a partir do FreeBSD. [[why-is-bsd-not-better-known]] == Por que o BSD não é mais conhecido? Por uma série de razões, o BSD é relativamente desconhecido: . Os desenvolvedores do BSD estão mais interessados em aprimorar o seu código do que em divulgá-lo. . Grande parte da popularidade do Linux se deve a fatores externos ao projeto Linux, como a mídia e empresas que foram criadas para prover serviços Linux. Até pouco tempo atrás os BSD de código aberto não tinham este tipo de proposta. . Em 1992 a AT&T processou a http://www.bsdi.com/[BSDI], que comercializava o BSD/386, alegando que o produto continha código protegido por direitos autorais da AT&T. O caso foi encerrado fora dos tribunais em 1994, mas o fantasma do litígio continua assombrando. Em março de 2000 um artigo publicado na web afirma que o caso foi "recentemente encerrado". + Um detalhe que o processo civil não deixa claro refere-se ao nome: nos anos 80 o BSD era conhecido como "BSD UNIX(R)". Com a eliminação dos últimos vestígios do código da AT&T do BSD, ele também perdeu o direito ao nome UNIX(R). Desta forma você verá referências em livros para o "sistema operacional 4.3BSD UNIX(R)" e o "sistema operacional 4.4BSD". [[comparing-bsd-and-linux]] == Comparando BSD e Linux Então, qual é realmente a diferença entre, digamos, o Debian Linux e o FreeBSD? Para a maioria dos usuários, a diferença é surpreendentemente pequena: Ambos são sistemas operacionais estilo UNIX(R). Ambos são desenvolvidos por projetos não comerciais (isto não se aplica a diversas outras distribuições Linux, é claro). Nas próximas sessões vamos olhar para o BSD e compará-lo ao Linux. As descrições se aplicam principalmente ao FreeBSD, que representa aproximadamente 80% das instalações de BSD, mas as diferenças do NetBSD, OpenBSD e Dragon FlyBSD são pequenas. === Quem é o dono do BSD? Nenhuma pessoa ou empresa é proprietária do BSD. Ele é criado e distribuído por uma comunidade de colaboradores altamente técnica e comprometida espalhada ao redor do mundo. Alguns dos componentes do BSD são projetos de código aberto com seus próprios licenciamentos e gerenciados por diferentes mantenedores. === Como o BSD é desenvolvido e atualizado? Os kernels dos BSDs são desenvolvidos e atualizados seguindo o modelo de desenvolvimento Open Source. Cada projeto mantém uma _árvore com código fonte_ publicamente acessível, que contém todo o código fonte do projeto, incluindo documentação e outros arquivos incidentais. Os usuários podem obter uma cópia completa de qualquer versão. Um grande número de desenvolvedores por todo o mundo contribuem com melhorias ao BSD. Eles estão divididos em três categorias: * _Contributors_ escrevem código ou documentação. Eles não têm permissão para adicionar código diretamente ao repositório principal de código fonte. Para que seu código seja incluído no sistema, ele deve ser revisado e verificado por um desenvolvedor registrado, conhecido como __committer__. * _Committers_ são desenvolvedores com acesso de gravação no repositório principal de código fonte. Para se tornar um committer, um indivíduo deve mostrar habilidade na área em que está ativo. + Fica a critério do bom senso individual de cada committer a decisão se eles devem obter ou não um consenso antes de enviar alterações para o repositório de código fonte. Em geral, um committer experiente pode fazer alterações que sejam inquestionavelmente corretas sem obter consenso. Por exemplo, um committer do projeto de documentação pode corrigir erros tipográficos ou gramaticais sem revisão. Por outro lado, espera-se que os desenvolvedores que realizam mudanças complexas ou muito extensas enviem suas alterações para revisão antes de enviá-las para o repositório de código fonte. Em casos extremos, um membro do Core Team com uma função tal como a de arquiteto principal, pode ordenar que as alterações sejam removidas do repositório, num processo conhecido como _backing out_. Todos os committers recebem emails que descrevem cada commit individual, portanto não é possível enviar alterações para o repositório de código fonte em segredo. * O _Core Team_. O FreeBSD e o NetBSD possuem uma equipe principal (Core team) que gerenciam o projeto. As equipes principais evoluíram ao longo dos projeto e a sua função nem sempre está bem definida. Não é necessário ser um desenvolvedor para ser um membro da equipe principal, embora isto seja normal. As regras para a equipe principal variam de um projeto para o outro, mas no geral elas têm mais voz ativa sobre a direção do projeto do que os demais membros tem. Esse arranjo difere do Linux de várias maneiras: . Ninguém controla o conteúdo do sistema. Na prática, essa diferença é superestimada, uma vez que o arquiteto principal pode exigir que o código seja removido ou substituído, e mesmo no projeto Linux, várias pessoas podem fazer alterações. . Por outro lado, _existe_ um repositório central, um lugar único no qual você pode encontrar todo o código fonte do sistema operacional, incluindo todas as versões mais antigas. . Os projetos BSDs mantêm todo o "Sistema Operacional", e não apenas o kernel. Essa distinção é apenas marginalmente útil: nem o BSD e nem o Linux são úteis sem aplicativos. Os aplicativos usados no BSD são frequentemente os mesmos aplicativos usados no Linux. . Como resultado da manutenção formal de um único repositório SVN com o código fonte, o desenvolvimento do BSD é claro e é possível acessar qualquer versão do sistema por número de release ou por data. O SVN também permite atualizações incrementais no sistema: por exemplo, o repositório do FreeBSD é atualizado cerca de 100 vezes por dia. A maioria dessas mudanças é pequena. === Releases do BSD O FreeBSD, o NetBSD e o OpenBSD fornecem o sistema em três diferentes "releases". Como no Linux, os releases recebem um número como 1.4.1 ou 3.5. Além disso, o número da versão tem um sufixo indicando sua finalidade: . A versão de desenvolvimento do sistema é chamada de _CURRENT_. O FreeBSD atribui um número a CURRENT, por exemplo, FreeBSD 5.0-CURRENT. O NetBSD usa um esquema de nomenclatura ligeiramente diferente e acrescenta um sufixo de uma única letra que indica mudanças nas interfaces internas, por exemplo, o NetBSD 1.4.3G. O OpenBSD não atribui um número ("OpenBSD-current"). Todo novo desenvolvimento no sistema entra neste branch. . Em intervalos regulares, entre duas e quatro vezes por ano, os projetos lançam uma versão _RELEASE_ do sistema, a qual é disponibilizada por meio de CD-ROMs e por meio de download gratuito em sites FTP, por exemplo, OpenBSD 2.6-RELEASE ou NetBSD 1.4-RELEASE. A versão RELEASE destina-se a usuários finais e é a versão normal do sistema. O NetBSD também fornece _versões de correção_ (Patch Releases) com um terceiro dígito, por exemplo, o NetBSD 1.4.2. . A medida que os erros são encontrados em uma versão RELEASE, eles são corrigidos e as correções são adicionadas ao repositório SVN. No FreeBSD, a versão resultante é chamada de _STABLE_, enquanto no NetBSD e OpenBSD continua sendo chamada de versão RELEASE. Novos recursos menores também podem ser adicionados a essa branch após um período de teste na branch CURRENT. Patches de segurança e outras correções de bugs importantes também são aplicadas a todas as versões RELEASE suportadas. _Por outro lado, o Linux mantém duas árvores de código separadas: a versão estável e a versão de desenvolvimento. Versões estáveis têm um número de versão menor par, como por exemplo 2.0, 2.2 ou 2.4. Versões de desenvolvimento têm um número de versão menor ímpar, como por exemplo 2.1, 2.3 ou 2.5. Em cada caso, o número é seguido por um outro número que designa a release exata. Além disso, cada fornecedor adiciona seus próprios programas e utilitários de área de usuário, portanto, o nome da distribuição também é importante. Cada fornecedor de distribuição também atribui números de versão à distribuição, portanto, uma descrição completa seria algo como "TurboLinux 6.0 com kernel 2.2.14 "._ === Quais versões do BSD estão disponíveis? Em contraste com as numerosas distribuições do Linux, existem apenas quatro grandes distribuições BSD de código aberto. Cada projeto BSD mantém seu próprio repositório de código fonte e o seu próprio kernel. Porém na prática, parece haver menos divergências do código entre os projetos BSD do que no Linux. É difícil categorizar os objetivos de cada projeto: as diferenças são muito subjetivas. Basicamente, * O FreeBSD visa o alto desempenho e a facilidade de uso pelos usuários finais, e é um dos favoritos dos provedores de conteúdo da web. Ele pode ser executado em link:www.FreeBSD.org/platforms/[diversas plataformas] e tem significativamente mais usuários do que os outros projetos. * O NetBSD visa a máxima portabilidade: "é claro que roda o NetBSD". Ele pode ser executado em diversas plataformas de hardware, de palmtops até grandes servidores, e até mesmo já foi usado em missões espaciais da NASA. É uma escolha particularmente boa para rodar em hardware antigo que não seja Intel(R). * O OpenBSD visa a segurança e a pureza de código: ele usa uma combinação do conceito de código aberto ao de revisões rigorosas de código para criar um sistema que seja comprovadamente correto, tornando-o a escolha preferida de organizações preocupadas com segurança, tais como bancos, bolsas de valores e departamentos do governo dos EUA. Tal como o NetBSD, ele pode ser executado em várias plataformas. * O DragonFlyBSD tem como objetivo o alto desempenho e a escalabilidade sob todos os aspectos, desde um sistema de um único nó até um sistema altamente clusterizado. O DragonFlyBSD tem várias metas técnicas de longo prazo, mas o foco está em fornecer uma infraestrutura compatível com SMP que seja fácil de entender, manter e desenvolver. Também existem dois sistemas operacionais BSD UNIX(R) que não são de código aberto, o BSD/OS e Mac OS(R) X da Apple: * O BSD/OS foi o mais antigo dos sistemas derivados do 4.4BSD. Não era um sistema de código aberto, embora as licenças do código-fonte estivessem disponíveis a um custo relativamente baixo. Assemelhava-se ao FreeBSD de várias maneiras. Dois anos após a aquisição da BSDi pela Wind River Systems, o BSD/OS não conseguiu sobreviver como um produto independente. O suporte e o código-fonte ainda podem estar disponíveis por parte da Wind River, mas todo desenvolvimento novo está focado no sistema operacional embarcado VxWorks. * O http://www.apple.com/macosx/server/[Mac OS(R) X] é a versão mais recente do sistema operacional para os equipamentos Mac(R) da Apple(R). O núcleo BSD deste sistema operacional, http://developer.apple.com/darwin/[Darwin], está disponível como um sistema operacional de código aberto totalmente funcional para computadores x86 e PPC. No entanto, o sistema gráfico Aqua/Quartz e muitos outros aspectos proprietários do Mac OS(R) X continuam fechados. Vários desenvolvedores do Darwin também são committers do FreeBSD, e vice-versa. === Como a licença BSD difere da licença GNU Publica? O Linux está disponível sob a http://www.fsf.org/copyleft/gpl.html[Licença Pública Geral GNU] (GPL), que é projetada para eliminar o software de código fechado. Em particular, qualquer trabalho derivado de um produto lançado sob a GPL também deve ser fornecido com o código fonte, se solicitado. Por outro lado, a http://www.opensource.org/licenses/bsd-license.html[licença BSD] é menos restritiva: é permitida a distribuição somente dos binários. O que é particularmente atraente para aplicativos embarcados. === O que mais eu deveria saber? Como menos aplicativos estão disponíveis para o BSD do que para o Linux, os desenvolvedores do BSD criaram um pacote de compatibilidade com o Linux, o qual permite que os programas Linux sejam executados sob o BSD. O pacote inclui tanto as modificações do kernel, necessárias para executar corretamente as chamadas do sistema Linux e quanto os arquivos de compatibilidade do Linux, como a biblioteca C. Não há diferença perceptível na velocidade de execução entre um aplicativo Linux em execução em uma máquina Linux nativa e um aplicativo Linux em execução em uma máquina BSD, contanto que ambas tenham o mesmo hardware. A natureza do BSD de ser um sistema em que tudo é provido por "um único fornecedor" significa que as atualizações são muito mais fáceis de se lidar do que frequentemente ocorre no caso no Linux. O BSD lida com as atualizações das versões das bibliotecas fornecendo módulos de compatibilidade para as versões anteriores, portanto, é possível executar binários bastante antigos sem problemas. === Qual devo usar, BSD ou Linux? O que tudo isso significa na prática? Quem deve usar o BSD, quem deve usar o Linux? Esta é uma pergunta muito difícil de responder. Aqui estão algumas diretrizes: * "Se não está quebrado, não conserte": Se você já usa um sistema operacional de código aberto e está feliz com ele, provavelmente não existe nenhuma razão para mudar. * Os sistemas BSD, em particular o FreeBSD, podem ter um desempenho notavelmente superior ao Linux. Mas isto não é uma verdade absoluta. Em muitos casos, há pouca ou nenhuma diferença no desempenho. E em alguns casos, o Linux pode ter um desempenho melhor que o FreeBSD. * Em geral, os sistemas BSD têm a reputação de oferecer uma melhor confiabilidade, principalmente como resultado de ter uma base de código mais madura. * Os projetos BSD têm uma reputação melhor pela qualidade e completude da sua documentação. Os vários projetos de documentação visam fornecer uma documentação que é atualizada constantemente, disponibilizada em muitos idiomas, e que cobre todos os aspectos do sistema. * A licença BSD pode ser mais atraente que a GPL. * O BSD pode executar a maioria dos binários do Linux, já o Linux por sua vez não pode executar binários do BSD. Muitas implementações do BSD também podem executar binários de outros sistemas semelhantes ao UNIX(R). Como resultado, pode ser mais fácil migrar de outros sistemas para o BSD do que seria migrar para o Linux. === Quem fornece suporte, serviços e treinamento para o BSD? A BSDi / http://www.freebsdmall.com[FreeBSD Mall, Inc.] fornece contratos de suporte para o FreeBSD já há quase uma década. Além disso, o website de cada um dos projetos possui uma lista de consultores disponíveis para contratação: link:www.FreeBSD.org/commercial/consult_bycat/[FreeBSD], http://www.netbsd.org/gallery/consultants.html[NetBSD], e http://www.openbsd.org/support.html[OpenBSD].