商业开源

• 适兕

  2023-07-25
  第一个原因是最直接的：专利诉讼的原告可以起诉要求经济赔偿。专利侵权诉讼主张是经济武器。律师圈有这样一个笑话：第一条规则是不要起诉任何穷人。开源项目通常因为没有任何钱而并非是好的损害赔偿诉讼主张目标。然而，用开源软件赚钱的公司却可能更有望成为目标。
• 适兕

  2023-07-25
  知识产权法最让人难以理解的一个概念是：专利是权利，而且仅仅只是权利。拥有专利权的人有且仅有排除他人实施本专利所声明的发明的权利。专利有时被称作非使能权利（non-enabling right）。专利并不使其所有人能够制造任何产品或从事任何业务。通过提起专利侵权诉讼来进行专利维权，并不要求专利权人从事任何他试图保护的业务。这就是专利“蟑螂”为什么可以存在的原因—这些公司除了起诉他人专利侵权之外不从事任何业务。专利只是消极的权利。相比之下，根据版权法，作者必须实际创造出某种东西才能拥有其权利。其他知识产权制度（商业秘密和商标）也是如此。在每种情况下，人们必须实际创造出某种东西才能对其拥有权利。商业秘密的产生是因为有人创造了机密的商业信息；而商标的产生是因为有人在贸易中使用了商标来指定商品来源或产地。
• 适兕

  2023-07-24
  要判断一家公司是否有开源合规流程的内部控制并不难—您一问便知。例如，如果您要求提供产品中的开源代码清单，若该公司没有这样的清单（或者不理解这个问题），那么该公司很可能没有适当的合规流程
• 适兕

  2023-07-24
  如今，许多客户在购买软件许可时坚持要求全面披露开源组件。事实上，如果要把产品分发给客户，供应商有义务以适用开源许可证要求的许可声明形式向客户提供这些信息。所以，企业应该做好随时披露其产品中的第三方开源软件的准备。在对公司的合规性做出保证前，最好为应对这一挑战做好准备。
• 适兕

  2023-07-24
  在Apache v2.0 与GPLv2.0 是否兼容的问题上闹得不可开交后，GPLv3.0起草项目致力于冰释前嫌。Apache v2.0 和 GPLv3.0 被宣布为是兼容的（尽管考虑到很多人不理解最初的兼容性争论），但该问题的解决方式似乎有点简单过头了。无论如何，FSF 显然认为，在 GPLv3.0 中加入专利和其他条款便可使二者兼容。
• 适兕

  2023-07-23
  事实上，因为内核开发项目是在没有贡献协议的情况下进行的，所以很可能无法重新考虑许可证（关于原因，请参见第16 章）。 GPLv2.0 和 GPLv3.0 并不兼容——程序必须基于其中之一。1 因此，可以将基于GPLv3.0 和“GPLv2.0 或任何后续版本”的程序代码组合在一个程序中——这意味着整个程序将基于GPLv3.0进行许可。但是，不可能将基于GPLv3.0 和“仅GPLv2.0”的软件进行组合。
• 适兕

  2023-07-23
  因为（从这个意义上说）边界之争的问题永远没有一个明确的答案，所以即便您无法判断是否遵循了GPL 的字面要求，也要遵守GPL 精神。GPL 精神即自由—任何获得二进制文件的人都应该能够获得源代码。所有使用二进制文件的人都应能够对其进行调试、研究、修改。如果您因为试图在专有模块中隐藏功能而思考边界之争，这就不是GPL 精神。但是，如果专有模块和GPL模块之间的接口透明、简单、有完善的文档、是个真正的黑匣子，那么即便您违反了GPL，也很少会有人投诉您，而这就是风险管理。此外，简单、清晰的接口也是好的工程的标志。所以在软件工程中做正确的事情就是遵守GPL 的最佳方法。
• 适兕

  2023-07-21
  正义要求一个社会的规则清晰易懂，否则只有那些具有神秘知识的人才能充分参与到社会中来。GPL 是自由软件世界的宪法，所以在这个（自由软件）世界工作的人（甚至是那些想推广自由软件的人）会持续关注GPL 中不清晰的问题。
• 适兕

  2023-07-20
  许多公司并不希望在前期提供源代码，原因有很多。通常，这么做不切实际。在某些情况下，公司反对在许可证没有要求的情况下（如BSD 或MIT 等宽松许可证）提供源代码。当许可证没有规定提供源代码的条件时，提供源代码便是一种选择而非要求。对于像 GPL 和 LGPL 这样的著佐权许可证以及MPL 这样的弱著佐权许可证，并不要求附随每一个二进制文件提供其源代码。
• 适兕

  2023-07-19
  大多数基于GPLv2.0 发布代码的作者根本不关注公司之间的协议和并购等问题，其原因在于，这些人主要是技术专家而非企业战略专家。如果GPL 作者通常并不打算在这些临界场景中行使其自身权利，那么可能没人会有兴趣提起可以在这个领域开创新法律的诉讼。因此，只要GPLv2.0 仍然是一个被广泛采用的许可证，这些问题很可能会持续存在，而仅基于Linux 内核的普遍性，这个过程终将漫长。评估开源合规的公司应确认其已识别出的最可能被质疑的分发类型，如此便可以放心使用开源软件，并以符合其开源合规战略的方式对其交易进行规划。
