Linux基金会 开源社KAIYUANSHE

【引言】

估计不少读者看原文会头晕脑胀,我试着用 “人话” 简短地为中国开源开发者如何安全参与开源项目的贡献划一下重点:

1. 优先选择合规性明确的平台与项目

  • 例如,华为的 OpenHarmony 已捐赠给 ‘’开放原子开源基金会‘’,其代码托管于中国平台 Gitee,社区治理遵循严格的开源合规规范(如代码引入审查、许可证声明等),降低法律风险。 
  • 贡献代码前先查阅项目合规文档(如 OpenHarmony 的《开源合规负面事件响应策略》),确保代码不包含受制裁实体的技术或专利。

2. 避免涉及敏感技术领域  

  • 若项目涉及“人工智能芯片设计、军事相关技术”等美国重点管制领域,需额外谨慎,因可能触发 “二级制裁”(即使无美国连接点)。

3. 审慎处理代码中的潜在风险  

  • 若代码依赖第三方开源组件,需检查其许可证是否包含美国出口管制限制条款(如某些加密算法库)。 
  • 避免在代码中嵌入受制裁国家的数据或技术(如为俄罗斯定制的功能模块)。
  1. 注意事项
  • 开发工具:考虑使用国产或非美国平台(如 Gitee  替代 GitHub)以减少 “美国连接点”。 
  • 代码内容:确保贡献的代码不包含受美国专利保护的技术或关联 SDN 清单中的实体。 
  • 合作对象:避免与受制裁地区的开发者共同提交代码或参与讨论。
  • 合规条款:若参与企业级开源合作,在协议中明确 “遵守 OFAC 制裁” 的条款,要求合作方提供合规证明。

——刘天栋,开源社联合创始人暨 2024 理事,ASF member 

Open source is a fundamental part of software supply chains and production systems. As such, it has reached a stage of maturity that requires new ways to deal with a complex world. The Linux Foundation has always pushed to promote and protect open collaboration in open source software and open standards-related activities. The model of allowing the brightest technical minds from around the world to contribute to an open commons has repeatedly proven its value over the past few decades. Protecting this commons is essential and something the Linux Foundation will continue to defend.

开源是软件供应链和生产系统的基本组成部分。因此,它已经达到了相当成熟的阶段,需要新方法来应对复杂的世界。Linux 基金会一直在推动和保护开源软件和开放标准相关活动中的开放协作。过去几十年反复证明允许来自世界各地最优秀的技术人才为开放的公共资源做贡献的模式具备价值。保护这些公共资源至关重要,Linux 基金会将继续捍卫。

However, increased cybersecurity risk and regulatory compliance are creating burdens on open source communities that must be met. There are newer regulations such as the EU’s Cyber Resilience Act, where we and others in the open source ecosystem invested great energy to educate regulators on the issues and concerns and carve out explicit exemptions for open source. Sanctions regulations are often very old regulations that never contemplated exemptions for the type of open collaboration that underpins modern daily life, societal systems, and business. The Linux Foundation is committed to open source and global collaboration and doing so responsibly while complying with laws and regulations where the foundation and our community members operate. Understanding the legal frameworks within which we all collaborate is essential to maintaining global collaboration.

然而,越来越高的网络安全风险和法规遵从性正在给开源社区带来必须应对的负担。还有一些较新的法规,如欧盟的《网络韧性法案》,我们和开源生态系统中的其他组织投入了大量精力来教育监管者了解这些问题和担忧,并给开源明确的豁免。制裁法规通常非常古老,从未考虑过对支撑现代日常生活、社会制度和商业的开放合作进行豁免。Linux 基金会致力于开源和全球协作,并在遵守基金会和我们的社区成员运营所在地法律法规的前提下负责任地这样做。理解我们大家合作的法律框架对于维持全球合作至关重要。

One of these areas is trade and sanctions regulations many countries have enacted. Many of these trade and sanctions regulations were enacted decades ago but have more recently been used to target technology providers. While there are sanctions programs in place around the globe, many developers will need to be mindful of laws and regulations like U.S. OFAC (Office of Foreign Assets Control) sanctions. Issues involving OFAC sanctions programs and open source are not very common, but are important to be aware of. These sanctions regulate interactions (or, in their word, “transactions”) with specific countries, entities, and individuals.

