April 2019 License-Discuss Summary

In April, the License-Discuss mailing list:

  • talked about non-commercial licensing
  • discussed license revocability
  • answered a question about LGPL/Apache compatibility

The corresponding License-Review summary is online at https://opensource.org/LicenseReview042019 and covers extensive discussion about the Cryptographic Autonomy License.

International Licenses Redux

As proposed in December, Richard Fontana has updated the “International” license category of the OSI license list.

Non-Commercial doesn't compose

Chris Webber posts an essay about non-commercial licenses to the list, based on his experience working at Creative Commons.

Webber is “sad to see history repeat itself […] given the [recent] volume of submissions in favor some sort of noncommercial style license” (Note: like SSPL). Whereas Rob Myers joked that NC stands for No Community, Webber argues it represents “‘No Composition’, which is just as much or more of a threat”. Core points:

  • Defining (non-)commercial use is extremely difficult. See https://wiki.creativecommons.org/wiki/Defining_Noncommercial.

  • NC is asymmetric. “NC has the kind of appeal that a lottery does: it's very fun to think about participating when you imagine yourself as the recipient.”

  • NC feels like a minefield. If single NC licenses are already confusing, how would it feel if the whole system switched? For example, would a partially-NC Debian distribution be usable?

  • Different license users have opposed goals. “Libre Commoners” want to protect the commons, and want everyone to abide by the license. In contrast, “Proprietary Relicensors” want to prevent free riders in order to develop income. This is anti-community.

Webber concludes that “Noncommercial fails in its goals and it fails the community. It sounds nice when you think you'll be the only one on top, but it doesn't work, and it never will.”

Can a contributor take back open source code?

Antoine Thomas asks whether a contributor would be able to revoke/remove their contributions from a project, and how this would affect old versions of a project.

Kevin Fleming responds that legitimately provided open source licenses are not revocable, but that a project might honor a request out of courtesy.

Brendan Hickey points out that copyright law may provide special revocation rights, e.g. 17 USC §203. And even without revocation, a contributor could make life difficult for users.

Compatibility of LGPLv2.1 and Apache 2.0

Bryan Christ [1,2] asks whether Apache-covered software can link with LGPLv2.1 libraries and vice versa. The question is motivated by their incompatible patent clauses.

Bruce Perens [1,2,3] affirms that either direction of linking is fine: neither license imposes terms on the software it is linked with. But the LGPL does extend some terms onto the linked work in its entirety, which could be a problem e.g. with proprietary licenses that prohibit reverse engineering. While the Apache-2 patent clause is incompatible with the GPLv2, the LGPL is structured differently.

Bryan Christ notes that the ASF lists the LGPL as incompatible. Bruce Perens explains that the Apache Foundation excludes LGPL software from their own projects because the LGPL affects the larger work, but that the licenses themselves allow linking with each other.

McCoy Smith links to the FSF comment on the Apache license, but notes that it only discusses GPL and not LGPL.

To promote and protect open source software and communities...

For over 20 years the Open Source Initiative (OSI) has worked to raise awareness and adoption of open source software, and build bridges between open source communities of practice. As a global non-profit, the OSI champions software freedom in society through education, collaboration, and infrastructure, stewarding the Open Source Definition (OSD), and preventing abuse of the ideals and ethos inherent to the open source movement.

Open source software is made by many people and distributed under an OSD-compliant license which grants all the rights to use, study, change, and share the software in modified and unmodified form. Software freedom is essential to enabling community development of open source software.