  Por que voce deve usar uma licenc,a de estilo BSD em seu Projeto Open Source

  Bruce Montague

   <brucem@alumni.cse.ucsc.edu>
             

   Revisao: 519de9f236

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium,
   Pentium, and Xeon are trademarks or registered trademarks of Intel
   Corporation or its subsidiaries in the United States and other countries.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2020-03-15 16:00:19 +0000 por Danilo G. Baio.
   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Introduc,ao

   2. Uma Breve Historia do Open Source

   3. Unix de uma Perspectiva de Licenciamento BSD

   4. O Estado Atual das Licenc,as FreeBSD e BSD

   5. As origens da GPL

   6. As origens do Linux e da LGPL

   7. Licenc,as Open Source e o Problema dos Softwares Orfaos

   8. O que uma licenc,a nao pode fazer

   9. Vantagens e Desvantagens da GPL

   10. Vantagens da licenc,a BSD

   11. Recomendac,oes Especificas para usar uma licenc,a BSD

   12. Conclusao

   13. Referencias Bibliograficas

1. Introduc,ao

   Este documento apresenta argumentos para a utilizac,ao de uma licenc,a de
   estilo BSD para software e dados; especificamente recomenda utilizar uma
   licenc,a de estilo BSD no lugar de uma GPL. Tambem pode ser lido como uma
   introduc,ao e resumo das licenc,as de Projeto Open Source, BSD versus GPL.

2. Uma Breve Historia do Open Source

   Muito antes do termo "Open Source" ser utilizado, o software era
   desenvolvido por associac,oes livres de programadores e os softwares eram
   livremente trocados ou negociados. A partir do inicio dos anos 50,
   organizac,oes como a SHARE e a DECUS desenvolviam grande parte do software
   que as empresas de hardware empacotavam em suas ofertas. Naquela epoca, as
   empresas de computadores estavam no negocio 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 proprios 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 distribuido durante a vida util do produto. A ADR reteve a
   propriedade e pode controlar a revenda e a reutilizac,ao.

   Em 1969, o Departamento de Justic,a dos EUA acusou a IBM de destruir
   negocios e empresas com seu agrupamento de software livre e hardware IBM.
   Como resultado deste processo, a IBM separou seu software; isto e, os
   softwares tornaram-se produtos independentes e separados do hardware.

   Em 1968, a Informatics apresentou o primeiro software comercial
   revolucionario 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 licenc,a perpetua que agora e comum em toda a
   industria de computadores, onde a propriedade do software nunca e
   transferida para o cliente.

