Assino embaixo do que o Alexsandro escreveu. E vamos todos ler de novo a Catedral e o Bazar, gente: http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar
<http://pt.wikisource.org/wiki/A_Catedral_e_o_Bazar>[]s Em 4 de março de 2011 15:18, Alexsandro Haag <alexsandro.h...@gmail.com>escreveu: > Acho no mínimo curiosa a visão de algumas pessoas sobre programação e > propriedade intelectual. > > Vejo que dão valor demais ao produto, quando o que importa mesmo é o > serviço prestado com este produto ao cliente. Claro que o bom é ter os > dois, mas o diferencial vem do segundo. > > Utilizemos como exemplo o Sistema QUALQUER de Gestão Comercial... Sou o > programador principal deste sistema e desenvolvi um algoritmo que faz o > cálculo dos impostos de uma forma otimizada, fazendo com que o tempo de > determinada rotina baixe, de 10 minutos para 10 segundos. Otimizei a > rotina, pois estava mal escrita. Fico muito orgulhoso e isso prá mim tem > muito valor, porém para o sistema inteiro ou para o cliente isso pode > não ter a mesma importância que tem prá mim. > Posso não querer compartilhar isso com ninguém, pois me deu trabalho > fazer e não quero dar isso de mão beijada. Mas com 30 minutos de > envolvimento outro programador foi lá, fez de outra maneira (seguindo a > mesma lógica ou não) e obteve o mesmo resultado. > > Outra possibilidade é deixar que qualquer pessoa pegue o que tenho, > melhore e me devolva agora rodando em 5 segundos. > > Também tem outro cenário... a preocupação de que alguém venha a hackear > meu sistema inteiro e, ao invés de fazer um do zero, se aproveite do que > já fiz. > > - Em primeiro lugar ele terá bastante trabalho para entender a forma > como pensei o sistema; > - Depois ele vai achar que determinada rotina faria diferente; > - Ele terá bastante trabalho para colocar este sistema para funcionar; > - Quando não funcionar ele não poderá apelar para mim, desta forma não > vai ter segurança para levá-lo adiante; > - Ele não vai me ligar pedindo ajuda; > - Vai literalmente morrer na casca. > > Outra possibilidade é deixar que qualquer pessoa possa pegar os fontes > do meu sistema e melhorá-lo. Ou ainda o implemente em clientes e me > contate se precisar de uma apoio ou melhoria, alavancando de uma forma > ou de outra meus negócios e de quebra, melhorando meu produto. > > Tenho visto hoje em dia um grande movimento neste sentido. Tudo está > indo para o código aberto, inclusive os ERPs. (vide OpenERP, OpenTaps, > OfBiz, OpenBravo+-,Stoq) > > Se eu não abrir o meus sistema QUALQUER vão usar outro. > E como tem outros de código aberto (muito completos principalmente por > utilizarem este modelo de negócio). Por quê vão querer ter o trabalho de > hackear meu engessado e ultrapassado sistema? > > Isso é só para contextualizar... Não estou dizendo que seu sistema seja > assim. > > O que quero demonstrar é que, a menos que meu sistema seja muito > específico para um nicho de mercado ou ramo de negócio, que nenhum outro > hoje atenda, não vejo vantagens em trabalhar no modelo de código > fechado. Isso só vai atrasar me negócio. Este modelo ficou para trás. > > Mesmo a Microsoft... Se buscasse desesperadamente uma forma de impedir a > pirataria do seu sistema, não estaria onde está hoje. > > Claro que esta é tão somente minha visão pessoal, não levem a mal. > > Abraço Amigos! > Att. > Alex > > Em 04-03-2011 13:32, Leandro DUTRA escreveu: > > 2011/3/4 Fabricio Srdic<fsa...@gmail.com>: > >> Vejam bem, os dados são sim do cliente, mas a estrutura não. > > Conceito básico de teoria de dados. Não há dados sem estrutura. > > > > > >> Ou seja, por exemplo, views > > Visões (relações derivadas) fazem parte da estrutura básica. > > > > > >> stored procedures, external functions, tudo isso não pertence ao > >> cliente. Porque isso faz parte estrutura do banco de dados. > > Absolutamente não. Isso é código executável, e faz parte da aplicação, > não da > > base de dados, e muito menos de sua estrutura. Somente está na base > porque > > não faz sentido colocar a rede (com latência&c) entre a lógica e os > dados. > > > > Existe um caso interessante, que é o código que suporta as > restrições > > de integridade. Este, por mais que seja expresso na mesma linguagem que > a > > lógica da aplicação, na verdade faz parte da estrutura, e portanto > pertence ao > > cliente. Ou deveria. > > > > > >> O modo como as tabelas estão organizadas no banco faz parte da > >> estrutura. Isso é patrimônio intelectual. > > Pode até ser, de acordo com a lei atual. Mas não quer dizer que a lei > seja > > justa ou razoável, como qualquer brasileiro com um mínimo de conhecimento > ou > > experiência de vida deveria saber. Aliás, é impossível separar o que é > do > > cliente (dados) do que pode, talvez, não ser (estrutura). Portanto, > mesmo que > > um tribunal fosse tentar estabelecer essa distinção, qualquer advogado de > meia > > tigela mostraria que é absurdo. > > > > > >> Se, ao cancelar o sistema, você > >> deixa no cliente a sua base de dados em Postgres mesmo, você está na > verdade > >> limitando o acesso do seu cliente aos dados, pois, não são todas as > >> pltaformas de programação que conseguem trabalhar com dll's > > E o que DLLs, quem nem são inerentes ao PostgreSQL, têm a ver com o caso? > DLL > > é uma excrecência da plataforma IBM OS/2 copiada pelo MS Windows, > exclusiva a > > essas plataformas. Nos sistemas operacionais ‘de verdade’ (POSIX, > inclusive > > Unix e GNU/Linux), usamos SOs. > > > > Também não entendo o que plataforma de programação tem a ver com o > > caso. Num caso de encerramento de contrato de suporte, o que o usuário > quer é > > maneira de exportar os dados para outra plataforma, ou a possibilidade de > > continuar a usar a mesma. O PostgreSQL é livre, e tem todas as > ferramentas de > > extração e interface possíveis e imagináveis. Mesmo que o usuário tenha > > alguma plataforma estranha, nenhum SGBD tem interface para tantas > linguagens > > de programação e plataformas operacionais quanto o PostgreSQL. > > > > > >> e não são todas que possui tipos de dados compatíveis com as utilizadas > em > >> dll's > > DLLs determinam uma única plataforma de programação: interfaces C em MS > > Windows, a menos que ainda sejas usuário de IBM OS/2. O que não faz > muita > > diferença, porque o MS Windows nada mais é que uma versão lobotomizada > nalguns > > aspectos, extendida noutros, do IBM OS/2. Aliás, seu primeiro nome foi > MS > > OS/2 3.0 NT i80860. > > > > Pelo contrário, tipos de dados não têm nada a ver com DLLs, a menos > > que, além de usar as interfaces C, se programe também em C, e aí são os > tipos > > de dados do C. Nada a ver com PostgreSQL. > > > > > >> Se analisarmos bem, a maneira correta de disponibilizar os dados para o > >> cliente em um eventual cancelamento seria disponibilizar esses dados em > >> arquivos txt em formato CVS > > Não existe um formato CVS, e txt não é formato de dados. Formatos de > dados > > são TSV (preferido), SSV (razoável) e CSV (horrível), e nenhum deles > expressa > > o mínimo de uma base, nem sequer as chaves. O cliente que aceitar isso > vai > > dançar, merecidamente. > > > > O mínimo absoluto seria a base de dados PostgreSQL, opcionalmente > com > > código‐fonte obscurecido — mas o código‐fonte das restrições de > integridade > > não pode ser obscurecido. > > > > Desculpai o tamanho da mensagem, mas havia muita coisa a > esclarecer. > > > > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Fábio Telles Rodriguez blog: http://www.midstorm.org/~telles/ e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
