2020年9月

由于物联网(IoT)的兴起,对硬件进行编程变得越来越普遍。RT-Thread 可以让你可以用 FinSH 从 Linux 命令行与设备进行沟通、

RT-Thread 是一个开源的实时操作系统,用于对物联网(IoT)设备进行编程。FinSH 是 RT-Thread 的命令行组件,它提供了一套操作界面,使用户可以从命令行与设备进行沟通。它主要用于调试或查看系统信息。

通常情况下,开发调试使用硬件调试器和 printf 日志来显示。但在某些情况下,这两种方法并不是很有用,因为它是从运行的内容中抽象出来的,而且它们可能很难解析。不过 RT-Thread 是一个多线程系统,当你想知道一个正在运行的线程的状态,或者手动控制系统的当前状态时,这很有帮助。因为它是多线程的,所以你能够拥有一个交互式的 shell,你可以直接在设备上输入命令、调用函数来获取你需要的信息,或者控制程序的行为。如果你只习惯于 Linux 或 BSD 等现代操作系统,这在你看来可能很普通,但对于硬件黑客来说,这是极其奢侈的,远超将串行电缆直接连线到电路板上以获取一丝错误的做法。

FinSH 有两种模式。

  • C 语言解释器模式,称为 c-style。
  • 传统的命令行模式,称为 msh(模块 shell)。

在 C 语言解释器模式下,FinSH 可以解析执行大部分 C 语言的表达式,并使用函数调用访问系统上的函数和全局变量。它还可以从命令行创建变量。

在 msh 模式下,FinSH 的操作与 Bash 等传统 shell 类似。

GNU 命令标准

当我们在开发 FinSH 时,我们了解到,在编写命令行应用程序之前,你需要熟悉 GNU 命令行标准。这个标准实践的框架有助于给界面带入熟悉感,这有助于开发人员在使用时感到舒适和高效。

一个完整的 GNU 命令主要由四个部分组成。

  1. 命令名(可执行文件):命令行程序的名称;
  2. 子命令:命令程序的子函数名称。
  3. 选项:子命令函数的配置选项。
  4. 参数:子命令函数配置选项的相应参数。

你可以在任何命令中看到这一点。以 Git 为例:

git reset --hard HEAD~1

这一点可以分解为:

 title=

可执行的命令是 git,子命令是 reset,使用的选项是 --head,参数是 HEAD~1

再举个例子:

systemctl enable --now firewalld

可执行的命令是 systemctl,子命令是 enable,选项是 --now,参数是 firewalld

想象一下,你想用 RT-Thread 编写一个符合 GNU 标准的命令行程序。FinSH 拥有你所需要的一切,并且会按照预期运行你的代码。更棒的是,你可以依靠这种合规性,让你可以自信地移植你最喜欢的 Linux 程序。

编写一个优雅的命令行程序

下面是一个 RT-Thread 运行命令的例子,RT-Thread 开发人员每天都在使用这个命令:

usage: env.py package [-h] [--force-update] [--update] [--list] [--wizard]
                      [--upgrade] [--printenv]

optional arguments:
  -h, --help      show this help message and exit
  --force-update  force update and clean packages, install or remove the
                  packages by your settings in menuconfig
  --update        update packages, install or remove the packages by your
                  settings in menuconfig
  --list          list target packages
  --wizard        create a new package with wizard
  --upgrade       upgrade local packages list and ENV scripts from git repo
  --printenv      print environmental variables to check

正如你所看到的那样,它看起来很熟悉,行为就像你可能已经在 Linux 或 BSD 上运行的大多数 POSIX 应用程序一样。当使用不正确或不充分的语法时,它会提供帮助,它支持长选项和短选项。这种通用的用户界面对于任何使用过 Unix 终端的人来说都是熟悉的。

选项种类

选项的种类很多,按长短可分为两大类。

  1. 短选项:由一个连字符加一个字母组成,如 pkgs -h 中的 -h 选项。
  2. 长选项:由两个连字符加上单词或字母组成,例如,scons- --target-mdk5 中的 --target 选项。

你可以把这些选项分为三类,由它们是否有参数来决定。

  1. 没有参数:该选项后面不能有参数。
  2. 参数必选:选项后面必须有参数。
  3. 参数可选:选项后可以有参数,但不是必需的。

