1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • AI 로봇이 오픈소스 프로젝트를 독립적으로 재구성해, 법적으로 구별되는 코드와 기업 친화적 라이선스를 제공
  • 원본 코드를 보지 않고 문서·API·타입 정의만 분석해 기능적으로 동일한 소프트웨어를 새로 작성
  • 결과물은 MalusCorp-0 라이선스로 배포되어, 저작권 표기·소스 공개·수정 공유 의무가 없음
  • 사용자는 package.json 등 의존성 목록을 업로드하면, 패키지 크기당 $0.01/KB 기준으로 자동 견적 산출
  • 오픈소스 라이선스 준수 부담을 제거하고, 기업의 법적 리스크 최소화를 목표로 함

오픈소스의 문제점

  • Apache License 표기 의무로 인해 문서에 “이 소프트웨어의 일부는…” 같은 문구를 넣어야 하는 점을 불편으로 지적
  • AGPL 라이선스는 코드 일부만 사용해도 전체를 공개해야 하는 위험이 있어, 기업에서 금지되는 경우가 많음
  • 수백 개의 의존성에 대한 라이선스 추적과 감사가 시간과 비용을 초래함
  • 일부 라이선스는 수정 사항을 커뮤니티에 환원해야 하며, 이는 주주 이익과 상충된다고 설명

해결책: Robot-Powered Clean Room Recreation

  • AI 기반 클린룸 재구성 시스템이 원본 코드를 전혀 보지 않고 문서와 API 명세만 분석
    • 분석 로봇과 구현 로봇이 서로 격리된 팀으로 운영되어, 복제나 파생 저작이 발생하지 않음
  • 결과물은 법적으로 독립된 코드로 간주되며, 사용자는 이를 완전히 소유
  • 주요 특징
    • 100% 로봇 작성 코드
    • 원본 코드 노출 0%
    • 기능적으로 동일한 결과물
    • 기업 친화적 라이선스 선택 가능
    • 법적 면책 보장 (해외 자회사 명의)

Liberation 절차

  • 1단계: 매니페스트 업로드
    • package.json, requirements.txt, Cargo.toml 등 의존성 목록을 업로드
  • 2단계: 격리된 분석
    • 로봇이 README, API 문서, 타입 정의만 검토
  • 3단계: 독립적 재구성
    • 별도의 로봇 팀이 명세 기반으로 코드를 새로 작성
  • 4단계: 라이선스 해방
    • 결과물은 MalusCorp-0 License로 제공
      • 기존 오픈소스 의무(표기, 수정 공유, 소스 공개 등) 제거
      • 사용자는 수정·배포·상용화에 제한 없음

가격 정책

  • 용량 기반 과금: npm 기준 패키지의 압축 해제 크기(KB) × $0.01
    • 최소 주문 금액 $0.50
    • 예시: lodash(1.3MB) → $13.78, moment(4.1MB) → $42.48
  • 포함 항목
    • AI 클린룸 재구성 및 MalusCorp-0 라이선스
    • CSP 명세 문서 10종
    • 최대 10MB 패키지, 50개 패키지까지 주문 가능
    • 구독료 없음, 해방한 만큼만 결제

보증 및 사례

  • MalusCorp Guarantee™: 침해 발생 시 전액 환불 및 본사 이전(국제 해역) 약속
  • 성공 사례
    • AGPL 종속성 847개를 3주 만에 해방, 인수 과정에서 라이선스 문제 ‘0’
    • 법무팀의 400만 달러 예상 비용을 5만 달러로 절감
    • 2,341개 npm 패키지를 재구성해 컴플라이언스 대시보드가 즉시 정상화

자주 묻는 질문

  • 합법성: 원본 코드를 보지 않은 독립적 재구성으로, 법적 선례에 기반
  • 원 개발자 보상 여부: 오픈소스로 공개한 것은 그들의 선택이며, 별도 보상 의무 없음
  • 복제와의 차이: 동일 기능을 독립적으로 구현한 것이며, 의도와 과정이 다름
  • 버그 발생 시: 기능적 동등성만 보장, 버그는 사용자 소유
  • 로봇 공개 여부: 위치 비공개, 엔터프라이즈 고객에 한해 NDA 체결 후 견학 가능
  • 지원 라이선스: MIT, Apache, GPL, AGPL, LGPL, BSD, MPL 등 모든 라이선스 해방 가능

결제 및 이용

  • Stripe를 통한 안전 결제 후 자동 처리
  • 견적은 무료, 결제는 USD·EUR·BTC·주식옵션 지원
  • “충분한 로봇이 있다면 오픈소스 의무는 단지 제안일 뿐”이라는 문구로 서비스 마무리
