夜天之书

开源软件和自由软件的概念与其许可证紧密绑定。

通常，开源软件被定义为使用 OSI 认可的，即符合开源定义的许可证来分发的软件，而自由软件被定义成使用 GPL 或说 Copyleft 式许可证分发的软件。

尽管今天人们最关心的可能是软件的生产过程即如何进行开源协同，但是为软件选择什么样的许可证，仍然是一个项目启动时必须考虑和决定的问题。某种意义上说，软件可以被如何使用和分发，反过来约束了可能实现的协同模式。

GitHub 维护了 ChooseALicense.com 网站以准确、中立地提供常用开源许可证的介绍，并指引开发者为他们的项目选择合适的许可证。不过，这个页面并没有针对企业开源的情形做出针对性的讨论。

本文从企业开源的场景出发，讨论选择不同开源许可证或源码可得的软件许可证，对企业和项目的影响，并给出主观的建议。

本文成文于 2019 年。最近 Apache StreamPark (Incubating) 项目要做第一个 Apache 版本的发布，遇到了类似的发布多 Scala 支持版本时如何正确生成对应 POM 文件，又尽可能复用流水线的问题。由于过往发布记录都被删除，故重新发布。

近日在阅读 FLINK 代码时发现 FLINK 有一个 force-shading 模块，关于这个模块的作用注释在其使用点 maven-shade-plugin 的配置中是这样写的

现在这个模块已经移动到 flink-shaded 仓库下，详见 pom.xml 文件。

1
2
3
4
5
6
7
8
9
10
11

<artifactSet>
  <includes>
    <!-- Unfortunately, the next line is necessary for now to force the execution
         of the Shade plugin upon all sub modules. This will generate effective poms,
         i.e. poms which do not contain properties which are derived from this root pom.
         In particular, the Scala version properties are defined in the root pom and without
         shading, the root pom would have to be Scala suffixed and thereby all other modules.
         -->
    <include>org.apache.flink:force-shading</include>
  </includes>
</artifactSet>

从注释中我们可以看到 force-shading 的作用是强制触发 maven-shade-plugin 的执行，并且提到了这样会生成所谓的 effective pom 文件。这究竟是怎么一回事呢？我们先从一个实例中理解这个问题。

本文整理自第七届中国开源年会开源码力圆桌：十字路口，代码是我们永恒的信仰上我的发言。

众所周知，开源软件许可证粗略分为 Copyleft 类和 Permissive 类。

这两者常被提及的不同之处，是前者要求对软件的修改和派生仍需以相同条款发布，而后者允许修改软件和派生软件不再发布源代码。

不过，如果我们从两者相同的要求出发，重新看待开源共同体的成员对作为契约的开源许可证的认识，就会有崭新的发现：无论是 Copyleft 类的许可证，还是 Permissive 类的许可证，都没有授予接收方使用软件商标的权利。

特别地，BSD 3-Clause 和 Apache License 2.0 明确限制了接收方使用软件商标（名称）为自己站台的权利，GPLv3 则在附加条款中允许许可方补充限制接收方使用商标的权利。

简言之，商标是被保留的，与发布软件和上游作者绑定的，而不是公共的，任何人可以随意使用的。

那么，为什么开源许可证在允许接受方任意使用、修改、复制和重分发软件的情况下，对商标却采取截然不同的保留态度呢？

过去两年间，我全职参与了多个开源项目的社群建设工作，逐渐形成了自己开展社群建设工作的知识体系，并将其发布在开源小镇网站上。

这个过程里，阅读开源主题的书籍对我借鉴成功经验、警惕历史教训和形成分析问题的框架起到了至关重要的作用。这几天频繁切换工作地点，总有几本开源之书不管到哪我都要随身携带，这里做一个推荐。

开源社群可以通过开展广泛的开源协同来规模化开发软件的生产力。为了实现提升生产力的目标，一般而言需要解决两个阶段的问题：第一个阶段是如何找到适合的潜在开发者人群，吸引他们参与软件开发和社群建设；第二个阶段是社群的原始生产力上来以后，应对项目复杂度和沟通成本随人员规模平方级别增长的难题。

第一阶段的解决方案在《共同创造价值》当中有过相关讨论，第二阶段的问题可以通过工作的模块化和 Review 质量的提升来解决。本文即聚焦在开源协同当中的 Code Review 应该秉承什么原则，做到什么程度，如何避免常见问题来展开。

本文演绎自 Kenneth Auchenberg 的 Developer Experience Infrastructure (DXI) 博客。

原文提到，现在大部分号称以开发者优先为理念建设基础设施的公司，对开发者体验的定义和落地都不是最佳实践。原文作者认为，随着业界对开发者体验的重视和发展，将会出现一个新的领域 Developer Experience Infrastructure (DXI) 也就是开发者体验的基础设施。

上周开发报表的时候实现了一个 Spring Boot + Next.js 前后端代码分离，但是端口唯一的 WebApp 方案。这个方案既能利用好各自的生态，也能避免要起两个 server 占用两个端口的繁琐构建部署逻辑。

本文从选型到实现做一个分享，主要面向熟悉 Spring Boot 技术栈，又想跟进 React 系前端组件化方案的开发者。

开源软件的用户在使用过程中遇到问题时，几乎总是先在自己的环境上打补丁绕过或快速修复问题。开源协同的语境下，开源软件以及维护开源软件的社群统称为该软件的上游，用户依赖上游软件的应用或基于上游软件复刻（fork）的版本统称为下游。上游优先（Upstream First），指的就是用户将下游发现的问题、做出的修改反馈到上游社群的策略。

网络上已经有不少文章讨论上游优先的定义、意义和通用的做法。例如，小马哥为极狐 GitLab 撰写了《Upstream First: 参与贡献开源项目的正确方式》。不过，这些文章往往是站在社群、平台或布道师的层面做笼统的介绍。本文希望从一个开发者的角度出发，由几个具体的上游优先的故事，讨论开发者角度实践上游优先策略的动机和方法。

本文是我继《企业实践开源的动机》、《开源世界当中到底存不存在“白嫖”？》和《免费增值的商业模式》之后再一次讨论免费增值相关的软件商业模式。主要受到 Percona 发布的 Open Source Bait and Switch: Licensing and Beyond 一文的启发，让我意识到 MongoDB Inc. 在很长一段时间里采用 AGPL 的免费增值战略仍然在开源的范畴之内，直到这些公司陆续切换到专有软件许可证，才真正走上了伪开源战略的道路。