其中许多国家颁布了贸易和制裁条例。很多贸易和制裁条例是几十年前制定的,最近被用来针对技术提供商。虽然全球各地都有制裁计划,但开发者需要注意类似美国外国资产管制办公室(Office of Foreign Assets Control,以下简称“OFAC”)制裁的法律法规。OFAC 制裁项目通常不涉及开源,但关注这类问题是非常重要的。这些制裁规范了与特定国家、实体和个人的互动(或用他们的话来说,“交易”)。

OFAC sanctions issues are not commonly seen or understood in open source communities. They target a specific list of entities, individuals, countries, or regions. Historically those targets were not engaged in open source communities. With the U.S. and international sanctions targeting technology companies based in Russia, this issue has become a topic in certain open source communities that have participation from entities targeted by such sanctions.

OFAC 制裁问题在开源社区中并不常见,开源社区也不了解这类问题。OFAC 制裁的对象为特定的实体、个人、国家或地区。历史上,这些 OFAC 制裁的对象并不参与开源社区。随着美国和国际制裁针对总部位于俄罗斯的技术公司,这个问题已经成为有受到此类制裁实体参与的开源社区的话题。

The OFAC sanctions rules are “strict liability”, which means it does not matter whether you know about them or not. Violating these rules can lead to serious penalties, so it's important to understand how they might affect your open source work. Many OFAC sanctions restrictions generally do not care if software or technology is public or published (although US export controls generally do) and are usually completely separate and independent of any Export Administration Regulations (EARs), which the LF has published guidance about in the past[1]. It is important to note that the OFAC SDN List for sanctions programs is very different from the BIS’s Entity List for Export Controls. Entities on the BIS’s Entity List are not affected by the OFAC sanctions unless they are also added by OFAC to the SDN List. When looking at export controls and trade sanctions, they are separate programs and each list needs to be evaluated as the implications of export and trade sanctions are very different.

OFAC 的制裁规则是“严格责任”,这意味着您是否知道这些规则并不重要。违反这些规则可能会导致严重的处罚,因此了解它们可能会如何影响您的开源工作是很重要的。OFAC 的许多制裁限制通常不关心软件或技术是否公开或已发表(尽管美国出口管制通常如此),并且通常完全独立于任何出口管制法规(EAR),Linux 基金会在过去曾发布过 EAR 相关指南[2]。需要注意的是,针对制裁计划的 OFAC SDN 清单与 BIS 的出口管制实体清单有很大不同。BIS 实体清单上的实体不受 OFAC 制裁的影响,除非 OFAC 也将它们添加到 SDN 清单上。出口管制和贸易制裁是单独的计划,引发的影响也非常不同,因此需要分别评估每个清单。

The following information is shared to generate awareness of the issues that may arise and current compliance obligations. This guide is not intended to provide legal advice and we encourage you to seek advice from your legal counsel if you should run into any issues or have any questions. The points raised in this article are intended for developers who need to follow the U.S. sanctions laws or who want to collaborate with others who are required to follow U.S. sanctions laws. Developers and companies operating in open source outside the U.S. will need to determine which sanctions laws are applicable and relevant to themselves and their project communities. Such a determination likely requires consulting with a legal counsel or your employer's legal team.

以下信息旨在提高对可能产生的问题以及当前合规义务的认识。本指南并非旨在提供法律咨询,如果您遇到任何问题或有任何疑问,我们鼓励您向法律顾问寻求建议。本文中提出的要点旨在供需要遵守美国制裁法律的开发人员或希望与需要遵守美国制裁法律的其他人合作的开发人员使用。在美国以外运营开源的开发人员和公司需要确定哪些制裁法律适用于他们自己和项目社区。这样的决定可能需要咨询法律顾问或雇主的法律团队。

