O dispositivo que controla minha bomba de insulina usa o kernel Linux, mas viola a GPL

• Um controlador de dispositivo médico que controla uma bomba de insulina funciona com base no kernel Linux
• Esse dispositivo está em violação de licença por não cumprir os termos da GPL (Licença Pública Geral)
• Usuários apontam como problema o fato de a obrigação de divulgação do código-fonte não estar sendo cumprida
• Na comunidade, discutem-se em conjunto a transparência do software de código aberto e a confiabilidade dos dispositivos médicos
• A violação da GPL chama atenção como um caso que revela os limites do uso de código aberto no setor de dispositivos médicos

---

Controlador de bomba de insulina baseado no kernel Linux

• Um dispositivo que controla uma bomba de insulina está usando o kernel Linux
  • O aparelho executa a função de ajustar automaticamente a administração de insulina
  • Foi confirmado por usuários que o kernel Linux está embarcado no dispositivo
• Esse dispositivo está violando os termos da licença GPL
  • A GPL determina que produtos que usam o kernel tenham a obrigação de divulgar o código-fonte
  • No entanto, esse dispositivo está sendo vendido sem acesso possível ao código-fonte

Problema de violação da GPL e transparência do código aberto

• Usuários apontaram a violação da GPL e exigiram a divulgação do código-fonte
  • Embora esteja claro que o kernel é usado, o fabricante não fornece o código
• Na comunidade, há críticas ao fato de fabricantes de dispositivos médicos ignorarem obrigações de código aberto
  • A violação da GPL vai além de uma simples questão legal e também afeta a segurança e a confiabilidade dos usuários

Conflito entre dispositivos médicos e código aberto

• No setor de dispositivos médicos, políticas de firmware fechado são comuns
  • Isso gera conflitos legais e éticos com a comunidade de código aberto
• A violação da GPL em dispositivos médicos que usam o kernel Linux é citada como um caso representativo de falta de transparência
  • Quando tecnologias baseadas em código aberto são aplicadas a dispositivos médicos, é importante cumprir a obrigação de divulgação

Reação da comunidade

• Alguns usuários pedem medidas para forçar o cumprimento da GPL
  • Eles defendem que o fabricante deve divulgar o código do kernel
• Outros usuários discutem em conjunto a segurança dos dispositivos médicos e a questão da responsabilidade legal
  • Aponta-se uma lacuna regulatória quando software de código aberto é usado em dispositivos médicos

Implicações

• Este caso chama atenção como um exemplo raro de violação da GPL ocorrendo em um dispositivo médico real
• Ele mostra a necessidade de um equilíbrio legal e ético entre a comunidade de código aberto e a indústria de dispositivos médicos
• No futuro, será necessário reforçar o cumprimento de licenças em produtos que usam o kernel Linux

[GN⁺]

Comentários no Hacker News

• Tentei pedir à Insulet o código-fonte do kernel licenciado sob GPLv2
  Mas dizer simplesmente “tem GPL, então eles têm que me dar o código” é um mal-entendido
  Na prática, a empresa precisa enviar ao usuário uma “oferta por escrito (written offer)”, e o usuário pode solicitar o código-fonte com base nessa oferta
  Se a empresa enviou a oferta e não a cumpre, isso seria quebra de contrato; mas, se nem chegou a enviar a oferta em primeiro lugar, isso vira violação da GPL (não sou especialista em direito)
  • Isso ainda é uma questão juridicamente não pacificada
    O caso Conservancy v Vizio discute se consumidores também têm o direito de fazer cumprir a GPL diretamente
  • O prazo de validade de 3 anos da oferta por escrito é apenas uma entre várias formas de distribuição
    Se não houve oferta, ela não fica protegida por essa cláusula e precisa cumprir a GPL por outros meios
  • Sobre a pergunta “uma oferta por escrito é quebra de contrato?”, há quem entenda que uma simples oferta não é a mesma coisa que um contrato
  • Essa interpretação pode até valer nos EUA, mas na Alemanha até o usuário final pode exigir diretamente o código-fonte e processar
  • A própria GPL é um contrato, então a distinção aqui é entre o contrato entre licenciador e licenciado e a relação entre licenciado e usuário
• Eu realmente recomendaria ler o comentário mais votado escrito por alguém de dentro da empresa
  Desenvolvimento de hardware costuma ser tratado como centro de custo e terceirizado, então muitas vezes não sobra ninguém para lidar com pedidos ligados à GPL
  A equipe de suporte da linha de frente não tem capacidade para tratar esse tipo de solicitação, e os e-mails acabam circulando internamente até serem esquecidos
  Quando chega ao jurídico, eles fazem as contas para ver “isso é mesmo um risco legal real?” e, na maioria das vezes, ignoram
  Quando trabalhei numa empresa que tinha muitos problemas ligados à GPL, eu fazia questão de guardar um tarball GPL de cada release e também treinava o suporte
  Em 70% dos pedidos, a raiva vinha do mal-entendido de “por que vocês não entregam o código inteiro?”
  Essa experiência me fez entender por que o suporte evita pedidos relacionados à GPL
  • Mas, se houver código não GPL linkado diretamente com código GPL, a reclamação desses usuários pode ter sido legítima
