gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
bug report: PHP < 4.1.1
Contribuído por scorpio em 28-02-02 10:23
do departamento wget&&patch&&make&&make install&&restart
php Foi encontrado um problema que afecta todas as versões do PHP desde a 3.0.10 até à 4.1.1, localizado no código que efectua o processamento de um upload (php_mime_split). Já saiu um patch que o corrige (este é para a versão 4.1.x), e a correspondente release 4.1.2 do PHP. Há a possibilidade de desactivar, no php.ini, o upload (apenas para versões superiores à 4.0.3) através da directiva file_uploads = off enquanto não se faz o update. Quanto aos aventureiros que usam a versão 4.2.0-dev (cvs), não se preocupem: essa versão não está vulnerável.

Mais "portais" | Nova versão beta da Red Hat  >

 

gildot Login
Login:

Password:

Referências
  • um problema
  • um patch
  • correspondente release 4.1.2 do PHP
  • Mais acerca php
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Este é um bom teste à comunidade UNIX... (Pontos:2)
    por pls em 28-02-02 12:01 GMT (#1)
    (Utilizador Info) http://pls.mrnet.pt
    A natureza dos problemas encontrados vai dar origem a alguns exploits faceis (as versões anteriores à 4.0.7.RC3). Curiosamente ("posts" a explorar heap e boundary checks) muito parecidos com os "gets mágicos dos codereds e afins" (por serem posts serão menos visiveis nos logs da maior parte das pessoas).

    Interessante vai ser verificar se a comunidade unix vai fazer o upgrade em percentagens maiores do que a comunidade windows. Quantos servidores estarão vulneráveis dentro de uns meses?

    Não sei o que o resto do pessoal pensa mas, pessoalmente, acho que teremos (administradores de unix) uma performance melhor. Para ajudar muitos sistemas unix são mantidos por profissionais em ambientes de hosting, o que significará que a estrutura do PHP estará a responsabilidade não de quem administra os sites mas de uma equipa que administra o servidor partilhado. Caramba, para estes não fazerem o upgrade é necessário que os clientes estejam a dormir também...

    Estou confiante...

    PLS
    Re:Este é um bom teste à comunidade UNIX... (Pontos:2)
    por Gamito em 28-02-02 12:25 GMT (#4)
    (Utilizador Info) http://gamito.freezope.org/
    Pois o meu Apachinho já está up to date :)

    Mário Gamito
    Grunf! (Pontos:2)
    por Gamito em 28-02-02 12:02 GMT (#2)
    (Utilizador Info) http://gamito.freezope.org/
    E eu a pensar que ia ter uma manhã de dolce fare niente. Grrr...
    www.dte.ua.pt is down for some minutes.

    Double grrr!

    Mário Gamito
    O que eu gostava que fosse alterado no php... (Pontos:2)
    por pls em 28-02-02 12:22 GMT (#3)
    (Utilizador Info) http://pls.mrnet.pt
    Há tantas coisas nos defaults do php que me irritam solenemente. Em 99% das ocasiões em que estou a auditar sistemas criam vulnerabilidades estupidas:

  • A opção de utilizar url's como files devia estar por defeito inactiva (i.e. de uma vez acaba com as vulnerabilidades de cross-scr1pting que se estão a tornar tão populares em aplicações de php). Olhando para os advisories não encontrei UM programa afectado (i.e. culpa dos programadores de php obviamente) que necessite da função... defaults permissivos são um conceito que tornam sempre o php menos seguro.

  • Os error e warning estarem activos por defeito a revelar paths...

  • safemode (que na minha opinião é demasiado limitativo; é preferivel correr o apache/php chrooted se se segurança é vital e a máquina não é partilhada) devia vir "on" mesmo que a maioria dos utilizadores o desligassem (pelo menos liam sobre o assunto).

  • file uploads idem...

  • idem para include paths e paths para coisas como o sendmail (procurar no path do sistema o executável é uma ideia tão má; e é o default que pode ser modificado para utilizar um path hardcoded).

    As configurações devem ser por defeito "seguras e consevadoras" se isso significa que para determinado tipo de aplicações devem ser alteradas "so be it", cabe a quem instala as aplicações fazer a modificação.

    PLS
  • Re:O que eu gostava que fosse alterado no php... (Pontos:2)
    por Gamito em 28-02-02 12:31 GMT (#5)
    (Utilizador Info) http://gamito.freezope.org/
    Podes acrescentar à lista das más instalações por omissão o MySQL...

    Mário Gamito
    pois pois (Pontos:0, Interessante)
    por Anonimo Cobarde em 28-02-02 18:41 GMT (#6)
    É muito lindo apache chrooted com php mas em servidores virtuais é impraticavel... Tal como é impraticavel em servidores virtuais verificar todos os scr1pts que a maior parte dos camelos er.. clientes metem para la... formmail.cgi é um dos grandes exemplos a citar.. phpnuke segue pela mesma linha.... Ou seja, é bastante complicado tomar conta dos clientes... Mas desde que o server esteja bem configurado ja é um grande passo para por muitas coisas em ordem.. O problema é quando isto nao acontece... Este bug do php, levanta questoes acerca da sua fiabilidade ao nivel de seguranca... Pelos vistos o codigo vulneravel esta do piorio.... E usar as CVS versions em hosting é impraticavel, logo faz-me pensar sobre o futuro do php ao nivel da seguranca... quantos mais buracos tera ?
    Re:pois pois (Pontos:1)
    por mlemos em 01-03-02 1:17 GMT (#8)
    (Utilizador Info) http://www.ManuelLemos.net/

    Para servidores virtuais seguros, recomendo cada cam^H^H^Hcliente a correr com o seu utilizador da máquina sob o seu IP. Assim, cada um só acede aos ficheiros para os quais tem permissões. Isto em Unixes, em Windows não sei dizer se isto é possível.


    Re:pois pois (Pontos:2)
    por pls em 01-03-02 1:20 GMT (#9)
    (Utilizador Info) http://pls.mrnet.pt
    Em máquinas virtuais tens os problemas de performance e eficiencia de ter "apache+php+bade de dados" acrescidos ao overhead de kernels concorrentes...

    PLS
    Re:pois pois (Pontos:1)
    por mlemos em 01-03-02 23:04 GMT (#17)
    (Utilizador Info) http://www.ManuelLemos.net/

    Acho que não estamos a pensar na mesma coisa. Quando digo servidores virtuais, são servidores que respondem pelo acessos a diferentes IPs na mesma máquina, portanto usando o mesmo OS (kernel). Cada cliente tem o seu IP e o seu utilizador, que não é root.


    Re:pois pois (Pontos:2)
    por pls em 01-03-02 23:14 GMT (#18)
    (Utilizador Info) http://pls.mrnet.pt
    Acho que não estamos a pensar na mesma coisa. Quando digo servidores virtuais, são servidores que respondem pelo acessos a diferentes IPs na mesma máquina, portanto usando o mesmo OS (kernel). Cada cliente tem o seu IP e o seu utilizador, que não é root.

    Estavamos de facto a falar de coisas diferentes... eu estava a pensar em "maquinas virtuais" (i.e. completas tipo vmware / user mode linux).

    A premissa de multi-utilizador de um unix é complexa de implementar de forma segura. Há demasiados problemas de segurança (localmente até no openbsd isso é verdade).

    A minha aposta (estou a equacionar construir host para serem partilhados em aplicações apache+mysql+php) está em as três aplicações correrem chrooted. Não vejo alternativa se por exemplo o php poder ter file uploads (i.e. permissões de escrita para o apache "que é partilhado entre utilizadores" algures no disco e manter privacidade entre os utilizadores tendo o apache o apache que ter acesso aos ficheiros para os passar pelo php). Tens alguma ideia brilhante para partilhar??

    PLS
    Re:pois pois (Pontos:1)
    por mlemos em 02-03-02 6:32 GMT (#20)
    (Utilizador Info) http://www.ManuelLemos.net/

    O que estou a falar é usado pela empresa onde alojo os meus sites desde há vários anos. Se fosse inseguro, eles não usariam.

    O pior que pode acontecer é os clientes terem acesso aos ficheiros uns dos outros porque deram permissões para isso. Mas isso é descuido do cliente.

    Agora coisas como tentar ler /etc/passwd pura e simplesmente desactivam-te o IP do servidor virtual e exigem-te explicações deixando desactivado até te explicares. Soube disto por acidente quando por engano tentei editar o /etc/passwd porque me enganei na shell pensando que estava a editar da minha máquina.

    De resto, a ideia de poder desactivar o teu servidor virtual simplesmente deactivando o interface do teu IP, é optima até para coisas como evitar o efeito de Slashdot num site teu sem afectar os clientes que estão na mesma máquina.

    Também é boa ideia para te bloquear o acesso sem sequer mexer nos teus ficheiros, por exemplo caso não pagues. Isto nunca me aconteceu, mas imagino que seja boa ideia para controlar os atrasos de pagamento abusivos dos clientes. Se vendes acesso aos teus clientes, deves gostar destas possibilidades. :-)


    Re:pois pois (Pontos:2)
    por pls em 02-03-02 12:33 GMT (#22)
    (Utilizador Info) http://pls.mrnet.pt
    Agora coisas como tentar ler /etc/passwd pura e simplesmente desactivam-te o IP do servidor virtual e exigem-te explicações deixando desactivado até te explicares. Soube disto por acidente quando por engano tentei editar o /etc/passwd porque me enganei na shell pensando que estava a editar da minha máquina.

    Isso não é um ambiente seguro.
    Não há unix nenhum sem vulnerabilidades locais.

    PLS
    Re:pois pois (Pontos:2)
    por pls em 01-03-02 1:24 GMT (#10)
    (Utilizador Info) http://pls.mrnet.pt
    Não disse que era simples... mas o apache e php chrooted é das soluções que encontrei a que apresenta menos overhead. Servidores virtuais "à seria" custam _muito_dinheiro e a solução para os pobrezinhos (usermode linux, lvs e vmware servers) são francamente ineficientes.

    PLS
    Re:O que eu gostava que fosse alterado no php... (Pontos:1)
    por [Dragon] em 01-03-02 13:22 GMT (#12)
    (Utilizador Info) http://www.cidadela.org/
    As configurações devem ser por defeito "seguras e consevadoras" se isso significa que para determinado tipo de aplicações devem ser alteradas "so be it", cabe a quem instala as aplicações fazer a modificação.

    Por default o php permite fazer essas coisas todas consideradas "inseguras". Mas não está errado. É apenas uma configuração default que se quer prática. Uma pessoa que queira experimentar php, faz o download, instala, e começa a brincar. É errado não poder fazer coisas porque está o "safe_mode on" ou não são permitidos uploads, ou para o fazer tem de configurar o sistema com a opção XPTO-Z. Se uma pessoa quer simplesmente testar, não tem que ser obrigada a ler manuais, docs, etc, para aprender a activar todas as opções do PHP. Por outro lado, se as empresas que auditas tem problemas a esse nivel, é porque não são empresas responsáveis. Como disse, a configuração que vem é uma configuração "facil e acessível". Claro que não se espera que este tipo de configuração seja a mais segura. Se uma empresa se preocupa, deve ser da responsabilidade da empresa ter o trabalho e a obrigação de tornar o seu servidor seguro, arranjar alguem (que é pago) para ler a documentação, e aprender a fazer essas coisas "irritantes". É dever da empresa saber configurar, e não do utilizador que apenas quer ver se a coisa funciona bem.

    Até porque se viesse seguro, por default, ficavas sem emprego! ;)

    []s


    ---
    "One Dragon to rule them all."
    Re:O que eu gostava que fosse alterado no php... (Pontos:2)
    por pls em 01-03-02 14:35 GMT (#13)
    (Utilizador Info) http://pls.mrnet.pt
    Por default o php permite fazer essas coisas todas consideradas "inseguras". Mas não está errado. É apenas uma configuração default que se quer prática.

    Eu apologista da opinião contrária. Os defaults devem ser seguros, o utilizador para ligar algo que pode ser perigoso ou inseguro deve ser informado do que está a fazer. Se não tem "know how" para lidar com o risco não deve utilizar o software sem se ter uma vaga ideia dos potenciais problemas e suas implicações.

    Uma máquina vulnerável coloca terceiros em risco. Não é só uma questão de responsabilidade relativa a quem corre algo inseguro, há que ter em conta o risco que essa opção de "facilitismo" representa para terceiros.

    Há algo que me incomoda nesta ideia de "ser simples para todos poderem experimentar". Não tem nada de ser simples, nem é direito fundamental de ninguém correr sistemas configurados às três pancadas na Internet. É algo que pode ter implicações para terceiros.


    É errado não poder fazer coisas porque está o "safe_mode on" ou não são permitidos uploads, ou para o fazer tem de configurar o sistema com a opção XPTO-Z. Se uma pessoa quer simplesmente testar, não tem que ser obrigada a ler manuais, docs, etc, para aprender a activar todas as opções do PHP.

    Seguindo essa lógica os unixed não deviam vir com autenticação, o su não deveria ser limitado aos utilizadores do grupo wheel e os serviços devem vir todos ligados e com configurações permissivas... ah, damn, é quase isso que acontece em N sistemas "unix like".


    Por outro lado, se as empresas que auditas tem problemas a esse nivel, é porque não são empresas responsáveis. Como disse, a configuração que vem é uma configuração "facil e acessível". Claro que não se espera que este tipo de configuração seja a mais segura. Se uma empresa se preocupa, deve ser da responsabilidade da empresa ter o trabalho e a obrigação de tornar o seu servidor seguro, arranjar alguem (que é pago) para ler a documentação, e aprender a fazer essas coisas "irritantes". É dever da empresa saber configurar, e não do utilizador que apenas quer ver se a coisa funciona bem.

    De acordo (mas não achando que seja diferente para as pessoas individuais)...

    O problema é, até jurisprudência em contrário, que se vive num clima de irresponsabilidade total de quem, por negligência (muitas vezes grosseira), faz disparates na Internet que prejudicam terceiros. Sejam empresas ou pessoas individuais.

    Se cometeres erros grosseiros na gestão de uma empresa há figuras legais como "gestão danosa" que te responsabilizam, se matares um tipo com o teu carro há figuras legais como "homicidio por negligência/involuntário" que te responsabilizam, se a tua máquina é um jump point para ataques a terceiros parece que o "irresponsável" que administra a máquina não tem nada a ver com isso; "coitadinho foi hackado também" e "nem sabia". Ora "deve saber", "deve ter que passar quanto mais não seja por warnings no php.ini", etc.

    PLS
    Re:O que eu gostava que fosse alterado no php... (Pontos:1)
    por [Dragon] em 01-03-02 17:23 GMT (#15)
    (Utilizador Info) http://www.cidadela.org/
    Esta discusão fez-me lembrar de uma conversa que tive uma vez, com um "Administrador de Redes" (que até à altura só tinha trabalhado com NT), numa empresa onde trabalhei:

    Estava eu a ler a bugtraq, a ver quais os patchs que deveria aplicar no linux que tinha sido instalado à pouco tempo, quando o "Admin" perguntou o que eu estava a fazer. Eu disse que estava a procura dos patchs para o linux, e a ver o que deveria desactivar para o tornar mais seguro. Ele ficou muito admirado e perguntou-me: "Patchs? Configurações?! Mas o linux precisa disso? Não é já seguro?".

    Basicamente, ele pensava que o linux por si só já vinha com tudo protegido, tudo fechado, e que não era necessario preocupar-se com nada. Este tipo de problemas, é o que acontece quando se passa a ideia de que as coisas são seguras de fabrica. Fica-se com a ideia de que é seguro, e não nos damos ao trabalho de explorar e ver o que realmente se passa. Neste caso, o "facilitismo" de segurança, também não funciona, porque não se fica com as noções necessárias do que realmente se passa, e qualquer pessoa pensa que é tudo seguro.

    Eu sou da opinião de que as coisas devem vir (e penso que o PHP vem +- segundo este critério) com os defaults a apanhar o meio termo entre funcionalidade e segurança. O indicador está no meio. Eu chego, instalo e trabalho com php. Sou programador, as coisas são simples de meter a funcionar em casa, e eu não necessito de me preocupar com segurança, porque só quero fazer umas centenas de linhas de código (;). Agora se ha alguem que quer fazer uma coisa séria, e o seu papel é de administrador, ele é que tem a obrigação de puxar o marcador para o lado da segurança. Tem um pouco a ver com a finalidade e o pretende.

    Eu não sugeri que o linux devia vir sem qualquer tipo de autenticação, para que se possam utilizar todos os comandos do linux. Eu defendi que o programador que quer testar/utilizar/desenvolver em php, não tem que ter tudo protegido, como se fosse um servidor da NASA. A segurança não se justifica, quando a finalidade dele é apenas desenvolver. As coisas depois mudam de nivel, se ele decide ter as coisas disponiveis na internet. Aí já deixa o papel de programador, para passar a ser um administrador. E nessa altura sim, deve-se preocupar em fechar as coisas que não utiliza, e preocupar-se mais com a segurança, porque nessa altura já não está sozinho, mas pertence à internet. Agora não acho justo que considerem que o PHP vem inseguro, quando se vê por aí pessoas que não querem ter o trabalho de aprender a administrar, e os seus servidores são vulneraveis. Se essas pessoas não querem aprender a configurar as coisas, não metam as suas máquinas online. Agora não fiquem à espera que o PHP venha todo fechado por causa desses preguiçosos que querem ser administradores, e não se dão ao trabalho. Depois sofrem as consequências e só têm o que merecem! :->

    If you can’t stand the heat, stay out of the kitchen!

    Um abraço!


    ---
    "One Dragon to rule them all."
    Hey, Not so fast... NOVAS VERSÕES, NOVOS BUGS (Pontos:1)
    por mlemos em 01-03-02 1:13 GMT (#7)
    (Utilizador Info) http://www.ManuelLemos.net/

    Antes que se ponham a fazer actualizações do PHP à maluca (too late...), lembrem-se de uma coisa sagrada: NOVAS VERSÕES, NOVOS BUGS!

    O que acontece é que por vezes os desenvolvedores do PHP têem ideias não muito brilhantes, como por exemplo quebrar o funcionamento de certas funções do PHP, como o caso de algumas que já funcionavam desde há 4 anos atrás, apenas porque não concordam com a sua implementação.

    Depois de terem sido alertados para a asneira, preferiram manter a atitude arrogante e orgulhosa de não admitir que fizeram asneira, para não terem que voltar atrás.

    Infelizmente isso foi o caso das funções strtok e dirname. Descobri quando fui fazer a actualização do PHP 4.0.0 para o 4.1.0 .

    O meu erro foi ter pressuposto que os desenvolvedores do PHP não iriam cometer a asneira de quebrar funções que sempre se comportaram da mesma forma durante 3 e 4 anos. Paguei o meu erro com 1 semana perdida a banir essas funções do código do site PHP Classes Repository que estava em produção.

    Para que não sofram as mesmas consequências, recomendo que vejam o código substituto que usei para não ter que reescrever mais o site.

    Agradeço que me comuniquem se encontrarem mais funções quebradas ou omitidas para que possa partilhar esta informação com todos os inocentes que irão fazer a actualização do PHP desprevenidamente.

    Para concluir, de acordo com o anunciando, não é preciso actualizar a versão do PHP, basta desligar a opção file_uploads se não preciasarem de uploads nos vossos sites, ou apenas aplicar os patches que existem disponíveis para versões mais antigas do PHP


    Re:Hey, Not so fast... NOVAS VERSÕES, NOVOS BUGS (Pontos:3, Informativo)
    por pls em 01-03-02 1:29 GMT (#11)
    (Utilizador Info) http://pls.mrnet.pt
    Eu levei com o --use_mysql quebrado e tive de utilizar o --enable-mysql...

    O problema é que se a tecnologia php muda e queres prosseguir com a linguagem estás literalmente condicionado a seguir em frente e tratar das adaptações. It stinks. Mas ninguém nos obriga a utilizar php...

    PLS
    Re:Hey, Not so fast... NOVAS VERSÕES, NOVOS BUGS (Pontos:1)
    por mlemos em 01-03-02 23:01 GMT (#16)
    (Utilizador Info) http://www.ManuelLemos.net/

    Exacto. Também ninguém obriga a usar a última versão do PHP que saiu, nem depois da revelação deste buraco de segurança.

    Aquilo que eu já previa, aconteceu. Muitas pessoas verificaram que algumas coisas ficaram diferentes e nas listas de discussão de PHP começam a aparecer os primeiros perdidos a perguntar o que é que mudou que de na versão mais actual do PHP os seus sites deixaram de funcionar. (I told you so)

    Isto apenas para lembrar que muitas pessoas actualizam primeiro antes sequer de ler os ChangeLogs. Espero que aprendam com o erro.

    Por mim, não vou actualizar a versão do PHP. Não se deve mexer na equipa que funciona. Mas o povo não aguenta a tentação de actualizar para última versão sem pensar primeiro se realmente precisam.


    Re:Hey, Not so fast... NOVAS VERSÕES, NOVOS BUGS (Pontos:2)
    por pls em 01-03-02 23:18 GMT (#19)
    (Utilizador Info) http://pls.mrnet.pt
    Por mim, não vou actualizar a versão do PHP. Não se deve mexer na equipa que funciona. Mas o povo não aguenta a tentação de actualizar para última versão sem pensar primeiro se realmente precisam.

    Mas há os que precisam... quanto mais não seja para adaptar as aplicações ao que vai mudando no php...

    Tu estas nessa situação. Podes adiar, mas será inevitável enfrentares esses problemas com a quantidade de aplicações de php a que estás associado (nomeadamente a metabase)...

    PLS

    PS: antes que perguntes; claro que conheço e gosto...
    Re:Hey, Not so fast... NOVAS VERSÕES, NOVOS BUGS (Pontos:1)
    por mlemos em 02-03-02 6:47 GMT (#21)
    (Utilizador Info) http://www.ManuelLemos.net/
    Por mim, não vou actualizar a versão do PHP. Não se deve mexer na equipa que funciona. Mas o povo não aguenta a tentação de actualizar para última versão sem pensar primeiro se realmente precisam.
    Mas há os que precisam... quanto mais não seja para adaptar as aplicações ao que vai mudando no php... Tu estas nessa situação. Podes adiar, mas será inevitável enfrentares esses problemas com a quantidade de aplicações de php a que estás associado (nomeadamente a metabase)...

    Sim, mas eu tento (e consigo) manter sempre a compatibilidade com versões do PHP do passado (actualmente mesmo com PHP 3). Para tirar o benefício de possibilidades de versões do PHP mais recentes, eu uso código condicional (if(function_exists()))

    De qualquer modo o Metabase é uma biblioteca de base para outras aplicações, não uma aplicação em si.

    Para além disso vem com testes de regressão que me permitem verificar se as alterações feitas em cada versão não quebram nada existente, tornando cada lançamente praticamente livre de bugs.

    Agora aplicações com sites inteiros com milhentas possibilidades de percorrer páginas nas mais diversas situações, fica difícil manter um conjunto de testes de regressão que te assegurem que as alterações em cada nova versão do PHP não quebram a aplicação em algum lado.

    É melhor não arriscar e evitar actualizações do PHP a menos que precises de algo absolutamente essencial duma versão mais recente. Não é o caso deste problema de segurança que foi descoberto uma vez que existem patches para versões mais antigas.

    PS: antes que perguntes; claro que conheço e gosto...

    Só por curiosidade gostas e usas em alguma coisa desenvolvida por ti, ou apenas aprecias o conceito?


    Metabase (Pontos:2)
    por pls em 02-03-02 12:39 GMT (#23)
    (Utilizador Info) http://pls.mrnet.pt
    Só por curiosidade gostas e usas em alguma coisa desenvolvida por ti, ou apenas aprecias o conceito?

    Ando a ganhar coragem para implementar em vários projectos... está testada, funciona, quero... falta o tempo, recursos e oportunidade para colocar em ambientes de produção.

    Estou a acabar a conversão da SIC de vignete (em windows) para unix... quando acabar vou tratar da implementação da metabase.

    A tua mudança de licença era fundamental mas foi demasiado recente para já estar no "pacote" a utilizar.

    PLS
    Com licença (era Re:Metabase) (Pontos:1)
    por mlemos em 02-03-02 17:56 GMT (#24)
    (Utilizador Info) http://www.ManuelLemos.net/

    O que é pena! Mas é curioso que o teor da licença não mudou. A licença BSD diz praticamente o mesmo que dizia na licença anterior.

    Aliás, eu mudei para a licença BSD apenas por ser uma licença Opens Source padronizada, aprovada e reconhecida na comunidade.

    Tinha a impressão que as pessoas não estava a aderir ao Metabase por não entenderem o que a licença anterior queria dizer e todas as suas implicações legais.

    Daí que decidi mudar para a licença BSD porque muitas pessoas nem sequer vão ler porque já a conhecem como uma licença confiável.

    A propósito, o teu SiteSeed também não tem uma licença Open Source reconhecida. Já pensaste em adotar uma licença certificada como Open Source? Acredito que terias muito mais adesão se fizesses isso.


    Re:Com licença (era Re:Metabase) (Pontos:2)
    por pls em 03-03-02 2:32 GMT (#25)
    (Utilizador Info) http://pls.mrnet.pt
    O que é pena! Mas é curioso que o teor da licença não mudou. A licença BSD diz praticamente o mesmo que dizia na licença anterior.

    Sim, mas eu a BSD nem preciso de a ler (again) para saber que posso integrar o software. A anterior podia ter "nuances" e consequentemente dava mais trabalho (i.e. teria de fazer algum esforço de interpretação). De qualquer forma estou na tua mailing list há muiiiito tempo. Acho que utilizo software teu há 15 anos; não precisava de ajuda para me interessar por ele.


    A propósito, o teu SiteSeed também não tem uma licença Open Source reconhecida. Já pensaste em adotar uma licença certificada como Open Source? Acredito que terias muito mais adesão se fizesses isso.

    Não duvido... mas não é o meu filme. O Siteseed é para ser comercial mesmo e de "utilização livre" (i.e. direito de utilizar) apenas por individuos. Tudo o resto é para ser reservado e cedido caso a caso a quem eu queira.

    Não é um projecto "livre". Não é, nem nunca foi, a ideia. E calculo que seria mais popular se seguisse essa via. Mas estou satisfeito com a forma como as coisas estão a correr.

    PLS

     

     

    [ Topo | FAQ | Editores | Contacto ]