OFAC sanctions are U.S. government regulations[3] that restrict or prohibit transactions with certain countries, entities, and individuals (“sanctions targets”). These rules are normally put in place to achieve economic emergency, foreign policy and national security goals. They apply not just to financial transactions, but often to almost all interactions with a sanctions target, including those in the open source community spaces.

OFAC 制裁属于美国政府法规[4],旨在限制或禁止与某些国家、实体和个人的交易(“制裁对象”)。这些规则通常是为了实现经济紧急状况、外交政策和国家安全目标而制定的。它们不仅适用于金融交易,而且经常适用于几乎所有与制裁对象的交互,包括那些在开源社区中的交互。

For developers, this means you need to be cautious about who you interact with and where your contributions come from. OFAC sanctions can target specific countries, regions, and individuals or organizations, with many of the individuals and organizations listed on the Specially Designated Nationals and Blocked Persons (“SDN”) List. OFAC updates this list regularly, adding or removing names as global situations change. OFAC sanctions also apply to all entities that are owned 50% or more directly or indirectly by one or more SDN individuals or entities, whether or not the owned entity shows up on the SDN List. Some entities, such as entities owned or controlled by OFAC-sanctioned governments, may also be sanctioned but not included on the SDN List. In addition, the few comprehensively sanctioned governments, regions, and countries also are not included on the SDN List.

对于开发人员来说,这意味着您需要谨慎对待您与谁交互以及代码贡献来自哪里。OFAC 制裁可以针对特定的国家、地区和个人或组织,而许多个人和组织已被列入特别指定国民和阻止人员(Specially Designated Nationals and Blocked Persons ,简称“SDN”)清单。OFAC 定期更新此清单,根据全球情况的变化添加或删除名单。OFAC 制裁还适用于由一个或多个 SDN 个人或实体直接或间接拥有 50%及以上所有权的所有实体,无论被拥有的实体是否出现在 SDN 列表中。某些实体(如被 OFAC 制裁的政府拥有或控制)未被列入 SDN 清单也可能受到制裁。此外,少数受到全面制裁的政府、地区和国家也不在 SDN 清单中。

Violating these sanctions can result in serious consequences, including large civil fines and criminal penalties. In general, if you’re a U.S. citizen or a U.S.-based organization, or if you deal with U.S.-origin goods, services, or U.S. Dollars for prohibited transactions, you’re likely required to follow these rules, no matter where in the world you are.

违反这些制裁措施可能导致严重后果,包括巨额民事罚款和刑事处罚。一般来说,如果您是美国公民或美国组织,或者如果您处理原产于美国的货物、服务或美元来用于被禁止的交易,则无论您在世界的哪个地方,都可能需要遵守这些规则。

U.S. OFAC sanctions only reflect the U.S. sanctions programs. Many other countries also have similar sanctions programs in place, including the European Union, United Kingdom, Japan, Australia, Switzerland, China, and many more. This post specifically addresses U.S. sanctions, but keep in mind if you are located elsewhere in the world, your local country may have similar sanctions in place.

美国 OFAC 的制裁只反映了美国的制裁计划。许多其他国家也实施了类似的制裁计划,包括欧盟、英国、日本、澳大利亚、瑞士、中国等。这篇文章专门讨论了美国的制裁,但请记住,如果您位于世界其他地方,您所在的当地国家可能也有类似的制裁。

It is disappointing that the open source community cannot operate independently of international sanctions programs, but these sanctions are the law of each country and are not optional. Many developers work on open source projects in their spare time, or for fun. Dealing with U.S. and international sanctions was unlikely on the list of things that most (or very likely any) open source developers thought they were signing up for. We hope that in time relevant authorities will clarify that open source and standards activities may continue unabated. Until that time, however, with the direct and indirect sponsorship of developers by companies, the intersection of sanctions on corporate entities leaves us in a place where we cannot ignore the potential risks.

令人失望的是,开源社区不能独立于国际制裁计划的运作,这些制裁是每个国家的法律、不是可选择性的。许多开发人员在业余时间或为了兴趣而在开源项目上工作。大多数(或者很可能是所有)开源开发人员以为他们只是注册和加入了一些开源项目,而应对美国和国际制裁肯定不在其中。我们希望相关当局及时澄清,开源和标准活动可以持续下去。然而在此之前,由于公司对开发人员的直接和间接资助,我们无法忽视对公司实体制裁的潜在风险。