• 适兕

  2023-07-17
  通过将GPL 代码与专有代码合并，并以GPL 以外的条款分发该组合代码，可能会违反GPL。开发者们脑海中想象着“大摇大摆”的病毒，担心如果将GPL 和专有代码合并到一个程序中，该GPL 许可条款将“ 传染 ”该专有代码，而该专有代码将自动基于 GPL 进行许可。开发者随后便担心他们将有义务提供其自身专有代码的源代码。这对于大多数专有代码开发者而言，根本不是一个可选项。这么做不仅会使其专有代码贬值因而违反其对股东的信托责任，而且很可能会使他们违反第三方许可协议。一个公司的专有产品通常包含基于专有条款进行分许可的第三方软件。因此，该公司即使想将该产品转换为GPL，也无权这么做。
• 适兕

  2023-07-17
  “传染”并不是著佐权的工作方式。事实上，如果一个开发者以违反GPL 的方式把GPL 和专有代码进行合并，结果就是违反了GPL—不多也不少（如果开发者将第三方 GPL 代码与第三方专有代码进行合并，则可能已经同时违反了这两个入站许可）。这意味着，从法律上讲，GPL 代码作者可能会就违反GPL 的行为获得救济，以及（如果该许可证因此被终止）对未经许可使用GPL 软件的行为获得救济。这两种可能性，本质上都是版权侵权主张。版权侵权主张的法律救济是损害赔偿（赔偿金）和禁令（停止使用GPL 代码）。
• 适兕

  2023-07-16
  尽职调查过程不是为了完美无瑕，而是为了进行风险管理。完全合规的事物是不存在的；软件领域（即使对于一个简单的产品或业务而言）要做到完全合规实在是太复杂了。尽职调查的过程意在首先解决最糟糕的问题，然后进入下一组问题，然后再进入下一组问题，直到人们耗尽时间、精力或对风险的恐惧。这是一个对问题进行分类并做出合理决策的过程。
• 适兕

  2023-07-15
  GPL 是典型的自由软件（free software）或著佐权许可证。GPL 通常被认为是使用最广泛的开源许可证。当然，衡量使用情况的方法有很多。根据不同来源来衡量，被项目应用最多的是GPL，但根据使用情况加权的方法来衡量，其结果无疑更倾向于Apache v2.0、MIT 或BSD。
• 适兕

  2023-07-15
  容器是一项热门新技术的同时，也带来了可能会使开源合规变难的问题。我听人说过，由于技术和安全原因，从网上抓取并使用预构建容器是不负责任的，我把这个判断留给别人。然而，可以肯定的是，使用预构建容器会导致大量开源许可证的使用不合规。在这一点上，行业正在加速完善，更负责任的容器供应商开始提供其包括哪些组件及其许可声明的元信息。但就目前而言，容器已对开源许可要求造成严重的破坏。
• 适兕

  2023-07-13
  程序员用同样的方式编写程序，但他们把这种系统性重用的方法发挥到了逻辑的极致。这样做不是剽窃或作弊，而是良好的编码实践。这是因为，代码是功能性的，它必须正确工作。如果重用有效（而非重写），则任何已经恰当测试过的代码都应该被重用。程序员们（像律师们一样）都在源代码和描述程序执行的人工文档中使用专有术语。统一这些术语意味着更多的程序员可以以最小的学习成本加入一个团队中。
• 适兕

  2023-07-12
  红帽公司于1999 年上市，从那时起，Linux 发行版的市场就趋于饱和。由于其基于服务和支持的商业模式存在的固有困难，市场上没有众多玩家生存的空间。然而，红帽公司仍然是一家蓬勃发展的企业，电子商务领域几乎完全依赖红帽公司。
• 适兕

  2023-07-12
  实际上，并不存在GPL 代码传染专有代码和改变其许可条款的法律机制。要使软件基于特定条款进行许可，作者必须采取一些行动合理引导被许可人得出许可人选择基于这些条款提供代码的结论。相反，在违反GPL 的情况下，将专有代码和GPL 代码组合在单一程序中会导致许可证不兼容（意味着两套条款发生冲突而不能同时得以满足）。对于这种许可证不兼容的更好的类比是软件漏洞而非软件病毒。想一想电视剧Lost in Space（《迷失太空》）中的机器人挥舞着手臂说“这无法运算！”，您就会明白了。
• 适兕

  2023-07-11
  大约在1996年，GPL在技术领域开始取得重大进展。我于1995年开始从事法律工作，之后不久，就有客户开始向我咨询与开源许可相关的问题。当时大多数知识产权律师在遇到“我是否应该基于这个叫做GPL的许可使用这款软件”这样的问题时，都会感到困惑和恐惧。容易给出的答案是“不可以”——一贯是个容易给出的答案。
• 适兕

  2023-07-23
  GPLv3.0 中引入了两个新的技术术语：发布（conveying） 和传播（propagating）。只有发布才会触发著佐权要求。GPLv3.0 明确规定，“仅通过计算机网络与用户交互而不传送副本，不属于发布”。传播是一个更广泛的术语，可能包括某些人所说的（令人困惑且不准确的）内部分发（internal distribution）或使用SaaS。