Hacker News 의견
  • SaaS(Software as a Service) 허점을 막으려는 조항이 포함되어 있음에도 불구하고, EUPL은 여전히 누군가가 내 코드를 GPL-2.0-only나 GPL-3.0-only로 재라이선스하는 것을 허용함, 두 라이선스 어느 것도 SaaS 조항이 없어서, 이런 허점을 막으려는 시도가 무의미해지는 것 같음, 이 점에 대해 FSF도 언급함, 개발자 입장에서는 강력한 카피레프트 효과 기대가 힘들어 보임, 그래서 AGPL을 사용하는 편이 낫다고 생각함
    FSF 의견/관련정보 참고

    • EUPL 라이선스의 호환성 조항은 단순히 "코드 혼용이 가능하다"는 의미임, 원본 코드는 여전히 EUPL로 커버되고 혼합된 저작물에만 필요 시 호환 가능한 라이선스가 적용됨, 링크 수준의 조합이라면 각 소스는 각각 원래 라이선스가 유지됨, 이런 게 유럽 법에 따른 결과임, 저작권 예외 조항으로 인터페이스(API, 데이터 구조 등)는 자유롭게 산출물에서 사용 가능함, 그런데 단순히 원 저작물만 재라이선싱하려는 목적으로 사용하면 저작권 침해에 해당함
      공식 FAQ 링크
  • EUPL의 “호환 라이선스와 충돌할 시, 그쪽 의무를 우선한다”는 규정으로 인해, 충돌 상황에서는 호환 라이선스를 따르게 되고 이 경우에도 SaaS 공개 의무 등 주요 카피레프트 조건은 여전히 유효함, 그래서 허점을 막는 기능은 남아 있다고 봄, 다만 완전히 명확하지 않아서 해석에 따라 달라질 수 있음
    관련 공식 토론 링크

  • AGPL이나 GPL도 본질은 "인위적 희소성은 해롭고, 정보를 자유롭게 공유해야 하며, 혜택을 얻은 자가 그만큼 기여해야 한다"는 의도임, 현실적으로 오픈소스 라이선스 조항은 거대 기업이나 정부에 대한 법적 무력이 있음, 왜냐하면 그들이 더 많은 변호사를 고용해서 법을 자기들에게 유리하게 다시 쓸 수 있기 때문임, 그래서 오픈소스 라이선스 집행은 사회적으로 되어야 함, 위반 기업을 보이콧하거나 공공의 압박을 가할 수 있음, 반면 다른 오픈소스 프로젝트에는 보다 관대하게 접근할 수 있음

  • 라이선스 호환성은 "같이 사용해도 된다"는 의미임, 두 라이선스가 충돌하지 않으면 함께 사용할 수 있음, 보통 더 엄격한 쪽 조항을 지켜야 하며, 예로 GPLv2와 Apache는 서로 안 맞지만 GPLv3가 출시된 후에는 업그레이드로 해결됨, EUPL로 GPLv2로 재라이선싱하는 건 당장은 안 되지만, GPLv2 코드를 쓸 수는 있음, 이런 재배포 조항이 중요함

  • EUPL은 여러 법적 틀에서 GPL이 명확히 다루지 않는 점들을 보완해서 좋다고 생각함, 특히 EU 관할임을 명확하게 밝히는 점이 좋음, 여러 언어로 작성되어 EU 내 수용성을 높이려는 것도 긍정적으로 봄, 호환 라이선스 목록이 가장 마음에 듦, 만약 내 판단이 맞다면, GPL과 EUPL 소프트웨어를 조합해서 새로운 소프트웨어를 GPL로 공개하는 게 가능할 듯함, 반대로 EUPL로도 자유롭게 공개할 수 있으면 더 좋겠음

    • 대부분의 라이선스는 영미권 법률만 가정하지만, EU법과는 미묘한 차이가 많음

    • 호환성 조항 때문에 오히려 EUPL이 무의미해지는 느낌임, 누군가 내 EUPL 코드를 GPL로 바꿔버리면 결국 EUPL 프로젝트는 사라지고 GPL만 남는 구조임

    • 구체적으로 GPL에서 미흡하지만 EUPL에서 명확하게 다루는 점이 무엇인지 궁금함, 그리고 EU 법관할 적용이 EU 외 지역 사용자에게는 오히려 꺼려질 수 있음, 다국어 지원이 좋긴 하지만 EU 기관만을 위한 라이선스로 보임, reciprocation(상호 공개)의 경우 EUPL 쪽 조항들 때문에 EU 기관이 아니면 꺼릴 수 있다고 생각함, 특히 클릭 동의 조건 등은 외부 기관에 매력적이지 않을 수 있음

  • 업무상 EUPL을 다뤄본 경험이 있어서, 몇 가지 정리해봄

    • EUPL은 GPL을 꽤 밀접하게 참고함, 자세히 보면 사실상 GPL임
    • GPLv3와 좀 더 비슷하고, 특허 관련 조항이 명시적임
    • 다만 Tivoization(티보화)와 DRM(디지털 권리 관리) 조항은 빠져 있음
    • GPL과 달리 EUPL은 라이선스 호환성에서 들어오는 것(inbound)과 나가는 것(outbound)을 명확히 구분함
    • 다른 카피레프트 라이선스(GPL 등)는 EUPL로 들어올 수 없음
    • GPL(v2, v3)로는 나갈 수 있음
    • 이때 EUPL에만 있는 더 엄격한 조항은, GPL로 옮기면 자동으로 빠짐
      그래서 사소한 듯하지만 이상한 구석임
      EDIT: 다른 의견 보니 EUPL이 AGPL과 더 비슷하게 느끼는 독자도 있지만, EUPL에서 GPL로 쉽게 바꿀 수 있기 때문에 실제로는 AGPL의 강력한 SaaS 조건이 무력화됨에 주목했음
      EDIT2: AGPL 관련해서 내 입장이 좀 단순할 수도 있다는 점, 다른 댓글 참고 바람
    • EUPL을 골라야 하는 이유, 시나리오가 있으면 구체적으로 듣고 싶음, 왜 GPLv3 대신 EUPL을 고르는지 궁금함

    • EUPL은 사실 카피레프트의 순수성보다는 기관 간 재사용, 법적 명확성을 염두에 두고 설계된 것으로 느껴짐

  • GoatCounter 개발자인 Martin Tournoi가 왜 GoatCounter에 EUPL을 선택했는지 설명한 글이 있음, 라이선스 선택을 고민하는 사람에게 유익한 비교/분석 자료임
    관련글 링크

    • 작성자는 EUPL을 수정해서 사용했는데, 라이선스 자체를 변형하는 건 별로 좋은 생각이 아님, 오히려 AGPL을 꺼리는 기업까지도 끌어모으려고 했던 장점이 사라짐, EU 외 기업 입장에선 EUPL이 관할권도 강제해서 매력이 덜함, 원 저작자에게 변경사항을 보내야 하는 강제 규정이 AGPL에 있다고 오해하고 있는데, 실제론 사용자만 공개하면 됨, EUPL의 변형으로 호환 라이선스가 매우 좁아져서 사실상 AGPL과 OSL만 남았음, 결과적으로 공식 EUPL과도 호환 안 되어버림

    • 참고로 GoatCounter는 오픈소스 웹 애널리틱스 플랫폼임, Google Analytics나 Matomo 같은 프라이버시 친화적인 대안임

  • 호환성 조항이 많은 댓글에서 혼동을 주는 듯함, 공식 문서에서 호환성에 대해 잘 정리해 놓았으니 참고하면 좋겠음
    호환성 시각자료
    호환 라이선스 매트릭스

  • 왜 링크가 공식 문서가 아니라 한 개인의 해석으로 연결되는지 의아하게 생각했음
    위키피디아, 공식 사이트, 공식 PDF 등 더 신뢰할 만한 소스를 추천함
    Wikipedia
    공식사이트
    공식 PDF

    • 게다가 해석 수준도 별로라고 생각함, 예시로 들었던 “유럽 위원회의 목적은 우선 자사 소프트웨어 배포“ 같은 문장은 실제 유럽 집행위원회 역할과 동떨어진 단순화라고 봄

    • 공식 EU 플래그 아이콘을 사용하고 있으면서도 공식 사이트가 아니라는 점, 사이트에 트래킹이 많은 점이 문제라는 의견임, 불편함

  • EUPL과 AGPL의 차이점이 궁금해서 찾아본 결과, EUPL이 AGPLv3와 유사(affero-like)하다는 평도 있고 SaaS 모델에도 적용된다고 함
    비교 공식 자료

    • 어디서 자세한 설명을 찾을 수 있을지 물어봄, GPLv3에 도입된 anti-Tivoization 요구와도 관련이 있는지 궁금함, 리처드 스톨만과 달리 Linus Torvalds는 GPLv2만을 고수하던 이유도 이해되지만 SaaS같은 변형에 대한 공헌 환원 규제가 아예 빠져있는 건 말이 안 된다고 생각함, AGPLv2같이 SaaS 공헌 반환만 있는 버전이 있었으면 좋겠음, 그런데 EUPL에도 결국 이상한 재라이선스 허점이 있다고 깨달았음
      GNU 설명

    • EUPL의 네트워크 소프트웨어(SaaS) 규정과 라이선스 호환 규정 사이에 충돌 문제가 있다고 보임, 누구나 EUPL 프로젝트를 GPL로 포크해서 EUPL 상의 추가 조항을 무력화할 수 있어서, 이건 오히려 EUPL의 실수이자 허점으로 봄, 본인은 변호사가 아니라 확실하진 않으니 법 전문가의 의견이 필요하다고 생각함

    • 개인적 경험에서 언급하자면, 라이선스 원문에서 SaaS를 커버한다는 조항을 아직 명확히 찾지 못했음, 구체적 부분을 짚어줬으면 함

    • AGPL의 핵심 목적 자체가 그 부분 아니냐는 질문임

  • Interoperable Europe Portal에서 EUPL 라이선스 해석과 활용법에 대한 아주 자세한 공식 문서를 찾을 수 있다고 안내함
    공식포털

    • 혹시 이 라이선스에 대해 더 명확하게 만드는 최신 버전 작업이 공식적으로 추진되고 있는지 궁금함
  • 본문에 언급된 전체 텍스트의 출처가 명확히 명시되어 있지 않아 혼동을 준다고 생각함
    EUPL 공식 원문

    • 정확히 어디로 가야 텍스트를 볼 수 있냐는 의견이 있었고, "What is the EUPL" 섹션 위쪽에서 각 언어별 라이선스 원문 링크가 있다는 설명임

    • 원하는 언어를 선택하면 해당 언어의 EUPL 전문으로 이동할 수 있음
      예시: 영문 원본

  • EUPL 소개글의 첫 부분에서 이게 소프트웨어 라이선스임을 명확히 밝혀두지 않아서 혼동을 준다는 의견임, EU같은 규제 내에서는 “라이선스”라는 단어가 보편적이어서 어떤 라이선스인지 추측하기 어렵고, LGPL처럼 친숙한 이름과 마케팅 때문일 수 있음, 따라서 인트로 첫 단락에 “소프트웨어 배포 라이선스”라고 명확히 써주면 혼란이 줄어들 것 같음

    • 물론 EUPL이 소프트웨어에만 국한된 것은 아님, 실제로 비-소프트웨어용 호환 라이선스(CC BY-SA 3.0 등)도 있음

    • GPL도 소프트웨어 라이선스인데 왜 그렇게 부정적으로 연상되는지 이해가 안 된다는 의견임, 더 기대한 게 있었는지 궁금함