In addition to strict liability, OFAC sanctions do not always have a blanket exemption for all transactions involving “publicly available” technology as the U.S. export control regulations generally do for nearly all export-controlled transactions[5].

除 “严格责任”外,OFAC 的制裁还有其他特点。一旦涉及“公开可获得”的技术,美国出口管制条例通常会对几乎所有的出口管制交易有一个全面的豁免[6],但 OFAC 制裁并没有这种豁免的规定。

It is important to understand the basics of these sanctions programs. OFAC’s prohibited transactions often include:

了解这些制裁计划的基本知识很重要。OFAC 禁止的交易通常包括:

  • Financial investments and transactions (e.g. payment for services)

    金融投资和交易(例如服务付款)

  • Trade (import or export) of goods, technology, or services

    货物、技术或服务的贸易(进出口)

  • Any other property transactions (including intellectual property and contracts)

    任何其他产权交易(包括知识产权和合同)

The OFAC sanctions may impact common community behaviors, such as two-way collaboration on a proposed software change which could be interpreted as a prohibited provision of services. It would be an issue for developers to provide services to a developer who is employed (directly or indirectly) by an SDN or an entity directly or indirectly owned 50% or more by an SDN.

OFAC 的制裁可能会影响到社区的基本行为,例如在软件变更提意上的双向协作可能会被解释为禁止提供服务中的一种。这意味着开发人员向一位受雇(直接或间接)于 SDN 的开发人员或者是向被 SDN 直接或间接拥有 50%及以上所有权的实体提供服务的行为将产生问题。

The application of U.S. sanctions, including both their prohibitions and exemptions, to open source software or standards-related activities is not 100% well defined, as OFAC has yet to issue clear guidance on whether and how U.S. sanctions apply to open source or standards-related activities. Therefore, application of these sanctions programs to open source often relies on interpretation and looking at how the sanctions have previously been applied in similar contexts. If you run into any issues or if you have any questions, you should consult your legal counsel immediately. The information provided below is meant to help others understand general issues to watch out for and be aware of, including exemptions that can be helpful for open source project communities.

OFAC 尚未就美国制裁是否以及如何适用于开源或标准相关活动发布明确的指导意见,所以美国对这类活动制裁的应用(包括禁令和豁免)并没有 100%明确定义。因此,将这些制裁计划应用于开源通常取决于先前在类似环境中制裁如何应用的解释和查看。如果您遇到任何问题或有任何疑问,您应立即咨询您的法律顾问。下面提供的信息旨在帮助其他人了解需要和注意的一般问题,包括对开源项目社区有帮助的豁免。

OFAC does publish an SDN List[7], and also offers an OFAC SDN list search[8] tool. Using the search tool, a user can check if an organization is on the OFAC SDN List. OFAC SDN entities show up with “SDN” under the column “List”. Please note this tool also searches other “Non-SDN Lists” that is not affected by the prohibited “transaction” outlined in this blog and all search hits are not necessarily for the OFAC SDN List.

OFAC 的确发布 SDN 清单[9],还提供了一个OFAC SDN 清单搜索[10]工具。使用搜索工具,用户可以检查组织是否在 OFAC SDN 清单中。OFAC SDN 实体会在“清单”列下显示“SDN”字样。请注意,此工具还会搜索其他‘非 SDN 名单’,这些名单不受本文中所述的禁止“交易”的影响,并且所有搜索结果并不一定与 OFAC SDN 名单相关。

