- Uma história baseada em fatos reais sobre os riscos do vendor lock-in e de práticas comerciais agressivas
- Órgãos públicos tentam migrar seus sistemas de e-mail para uma base open source, mas acabam enfrentando contratos injustos e suspeitas de vigilância por parte do fornecedor
- Cláusulas escondidas no contrato e alterações unilaterais impedem a saída livre dos clientes e fazem os custos de administração dispararem
- Mesmo quando surgem indícios reais de vigilância e leitura de e-mails, as organizações se mostram mais preocupadas com o aumento de custos do que com respostas legais e éticas
- Até empresas que defendem o espírito do open source acabam envolvidas em casos de abuso, deixando apenas danos à confiança e uma imagem negativa para todo o setor
Prefácio do autor
- Esta história é baseada em experiência real, mas, para proteger a identidade de pessoas e empresas, parte da tecnologia, dos detalhes e do contexto foi modificada ou mesclada
- Recomenda-se lê-la como um caso típico para discutir dois problemas disseminados no setor de TI: vendor lock-in e práticas de negócios agressivas
Andamento – adoção de um novo sistema de e-mail
- Alguns anos atrás, um importante órgão público (Agency A) usava um servidor de e-mail Exchange obsoleto
- As atualizações de segurança estavam há muito tempo sem ser aplicadas, o que criava grande exposição a riscos, e surgiram regras recomendando a adoção de open source
- Uma prestadora terceirizada propôs um serviço gerenciado baseado em uma stack de e-mail open source, ampliada por ela mesma e acompanhada de suporte enterprise
- O preço era semelhante ao que se via no mercado, mas, em relação ao serviço efetivamente entregue, o valor era excessivamente alto
- A Agency A já possuía uma infraestrutura confiável (múltiplos datacenters, faixas de IP robustas etc.)
- O pedido do órgão era: "avaliar essa solução e, se for adequada, migrar" (escopo: cerca de 500 caixas de e-mail e aliases)
Projeto-piloto e migração bem-sucedida
- O autor aplicou essa stack open source em um ambiente não crítico e em alguns clientes de teste com preço promocional, validando-a por um ano sem problemas
- Satisfeito com a flexibilidade do design, recomendou à Agency A uma migração piloto
- Foi feito o provisionamento de novos servidores, a configuração do domínio para os primeiros participantes e, em seguida, uma migração gradual
- Após a troca dos registros MX, a transição se estabilizou sem problemas, e a equipe interna da organização conseguiu manter a operação sem grandes incidentes
O rumor se espalha e surge um segundo órgão
- A Agency B já era cliente da mesma prestadora de serviço gerenciado
- Ao ver vantagens como redução do custo total para 1/10, maior autonomia sobre os dados e mais estabilidade, ela demonstrou interesse em migrar
- Porém, ainda restavam dois anos de um contrato com renovação automática de 5 anos, embora houvesse alguma margem de tempo por causa da cláusula de aviso prévio de 6 meses
- Com receio da política comercial agressiva do fornecedor e de possíveis retaliações, os preparativos foram conduzidos em absoluto sigilo
- Depois de concluir a configuração de contas, aliases e o conjunto de testes, planejou-se a migração real para coincidir com o momento da notificação de rescisão
Surge um terceiro órgão e um mau pressentimento
- A Agency C também usava o mesmo fornecedor e demonstrou intenção de migrar para a mesma stack open source
- O autor enviou um orçamento separado para a Agency C, sem mencionar a relação com a Agency B
- O processo parecia transcorrer bem, até que chegou um contato inesperado por SMS (dizendo que "não conseguia enviar e-mail")
Bloqueio da rescisão e indícios de vazamento de informações internas
- O responsável de TI da Agency B informou que "houve problemas na rescisão, e os preparativos internos para a saída foram expostos ao fornecedor"
- O fornecedor obteve acesso tanto aos planos internos do órgão quanto até ao orçamento que o autor havia enviado à Agency C
- A Agency C recebeu do fornecedor a alegação de que ele seria "o único instalador oficialmente autorizado daquele software", junto com acusações de concorrência desleal e até ameaças jurídicas
- Temendo um conflito potencial, o órgão desistiu do plano de migração
Suspeita de monitoramento de e-mails e teste
- Na Agency C, foi confirmado que uma conta com autenticação por token de um antigo administrador contratual externo tinha permissão de acesso a todos os e-mails
- Essa pessoa admitiu ter "avisado" o fornecedor, embora negasse ter mencionado o autor
- Para confirmar a suspeita de monitoramento de e-mails, foi enviado um orçamento falso por meio de um conhecido no exterior, após o que o fornecedor passou a mencionar imediatamente aquelas informações
- Com isso, ficou altamente evidente a possibilidade de leitura de e-mails
Cláusulas contratuais chocantes e a resposta do fornecedor
- Quando a equipe de TI apresentou uma reclamação formal, o fornecedor respondeu que isso era "permitido pelas cláusulas do contrato", apontando para alterações unilaterais aceitas dois anos antes
- Exemplos dessas alterações:
- extensão do prazo de aviso prévio de 6 meses para 12 meses
- possibilidade de transformar serviços antes gratuitos em pagos
- bloqueio de acesso fora do webmail sob o pretexto de "segurança" (algo que de fato foi aplicado imediatamente)
- Isso era possível numa era anterior à entrada em vigor do GDPR, quando a regulação ainda era insuficiente
Resposta passiva e danos adicionais
- O autor tentou esclarecer diretamente a controvérsia sobre concorrência justa e sobre ser um instalador não reconhecido, mas o fornecedor não respondeu às tentativas de contato
- Embora ele tenha recomendado aos dois órgãos uma investigação legal e ética, na prática eles se concentraram apenas no aumento de custos (cobrança por funções antes gratuitas e mais 30% de custo adicional)
- As organizações encerraram o assunto tratando apenas o peso no orçamento como problema, e não a corrupção interna nem a violação de dados pessoais
Desfecho e implicações
- Anos depois, todos os diretores responsáveis haviam sido substituídos, e apenas a equipe técnica permaneceu, agora mais cautelosa e arrependida
- No fim, tudo terminou com uma migração para um fornecedor mais seguro, porém nada inovador
- O autor não conseguiu resolver o problema em sua raiz
- Quando empresas que dizem oferecer suporte a open source adotam esse tipo de vendor lock-in ou comportamento antiético, todo o setor sai prejudicado
- O cerne do problema não é o software, mas a atitude das pessoas que lidam com ele
1 comentários
Comentários do Hacker News
Havia um ex-gerente interino de TI que continuava conectado ao cliente de e-mail por meio de autenticação por token e tinha acesso a todas as mensagens. Essa pessoa tinha sido a parte que originalmente firmou o contrato com o fornecedor no passado. Ao ser questionada informalmente, disse que entrou em contato “para alertar” e que não havia nenhum grande problema. Esse tipo de atitude realmente causa uma péssima sensação. É por causa de gente que vaza algo ou viola regras e depois diz que “não foi nada demais”. Um Director com quem trabalho também fez coisas parecidas várias vezes. Ele conhece um software em uma conferência, já marca uma demo e propõe um contrato. Depois promete trabalho antes a alguma empresa terceirizada que conhece. Como na prática não tem autoridade para fechar o contrato, só então entra em contato comigo. Isso aconteceu duas vezes mesmo depois que a seleção de produtos ficou sob minha responsabilidade. Toda vez eu estava sob um gerente diferente, mas ambos só diziam “não há problema nenhum”. Por fim, apontaram que esse hábito do Director de prometer trabalho e preparar contratos violava gravemente a política da empresa. O Director nem ligou, dizendo que era uma questão interna e que ninguém poderia puni-lo. Mais tarde, quando fomos revisar o produto, ele prometia que “ficaria melhor com o tempo”, e todos os dados da empresa estavam simplesmente indo para a IA. Não havia a menor preocupação com as regras de segurança de dados corporativos. Mesmo assim, o Director reagiu com indiferença: “qual é o problema, todo mundo lê os dados dos outros”. No fim, o departamento jurídico interveio e desativou a funcionalidade de IA. É realmente difícil confrontar colegas mal-intencionados ou imprudentes assim, especialmente quando a pessoa está acima de você. Eles tratam tudo como se fosse só um erro e seguem em frente, e ninguém consegue impor consequências
Trabalhei em duas empresas da Fortune 100. Vi repetidamente, de forma escancarada, gestores recebendo rebates pessoais de fornecedores. Quando apontei isso publicamente, pararam de me chamar para várias reuniões
O que esse Director fez é muito parecido com o que vi HR Directors fazerem o tempo todo. Eles adoram trocar, a cada 2 ou 3 anos e sem qualquer consulta, todo tipo de software caro de avaliação de desempenho. Pelo menos o Lattice, que é o favorito atual, tem uma UX razoável, mas o PeopleSoft que usávamos antes era realmente horrível
O pedido era simples: “avalie esta solução e, se fizer sentido, vamos migrar”. Mas tive que ler várias vezes para entender direito. A solução aqui se refere apenas a uma stack open source, sem o fornecedor mencionado no parágrafo anterior. No começo achei que o fornecedor também estava incluído, mas fui ficando confuso quando começaram as comparações
Eu também só entendi isso depois de ler alguns parágrafos
Interessante. Foi justamente nesse ponto que eu parei de ler
Isso parece coisa da Oracle. Claro que a Oracle faz esse tipo de coisa de forma muito mais sofisticada, mas eu sempre recomendo às pessoas que evitem produtos da Oracle sempre que possível
Espero ver o dia em que essa história venha a público com nomes reais
Segundo o autor, essa empresa move ações judiciais com muita frequência. É natural querer evitar a situação de ser processado pessoalmente por eles. Nem os próprios diretores da empresa deles provavelmente comprariam essa briga
Houve o comentário “espero que um dia os nomes reais sejam divulgados”. Mas a resposta foi que o texto é anônimo para “proteger a privacidade das pessoas envolvidas e da empresa”. Isso me faz pensar se empresas agora também têm direito à privacidade, mas eu entendo o sentimento. Já trabalhei em um lugar que fez algo absolutamente inaceitável durante um desastre natural. Quando levantei a questão, fui o único a sofrer sanção, enquanto meus colegas ficaram em silêncio e suportaram. Acabei saindo da empresa na primeira oportunidade. Isso já faz 20 anos, mas mesmo assim não é fácil colocar essa história por escrito. Já se passaram décadas, então às vezes parece que não faria diferença; a liderança mudou, o nome da empresa mudou, então o que restaria? Por isso tenho no meu blog um dead-man's switch para divulgar automaticamente várias coisas desagradáveis que empresas fizeram, mas também penso: mesmo que alguém veja isso, o que mudaria? Talvez só me deixasse mais irritado ou não servisse para nada. Ainda assim, eu sou uma dessas pessoas no HN que vive pedindo para divulgarem os nomes reais, então no fim também sou contraditório
Infelizmente, eles estão na UE, onde aparentemente a liberdade de expressão não é tão valorizada, nem legal nem culturalmente
Essa pessoa realmente parece trabalhar em um ambiente “campo minado”. Cada passo gera um problema, e há adversários poderosos envolvidos link relacionado
Posso estar confundindo o fuso horário ou as partes envolvidas, mas a frase “a empresa propôs uma versão autogerenciada e com funcionalidades próprias” me faz duvidar que isso seja realmente open source
Existem muitos projetos assim. Por exemplo, o Gitlab tem a Community Edition open source e também as edições Premium e Ultimate, pagas
Isso é um caso clássico de “seguir só a letra da lei”. Em leis europeias, especialmente em legislações nacionais da Europa, muitas vezes o setor público é obrigado a usar open source por motivos como garantir interoperabilidade, evitar vendor lock-in, assegurar soberania digital e seguir o princípio de que “dinheiro público = código público”. Usar software open source no servidor de outra pessoa tecnicamente pode até cumprir a exigência, mas, considerando o verdadeiro motivo de adotar open source, especialmente evitar vendor lock-in, a situação fica quase cômica
Você deve sempre ler cuidadosamente as cláusulas detalhadas do contrato antes de assinar. Isso vale para contratos de consumo em geral, mas em contratos empresariais é indispensável
Mesmo contratos pequenos de negócios não são exceção. Em uma organização sem fins lucrativos da qual faço parte do conselho, os funcionários pesquisaram multifuncionais de escritório e trouxeram um contrato. Disseram que já estava tudo analisado e que eu só precisava assinar, mas as cláusulas eram realmente chocantes. Por exemplo, se cancelássemos por qualquer motivo — até mesmo se a outra parte não cumprisse o contrato — teríamos de pagar imediatamente todo o valor restante do contrato. Como era uma estrutura de locação, o valor integral do equipamento já estava embutido nas mensalidades, mas a propriedade do equipamento continuava sendo da empresa. Ou seja, mesmo cancelando, o equipamento continuava com eles e nós é que pagaríamos tudo. Se houvesse disputa judicial, ainda teríamos de arcar integralmente com os honorários advocatícios do nosso lado. Eu disse que jamais aceitaria isso, e os funcionários ficaram irritados comigo por quase um ano porque “todo mundo assina esse tipo de coisa em outros lugares”
O conselho para ler as cláusulas em detalhe faz sentido, mas, olhando para o texto, às vezes isso também não adianta. Está cada vez mais comum os termos do contrato serem alterados “unilateralmente” sem nem avisar a outra parte. No setor de TI isso é quase rotina. Não adianta conferir as cláusulas de um contrato já assinado se elas já foram mudadas. Hoje em dia, se ao menos chega um e-mail avisando que os termos mudaram, você já teve sorte. A atitude é basicamente “e o que você vai fazer se não concordar?”. Se eu não fosse advogado, diria que isso é ilegal, mas como os courts nunca reprimiram isso de verdade, continuam repetindo
É preciso considerar como custo também o tempo e o esforço para interpretar e revisar o contrato, além do risco de entendê-lo errado. Pensando assim, muitas vezes é melhor simplesmente não fechar certos contratos
Tenho curiosidade sobre como essas “cláusulas de alteração unilateral” funcionam na prática. Se você não gostar dos novos termos, precisa avisar com 6 meses de antecedência e rescindir na hora?
Fiquei chocado ao ler o contrato de inscrição do ID.me. Ele pede que você renuncie “voluntariamente” à cidadania. Por isso não quero usar. Mas para entrar no IRS.gov não existe outro jeito. Para ver YouTube é preciso ter conta Google. Para participar do grupo de pais da escola no WhatsApp, você tem que aceitar os termos da Meta. Não tem fim esse tipo de situação
Não sou especialista jurídico, mas acho que, como o objetivo deles ao ler os e-mails e agir com base nisso era claramente ilegal, o próprio contrato deveria ser considerado nulo
Especialmente se isso for um órgão governamental, é realmente chocante. E se um fornecedor terceirizado instalasse secretamente um backdoor no servidor de e-mail e espionasse as mensagens? Pode ser qualquer coisa, de corrupção a atividade de inteligência estrangeira. Se isso acontecesse nos EUA, o FBI ou a CIA já teriam entrado para varrer esse problema de fornecedores
Sim. O problema é que, se você rescindir, vai acabar enfrentando em tribunal uma parte extremamente hostil, e ela fará de tudo para nos obrigar a pagar mais. Algumas organizações valorizam mais segurança do que ética e simplesmente absorvem o custo extra. Por outro lado, certamente há empresas que lutam contra processos abusivos de patentes, cláusulas contratuais absurdas e coisas do tipo. A organização deste caso claramente não era desse tipo
Não é aconselhamento jurídico, mas acho que esse tipo de coisa precisa ser exposto com nomes reais para servir de alerta
Imagino que muita gente no HN já tenha passado por algo parecido. Há algum tempo, estávamos fazendo de forma confidencial um trabalho de descontinuação de sistema, e o codebase era compartilhado entre a nossa empresa e a parceira. Um dos nossos desenvolvedores deixou em um commit algo como “Reversing Migration Script”, e menos de uma hora depois começou uma guerra total entre os CEOs das duas empresas. Só depois descobrimos que a outra empresa monitorava em tempo real certas palavras no código e, assim que percebeu sinais de que estávamos encerrando a relação, entrou em ação imediatamente. Na prática, era apenas um encerramento legal antes do fim do contrato, então não havia nada especialmente estranho. Depois que descobrimos que havia esse monitoramento, ainda começou uma caça às bruxas interna para descobrir “quem era o espião”. Foi uma experiência realmente difícil. Parece que hoje em dia esse tipo de comportamento nível psicopata virou algo normal. Só eu continuo trabalhando de forma inocente, como alguém de outra época, então faz sentido que tantas empresas só queiram contratar gente de 20 e poucos anos / meio brincando
Seria bom se você pudesse compartilhar especificamente como eles monitoravam isso. Dá para aprender com casos assim
Em lugares onde você pode estar sendo monitorado, é bom colocar nomes de variáveis que disparem alarmes com facilidade. Como aquelas piadas antigas sobre a NSA
Dizem que é uma “história de terror baseada em fatos reais”, mas fico curioso se é realmente verdade. Seria ainda mais interessante se os detalhes fossem mesmo factuais