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<[email protected]>: >> 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 [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
