Centro de controle para o major trial
(virtualize.sh)- A Vates divulgou o caso de uma empresa espacial com características semigovernamentais, com receita anual de cerca de US$ 130 milhões, que repetiu o uso do teste gratuito do Xen Orchestra Appliance por quase 10 anos
- A organização operava centenas de hosts físicos e cerca de 4.000 VMs, rodando boa parte de sua stack de TI na plataforma da Vates, mas não era cliente pagante nem usuária gratuita da instalação via código-fonte
- Os testes repetidos começaram em abril de 2015 com e-mails corporativos e seguiram com endereços pessoais do Outlook e Gmail e contas incrementais como
johndoe01,johndoe02, sempre informando o mesmo nome de empresa - O Xen Orchestra pode ter todos os recursos usados gratuitamente quando instalado a partir do código-fonte, mas o XOA é um produto pago que oferece uma VM pré-configurada e testada, atualizações com um clique, suporte e estabilidade
- A Vates vê esse tipo de trial farming como algo que abala a sustentabilidade do open source e pode avaliar limites de teste mais inteligentes, sem prejudicar usuários honestos
Uso repetido do teste do Xen Orchestra Appliance por 10 anos
- A Vates apresentou este caso no contexto do peso de manter projetos open source e do aumento de contribuições e relatórios de segurança falsos gerados por IA
- A organização em questão é uma empresa de caráter semigovernamental, com receita anual de cerca de US$ 130 milhões, que fabrica e opera equipamentos espaciais de alto custo
- Essa organização possui centenas de hosts físicos e quase 4.000 VMs, e executa uma parte significativa de sua stack de TI na plataforma da Vates
- Mas não era cliente pagante, nem usava a versão totalmente open source diretamente a partir do código-fonte
Diferença entre XOA e a instalação gratuita via código-fonte
- O produto cujo teste foi repetido por essa organização era o Xen Orchestra Appliance (XOA)
- Uma máquina virtual turnkey com o Xen Orchestra pré-instalado
- Testada regularmente
- Fácil de implantar e atualizar
- Funciona de forma totalmente on-premises
- Uma experiência com suporte e estabilizada para equipes que não querem dar
git pullno branchmasterem produção
- Usuários gratuitos podem seguir a documentação para compilar a partir do código-fonte e usar todos os recursos gratuitamente
- Sem garantia de estabilidade e sem suporte profissional
- Mas com todos os recursos disponíveis
- O que a Vates vende não é acesso a recursos, e sim uma VM pré-empacotada e testada, atualizações com um clique, economia de tempo, redução de risco e uma experiência com suporte
O padrão de contas: de e-mails corporativos para e-mails pessoais
- O uso repetido do teste começou em abril de 2015
- No início, os pedidos de teste gratuito eram feitos com e-mails corporativos
- Apareciam um ou dois casos por vez e, no começo, nada parecia suspeito
- Com o tempo, acumularam-se várias contas de desenvolvedores, administradores de sistemas, gerentes e outros perfis
- Depois que os e-mails corporativos se esgotaram, passaram a usar endereços pessoais do Outlook ou Gmail
- Iniciavam novos testes de 30 dias com e-mails pessoais reais
- Aumentando o identificador em formatos como
johndoe01@outlook.com,johndoe02@outlook.com - Atualmente, já passaram muito de
johndoe60
- No formulário de cadastro, o nome da empresa não é obrigatório, mas eles sempre informavam o mesmo nome de empresa
Continuaram burlando mesmo após receber suporte
- A Vates ofereceu suporte a essa organização como faz com usuários em avaliação
- Respondeu perguntas
- Orientou sobre como usar o produto
- Quase dedicou um dia inteiro ao suporte na fase inicial, quando o discurso era “estamos testando e talvez avaliemos uma compra”
- Com o tempo, perguntas e configurações semelhantes se repetiram, e a busca nos registros confirmou pelo menos 60 contas separadas ligadas à mesma organização
- Quando a Vates entrou em contato, a organização pediu desculpas de forma vaga e respondeu que migraria para a versão via código-fonte
- Não demonstrou interesse em suporte profissional nem em possíveis descontos por volume, e depois não migrou de fato para a versão via código-fonte
- Em vez disso, continuou pedindo testes gratuitos com endereços pessoais do Outlook e identificadores incrementais nos e-mails
Sustentabilidade do open source e possíveis limites futuros
- Essa situação é diferente de casos em que se burla um SaaS comum que não permite self-hosting
- O Xen Orchestra pode ser hospedado gratuitamente por conta própria com tudo incluído
- Não há limitação de recursos, apenas uma experiência de upgrade menos conveniente que a do XOA
- O fato de terem preferido criar contas de teste repetidamente em vez de ler uma documentação curta e digitar alguns comandos também mostra o valor da conveniência do XOA
- A mesma organização passou os últimos 10 anos pedindo repetidamente testes gratuitos com contas pessoais de Outlook e Gmail, enquanto continuava informando o nome real da empresa
- Esse comportamento enfraquece a base que torna o open source sustentável
- No futuro, podem ser introduzidos limites mais inteligentes para impedir trial farming
- Não para bloquear usuários honestos
- E sim para gastar energia com desenvolvimento de software, suporte a usuários reais e manutenção do open source
1 comentários
Opiniões no Hacker News
Acho que chegou a hora de aplicar uma pressão à la Larry Ellison. No mínimo, esvaziar os bolsos deles e arrancar o troco.
Essa empresa está roubando. Vocês já foram suficientemente íntegros e generosos ao tentar ajudar empresas oferecendo uma opção OSS. Isso é abuso, não há motivo para tolerar.
Considerando o histórico, eu resumiria 10 anos de roubo e medidas de contorno em uma breve notificação de cessação e desistência (C&D), informando que, se não pararem ou comprarem uma licença em 15 dias, serão cobrados 10 anos de taxas de licença, juros e multas. Especialmente se, no 16º dia, vocês tiverem que desligar o software, alguém certamente entrará em contato.
Parece ser uma quantia considerável, mas também é uma questão de ética e responsabilidade. Como CEO, é preciso avaliar se a responsabilidade maior é com funcionários e acionistas ou com essa empresa espacial. Mesmo que a empresa seja extremamente rica, vejo uma forte obrigação, como CEO, de tentar recuperar ativos roubados.
Se for uma empresa dos EUA, esse comportamento provavelmente pode se enquadrar nas disposições anti-circunvenção do DMCA. Nesse caso, também poderia haver responsabilidade criminal individual. Considero o DMCA uma lei terrível, que permite que empresas criem responsabilidade criminal por meio de contratos de licença, mas, nos EUA, ela é a lei vigente; se um advogado explicar esse ponto, é bem provável que os advogados do outro lado logo venham negociar.
Não acho que chegaria ao tribunal. A conduta em si é indefensável; a única questão seria quanto eles devem pagar à empresa do OP.
Pode levar tempo, mas no fim dá para receber.
“Não vou perder tempo perseguindo isso por dias. Mas, a partir de certo ponto, deixa de ser só economizar uns trocados e vira arte performática” — por favor, corra atrás.
Muito provavelmente isso viola os termos do teste gratuito, então deveriam levá-los ao tribunal. Se não, no mínimo deveriam divulgar o nome da empresa para expô-la. Talvez o gerente idiota que arquitetou esse roubo ridículo seja demitido e alguém mais maduro assuma.
Não estou correndo para tomar medidas legais agora. No momento, não parece valer muito a energia, mas senti que era necessário apontar publicamente esse tipo de comportamento. Também serve de sinal para outras pessoas do ecossistema sobre as besteiras que mantenedores de OSS às vezes precisam enfrentar.
Ainda estou segurando a divulgação direta do nome da empresa, mas não descartei completamente.
Algo como: “Nosso produto é tão bom que empresas aeroespaciais estão literalmente roubando para usá-lo. Mas, por acaso, você já viu nosso novo teste de 30 dias? Voltando àquela empresa aeroespacial, dê uma olhada no nosso produto atual e veja como é barato usar nosso software…”
As pessoas sempre encontram uma forma de usar até o limite ou abusar. É preciso pensar onde colocar restrições entre experiência do usuário e prevenção de abuso.
Em uma empresa de US$ 1 bilhão onde trabalhei antes, alguém tinha criado algo tipo um proxy para que cerca de 100 pessoas usassem uma única conta gratuita de usuário.
Precisávamos de mais recursos, então também avaliamos produtos concorrentes, e participei de uma reunião para decidir se continuaríamos com o método existente ou migraríamos para uma solução melhor. Os dois produtos foram comparados de forma justa, com exceção do preço.
O plano era continuar usando ilegalmente sem pagar o que deveria ser pago, ou usar outro serviço que teria sido mais barato se usado legalmente. Levantei a questão de que, para comparar, deveríamos no mínimo comparar os custos reais, mas ninguém concordou; no fim, decidiram não migrar e continuar usando ilegalmente. Dinheiro nem era o problema.
A pessoa que criou isso já tinha saído da empresa, mas ninguém queria lidar com o problema e parece que decidiram que era mais fácil simplesmente ignorar.
Se a “Rocket Company” usava em média 30 equipamentos por mês, a no máximo US$ 1.600 por mês, isso daria cerca de US$ 600 mil por ano antes de descontos. Em 10 anos, podem ter segurado algo como US$ 3 milhões.
Para a Vates conseguir receber, acho que teria que tirar o controle da organização operacional que faz o trabalho real e abstraí-lo para uma organização central de TI.
Gosto da expressão “mas, a partir de certo ponto, deixa de ser só economizar uns trocados e vira arte performática”. Bom humor e bom caso.
É bem provável que a empresa esteja gastando mais dinheiro em tempo de funcionários do que no custo do produto.
É difícil até imaginar alguém rodando algo mission critical em uma versão de teste gratuita. Lembro de ter ouvido que a Adobe perdeu um processo antes; alguém tinha criado uma imagem na versão de teste gratuita e depois não conseguia abri-la quando o período de avaliação acabou.
Se eu fosse cliente dessa empresa, ficaria bem preocupado.
Basta dizer: “Seu teste gratuito acabou e sua empresa não pode mais receber chaves de teste gratuito”. Isso não exige advogado nem ameaça.
Diga de forma educada, como: “Ficamos felizes que vocês gostem do nosso produto. Infelizmente, não podemos mais atendê-los por meio de testes gratuitos”.
Se continuarem escondendo a afiliação para obter testes gratuitos, bloqueie cada solicitação falsa quando descobrir e, como último recurso de verdade, envie uma notificação legal. Talvez não consigam pegar todas, mas para o outro lado será muito incômodo.
O objetivo é fazer o onboarding deles como clientes pagos. Qualquer outro resultado é essencialmente perda. Seja educado, mas firme.
O mais deprimente é que isso não é nada surpreendente
É exatamente por isso que testes gratuitos pedem primeiro um cartão de crédito. Não é para cobrar escondido, mas porque é mais difícil de falsificar. Por causa de gente assim
Parece uma prática que talvez impeça quem quer abusar casualmente de trials, mas só incomoda clientes pagantes de verdade e quase não barra agentes mal-intencionados
Como CTO, sou bem contrário a esse tipo de comportamento, e acho que a responsabilidade é do CTO da empresa aeroespacial
Economizar e sobreviver no começo faz parte do trabalho, mas, quando a receita começa a entrar, é preciso converter o plano gratuito para um plano inicial conforme a escala aumenta
É lamentável que haja pessoas no nosso setor agindo desse jeito
Pessoalmente, vejo o plano gratuito de cloud/SaaS como algo que compensa o custo inicial de uso. Então, a menos que seja uma escala realmente pequena, o plano gratuito não é adequado
Passei por algo parecido em uma startup voltada a consumidores por causa de um programa de indicação
Todo mês, como um relógio, uma pessoa criava indicações falsas para ganhar um mês grátis, passando por um processo bem trabalhoso: reinstalar o app, criar conteúdo em contas falsas e depois voltar. Tudo isso para economizar 5 dólares, e havia um plano gratuito de qualidade quase igual
Acho que a adrenalina de vencer o sistema e não ser pego também era um fator bem grande. Dá para entender
Quando trabalhei no departamento de TI de uma grande empresa, o esforço necessário para comprar software era tão absurdo que qualquer “solução criativa” parecia muito melhor
O pior é que softwares baratos são os mais prejudicados. Um upgrade da Cisco de milhões de dólares não é problema. Afinal, já custa milhões. Mas, para comprar uma licença shareware de e-mail de 10 dólares, várias pessoas teriam que gastar muitas horas de trabalho; quem faria isso?
Mas, de forma constrangedora, a pessoa responsável disse ao CEO que havia uma regra: a empresa só podia usar OSS. Só que o próprio produto da empresa deles não era OSS
Supondo que essa história seja bastante precisa, fico curioso sobre o que os dois lados estavam pensando
Do lado de quem usava de graça, será que achavam que estavam dentro das regras? Até que nível hierárquico subiu a aprovação para continuar usando esse método? Alguém tentou pagar, mas foi bloqueado? Será que alguém disse ao chefe que tudo havia sido feito internamente e agora não quer admitir que terceirizou e que a empresa ficou exposta? Será que isso chegou até o topo, e um advogado aconselhou que, se colocassem o nome da empresa e o nome real toda vez, poderiam ficar protegidos por agir de boa-fé?
Do lado do fornecedor, ao ver um usuário corporativo preso ali por 10 anos, por que um vendedor não partiu para cima? Como deixaram isso acontecer por 10 anos sem mudar um pouco a política para bloquear esse caronista e outros que poderiam copiá-lo? Nesse período, quando esse assunto surgia, o que o pessoal de negócios dizia? O negócio estava indo tão bem que não valia o tempo de convertê-los em clientes pagantes?
https://250bpm.substack.com/p/accountability-sinks