Open-source News

Google is teaming up with Ubuntu to bring Flutter apps to Linux  Android Police

Google and Canonical partner to bring Linux apps support to Flutter  9to5Google

Google and Canonical bring Flutter apps to Linux and the Snap Store  VentureBeat

Google and Canonical bring Flutter apps to Linux and the Snap Store  VentureBeat

Google is teaming up with Ubuntu to bring Flutter apps to Linux  Android Police

Google's Flutter: Now developers can use it to build apps for Ubuntu Linux machines  ZDNet

IGEL First to Deliver Microsoft Teams Optimization With Citrix Workspace App Linux Client  AiThority

Open Usage Commons is a new organization announced today that is backed by Google for helping open-source projects in managing their trademarks...

SUSE is upping their container game by acquiring Rancher Labs...

Intel has today made public more details on their next-generation Thunderbolt connectivity that brings more features while offering USB4 specification compliance. Thunderbolt 4 is coming with forthcoming Tiger Lake laptops...

Linux company SUSE outbids competitors for fast-growing start-up Rancher Labs  CNBC

Chinese Language Version Available

Introduction

One of the greatest strengths of open source development is how it enables collaboration across the entire world. However, because open source development is a global activity, it necessarily involves making available software across national boundaries. Some countries’ export control regulations, such as the United States, may require taking additional steps to ensure that an open source project is satisfying obligations under local regulations.

The Linux Foundation has recently published a whitepaper on considerations for open source communities in detail, which can be downloaded here. This blog post is a summary of the general principles open source communities should be aware of and follow as it relates to both US export control requirements and open source encryption.

Export controls in the United States and other countries

The primary source of United States federal government restrictions on exports are the Export Administration Regulations or EAR. The EAR is published and updated regularly by the Bureau of Industry and Security (BIS) within the US Department of Commerce. The EAR applies to all items “subject to the EAR,” and may control the export, re-export, or transfer (in-country) of such items.

Under the EAR, the term “export” has a broad meaning. Exports can include not only the transfer of a physical product from inside the US to an external location but also other actions. The simple act of releasing technology to someone other than a US citizen or lawful permanent resident within the United States is deemed to be an export, as is making available software for electronic transmission that can be received by individuals outside the US. 

This may seem alarming for open source communities, but the good news is open source technologies that are published and made publicly available to the world are not subject to the EAR. Therefore, open source remains one of the most accessible models for global collaboration.

For the purposes of compliance with the EAR, if the open source technology is publicly available without restrictions upon its further dissemination, then it is “published” and therefore “not subject to” the EAR. 

In addition to the United States, the European Union has similar provisions under its own export control regulations. 

What kind of open source projects are not subject to the EAR and export restrictions?

All of them. Open source software from the Linux Foundation and project communities we work with is published and made available to the public without restrictions on further dissemination or distribution of the software. 

The following typical scenarios (but not an exhaustive list) are not subject to the EAR because “open source” is “published”:

• Open source software that is published publicly is not subject to the EAR
• Open source specifications that are published publicly are not subject to the EAR
• Open source files that describe the designs for hardware that are published publicly are not subject to the EAR
• Open source software binaries that are published publicly are not subject to the EAR

To meet the requirement of “published” under the EAR, however, open source communities may need to take an additional step if the project includes encryption technology.

Projects that use encryption

The EAR regulates exports of certain encryption software and technology. The definition of “encryption software” is very broad and can include software that merely activates or enables encryption features in another software or hardware product.

However, as with the EAR exemption for software that is published, there is also an exemption for software that uses encryption that is (1) it is “publicly available,” and (2) an email notification has been sent for it to the addresses listed in that section.

To meet the first of the exemption requirements, the meaning of “publicly available” refers to the EAR’s definition of “published,” which includes public dissemination by posting on the Internet on sites available to the public. Given this, the first part of the test should be met for all fully-public open source software projects: if the project’s source code is openly available on the Internet, then it should be considered “publicly available.”

To meet the second of the exemption requirements, it is additionally necessary to send an email to two specified addresses, one at BIS at crypt@bis.doc.gov and the other at the US National Security Agency (NSA) at enc@nsa.gov. The email should include the URL of the publicly-available code (or a copy of the code itself). An updated notification should be sent later if the previously-provided URL or copy has changed.