The OFAC SDN list and search tool are also not exhaustive and any analysis cannot solely rely on this list. First, there’s the 50% percent rule if an entity is 50% or more owned directly or indirectly by one or more SDNs. That requires identifying who owns an entity, and (in many cases) who also owns that entity, up until all owners are identified. Second, some sanctions apply to entire countries (e.g. Iran), regions (e.g., the Crimea region of Ukraine), or governments (e.g., the Government of Venezuela), and those countries, regions, and governments are not listed on the SDN List. Additionally, the SDN List is constantly changing. Just because an individual or entity is not on the SDN List today does not mean they, or their owner, will not be added tomorrow. In some weeks, OFAC may add hundreds of individuals or entities to the list. Finally, just because an individual or entity is not subject to U.S. OFAC sanctions does not mean that another country has not sanctioned the individual or entity. Remember that open source is global, and depending on where your project’s developers are located, other sanctions programs may apply.

OFAC SDN 清单和搜索工具也不是详尽无遗的,任何分析都不能仅依赖于此清单。首先,如果一个实体由一个或多个 SDN 直接或间接拥有 50%及以上所有权,则受到 50%规则的约束。这需要确定谁拥有一个实体,以及(在许多情况下)是否有其他人也拥有这个实体,直到所有股东被识别。其次,某些制裁适用于整个国家(如伊朗)、区域(如乌克兰克里米亚地区)或政府(如委内瑞拉政府),而这些国家、地区和政府并未列入 SDN 清单。此外,SDN 清单也在不断变化。个人或实体今天没有出现在 SDN 清单上,并不意味着他们或他们的所有者明天不会被添加。在某些时段,OFAC 可能会将数百名个人或实体添加到清单中。最后,个人或实体不受美国 OFAC 制裁,并不意味着另一个国家没有对该个人或实体进行制裁。请记住,开源是全球性的,根据您的项目开发人员所在的位置,其他的制裁计划可能会适用。

Most OFAC sanctions contain an exemption for the importation and exportations of “informational materials.” Open source code appears to generally be considered "informational material" by OFAC, and a one-way receipt of source code via an SDN therefore should be exempt from OFAC sanctions. However, this would only apply to existing code sent by an SDN, and it would not apply if you requested a developer working for an SDN to create new code or to modify code. In a simple example, if an SDN identified a memory bug and submitted an unsolicited patch to fix the issue, developers receiving this patch should be able to evaluate the patch on its technical merit, modify it if they see fit, and apply the patch to their repository. The SDN’s developer submitting the patch would see the patch being applied but should not be engaged in a two-way communication discussing the patch, the technical merits, or ways to improve the patch. The source code itself is informational material, but the concern is a developer crossing a line into providing a service to the SDN.

大多数 OFAC 制裁都包含了对“信息材料”进出口的豁免。开源代码似乎通常被 OFAC 视为“信息材料”,因此,通过 SDN 单向接收源代码应免于 OFAC 的制裁。但是,这只适用于 SDN 发送的现有代码,要求为 SDN 工作的开发人员创建新代码或修改代码的行为则不适用。举个简单的例子,如果 SDN 发现了内存错误,并提交了一个主动提出的补丁来修复该问题,那么收到此补丁的开发人员应该可以为该补丁评估技术价值,对该补丁进行合适的修改,并将补丁合入到他们代码仓。提交该补丁的 SDN 开发人员将看到补丁正在生效,但不应参与补丁的讨论、技术优点或补丁改进方法的双向交流。源代码本身是信息材料,但需要关注的是开发人员跨越界限向 SDN 提供服务。

Reviewing an unsolicited patch from a contributor in a sanctioned region should generally be fine, but actively engaging them to better understand their issue, diagnose the problem, or help improve a patch or modify code would likely cross the line. If the contributor is linked to a sanctioned entity or region, in general, it is best to keep communications strictly one-way. If a patch is received and you improve it and submit it upstream, that should be fine, but going back and forth in communications with the SDN developer likely would not.

审查受制裁地区的贡献者主动提供的补丁程序通常应该没有问题,但以更好地了解他们的提交、诊断问题、帮助改进补丁程序或修改代码为目的主动接触他们则可能会越界。如果贡献者与受制裁的实体或地区有关联,一般来说,最好保持严格的单向通信。如果收到了一个补丁,您对它进行了改进,并将其提交到上游,应该是没有问题的,但在与 SDN 开发人员交互的沟通很可能存在问题。