Hacker News 의견들
  • Malus.sh 블로그을 읽으며 흥미로운 점을 발견했음. 수십 년간 느껴온 문제인데, 법체계가 여전히 다루지 못한 부분이 있음. 바로 집행 비용(costs matter) 의 문제임
    예를 들어 제한속도 55mph 표지판을 세우는 것만으로는 충분하지 않음. 사람을 투입해 간헐적으로 단속하는 것과, 로봇으로 완벽히 단속하는 것은 완전히 다른 정책임. 법 문구는 같지만 실제 정책은 전혀 다름
    과거에는 법이 de jure(명목상)de facto(실질상) 로 달랐지만, 이제 기술로 인해 두 개가 일치할 수 있게 되었음. 그러나 아무도 그 변화의 크기를 인식하지 못하고 있음. 집행이 쉬워질수록 법의 의미가 완전히 달라짐. 수 세기 동안 법은 ‘집행이 어렵다’는 전제를 깔고 만들어졌는데, 이를 맹목적으로 자동화하는 것은 모두에게 나쁜 아이디어
    언젠가 법적 판례에서 ‘집행 비용’이 합법성 판단의 일부로 고려되는 날이 올지도 모름

    • 정밀한 법 집행을 환영해야 한다고 생각함. 불완전한 집행은 선택적 단속으로 이어지고, 이는 법 집행자가 임의로 법을 바꾸는 권력을 갖게 함. 하지만 집행이 완벽해질수록 규칙과 처벌도 함께 조정되어야 함. 그렇지 않으면 사회적 혼란이 생김. 법은 원래 느리게 바뀌도록 설계되었지만, 이제는 그 속도를 따라가지 못할 수도 있음
    • Dean Ball이 Ezra Klein 쇼에서 같은 주제를 언급했음. 완벽한 집행이 정의를 가져올 거라 생각했지만, 이행 계획(migration plan) 이 없다면 아무 의미 없음. AI가 멋진 미래를 약속하지만, 그로 가는 전환 과정이 가장 어려운 부분임
    • 이 문제는 양방향임. 많은 정부 기관이 시민의 서면 요청에 응답해야 하는 법적 의무가 있는데, 과거엔 사람들이 편지를 거의 쓰지 않았음. 하지만 LLM 덕분에 누구나 쉽게 공식 서한을 작성할 수 있게 됨. 이제 ‘불만 편지’를 자동으로 써주는 AI가 등장하면 행정 시스템이 감당하기 어려워질 것임
    • Pamela Samuelson과 Suzanne Scotchmer의 논문(Yale Law Journal PDF)을 보면, 저작권법도 ‘비용이 존재하는 우회로’를 긍정적으로 봤다고 함. 즉, 완전히 무료이거나 자동적인 우회는 바람직하지 않다고 본 것임. 법체계가 비용의 중요성을 암묵적으로 인식하고 있었다는 점이 흥미로움
    • ‘집행 비용이 중요하다’는 관점을 정말 좋아함. 18~19세기 법률은 경찰력이 제한적이라는 전제에서 만들어졌지만, 지금은 감시 기술이 모든 것을 바꾸고 있음. 완벽한 집행은 프라이버시 비용을 초래함. 다만 자동화된 집행이 선택적 단속의 불공정을 줄일 수도 있다는 점은 반론으로 남음
  • 처음엔 이게 풍자인 줄 몰랐음. 하지만 곰곰이 생각해보면, OSS 개발자에게 수익을 돌려주는 모델로 발전할 수도 있을 것 같음. 예를 들어 “clean room as a service”를 만들되, 수익이 Malus.sh가 아니라 원 저작자에게 돌아가게 하는 구조임. 모든 OSS가 AGPL 같은 라이선스로 전환하고, 기업은 맞춤형 구현을 의뢰해 대가를 지불하는 방식임. 이런 시스템의 MVP가 궁금함

    • 실제로 이 사이트는 풍자가 아님. Stripe 결제도 가능하고, 진짜로 코드를 생성함. 다만 풍자적 언어로 포장되어 있을 뿐임
    • 혹시 진지하게 제안한 거라면, 이미 존재하는 이중 라이선스 방식으로도 가능함. 농담이라면 재밌지만, 진심이라면 오해일 수도 있음
    • Copyleft의 본래 목적은 소프트웨어의 자유(freedom) 를 지키는 것이었음. 코드 일부를 잠그는 제안은 그 원칙에 정면으로 반함
    • 나도 처음엔 풍자인 줄 몰랐지만, 사이트 하단의 가짜 후기들을 보고 바로 눈치챘음. “AGPL 의존성 847개를 3주 만에 해방시켰다” 같은 문구는 정말 웃겼음
    • 이런 모델이 잘 작동할 수도 있음. OSS 개발자는 영업이나 컨설팅에 신경 쓰지 않고 개발에만 집중할 수 있음. 기업 후원도 필요 없음
  • “오픈소스 유지보수자에게 죄책감을 느꼈지만, 분기 실적엔 죄책감이 반영되지 않는다”는 문구가 너무 현실적임.
    ◆ Chad Stockholder, Profit First LLC 엔지니어링 디렉터

    • OSS와 상업 소프트웨어의 관계는 늘 도덕적 긴장과 순진한 이상주의가 섞여 있음
  • “지옥을 믿진 않지만, 만약 있다면 이런 사람들을 위한 자리가 있길 바람”이라는 반응이 나올 정도로 강한 거부감이 듦. “오픈소스 라이선스 의무에서 해방시켜준다”는 문구는 듣기만 해도 불쾌함. 게다가 “우리 AI는 원본 코드를 본 적이 없다”고 주장하는데, 그걸 독립 감사로 어떻게 증명할 수 있을지 의문임. 풍자라지만 혈압이 오름

    • 풍자이긴 하지만, 사실 FLOSS 라이선스는 내부 사용에 대해 공개 의무가 없음. AI가 완전히 새로운 구현을 만든다고 해도, 저작권 보호는 여전히 불완전함
    • 실제로 이 프로젝트는 FOSDEM에서 발표된 풍자임. 작성자들도 오픈소스 커뮤니티 출신임
  • 처음엔 풍자인 줄 몰랐는데, 그게 오히려 지금의 현실을 보여주는 것 같음. 세상이 너무 빠르게 변하고 있음

    • 이 사이트는 실제로 Stripe 결제가 가능함. 풍자처럼 보이지만 진짜 서비스임
    • 나도 처음엔 풍자인 줄 몰랐지만, 가짜 후기를 보고 안심했음. 아직 현실이 아니어서 다행임
    • 하지만 이름이 ‘Malus’인 걸 보면, 나중에야 풍자임을 깨닫게 됨
    • 이름이 뭐가 됐든, 이런 일은 결국 현실화될 것 같음
  • 전통적인 클린룸 구현(clean-room implementation) 은 팀을 분리해 한쪽이 명세를 쓰고 다른 쪽이 구현하는 방식이었음. 하지만 LLM은 이미 원본 코드를 학습했을 가능성이 있음. 그렇다면 진짜 법적 쟁점은 “모델 자체가 오염된 방인가?” 하는 질문임

  • 실제 사례로 chardet 이슈 #327#331을 보면, 누군가 이런 접근을 시도하고 있음

    • Opus 4.6 모델이 웹 접근 없이도 chardet의 전체 소스코드를 기억하고 재현했다는 예시가 있음 (gist 링크)
    • 10년 넘게 프로젝트를 유지해온 개발자가 MIT 라이선스 재구현을 위해 노력했는데, 오히려 커뮤니티가 그를 비난함. 이런 반응은 너무 안타까움
    • 이건 별도의 토론 주제로 다뤄야 할 만큼 중요한 사례임
  • “만약 우리 코드가 침해로 판명되면 전액 환불하고 본사를 공해상으로 이전하겠다”는 문구는 정말 천재적인 풍자임. 미래를 예견하는 듯함

    • 풍자 완성도가 매우 높음. 처음엔 진짜처럼 보이지만, 읽다 보면 곳곳에 의도적 단서가 숨어 있음. 현실이 될 수도 있다는 점이 오히려 무섭게 느껴짐
  • 나는 처음 “클린룸” 개념을 야구 통계 데이터베이스에서 접했음. 공식 데이터가 무료이지만, 그 포맷과 구조는 저작권이 있을 수 있어서 팬들이 독립적으로 데이터를 재구성했음. Baseball Mogul 같은 게임도 이를 사용했었음. 앞으로 이런 형태의 독립 재구현 노력이 더 많아질 것 같음

  • 정말 훌륭한 풍자임. 그런데 왜 아직 아무도 실제로 이런 서비스를 만들지 않았을까? 오픈소스를 이용해 이익을 취하려는 사람들은 충분히 있을 텐데. 혹시 소송 리스크가 너무 커서일까, 아니면 이미 누군가 시도 중일까?

    • 사실 누구나 최신 LLM을 사용할 수 있으니, 굳이 제3자에게 돈을 내고 “클린룸 구현”을 맡길 이유가 없음. 진짜 가치는 법적 리스크를 대신 떠안아주는 포장(wrapper) 에 있을 것임
    • 세상엔 악의적으로 행동할 수 있는 기회가 많지만, 대부분의 사람은 도덕적 제약을 가지고 있음. 다만 이런 아이디어가 공개되면 모방 범죄(copycat crime) 처럼 실제 시도가 늘어날 수도 있음
    • 사실 이미 이런 일은 일어나고 있음. 개발자가 AI에게 “이 기능을 구현해줘, 참고로 이 GitHub 리포를 참고해”라고 하면, 의도치 않게 재구현이 일어남
    • 문제는 신뢰와 보안임. 기업 비밀을 SaaS에 맡기기보단 로컬 AI로 처리하는 게 낫다고 생각함. 이미 그런 시스템은 존재하고 활발히 쓰이고 있음
    • 그리고 현실적으로 LLM은 아직 복잡한 코드를 완벽히 작성할 수준이 아님. 그래서 이런 서비스가 실제로 작동하기는 어려움