After these two requirements are satisfied, then its corresponding object code counterpart for the project is also not subject to the EAR.

At The Linux Foundation, the source code for all of our projects, including encryption software, is publicly available, and we have provided email notices as described above. We also make copies of these email notices publicly available for viewing on the LF’s website. As a result, the Linux Foundation’s project source code and corresponding object code are not subject to EAR encryption restrictions.

Please keep in mind that this applies only to the open source project itself. Downstream redistributors of modified project code or products derived from it, where the source code is not publicly available, would still need to evaluate their own compliance with the EAR (just as with any other software that they export).

In addition to projects that use encryption, the EAR added a new regulation in January 2020 for systems that employ a certain use of neural network-driven geospatial analysis training. As with other open source technologies that are publicly available, open source software that is published and publicly available, even in this category of neural network-driven geospatial analysis training, would also not be subject to the EAR. Please refer to our full whitepaper for more explanation.

Best practices for open source software communities

While open source projects are exempt from EAR restrictions, there are a few practices we have learned or developed that may be helpful for all open source communities as it relates to export regulations. 

We often use the word “open” to mean many things: an open source license, open and transparent discussions, open community, openly available source code on a public repository. “Open” may seem an obvious practice for open source communities, but the following are some specific recommendations for communities to consider. 

Be open and be public

First, communities should strive to keep their technical conversations open and public. If private technical conversations happen within communities, that’s normal, but it is recommended to make the community decisions and outcomes publicly available. It is important for our projects to make information available transparently and publicly as the private exchange of technology or technical information may not meet the “publicly available” standard according to the EAR.

One question that has come up has to do with exchanges of information related to security issues under a security disclosure process. As a best practice, projects may want to consider making exchanges like this public upon the availability of fixes, and not limit this information to only a confidential disclosure list.

Send notifications of encryption to BIS and the NSA

If your open source software project implements or uses encryption functionality classified under ECCN 5D002, you will likely want to deliver a notification of encryption to the BIS and the NSA according to the EAR requirements. The EAR describes these requirements:

• • Send an email to crypt@bis.doc.gov and enc@nsa.gov. If your project is an LF project and your notice is not listed on our export website, please notify legal@linuxfoundation.org.
  • The email should contain either the URL of the publicly available encryption source code or a copy of the source code itself. 
  • If you provided a URL to a site where you posted the source code on the Internet, you must notify by email again each time the Internet location is changed, but you are not required to notify them of updates or modifications made to the encryption source code at the previously notified location.
  • If you provided a copy of the source code, and you update or modify the source code, you must also provide additional copies to each of them each time the cryptographic functionality of the source code is updated or modified. 

The Linux Foundation suggests a few additional details as best practices:

• Make publicly available copies of the notices that were delivered to BIS and NSA, in order to increase transparency and visibility of compliance. This also helps with your community of downstream users who may wonder “do they send notices?” You can prevent concerns by making the notices themselves public.
• Include contact information and, where applicable, the name of the particular legal entity that is responsible for the project.
• Establish a system to ensure that you maintain evidence, for a medium- to long-term period of time, that the notification emails to BIS and NSA were in fact delivered. Relying solely on an individual’s “Sent” mailbox records may not be preferable if a question arises in the future, or if that individual loses access to that Sent mailbox (e.g. if they change employers).

Additionally, If you are distributing publicly available encryption software in object code form, then you will also want to ensure that it is publicly available in source code form as well.

If it is necessary to distribute encryption software in binary or object code form, then ensure that the corresponding source code is publicly available. The easiest way to do this is to make available the source code for that version of the encryption software yourself, as part of the project’s own code. (In fact, depending on the applicable open source license, this may be necessary or at least useful in complying with that open source license as well!)

In addition to manual review, there are some scanning tools (such as Fossology and exportctl) with varying degrees of ability to scan source code and detect usage of encryption functionality. No automated scanning tool is likely to be a perfect detector of all applicable uses, but these may be helpful in identifying copies of encryption software in a large codebase.

To download the “Understanding Open Source Technology and US Export Controls” whitepaper, click on the button below.

Download Whitepaper

The post Understanding US export controls with open source projects appeared first on The Linux Foundation.

简介

开源开发的最大优势之一是它实现了整个世界的协作。然而，由于开源开发是一项全球性的活动，它必然涉及跨国界提供可用的软件。一些国家的出口管制条例，例如美国，可能需要采取额外的步骤来确保一个开源项目符合当地条例规定的义务。

