内源许可证
属于同一组织的两个法律实体希望彼此共享软件源代码，但他们担心在法律责任或跨公司会计方面的影响。
“内源许可证”为组织内的源代码共享提供了一个可复用的法律框架。它提供了新的合作选择，并明确了参与的法律实体的权力和义务。
当一个组织中的两个或更多的法律实体想要互相分享代码时，他们需要一个关于条款的协议，通常是一个法律合同。在每个项目的基础上创建此类协议需要付出努力并会对共享创造障碍。例如，一个法律实体内的团队可能决定不与组织内的另一个法律实体分享他们的源代码，因为这看起来很复杂。
共享的障碍会导致在组织内多个实体重建类似的解决方案时出现独自开发和重复劳动的现象。
在共享源代码时，可能无法可靠地预测共享的价值。如果共享活动需要付出巨大的努力（例如，对源代码使用的条款进行持续谈判），则法律实体不太可能这样做，因为他们关心投资的回报。
大型组织内有许多想要共享代码的法律实体（子公司）。当组织变大时，共享模式的价值会增加。
按照定义，法律实体有自己的法律权利和义务。
这些法律实体中有多个实体正在开发软件，并正在使用其他法律实体的服务。他们有动力为彼此的源代码做出贡献。
该组织及其组织结构足够复杂
撰写正式协议所需的努力程度，特别是如果他们需要考虑技术、法律和商业角度。
一个大型组织（由许多法律实体组成）有许多内部规定。任何新签订的协议都必须遵守这些规定，例如安全、隐私、采购流程等。规定的数量会导致难以评估两个法律实体之间共享软件是否符合这些规定，尤其是在没有标准程序的情况下。
如果组织中的任何一个法律实体有一个商业模式依赖专有代码和组织内许可费用的核算。
公司文化不习惯于内源协作和共享代码。这导致了在使用共享代码时权利和义务的不确定性。
使用软件的自由导致了竞争以及所有权的分散。
有一些法律合同，涵盖了源代码的共享。这些合同并不是标准化的，所以它们为每个项目的谈判和理解带来了额外的负担。现有的合同也可能不允许在足够开放的意义上共享源代码，以支持真正的内源方法。
或者，没有法律合同，但源代码被非正式地共享。在需要明确所有权和权利义务的情况下，这可能会造成不确定性。
创建一个根据有关组织（及其法律实体）的需要定制的内源许可证。这个许可证需要有足够的通用性，可以应用于最重要的公司间关系。
重要的是，撰写内源许可证，要真正允许类似开源的合作跨越相关法律实体的边界进行。因此，自由软件的4项自由应当被融入许可证中。
许可证按正式的法律文件撰写，并作为法律实体之间的合同的一部分来管理代码共享协议。
有了内源许可证，我们就有了一个在组织内的法律实体之间分享代码的工具。
该许可证简化了我们组织内部关于共享源代码的对话，并推动第一批法律实体这样做。
注意： 已知实例中描述的实验还处于早期阶段。因此，一个可靠的结果还没有形成。几个月后，内源许可证对这一问题空间的影响将更加清晰，本节也将更新。
DB Systel创建了他们自己的内源许可协议，见DB Inner Source License。他们使用了EUPL是因为它提供了一个类似于开源的起点，然后在他们特定的组织环境中制定了所需的约束和附加规则。
DB AG内部的第一批法律实体（公司）正在使用他们的内源许可证。
一个已经显示出来的积极效果是，它简化了对话，特别是当一些参与方还不太了解内源的概念时。许可证是一个众所周知的概念，因此拥有一个内源许可证是一个很好的讨论起点。
实验还发现，为了实现真正的内源贡献和合作模式，还有更多的合作挑战需要解决。
所提到的合作挑战包括：
让大家能够找到适用内源许可的项目
像在开源中一样建立项目合作的社群。
值得一提的是，到目前为止，在这个内源许可下分享的软件主要是工程工具、基础设施和底层的工具。
结构化
在已知实例下所列的实验自2020年2月开始运行。初步的经验显示了第一个积极的效果，但需要更多的经验来全面评估该模式。
Cornelius Schumacher (DB Systel GmbH)
Schlomo Schapiro (DB Systel GmbH)
Sebastian Spier
FOSSBack 2020演讲。Cornelius Schumacher - Blending Open Source and Corporate Values - 请看27:30及以后的内容，了解有关内源许可的细节。
组织 - 多个法律实体的综合体。(同义词：集团、企业）（如汉莎航空）。
法律实体 - 拥有自身的法律权利和义务的实体（同义词：公司，子公司）（例如汉莎系统有限公司，汉莎工业解决方案TS有限公司，...）