3. Unix de uma Perspectiva de Licenciamento BSD

   A AT&T, que detinha a implementac,ao original do Unix, era um monopolio
   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 instituic,oes academicas pelo prec,o da
   midia.

   As universidades adotaram rapidamente o Unix depois da divulgac,ao de sua
   disponibilidade em uma conferencia de Sistema Operacional. Foi
   extremamente util o Unix rodar no PDP-11, um computador de 16 bits muito
   acessivel na epoca, e que foi codificado em uma linguagem de alto nivel,
   que era comprovadamente boa para a programac,ao de sistemas. O DEC PDP-11
   tinha, na verdade, uma interface de hardware aberta, projetada para tornar
   mais facil para os clientes escreverem seus proprios sistemas
   operacionais, o que era comum. O famoso fundador da DEC, Ken Olsen,
   proclamou que "o software vem do ceu quando voce tem um bom hardware".

   O autor do Unix, Ken Thompson, retornou `a Universidade da California de
   Berkeley (UCB) em 1975, e lecionou sobre o kernel linha por linha. Isso
   acabou resultando em um sistema evoluido conhecido como BSD (Berkeley
   Standard Distribution). A UCB converteu o Unix em 32 bits, adicionou
   memoria virtual e implementou a stack TCP/IP, a qual foi essencialmente
   necessaria para a construc,ao da Internet. A UCB disponibilizou o BSD pelo
   custo da midia, e isso ficou conhecido como "a licenc,a BSD". Um cliente
   comprava o Unix da AT&T e depois comprava uma fita BSD da UCB.

   Em meados da decada de 80, um processo anti-trust governamental contra a
   AT&T resultou no seu desmembramento. A AT&T ainda possuia o Unix e a
   partir daquele momento podia vende-lo. Entao a AT&T embarcou em um
   esforc,o agressivo de licenciamento e a maioria dos Unixes comerciais da
   epoca tornaram-se derivac,oes do Unix AT&T.

   No inicio dos anos 90, a AT&T processou a UCB por violac,oes de licenc,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 periodo, alguns programadores da UCB embarcaram
   em um projeto para reescrever todos os codigos AT&T que estavam associados
   ao BSD. Este projeto resultou em um sistema chamado BSD 4.4-lite (lite
   porque nao era um sistema completo; faltavam 6 arquivos-chave AT&T).

   Uma longa serie de artigos foram publicados um pouco depois disso na
   revista Dr. Dobbs, que descreviam uma versao do Unix derivada do BSD para
   PC 386, na qual os 6 arquivos que estavam faltando no 4.4 lite foram
   substituidos por arquivos de licenc,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 estao atualmente em uso.

   Em meados da decada de 90, a Novell comprou os direitos do Unix da AT&T e
   um acordo (entao secreto) foi fechado para encerrar o processo. A UCB logo
   encerrou seu suporte para o BSD.

4. O Estado Atual das Licenc,as FreeBSD e BSD

   A chamada nova licenc,a BSD aplicada ao FreeBSD nos ultimos anos e
   efetivamente uma afirmac,ao de que voce pode fazer qualquer coisa com o
   programa ou seu codigo fonte, mas voce nao tem nenhuma garantia e nenhum
   dos autores tem qualquer responsabilidade (basicamente, voce nao pode
   processar ninguem). Esta nova licenc,a BSD destina-se a incentivar a
   comercializac,ao de produtos. Qualquer codigo BSD pode ser vendido ou
   incluido em produtos proprietarios, sem quaisquer restric,oes quanto `a
   disponibilidade do seu codigo ou seu comportamento futuro.

   Nao confunda a nova licenc,a BSD com "dominio publico". Enquanto um item
   no dominio publico tambem e gratuito para todos, ele nao possui um
   proprietario.

5. As origens da GPL

   Enquanto o futuro do Unix era tao confuso no final dos anos 80 e inicio
   dos anos 90, a GPL, um outro desenvolvimento com importantes
   considerac,oes sobre licenciamento, surgiu.

   Richard Stallman, o desenvolvedor do Emacs, era membro da equipe do MIT
   quando seu laboratorio mudou de sistemas domesticos para sistemas
   proprietarios. Stallman ficou chateado quando descobriu que nao podia
   adicionar legalmente pequenas melhorias ao sistema. (Muitos dos colegas de
   trabalho de Stallman tinham saido para formar duas empresas com base em
   software desenvolvido no MIT e licenciado pelo MIT; parece ter havido
   desacordo sobre o acesso ao codigo-fonte desse software). Stallman criou
   uma alternativa para a licenc,a de software comercial e a chamou de GPL,
   ou "GNU Public License". Ele tambem fundou uma fundac,ao sem fins
   lucrativos, a Free Software Foundation (FSF), que pretendia desenvolver um
   sistema operacional completo, incluindo todos os softwares associados, e
   que nao estaria sujeito a uma licenc,a proprietaria. Este sistema foi
   chamado de GNU, que significa "GNU is Not Unix".

   A GPL foi projetada para ser o oposto da licenc,a proprietaria padrao.
   Para este fim, quaisquer modificac,oes que eram feitas a um programa GPL
   tinham que ser devolvidas `a comunidade GPL (exigindo que o codigo fonte
   do programa fosse disponibilizado para o usuario) e que qualquer programa
   que utilizar ou linkar com codigo GPL, teria que estar sob a GPL. A GPL
   pretendia impedir que o software se tornasse proprietario. Como o ultimo
   paragrafo da GPL afirma:

   "This General Public License does not permit incorporating your program
   into proprietary programs."[1]

   A GPL e uma licenc,a complexa, entao aqui estao algumas regras basicas ao
   usar a GPL:

     * voce pode cobrar o quanto quiser para distribuir, dar suporte ou
       documentar o software, mas nao pode vender o software em si.

     * a regra basica indica que, se um codigo fonte GPL for necessario para
       um programa compilar, entao 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 varios programas
       sao colocados em um disco, nao conta como inclusao de programas GPL em
       programas nao-GPL.

     * o que se resulta de um programa nao conta como um trabalho derivado.
       Isso permite que o compilador gcc seja utilizado em ambientes
       comerciais sem problemas legais.

     * como o kernel do Linux esta sob a GPL, qualquer codigo estaticamente
       linkado ao kernel do Linux deve ser GPL. Este requisito pode ser
       contornado ao linkar dinamicamente modulos carregaveis do kernel. Isso
       permite que as empresas distribuam drivers binarios, mas geralmente
       tem a desvantagem de que eles so funcionarao para versoes especificas
       do kernel do Linux.

   Devido em parte `a sua complexidade, em muitas partes do mundo hoje as
   legalidades da GPL estao sendo ignoradas em relac,ao ao Linux e softwares
   relacionados. As ramificac,oes de longo prazo por causa disso nao sao
   claras.