Linux基金会最近发布了一份关于开源社区如何详细解决这些问题的白皮书，点击此处可下载。本文概述了开源社区应该了解并遵循的与美国出口管制要求和开源加密相关的一般性原则。

美国和其他国家的出口管制

《出口管理条例》（Export Administration Regulations，以下简称“EAR”）是美国联邦政府限制出口的主要条例，由美国商务部（US Department of Commerce）下的产业与安全局（Bureau of Industry and Security，以下简称“BIS”）发布并定期修订。《出口管制条例》适用于所有”受《出口管制条例》管制的物品，并可管制这些物品的出口、再出口或(在国内)转让。

EAR下“出口”的定义较为宽泛。出口不仅包括从美国境内向境外输送实物产品，还包括其他行为，例如向在美国居住的非美国公民或非美国合法永久居民传送技术，2以及向美国境外人员提供用于电子传输的软件。

这EAR似乎给开源社区敲响了警钟，但是好消息是，公开发布给全世界享用的开源技术是不受制于EAR的。因此，开源至今仍然是一个最为便利的全球协作的模式。

为了符合EAR的要求，如果开源技术是公开的，不受进一步传播的限制，那么它是“已发布的”，因此“不受制”于EAR。

除美国外，欧盟在其出口管制条例中也有类似规定

什么样的开源项目不受EAR和欧盟出口限制?

所有。Linux基金会以及与我们合作的项目社区制作的开源软件均已发布，并且在没有任何传播限制的前提下供公众通过公开渠道获取。

以下情形（但不仅限于此）不受到EAR限制，因为“开源”“已发布”：

• 已公开发布的开源软件不受制于EAR
• 已公开发布的开源规范不受制于EAR
• 已公开发布的，说明硬件设计的开源文档不受制于EAR
• 已公开发布的开源软件二进制不受制于EAR

然而，若项目涉及加密技术，则开源社区可能需要采取一些其他的措施以满足EAR “已发布”的要求。

使用加密技术的项目

EAR规范了特定加密软件和技术的出口。“加密软件”的定义非常广泛，并可能包括仅激活或启用其他软硬件产品的加密功能的软件。

但是，与已发布的软件不受制于EAR一样，使用加密技术的软件即如符合以下两个条件，则不受制于EAR：（1）该源代码是“可公开获取”的，以及（2）已向第742.15（b）部分所提供的电子邮箱地址发送了邮件以示通知。

为符合第一项豁免要求，“可公开获取”指的是在EAR法下“已发布”的定义，这包括通过公共站点进行发布（即公开传播）。9只要完全公开的开源软件项目达到该标准，则应当视为通过了衡量标准的第一部分要求：如果项目的源代码可在互联网上公开获取，则应被视为“可公开获取”。

为满足上述衡量标准的第二部分要求，还需要向两个指定的邮箱地址发送邮件（一个是BIS的邮箱地址：crypt@bis.doc.gov，另外一个是国家安全局（National Security Agency，简称“NSA”）的邮箱地址：enc@nsa.gov）。邮件内容需要包括可公开获取的源代码的URL地址（或源代码本身）。如URL或源代码发生任何变更，则需要再次以邮件形式通知上述邮箱地址。

当该可公开获取的加密源代码通过了上述两项衡量标准后，那么相应的目标代码也将不受EAR管辖。

Linux基金会的所有项目源代码，包括加密软件，均可公开获取，我们也已经提供了如上所述的电子邮件通知。我们也在LF官网上公开了上述电子邮件通知的副本。所以，Linux基金会的项目源代码及对应的物件代码均不受制于EAR关于加密的限制。

请注意，上述情况只适用于开源项目本身。如源代码并未公开，修改了项目代码的下游分销商或其衍生产品的下游分销商仍然需要自行评估是否符合EAR的规定（和其出口的其他软件一样）。

除了使用加密技术的项目外，EAR还在2020年1月为采用神经网络驱动的地理空间分析培训的系统增加了一项新法规。与其他公开提供的开源技术一样，公开发布的开源软件，即使是在神经网络驱动的地理空间分析培训这一类别中，也不会受到EAR的约束。请参阅我们的完整白皮书了解更多说明。

开源软件社区的最佳实践