正如你对大多数 Linux 命令的期望,FinSH 的选项解析非常灵活。它可以根据空格或等号作为定界符来区分一个选项和一个参数,或者仅仅通过提取选项本身并假设后面的内容是参数(换句话说,完全没有定界符)。

  • wavplay -v 50
  • wavplay -v50
  • wavplay --vol=50

使用 optparse

如果你曾经写过命令行程序,你可能会知道,一般来说,你所选择的语言有一个叫做 optparse 的库或模块。它是提供给程序员的,所以作为命令的一部分输入的选项(比如 -v--verbose)可以与命令的其他部分进行解析。这可以帮助你的代码从一个子命令或参数中获取一个选项。

当为 FinSH 编写一个命令时,optparse 包希望使用这种格式:

MSH_CMD_EXPORT_ALIAS(pkgs, pkgs, this is test cmd.);

你可以使用长形式或短形式,或者同时使用两种形式来实现选项。例如:

static struct optparse_long long_opts[] =
{
    {"help"        , 'h', OPTPARSE_NONE}, // Long command: help, corresponding to short command h, without arguments.
    {"force-update",  0 , OPTPARSE_NONE}, // Long comman: force-update, without arguments
    {"update"      ,  0 , OPTPARSE_NONE},
    {"list"        ,  0 , OPTPARSE_NONE},
    {"wizard"      ,  0 , OPTPARSE_NONE},
    {"upgrade"     ,  0 , OPTPARSE_NONE},
    {"printenv"    ,  0 , OPTPARSE_NONE},
    { NULL         ,  0 , OPTPARSE_NONE}
};

创建完选项后,写出每个选项及其参数的命令和说明:

static void usage(void)
{
    rt_kprintf("usage: env.py package [-h] [--force-update] [--update] [--list] [--wizard]\n");
    rt_kprintf("                      [--upgrade] [--printenv]\n\n");
    rt_kprintf("optional arguments:\n");
    rt_kprintf("  -h, --help      show this help message and exit\n");
    rt_kprintf("  --force-update  force update and clean packages, install or remove the\n");
    rt_kprintf("                  packages by your settings in menuconfig\n");
    rt_kprintf("  --update        update packages, install or remove the packages by your\n");
    rt_kprintf("                  settings in menuconfig\n");
    rt_kprintf("  --list          list target packages\n");
    rt_kprintf("  --wizard        create a new package with wizard\n");
    rt_kprintf("  --upgrade       upgrade local packages list and ENV scripts from git repo\n");
    rt_kprintf("  --printenv      print environmental variables to check\n");
}

下一步是解析。虽然你还没有实现它的功能,但解析后的代码框架是一样的:

int pkgs(int argc, char **argv)
{
    int ch;
    int option_index;
    struct optparse options;

    if(argc == 1)
    {
        usage();
        return RT_EOK;
    }

    optparse_init(&options, argv);
    while((ch = optparse_long(&options, long_opts, &option_index)) != -1)
    {
        ch = ch;

        rt_kprintf("\n");
        rt_kprintf("optopt = %c\n", options.optopt);
        rt_kprintf("optarg = %s\n", options.optarg);
        rt_kprintf("optind = %d\n", options.optind);
        rt_kprintf("option_index = %d\n", option_index);
    }
    rt_kprintf("\n");

    return RT_EOK;
}

这里是函数头文件:

#include "optparse.h"
#include "finsh.h"

然后,编译并下载到设备上。

 title=

硬件黑客

对硬件进行编程似乎很吓人,但随着物联网的发展,它变得越来越普遍。并不是所有的东西都可以或者应该在树莓派上运行,但在 RT-Thread,FinSH 可以让你保持熟悉的 Linux 感觉。

如果你对在裸机上编码感到好奇,不妨试试 RT-Thread。


via: https://opensource.com/article/20/9/hardware-command-line

作者:Alan Smithee 选题:lujun9972 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

我最近在我的树莓派上安装了 Ubuntu 服务器。我在 Ubuntu 终端连接上了 Wi-Fi,然后做了我在安装任何 Linux 系统后都会做的事情,那就是更新系统。

当我使用 sudo apt update 命令时,它给了一个对我而言特别的错误。它报出仓库的发布文件在某个时间段内无效。