Accepting unsolicited patches that fix general issues in your open source project should be okay. However, if the changes directly benefit a restricted party’s products or services, it could be a problem. For example, if a developer from AcmeSDN (and AcmeSDN is an SDN subject to OFAC sanctions) contributes a driver that enables the AcmeSDN processor to work in your software, that contribution would likely be an issue. Think carefully not just about the source code, but the impact of these unsolicited patches.

接受主动提交的补丁来修复您的开源项目中的一般问题应该是没问题的。但是,如果这些改动直接使被限制方的产品或服务受益,则可能存在问题。例如,如果来自 AcmeSDN 的开发人员(并且 AcmeSDN 是受 OFAC 制裁的 SDN)贡献一个驱动程序,使 AcmeSDN 处理器能够在您的软件中工作,那么该贡献很可能是一个问题。不仅仅要对源代码本身进行考量,还要考量这些主动提交补丁的影响。

Sanctioned entities might try to contribute indirectly through third parties or developers acting "individually." Developers should understand other contributors' affiliations and raise any concerns with their community and legal counsel. For example, if in the prior example, AcmeSDN paid a developer in a country not subject to sanctions to make the driver contribution enabling AcmeSDN’s processor, that would still likely be an issue. A common pattern is that an SDN’s developer is blocked from making a contribution, but then a very similar (or the same) patch is submitted to the project from another account or email address. It could be an anonymous email account. Just because the contributor has been obfuscated does not change an assessment of the situation.

受制裁的实体可能会尝试通过第三方或“单独行动”的开发人员间接地进行贡献。开发人员应该了解其他贡献者的从属关系,并向他们的社区和法律顾问提出任何关切。例如,如果在前面的举例中,AcmeSDN 向一个不受制裁的国家/地区的开发人员付费来贡献 AcmeSDN 处理器的驱动程序,那么这仍然可能是一个问题。一个常见的模式是,SDN 的开发人员被阻止做贡献,但随后从另一个帐户或电子邮件地址向项目提交了非常相似的(或相同的)补丁。这可能是一个匿名的电子邮件帐户,可是仅仅因为贡献者被混淆并不能改变对情况的评估。

Many open source projects require a CLA, which would bar contributors from OFAC sanctioned entities. OFAC sanctions bar transacting in intellectual property, and specifically, any agreement in intellectual property or any other contract with an SDN. If your open source project requires a CLA, make sure your CLA validation process includes compliance checks against the SDN List.

许多开源项目需要签署贡献者许可协议 CLA,这可能会拦截来自 OFAC 制裁实体的贡献者。OFAC 制裁禁止在知识产权方面进行交易,特别是禁止与 SDN 签订任何知识产权协议或任何其他合同。如果您的开源项目需要签署 CLA,请确保签署 CLA 的验证过程包括根据 SDN 清单进行合规性检查。

The open source community is built on collaboration, but compliance with sanctions programs is not optional for developers who could unknowingly violate the law. If you encounter situations that seem unclear, seek legal advice early to avoid compliance issues. The Linux Foundation’s goal is to help developers navigate these complexities, so you can focus on building great software without legal headaches. The Linux Foundation has already built compliance or verification checks into many of its processes and tools. If you are a maintainer of an LF project, please reach out to your LF contact point (or mailto:legal@linuxfoundation.org) for any questions you may have on our approach or for any support we can provide for your project. By staying aware and proactive, you can contribute to open source confidently while respecting global regulations.

开源社区建立在协作的基础上,但遵守制裁计划是必要的,否则开发人员可能在不知不觉中违反法律。如果您遇到看不清楚的情况,请尽早寻求法律咨询以避免合规问题。Linux 基金会的目标是帮助开发人员驾驭这些复杂性,这样您就可以避免法律上的麻烦、同时专注于构建伟大的软件。Linux 基金会已经在其许多流程和工具中构建了合规性或验证检查。如果您是一个 Linux 基金会项目的维护人员,无论您对我们的处理方法或我们为您的项目提供任何支持存在任何疑问,请联系您的 Linux 基金会联系人(或 mailto:legal@linuxfoundation.org)。只要保持警惕和主动性,您可以自信地在遵守全球法律法规的同时贡献开源。