• Nesses casos, o certo é entrar em contato com a empresa pela via jurídica, por meio de advogado
  Engenheiros ou a equipe de suporte não vão tomar uma decisão legal de entregar ativos da empresa
  Seria de grande ajuda se a FSF publicasse um modelo de notificação extrajudicial com a fundamentação legal e o procedimento para pedir indenização
  • Também há o contra-argumento de que “isso não é um ativo da empresa”
• Se a única parte coberta pela GPL for apenas o kernel Linux, então provavelmente não existe quase nenhum direito especial de receber código-fonte
  O simples uso do kernel não impõe obrigações da GPL aos programas em espaço de usuário (userspace)
  O mais provável é que seja uma combinação de kernel não customizado com programas de espaço de usuário de código aberto
  • Nesse caso, fornecer o código-fonte deveria ser algo muito simples de resolver
  • Além disso, módulos de driver que usam um shim GPL (por exemplo, o driver da NVIDIA) não entram sob a GPL, então não entendo por que o autor acha que isso seria uma violação
• Esse tipo de discussão sobre violação de licença é realmente estressante
  Se for violação mesmo, então basta entrar com uma ação e deixar o tribunal decidir
  Sendo um dispositivo médico, talvez já valha a pena tentar mesmo com algumas centenas de dólares
  • Mas é bem provável que o OP não seja o detentor dos direitos autorais do kernel Linux
  • E, além disso, não há chance de um processo terminar custando só algumas centenas de dólares
• Se eles compilaram o kernel diretamente, talvez bastasse informar o link do repositório oficial do kernel Linux
  • Mas, se a empresa compilou isso diretamente para fins comerciais, então ela não cumpre ambas as condições do GPLv2 3(c), então essa cláusula não se aplica
• Não seria sobre o Omnipod?
  Já houve muitos recalls, e é difícil confiar na qualidade do hardware e do software deles
  Desculpas a quem trabalha ou trabalhou nessa empresa, mas espero que hoje esteja num lugar melhor
• Como alguém que não depende de insulina, o que me deixa curioso é por que uma bomba de insulina precisaria ser controlada por celular
  Um controlador Bluetooth já deveria bastar, então usar um celular barato chinês parece aumentar o risco de vazamento de dados
  • É por segurança. O PDM fica totalmente isolado, sem possibilidade de instalar apps nem de se conectar ao Wi‑Fi
    Se for controlado de forma incorreta, pode acontecer uma superdosagem fatal de insulina
    Curiosamente, o Omnipod 5 da mesma empresa pode ser controlado por smartphone comum nos EUA
  • Antigamente, para controlar a bomba com um dispositivo externo, era obrigatório fornecer um controlador dedicado
    Foi por isso que a Insulet lançou um aparelho separado
    CGMs como o Dexcom G7 também são vendidos com um “controlador” pelo mesmo motivo
    Mais recentemente, o FDA flexibilizou essa exigência, e agora também permite produtos concebidos para usar o celular do próprio usuário
• Na verdade, esse dispositivo já passou por engenharia reversa (RE)
  Dá para ver isso em projetos como Loop, Trio e OpenAPS
  A Insulet foi relativamente tolerante com esse tipo de hack
  O que falta agora é ajudar na RE do Omnipod 5
  • Eu também estou em contato com algumas pessoas que conhecem o trabalho de RE do Omnipod 5
    O problema atual é que o PDM/app busca uma chave privada na API ao fazer login e a salva no keychain, além de usar SSL pinning para impedir ataque man-in-the-middle
    Ainda não conseguimos extrair a chave privada, então o progresso está lento
  • Estou tentando fazer RE da leitura de dados de glicose das bombas Minimed (780G), mas ainda não resolvi tudo
    Espero conseguir contribuir algum dia
• Eu tinha curiosidade se existe algum processo para peticionar isso à FSF
  Queria saber por quais critérios eles escolhem os casos
  • Na prática, quem cuida disso não é a FSF, e sim a SFC (Software Freedom Conservancy)
    A teoria dominante é que só o detentor dos direitos autorais pode fazer cumprir a GPL
    A SFC quer que o processo contra a Vizio reconheça que o usuário final também pode fazer cumprir a GPL como terceiro beneficiário
    A FSF só pode intervir quando recebeu cessão de direitos autorais, como no projeto GNU
    Violações relacionadas ao GNU podem ser denunciadas em [e-mail]
    A SFC também é representante legal de vários projetos, como OpenWrt, Git e QEMU
    Para denunciar, vale consultar a página de orientação da SFC
    Mas a SFC tem recursos limitados, então prioriza casos de maior impacto social, como dispositivos médicos
    Em especial porque há pessoas como Karen Sandler (usuária de desfibrilador cardíaco) e Bradley Kühn (usuário de monitor de glicose) que têm grande interesse em questões ligadas a dispositivos médicos