6. 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
   existencia do compilador GNU C e das ferramentas GNU associadas pela
   existencia 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 codigo GPL, tambem seja colocado sob a GPL. O codigo fonte
   desse software deve ser disponibilizado ao usuario do programa. O link
   dinamico, no entanto, nao e considerado uma violac,ao da GPL. A pressao
   para colocar aplicativos proprietarios no Linux tornou-se esmagadora. Tais
   aplicativos geralmente precisavam se linkar a bibliotecas do sistema. Isso
   resultou em uma versao modificada da GPL chamada LGPL ("Library", e depois
   renomeado para "Lesser", GPL). A LGPL permite que o codigo proprietario
   fac,a link com `a biblioteca GNU C, glibc. Voce nao precisa liberar o
   codigo fonte que foi linkado dinamicamente a uma biblioteca LGPL.

   Se voce linkar estaticamente uma aplicac,ao com a glibc, o que geralmente
   e necessario em sistemas embarcados, nao sera possivel manter seu
   aplicativo proprietario, isto e, o codigo fonte deve ser liberado. Tanto a
   GPL quanto a LGPL requerem que qualquer software sob suas licenc,as
   liberem quaisquer modificac,oes no codigo fonte.

7. Licenc,as Open Source e o Problema dos Softwares Orfaos

   Um problema serio associado ao software proprietario e conhecido como
   "orphaning". Isso ocorre quando um simples negocio falha ou quando uma
   mudanc,a na estrategia de um produto faz com que uma cadeia de sistemas e
   empresas que dependiam deste produto, tambem falhem por motivos que estao
   fora de seus controles. Decadas de experiencia mostraram que o tamanho ou
   o sucesso momentaneo de um fornecedor de software nao e uma garantia de
   que seu software permanecera disponivel, pois as condic,oes e estrategias
   atuais do mercado podem mudar rapidamente.

   A GPL tenta impedir o software orfao cortando o link para a propriedade
   intelectual proprietaria.

   Uma licenc,a BSD concede a uma pequena empresa o equivalente a um
   software-in-escrow sem quaisquer complicac,oes ou custos legais. Se um
   programa licenciado pela BSD se torna orfao, uma empresa pode simplesmente
   assumir, de maneira proprietaria, o programa do qual eles sao dependentes.
   Uma situac,ao ainda melhor ocorre quando uma base de codigo BSD e mantida
   por um pequeno consorcio informal, uma vez que o processo de
   desenvolvimento nao depende da sobrevivencia de uma unica empresa ou de
   uma linha de produtos. A capacidade de sobrevivencia da equipe de
   desenvolvimento quando eles estao mentalmente seguros e muito mais
   importante do que a simples disponibilidade fisica do codigo-fonte.

8. O que uma licenc,a nao pode fazer

   Nenhuma licenc,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 presunc,ao na comunidade BSD e de
   que tal tentativa simplesmente faz com que o codigo fonte seja derivado
   (fork).

   A GPL proibe explicitamente a revogac,ao da licenc,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 [2]. Ou seja,
   eles revogaram legalmente toda a distribuic,ao e todos os trabalhos
   derivados com base nos direitos autorais. Se isso pode acontecer com uma
   distribuic,ao maior e mais dispersa, fica uma questao em aberto; Ha tambem
   alguma confusao 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 compilac,ao da
   FSF. A Cygnus foi capaz de fazer isso porque eles desenvolveram um modelo
   de negocios no qual eles vendiam suporte para o software GNU. Isso
   permitiu que eles empregassem cerca de 50 engenheiros e os orientassem na
   direc,ao dos programas, contribuindo com a preponderancia de
   modificac,oes. Como afirma Donald Rosenberg, "projetos usando licenc,as
   como a GPL ... vivem sob constante ameac,a de que alguem assuma o projeto
   produzindo uma versao melhor do codigo e fazendo isso mais rapido que os
   proprietarios originais". [3]

9. Vantagens e Desvantagens da GPL

   Um motivo comum para usar a GPL e ao modificar ou criar extensoes ao
   compilador gcc. Isso e particularmente apropriado quando se trabalha com
   CPUs especiais unicas em ambientes em que todos os custos de software
   provavelmente sao considerados como despesas gerais, com expectativas
   minimas de que outros usarao o compilador resultante.

   A GPL tambem e atraente para pequenas empresas que vendem CDs em um
   ambiente em que o "buy-low, sell-high" ainda pode dar ao usuario final um
   produto muito barato. Tambem e atraente para empresas que esperam
   sobreviver fornecendo varias formas de suporte tecnico, incluindo
   documentac,ao, para o mundo da propriedade intelectual GPL.

   Um uso menos divulgado e nao intencional da GPL e que ela e muito
   favoravel a grandes empresas que querem minar empresas de software. Em
   outras palavras, a GPL e bem adequada para uso como arma de marketing,
   reduzindo potencialmente o beneficio economico 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 pos-graduac,ao tera em formar diretamente
   uma empresa para comercializar seus resultados de pesquisa, ou a
   dificuldade que um aluno tera em ingressar em uma empresa com a suposic,ao
   de que um promissor projeto de pesquisa sera comercializado.

   Para aqueles que precisam trabalhar com implementac,oes linkadas
   estaticamente em varios modelos de software, a GPL e geralmente uma
   licenc,a ruim, porque impede o uso de implementac,oes proprietarias dos
   modelos. A GPL minimiza, assim, o numero de programas que podem ser
   compilados usando o modelo GPL. A GPL tinha como objetivo nao fornecer um
   mecanismo para desenvolver um padrao na engenharia de produtos
   proprietarios. (Isso nao se aplica a aplicativos Linux porque eles nao
   usam links estaticos, 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 entao competir na distribuic,ao e
   suporte deste conjunto. Essa situac,ao nao e realista para muitos dos
   padroes de sistema exigidos, que podem ser aplicados em ambientes
   amplamente diferentes, e que exigem personalizac,ao comercial ou
   integrac,ao com padroes legados sob licenc,as existentes (nao-GPL). Os
   sistemas real-time usam frequentemente links estaticos, de modo que a GPL
   e a LGPL sao definitivamente consideradas problemas potenciais por muitas
   empresas de sistemas embarcados.

   A GPL e uma tentativa de manter os trabalhos disponiveis,
   independentemente da demanda nos estagios de pesquisa e desenvolvimento.
   Isso maximiza os beneficios para pesquisadores e desenvolvedores, a um
   custo desconhecido para aqueles que se beneficiariam de uma distribuic,ao
   mais ampla.

   A GPL foi projetada para impedir que os resultados de uma pesquisa sejam
   transferidos para produtos proprietarios. Este passo e frequentemente
   considerado o ultimo passo no pipeline tradicional de transferencia de
   tecnologia e e geralmente o mais dificil mesmo sob as melhores
   circunstancias; a GPL pretendia tornar isso impossivel.

10. Vantagens da licenc,a BSD

   Uma licenc,a de estilo BSD e uma boa opc,ao para pesquisas de longa
   durac,ao ou outros projetos que precisam de um ambiente de desenvolvimento
   que:

     * tem custo proximo a zero

     * ira evoluir durante um longo periodo de tempo

     * permite que qualquer pessoa mantenha a opc,ao de comercializar os
       resultados finais com problemas legais minimos.

   Esta considerac,ao final pode muitas vezes ser a dominante, como foi
   quando o projeto Apache decidiu sua licenc,a:

   "Este tipo de licenc,a e ideal para promover o uso de um corpo de
   referencia de codigo que implementa um protocolo para um servic,o comum.
   Esta e outra razao pela qual a escolhemos para o grupo Apache - muitos de
   nos queriam que o HTTP sobrevivesse e se tornasse um verdadeiro padrao
   multipartidario, e nao nos importariamos nem um pouco se a Microsoft ou a
   Netscape escolhessem incorporar nosso mecanismo HTTP ou qualquer outro
   componente de nosso codigo 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 impeto suficiente e que
   os participantes percebam um maior valor contribuindo com seu codigo para
   o projeto, mesmo codigo que teria valor se fosse mantido proprietario."

   Os desenvolvedores tendem a achar a licenc,a BSD atrativa, pois ela mantem
   os problemas legais fora do caminho e permite que eles fac,am o que
   quiserem com o codigo. Em contraste, aqueles que esperam principalmente
   usar um sistema em vez de programa-lo, ou que esperam que outros evoluam o
   codigo, ou aqueles que nao esperam ganhar a vida com seu trabalho
   associado ao sistema (como funcionarios do governo), achem a GPL atraente,
   porque forc,a o codigo 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 orfao. Se voce
   quiser forc,ar seus concorrentes a ajuda-lo, a GPL e atraente.

   Uma licenc,a BSD nao e simplesmente um presente. A pergunta "por que
   devemos ajudar nossos concorrentes ou deixa-los roubar nosso trabalho?"
   surge frequentemente em relac,ao a uma licenc,a BSD. Sob uma licenc,a BSD,
   se uma empresa vier a dominar um nicho de produto que outros consideram
   estrategico, as outras empresas podem, com esforc,o minimo, formar um mini
   consorcio visando restabelecer a paridade, contribuindo para uma variante
   BSD competitiva que aumente a competic,ao e a justic,a no mercado. Isso
   permite que cada empresa acredite que sera capaz de lucrar com alguma
   vantagem que ela possa proporcionar, ao mesmo tempo em que contribui para
   a flexibilidade e eficiencia economica. Quanto mais rapido e facil os
   membros cooperantes puderem fazer isso, maior sucesso eles terao. Uma
   licenc,a BSD e essencialmente uma licenc,a minimamente complicada que
   permite tal comportamento.

   Um efeito chave da GPL e fazer com que um sistema Open Source completo e
   competitivo seja amplamente disponibilizado ao custo de midia, e isso e
   uma meta razoavel. Uma licenc,a no estilo BSD, em conjunto com consorcios
   ad-hoc de individuos, pode atingir essa meta sem destruir as premissas
   economicas construidas em torno da implementac,ao final do pipeline de
   transferencia de tecnologia.

11. Recomendac,oes Especificas para usar uma licenc,a BSD

     * A licenc,a BSD e preferivel para a transferencia de resultados de
       pesquisa de uma maneira que seja largamente implantada e que mais
       beneficie uma economia. Como tal, as agencias de financiamento de
       pesquisa, como a NSF, ONR e DARPA, devem encorajar nas fases iniciais
       dos projetos de pesquisa financiados, a adoc,ao de licenc,as de estilo
       BSD para software, dados, resultados e hardware aberto. Eles tambem
       devem incentivar a formac,ao de padroes baseados em sistemas Open
       Source implementados e projetos Open Source em andamento.

     * A politica do governo deve minimizar os custos e as dificuldades de
       passar da pesquisa para a implantac,ao. Quando possivel, os subsidios
       devem exigir que os resultados estejam disponiveis sob uma licenc,a de
       estilo BSD amigavel `a comercializac,ao.

     * Em muitos casos, os resultados de longo prazo de uma licenc,a de
       estilo BSD refletem com mais precisao os objetivos proclamados na
       carta de pesquisa das universidades do que no que ocorre quando os
       resultados sao protegidos por direitos autorais ou patenteados e
       sujeitos ao licenciamento universitario proprietario. Existem
       evidencias casuais de que as universidades sao financeiramente mais
       bem recompensadas a longo prazo, divulgando resultados de pesquisa e
       apelando para doac,oes de ex-alunos de sucesso comercial.

     * As empresas ha muito reconheceram que a criac,ao de padroes de facto e
       uma tecnica de marketing fundamental. A licenc,a BSD serve bem a essa
       func,ao se uma empresa tiver realmente uma vantagem exclusiva na
       evoluc,ao do sistema. A licenc,a e legalmente atraente para o publico
       mais amplo, enquanto a expertise da empresa garante o seu controle. Ha
       momentos em que a GPL pode ser o veiculo apropriado para uma tentativa
       de criar tal padrao, especialmente quando se tenta prejudicar ou
       cooptar outras pessoas. A GPL, no entanto, penaliza a evoluc,ao desse
       padrao, porque promove um conjunto em vez de um padrao comercialmente
       aplicavel. O uso de tal conjunto constantemente sofre um aumento de
       problemas legais e comerciais. E pode nao ser possivel misturar
       padroes quando alguns estao sob a GPL e outros nao. Um verdadeiro
       padrao tecnico nao deve obrigar a exclusao de outros padroes por
       razoes nao tecnicas.

     * As empresas interessadas em promover um padrao em evoluc,ao, que pode
       se tornar o nucleo dos produtos comerciais de outras empresas, devem
       ter cuidado com a GPL. Independentemente da licenc,a usada, o software
       resultante geralmente sera transferido para quem realmente faz a
       maioria das alterac,oes de engenharia e que mais entende o estado do
       sistema. A GPL simplesmente adiciona mais atrito legal ao resultado.

     * Grandes empresas, nas quais codigo Open Source e desenvolvido, devem
       estar cientes de que os programadores apreciam o Open Source porque
       ele deixa o software disponivel para o funcionario quando ele mudar de
       empregador. Algumas empresas encorajam esse comportamento como uma
       vantagem de emprego, especialmente quando o software em questao nao e
       diretamente estrategico. Trata-se, na verdade, de um beneficio
       antecipado com possiveis custos de oportunidade perdidas, mas sem
       custos diretos. Incentivar os funcionarios a trabalhar pela aclamac,ao
       dos colegas fora da empresa e um beneficio barato que uma uma empresa
       pode, por vezes, fornecer com desvantagem quase zero.

     * Pequenas empresas com projetos de software vulneraveis ao software
       orfao, devem tentar usar a licenc,a BSD sempre que possivel. Empresas
       de todos os portes devem considerar a formac,ao de tais projetos Open
       Source quando for vantajoso manter minimas as despesas legais e
       organizacionais associadas a um verdadeiro projeto Open Source de
       estilo BSD.

     * As organizac,oes sem fins lucrativos devem participar de projetos Open
       Source sempre que possivel. Para minimizar os problemas de engenharia
       de software, como a mistura de codigo sob diferentes licenc,as, as
       licenc,as no estilo BSD devem ser incentivadas. Desconfiar da GPL deve
       ser particularmente o caso de organizac,oes sem fins lucrativos que
       interagem com o mundo de desenvolvimento. Em alguns locais onde a
       aplicac,ao da lei se torna um exercicio caro, a simplicidade da nova
       licenc,a BSD, em comparac,ao com a GPL, pode ser de consideravel
       vantagem.

12. Conclusao

   Em contraste com a GPL, que e projetada para impedir a comercializac,ao
   proprietaria do codigo Open Source, a licenc,a BSD impoe restric,oes
   minimas sobre o comportamento futuro. Isso permite que o codigo BSD
   permanec,a como codigo aberto ou se integre a soluc,oes comerciais, `a
   medida que as necessidades de um projeto ou empresa mudam. Em outras
   palavras, a licenc,a BSD nao se torna uma bomba-relogio legal em nenhum
   ponto do processo de desenvolvimento.

   Alem disso, como a licenc,a BSD nao vem com a complexidade legal das
   licenc,as GPL ou LGPL, ela permite que desenvolvedores e empresas gastem
   seu tempo criando e promovendo um bom codigo, em vez de se preocupar se
   esse codigo viola algum licenciamento.

13. Referencias Bibliograficas

 [1] http://www.gnu.org/licenses/gpl.html

 [2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/

 [3] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books,
     2000. Quotes are from page 114, ``Effects of the GNU GPL''.

 [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