虽然开源项目不受EAR限制，但我们已经学习或者掌握了一些可能对所有开源社区有所助益的实践，都与出口管理条例相关。

我们经常用“公开”这个词来形容许多事情：开源许可、公开和透明的讨论、公开的社区、公共智库里储存的可公开获取的源代码。对于开源社区来说，“公开”似乎是显而易见的做法，但以下是一些社区需要考虑的具体建议。

开放，公开

首先，社区应该尽量保持技术对话的开放和公开。如果私人技术对话在社区内发生，这是正常的，但建议将社区决策和结果公开。对于我们的项目来说，使信息公开透明是很重要的，因为技术或技术信息的私人交流可能不符合EAR的“公开可得”标准。

出现的一个问题与在安全披露过程中交换与安全问题有关的信息有关。作为一种最佳实践，项目可能会考虑在修复程序可用时公开此类交换，而不是将此信息限制在一个机密的公开列表中。

向BIS和NSA发送加密通知

如果您的开源软件项目实施或使用属于ECCN 5D002规定的加密功能，那么根据EAR的要求，您将需要向BIS和NSA发送加密通知。EAR的具体要求如下：

• 发送电邮至crypt@bis.doc.gov及enc@nsa.gov。如果您的项目是LF的项目，并且您的通知没有出现在我们的出口管理页面上，请发送通知至legal@linuxfoundation.org。
• 邮件应该包括含有可公开获取加密源代码的网站地址，或源代码本身。
• 如果您提供的是网站地址，那么每次更换网站地址时，您都必须通过电子邮件发送通知，但是您不需要通知有关源代码本身的更新或者变更。
• 如果您提供的是源代码本身，那么每当加密功能进行更新或者变更后，您都必须提供最新的源代码。

Linux基金会建议将其他的一些细节作为最佳实践：

• 为了加强透明度和展现合规性，将提交给BIS和NSA的通知公开化。这也有助于解决下游用户对社区是否发送了通知的疑惑。通过公开通知的方式，您可以避免这些困扰。
• 附加联系方式和负责项目的法人实体的名称。
• 设计一个保留中期至长期证据的系统（证明发送给BIS和NSA的通知电邮实际上已经送达）。因为如果将来发生问题，或者如果个人无法访问该“已发送”邮箱，仅依靠“已发送”邮箱记录不是个好办法（例如发件人跳槽了）。

此外，如果您正在以目标代码的形式分发公开可用的加密软件，那么您还需要确保它也以源代码的形式公开可用。

如果必须以二进制或目标代码形式分发加密软件，那么就必须确定相应的源代码是可公开获取的。最简便的方式就是自主将该加密软件版本的源代码公开，作为项目本身的源代码。（事实上，根据适用的开源许可，这对遵守开源许可可能也是必要的，或者至少是有用的！）

除人工审核外，还有一些性能各异的扫描工具(例如 Fossology 和 exportctl)，可以扫描源代码并探测加密功能的应用。没有一种自动扫描工具能够完美地检测出所有的应用，但这些工具可能有助于识别大型代码库中的加密软件。

请点击下面的按钮，下载“了解开放源码技术和美国出口控制”白皮书，。

下载

The post 了解美国对开源项目的出口管制 appeared first on The Linux Foundation.

Understanding Open Source Technology & US Export Controls 了解开源科技和美国出 口管制 Open development enables global collaboration: a guide for companies using and developing open source technology 开源发展使全球协作成为可能：一份致使用与开发开源科技公司的指南 Author: The Linux Foundation Download Now

The post Understanding Open Source Technology & US Export Controls appeared first on The Linux Foundation.

Linux Articles, Stories & News  Robotics Tomorrow

Linux-based Software for Automation | RoboticsTomorrow  Robotics Tomorrow

New life for obsolete Intel Macs: Great Windows (or Linux) machines for years to come?  ZDNet

Intel CPUs have long supported LBR for last branch records as a means of recording the branches to which software has taken along with exposing other control flow information. This has relied upon model-specific registers while with future Intel CPUs this is being folded into a more universal CPU architectural feature. Support for Intel "Arch LBR" is set to come later this year with the Linux 5.9 kernel...

Intel Architectural LBR Support Going Into Linux 5.9  Phoronix

Intel Architectural LBR Support Going Into Linux 5.9  Phoronix