As stated at the beginning, the Linux Foundation’s position is that open source and open standards are the most inclusive collaborative innovation model in the world. We hope that developers will begin to understand sanctions programs and regulations on the one hand, and at the same time, understand when to reach out to experts for help. It’s important to not overreact and to ensure open source communities take informed action when presented with a possible issue. For the vast majority of developers around the world, regardless of their nationality, country of residence, political system, cultural beliefs, or ideology, the open source community is still the most open collaboration ecosystem, just as it has always been before. In open source, communities are not used to having to exclude or curtail anyone’s ability to participate. It is understandable that trade and sanctions regulations may cast a different light on many people’s interpretations of the neutrality and equality of open source. We also hope that enactors of sanctions programs in the US and around the world will provide clear exemptions for open source cooperation in the future.

正如开头所说,Linux 基金会认为开源和开放标准是世界上最具包容性的协同创新模式。我们希望开发人员一方面逐渐了解制裁计划和法规,同时也要明白何时应该向专家寻求帮助。重要的是不要反应过度,并确保开源社区在遇到可能的问题时采取明智的行动。对于全球绝大多数开发人员而言,无论其国籍、居住国、政治体制、文化信仰或意识形态如何,开源社区到目前为止仍然是最开放的协作生态系统。开源社区仍然不习惯必须排除或限制任何人的参与能力。贸易和制裁条例可能会给许多人对开源中立性和平等性的观念带来影响,这是可以理解的。我们也希望美国和世界各地的制裁计划的制定者能够为未来的开源合作提供明确的豁免条款。

滑动查看全部参考资料

[1] which the LF has published guidance about in the past: https://www.linuxfoundation.o...

[2] 在过去曾发布过 EAR 相关指南: https://www.linuxfoundation.o...

[3] U.S. government regulations: https://www.ecfr.gov/current/...

[4] 美国政府法规: https://www.ecfr.gov/current/...

[5] as the U.S. export control regulations generally do for nearly all export-controlled transactions: https://www.linuxfoundation.o...

[6] 美国出口管制条例通常会对几乎所有的出口管制交易有一个全面的豁免: https://www.linuxfoundation.o...

[7] publish an SDN List: https://sanctionslist.ofac.tr...

[8] OFAC SDN list search: https://sanctionssearch.ofac....

[9] 发布 SDN 清单: https://sanctionslist.ofac.tr...

[10] OFAC SDN 清单搜索: https://sanctionssearch.ofac....

转载自 | Linux基金会

编辑 | 李楠

相关阅读 | Related Reading

奥特曼:在开源AI上,我们错了!DeepSeek让OpenAI优势不再,下一个是GPT-5

【灵蛇献瑞】| 2024 中国开源年度报告正式发布! 

图片

开源社简介

图片

开源社(英文名称为“KAIYUANSHE”)成立于 2014 年,是由志愿贡献于开源事业的个人志愿者,依 “贡献、共识、共治” 原则所组成的开源社区。开源社始终维持 “厂商中立、公益、非营利” 的理念,以 “立足中国、贡献全球,推动开源成为新时代的生活方式” 为愿景,以 “开源治理、国际接轨、社区发展、项目孵化” 为使命,旨在共创健康可持续发展的开源生态体系。

开源社积极与支持开源的社区、高校、企业以及政府相关单位紧密合作,同时也是全球开源协议认证组织 - OSI 在中国的首个成员。

自2016年起连续举办中国开源年会(COSCon),持续发布《中国开源年度报告》,联合发起了“中国开源先锋榜”、“中国开源码力榜”等,在海内外产生了广泛的影响力。


开源社
6 声望1 粉丝

开源社成立于 2014 年,是由志愿贡献于开源事业的个人成员,依 “贡献、共识、共治” 原则所组成,始终维持厂商中立、公益、非营利的特点,是最早以 “开源治理、国际接轨、社区发展、开源项目” 为使命的开源社区联...