E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-security/InRelease is not valid yet (invalid for another 159d 15h 20min 52s). Updates for this repository will not be applied.**

下面是完整输出:

ubuntu@ubuntu:~$ sudo apt update
Hit:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease    
Get:2 http://ports.ubuntu.com/ubuntu-ports focal-updates InRelease [111 kB]                           
Get:3 http://ports.ubuntu.com/ubuntu-ports focal-backports InRelease [98.3 kB]      
Get:4 http://ports.ubuntu.com/ubuntu-ports focal-security InRelease [107 kB]                     
Reading package lists... Done
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal/InRelease is not valid yet (invalid for another 21d 23h 17min 25s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-updates/InRelease is not valid yet (invalid for another 159d 15h 21min 2s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-backports/InRelease is not valid yet (invalid for another 159d 15h 21min 32s). Updates for this repository will not be applied.
E: Release file for http://ports.ubuntu.com/ubuntu-ports/dists/focal-security/InRelease is not valid yet (invalid for another 159d 15h 20min 52s). Updates for this repository will not be applied.

修复 Ubuntu 和其他 Linux 发行版中 “Release file is not valid yet” 的错误。

错误的原因是系统上的时间和现实世界的时间不同。

你看,每个仓库文件都是在某个日期签名的,你可以通过查看发布文件信息了解:

sudo head /var/lib/apt/lists/ports.ubuntu.com_ubuntu_dists_focal_InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Origin: Ubuntu
Label: Ubuntu
Suite: focal
Version: 20.04
Codename: focal
Date: Thu, 23 Apr 2020 17:33:17 UTC
Architectures: amd64 arm64 armhf i386 ppc64el riscv64 s390x

现在,由于某些原因,我的 Ubuntu 服务器上的时间是过去时间,这也是为什么 Ubuntu 报出发布文件已经无效 X 天的原因。

如果你连接到了互联网,你可以等待几分钟让系统同步时间

如果不行,你可以强制系统使用本地时间作为实时时钟(硬件时钟):

sudo timedatectl set-local-rtc 1

timedatectl 命令可以让你在 Linux 上配置时间、日期和更改时区

你应该不需要重新启动。它可以立即工作,你可以通过更新你的 Ubuntu 系统再次验证它。

如果问题解决了,你可以将实时时钟设置为使用 UTC(Ubuntu 推荐的)。

sudo timedatectl set-local-rtc 0

是否为你解决了这个问题?

我希望这个提示能帮助你解决这个错误。如果你仍然遇到这个问题,请在评论栏告诉我,我会尽力帮助你。


via: https://itsfoss.com/fix-repository-not-valid-yet-error-ubuntu/

作者:Abhishek Prakash 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

美国国税局要求在纳税申报表上申报加密货币交易

对加密货币态度改变和最近的其他行动表明,美国国税局正在认真对待加密货币对税收制度的威胁,无论对方是不合规的爱好者还是复杂的国际犯罪分子。许多加密货币用户对美国国税局的指导意见感到愤怒,该指南将比特币、以太币及其加密货币视为财产,而非货币。

来源:cnbeta

拍一拍:加密货币已经从微不足道逐渐变成了正常经济生活的一部分。但是究竟该将加密货币视作货币还是资产,抑或兼而有之,这是一个全新的需要探索的领域。

OpenSSH 8.4发布 为 FIDO/2FA 密钥带来更好的支持

对于那些使用 YubiKey 或 Google Titan 安全密钥等 FIDO 密钥处理双因素认证的用户,OpenSSH 8.4 有了更好的支持。OpenSSH 8.4 现在支持每次使用都需要输入 PIN 码的 FIDO 密钥,SSHD 支持“验证-要求”选项,要求 FIDO 签名断言令牌被验证。

来源:cnbeta

拍一拍:最好的安全就是“不用”密码的安全。

英特尔异构编程器 oneAPI 发布 1.0 正式版

oneAPI 是英特尔推出的开源、基于标准的统一编程模型,旨在为从 CPU 到 GPU,再到 FPGA 等其他加速器的一系列硬件提供支持。oneAPI 的核心是英特尔的 Data Parallel C++(DPC++),是建立在 C++ 和 Khronos SYCL 标准之上的语言。除了基于 LLVM/Clang 的 DPC++ 编译器工具链外,oneAPI 还包含了许多库。

来源:cnbeta

拍一拍:虽然不懂,但是感觉很厉害。

近日,著名开源领袖、写出《大教堂与集市》的 ESR(Eric S. Raymond)撰文指出,微软的 Windows 可能最后会切换到 Linux 内核,成为一个保留 Windows 界面的 Linux。微软目前的主要收入来源于其云服务,而操作系统业务对微软来说,所能贡献的利润比例会越来越少。Windows 将来可能是运行于 Linux 内核之上的一个桌面环境和一个越来越薄的 Windows 兼容层 —— 以兼容原有的 Windows 二进制程序。

对于 ESR 的这个观点,老王是赞同的:

这些年来,随着云技术的发展,越来越多的操作系统厂商将业务重点从单机操作系统转向云基础设施。在这一点上,从著名的 Linux 发行版 Ubuntu 的发行商 Canonical 身上也可见一斑。

而另一方面,不说谷歌的 Chromebook 上运行的 Chrome OS,主流的操作系统 macOS 也早已针对 Apple 公司的硬件免费提供。在这种情况下,操作系统已经不是早些年的现金奶牛了。

从微软这几年发布的 Windows 的更新中屡屡出现严重问题所反映出的其内部质控环境的劣化,可见微软已经逐步减少了对操作系统部门的投入。因此,ESR 的这个预测可谓有一定的道理。

看来,我们终将能看到 Linux 打败 Windows 的一天,真正地、彻底地解决 “Ubuntu 第一号 bug”。或许,这不能称之为打败,相对于 Linux 在服务器领域、移动领域、高性能计算领域的高歌猛进,Linux 一直在桌面领域方面进展乏力,这应该说是 Linux 和 Windows 的融合更加合适。

以下是 ESR 的原文译文:

桌面战争的最后阶段?

在微软 Windows 操作系统最近的发展中,最令人感兴趣的两个发展是 Windows System for Linux(WSL)和他们将微软 Edge 浏览器移植到 Ubuntu。

对于那些没有注意到的人来说,WSL 允许未经修改的 Linux 二进制文件在 Windows 10 下运行。没有仿真层,没有中间层,它们只需加载就能运行。

微软开发人员现在正在 Linux 内核中提供功能来改进 WSL。而这指向了一个迷人的技术方向。为了理解其中的原因,我们需要注意到自 2010 年推出云服务以来,微软的收入来源是如何变化的。

在十年后,Azure 为微软提供了大部分的创收。Windows 的垄断地位已经成为一个旁观者,传统台式电脑(这是它唯一占据主导地位的市场)的销量在下降。相应地,花在 Windows 开发上的投资回报率也在下降。随着 PC 的销量持续下滑,它不可避免地将不再是利润中心,而变成业务的拖累。

从冷血的利润最大化的角度来看,这意味着继续开发 Windows 是微软宁愿不做的事情。相反,他们最好把更多的资本投入到 Azure 上 —— 据说现在 Azure 运行的 Linux 实例比 Windows 还多。

我们的第三个理由是 Proton。Proton 是一个仿真层,它允许在 Linux 上运行 Steam 上发布的 Windows 游戏。它还不够完美,但已经很接近完美了。我自己就用它在这个巨兽上玩《战舰世界》。

对于游戏而言,它们是对 Windows 仿真层最苛刻的压力测试,比商业软件更苛刻。我们可能已经到了类似 Proton 的技术完全可以在 Linux 上运行 Windows 商业软件的地步。如果还没有,那我们很快就会实现。

那么,如果你是微软公司的战略专家,考虑到所有这些因素,利润最大化的前进道路是什么?

它会是这样:微软 Windows 成为 Linux 内核上的 Proton 一样的模拟层。随着时间的推移,这个层会越来越薄,因为更多的支持会落在主线内核源代码上。而经济上的动机是,由于需要在公司内部完成的开发成本越来越少,因此微软可以减去越来越多的开发成本。

如果你认为这是天方夜谭,那你可以再思考一下。证明这已经是(微软的)计划的最好证据是,微软已经将 Edge 移植到 Linux 下运行。这只有这种方式是有意义的:那就是作为一个试运行,让 Windows 实用程序套件的其他部分摆脱对任何仿真层的依赖。

所以,这一切指向的最终状态是。新的 Windows 将主要是一个 Linux 内核,在它上面有一个旧的 Windows 仿真层,但 Edge 和其余的 Windows 用户空间实用程序并不使用仿真。仿真层是为了游戏和其他传统的第三方软件而存在的。

经济上的压力会让微软取消仿真层。部分原因是它完全是一个成本中心。部分原因是因为他们想降低运行 Azure 的复杂性成本。 Windows/Linux 每一点融合都有助于实现这一点 —— 可以减少管理和预期的支持费用。

最终,微软将会宣布结束对 Windows 的仿真。操作系统本身,以及它的用户空间工具,一段时间后,会在一个精心保存的旧 Windows 用户界面下成为 Linux。第三方软件供应商会停止发布 Windows 二进制文件,转而采用原生 Linux API 的 ELF 二进制文件……。

……而 Linux 终将赢得桌面战争,不是通过取代 Windows,而是通过合作。也许这一直是它必须要做的事情。

这个老牌 Linux 备份方案迁移到了 Python 3 提供了添加许多新功能的机会。

2020 年 3 月,rdiff-backup 升级到了 2.0 版,这距离上一个主要版本已经过去了 11 年。2020 年初 Python 2 的废弃是这次更新的动力,但它为开发团队提供了整合其他功能和优势的机会。

大约二十年来,rdiff-backup 帮助 Linux 用户在本地或远程维护他们的数据的完整备份,而无需无谓地消耗资源。这是因为这个开源解决方案可以进行反向增量备份,只备份从上一次备份中改变的文件。

这次改版(或者说,重生)得益于一个新的、自组织的开发团队(由来自 IKUS Software 的 Eric Zolf 和 Patrik Dufresne,以及来自 Seravo 的 Otto Kekäläinen 共同领导)的努力,为了所有 rdiff-backup 用户的利益,他们齐心协力。

rdiff-backup 的新功能

在 Eric 的带领下,随着向 Python 3 的迁移,项目被迁移到了一个新的、不受企业限制的仓库,以欢迎贡献。团队还整合了多年来提交的所有补丁,包括对稀疏文件的支持和对硬链接的修复。

用 Travis CI 实现自动化

另一个巨大的改进是增加了一个使用开源 Travis CI 的持续集成/持续交付(CI/CD)管道。这允许在各种环境下测试 rdiff-backup,从而确保变化不会影响方案的稳定性。CI/CD 管道包括集成所有主要平台的构建和二进制发布。

使用 yum 和 apt 轻松安装

新的 rdiff-backup 解决方案可以运行在所有主流的 Linux 发行版上,包括 Fedora、Red Hat、Elementary、Debian 等。Frank 和 Otto 付出了艰辛的努力,提供了开放的仓库以方便访问和安装。你可以使用你的软件包管理器安装 rdiff-backup,或者按照 GitHub 项目页面上的分步说明进行安装。

新的主页

团队将网站从 Savannah 迁移到了 GitHub Pages,并对 rdiff-backup.net 官网进行了改版,加入了新的内容,让外观和感觉更加到位。

如何使用 rdiff-backup

如果你是 rdiff-backup 的新手,你可能会对它的易用性感到惊讶。备份方案应该让你对备份和恢复过程感到舒适,而不是吓人。

开始备份

要开始备份到本地驱动器,例如通过 USB 连接的驱动器,输入 rdiff-backup 命令,然后输入要备份的驱动器和要存储文件的目标目录。

例如,要备份到名为 my_backup_drive 的本地驱动器,请输入:

$ rdiff-backup /home/tux/ /run/media/tux/my_backup_drive/

要将数据备份到异地存储,请使用远程服务器的位置,并在 :: 后面指向备份驱动器的挂载点:

$ rdiff-backup /home/tux/ [email protected]::/my_backup_drive/

你可能需要设置 SSH 密钥来使这个过程更轻松。

还原文件

做备份的原因是有时文件会丢失。为了使恢复尽可能简单,你甚至不需要 rdiff-backup 来恢复文件(虽然使用 rdiff-backup 命令提供了一些方便)。

如果你需要从备份驱动器中获取一个文件,你可以使用 cp 将其从备份驱动器复制到本地系统,或者对于远程驱动器使用 scp 命令。

对于本地驱动器,使用:

$ cp _run_media/tux/my_backup_drive/Documents/example.txt ~/Documents

或者用于远程驱动器:

$ scp [email protected]::/my_backup_drive/Documents/example.txt ~/Documents

然而,使用 rdiff-backup 命令提供了其他选项,包括 --restore-as-of。这允许你指定你要恢复的文件的哪个版本。

例如,假设你想恢复一个文件在四天前的版本:

$ rdiff-backup --restore-as-of 4D /run/media/tux/foo.txt ~/foo_4D.txt

你也可以用 rdiff-backup 来获取最新版本:

$ rdiff-backup --restore-as-of now /run/media/tux/foo.txt ~/foo_4D.txt`

就是这么简单。另外,rdiff-backup 还有很多其他选项,例如,你可以从列表中排除文件,从一个远程备份到另一个远程等等,这些你可以在文档中了解。

总结

我们的开发团队希望用户能够喜欢这个改版后的开源 rdiff-backup 方案,这是我们不断努力的结晶。我们也感谢我们的贡献者,他们真正展示了开源的力量。


via: https://opensource.com/article/20/9/rdiff-backup-linux

作者:Patrik Dufresne 选题:lujun9972 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

开源法规对成功有不同寻常的要求。一起来了解开源组织的律师如何帮助其雇主找到可行路径。

正如我在这个分为两部分的系列文章的第一部分中所分享的那样,我是 红帽公司 Red Hat 的一名开源律师。我工作中的一个重要部分是向其他公司(包括其内部法律顾问)提供有关红帽公司如何采用完全开源的开发模式来构建企业级产品的信息,并回答他们有关开源许可的一般问题。在听了红帽公司的成功经验之后,这些律师与我对话的话题常常转变为其所在组织如何发展成为更具开源意识和能力的组织,他们也经常询问我如何改善他们的做法,以便更熟练地为其组织的雇员提供开源法律咨询。在这两篇文章中,我将分享我通常在这些主题上告诉内部法律顾问的那些内容。

总是要找到一条可行路径

我的雇主红帽公司在使用开源软件方面的独特之处在于,我们的开发模式始于具有数千名贡献者的开源社区,并产生了经受过尝试、测试和信任的最终产品。更具体地说,通过我们独特的开发模式,我们从社区创建的开源软件开始,并在每个项目的基础上加强安全性,修复错误,修补漏洞并添加新功能。然后,我们将这些改进回馈给每个项目,以便使整个开源社区受益。此方法的效用非常重要,包括:

  1. 通过内部团队与组织外部其他人之间的协作来利用外部创新;
  2. 当现有或潜在的社区与您在同一问题上开展工作而且能够合作时,可以避免您自己开发和维护开源解决方案的成本和效率低下的问题;
  3. 通过与合作伙伴和上游项目社区的富有成效的合作,能够避免维护主项目下游分支的昂贵代价。

    • 一些公司发现创建上游代码的非公共分支很诱人,因为它是解决特定 用例 use case 的快速方法,或者因为它们不愿意在社区中进行协作。然而,由于增加的开发成本、互操作性损失和其他原因,这种分支的长期维护负担可能是令人望而却步的。相比之下,将开发集中在原始上游社区中,可以在所有参与者之间分担开发成本。

除少数例外(例如红帽公司)外,大多数使用开源软件的组织可能都拥有专有软件许可模式(或与 SaaS 等效的概念),并在其业务中对专有软件进行许可。这些组织认为他们拥有可以提供某些竞争优势的软件组件,并且不希望看到这些组件在开源条款下对其他人可用。这是可以理解的。但是,我会鼓励任何咨询此类问题的开源律师来敦促其客户采用开源开发模式,尤其是对于所有无差异且通用的软件。

例如,如果您的公司开发了用于手机的应用程序,并且您需要一个软件模块来读取和写入 PNG 图像文件,那么使用 GitHub 上流行的开源 PNG 软件模块之一将便宜得多。对于您的业务而言,对 PNG 图像进行编码和解码可能是无差别的,那么为什么要花费宝贵的工程时间来编写自己的版本?此外,为此功能编写自己的模块也可能会导致与使用常用开源模块的其他软件的兼容性问题。这是为什么呢?尽管您的模块和开源模块可能已被编写为对已发布的 PNG 规范进行编码和解码,但有时对规范的解释可能会有所不同,也可能会出现实施错误。使用同一模块执行此功能的每个人都可以确保大多数用户的兼容性,并降低开发和维护成本。

还必须意识到,您可能需要某些软件来保持专有性,并且不受开源条款的约束。取决于您系统的软件体系架构和所使用的开源许可证,除非采取某些措施(超出本文的范围),否则打算保留专有权的软件代码可能会受到开源许可证条款的约束。在这里向客户提供一些有关许可证选择和体系架构的咨询服务将变得很有用。

寻找灵活的解决方案

之前主要许可专有软件的组织逐渐增加了对开源软件的使用,但审核和批准的要求可能会增长(以我的经验甚至成倍增长)。由于资源限制,这样的组织可能会陷入困境。下面介绍了一些可以采用的灵活的解决方案。

授权并委托他人

律师不能也不应成为看门人。那样效率低下,并且肯定会导致开发和发布时间出现瓶颈,从而产生挫败感和收入损失。相反,应将审批权限授予产品或项目管理和工程领域有能力的个人。这可以让组织有效地保持灵活性。对客户进行教育(请参阅下一节)对于成功实现这一点至关重要。

我采用的一种方法是为整个工程组织提供开源培训,以便他们可以进行基本的许可模式和体系架构选择,同时为软件开发人员提供更专业的培训,以使他们能够提供更复杂的指导和决策。也要考虑在每个级别上对权限进行明确限制,包括哪些类型的问题和决定必须上报给作为他们开源律师的您。您组织的特定授权级别将取决于您团队在开源方面的经验以及对某些开源问题的敏感性。

教育客户

我发现培训是将您的组织迁移到更具开源意识组织的最有效工具之一。培训您的软件工程师和产品经理至关重要。让我详细说明。

尽管您的软件工程师处在最前沿,并且通常可能对开源问题和软件许可非常了解,但是基于您组织的特定要求对他们进行培训仍然很重要。例如,您的公司可能只允许使用宽松的开源许可证,并且可能对其版权声明和源代码可用性有某些要求。为避免开发中出现随后必须纠正的问题(一种昂贵且耗时的实践),最好培训工程师最大程度地减少不当行为的可能性,尤其是在所有开发过程的开始时(请参阅下一节)。

产品经理也必须接受培训。在许多公司中,产品经理负责营销的经典四个环节(产品、价格、定位和促销),并负责产品从生到死的整个生命周期。产品经理工作的方方面面可能会受到使用开源软件的影响。出于上述相同的原因,了解使用开源软件的要求对他们很有用。此外,更重要的是,产品经理在组织中的重要影响,意味着他们通常能够对流程和政策进行必要的更改。产品经理可能会成为您针对“开放”进行流程变更的最强有力的拥护者之一。

早期发现

在开发过程快要结束时解决开源许可问题非常困难且成本很高。随着软件的发布日期临近,体系架构和开源软件模块都是已经选定且难以更改了。如果检测到问题,例如专有软件模块中嵌入的“左版”(copyleft)软件(当该专有模块无意受开源条款约束时),则在该开发阶段修改体系架构或模块可能非常困难且成本昂贵。相反,应该在开发过程中尽早进行架构分析和开源模块选择的过程,以便可以进行成本更低且更有效的更正。

开源法规的“奖励”

实践开源法规是一项有益的职业,因为它具有影响组织朝着“开放”方向发展的能力,这具有很大的好处。是否成功取决于您随着组织的成长和成熟而找到具备可行性和灵活性的解决方案的能力。


作者简介:Jeffrey R. Kaufman 是全球领先的开源软件解决方案供应商 红帽公司 Red Hat 开源法务团队的资深商务法律顾问,还担任 北卡罗来纳大学 University of North Carolina 的兼职法律教授。在任职红帽公司之前,Jeffrey 曾担任 高通公司 Qualcomm 的专利和开源法律顾问。

译者简介:薛亮,集慧智佳知识产权咨询公司互联网事业部总监,擅长专利分析、专利布局、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析,致力于为互联网企业、高科技公司提供知识产权咨询服务。