Open Source Initiative Blog

  1. License-Review mailing list topics for January 2020:

    • Continued discussion on the Mulan PSL V2
    • Continued discussion on the Cryptographic Autonomy License (Beta 4)
    • Resolution of the Vaccine License – Not Approved
    • Continued discussion on the BSD-1-Clause [Legacy]
    • Resolution of the CasperLabs Open Source License (COSL) – Considered Withdrawn

    Continued discussion on the Mulan PSL V2

    Suggested improvements to the text in the license in around grammar, clarity of intentions, and legal matters

    Revised license submission

    Continued discussion on the Cryptographic Autonomy License (Beta 4)

    Questions on the license use, promulgation, and contributions

    Issue regarding proprietary relicensing seemingly being the primary use case

    Questions with regards to OSD compliance and user freedom, as well as further viewpoints and considerations with regards to data exportability

    Statement that it is OSD compliant and that arguments against it are too situation-specific

    Resolution of the Vaccine License – Not Approved

    Decision that the Vaccine License does not conform to the OSD, specifically OSD 5 regarding user discrimination, and does not assure user freedom.

    Continued discussion on the BSD-1-Clause [Legacy]

    Argument that all that use the license should just be relicensed under the BSD License since multiple identical licenses hinders freedom due to their costs

    Clarification that as a legacy submission, the submitter has no power over the license and that there are significant logistical issues with regards to push a change

    Resolution of the CasperLabs Open Source License (COSL) – Considered Withdrawn

    Decision that the license is considered withdrawn due to non-responsiveness and the criticisms that were brought up

  2. License-Discuss mailing list topics for January 2020:

    • Dual Licensing
    • Copyright on APIs
    • Decision process regarding license review submissions
    • AGPL evaluation and real-world license testing
    • ZFS Kernel Code on Linux

    Dual Licensing

    Centralizing copyright licensing and not centralizing copyrights themselves

    Single entity open source business model

    Copyright on APIs

    Doubt on article assumptions due to machine-readable interface description in the source code

    Decision process regarding license review submissions

    Suggestion to postpone OSI evaluation of new licenses until after some time of practical use

    The role of the OSI and defining norms

    Writing down all rules would be divisive and further enable bad actors

    Postponing evaluation means ignoring and that the current OSI certification process is fine and shouldn’t be changed because of one license being reviewed. Introduce retiring licenses or have a category of "open source but not recommended."

    It is undesirable to have the OSI determine which licenses are better than others

    Concern with interim naming of a license while it is in use but before OSI evaluation

    AGPL evaluation and real-world license testing

    Copyleft-next is engaging in a public drafting process

    ZFS Kernel Code on Linux

  3. Open Course banner

    Each year the Open Source Initiative relies on the dedicated contributions of individual open source developers and advocates, OSI members, and corporate sponsors. This year, with the global pandemic now affecting so many communities, funding priorities have rightly changed: new initiatives that need dedicated support have emerged, yet many fundamental organizations still need continued support to deliver core services.

    Each year the OSI attends over 20 events to meet with sponsors and secure annual funding. With so many events now canceled, our primary channel for fundraising and development has simply disappeared. We recognize many organizations may be struggling themselves and unable to contribute. Individuals too are facing unprecedented pressures, facing professional uncertainties and personal loss.

    Yet in one way--perhaps small, but not insignificant--the Open Source Software movement and community is both inspired and inspiring. The Open Source Software community has come together to collaborate, contribute, and co-create to combat the COVID-19 crisis. Every day we're thrilled to discover new communities of practice emerging in response to the demands faced in combating and ultimately curing COVD-19.

    • Fabio Balli from OSI Affiliate Breathing Games was nominated by the European Union as co-curator of the pan-European hackathon connecting civil society, innovators, partners and buyers across Europe to develop innovative solutions to overcome coronavirus-related challenges.
    • OSI Incubator Project ClearlyDefined is working with The Open Source Center at the Digital Impact Alliance to make open source tools that support relief more accessible, deployable, and interoperable. The Online Digital Global Goods catalog tracks over 200 products that support health, development, and better lives.
    • Affiliate DemocracyLab has created the COVID-19 Volunteer Platform to support at-risk families, health care workers, and first responders during the Covid-19 pandemic.
    • Affiliate Software Freedom Conservancy has shared their Remote Work Tools, to help organizations find the resources to support their distributed staff.
    • OSI members and board directors with leaders from various open source projects and organizations have created FOSS Responders to provide a crowd-sourcing approach to help those in the open source community affected by COVID-19.
    • and so much, much, much, muchmuch more...

    If you have the means, and find the Open Source Software community a valuable global resource that can provide meaningful contributions to address those suffering through COVID-19, we hope you will consider donating to support a project you find inspiring.

    If you believe our role here at the OSI also merits support through these challenging times, we hope you will also consider donating now.

    Stay healthy, stay safe, and thank you for your support.
    The OSI Board of Directors

    Image credit: "COVIDCommunitiy.png" by Open Source Initiative, 2020 (CC BY 4.0)

  4. License-Review mailing list topics for December 2019:

    • ESA Permissive PL v2.3,
    • Mulan Permissive Software License v1 and v2
    • LGPL-2+-KDE (Legacy)
    • Cryptographic Autonomy License (Beta 4)
    • CasperLabs Open Source License (COSL)
    • BSD-1-Clause (Legacy)
    • MIT-0

    ESA Permissive PL v2.3

    Concern was expressed with conflicts between the license text and its FAQ

    Mulan Permissive Software License v1 and v2

    The Mulan Permissive Software License, version 1 and version 2, were introduced.

    It was noted that this may be similar to licenses like the BSD+patents. Ambiguity in which language is authoritative.

    The authors explained that there was a need for a Chinese license to engage the Chinese developer community with Chinese version authoritative in case of conflict.

    Possible for the authority of version to be different depending on the country in use.?

    Can the copyright holder decide which version is authoritative?

    Two possibilities were suggested: the Chinese version be authoritative in case of legal disputes, or users select either as the normative version.


    The LGPL-2+-KDE license was submitted.

    A question asked, and confirmed: license falls outside the scope of the license review process.

    Cryptographic Autonomy License (Beta 4)

    Based upon ongoing discussions with the license review committee, the author(s) withdrew Beta 3 and substituted Beta of the Cryptographic Autonomy License.

    Concerns offered regarding the effectiveness of the license, terms preventing documentation, and Interoperability.

    The lack of a patent grant and burdens placed on users for compliance was introduced.

    The importance of clarity due to uncertainty when being evaluated at court was stressed.

    Issues regarding difficulties in determining compliance were introduced and the CAL seems to be a special-purpose license only applicable to Holochain.

    A strict reading was recommended, and examples where data about a third party not be accessible on-demand were provided. It was offered that network node governance agreements were more appropriate to manage issues related to CAL than software licenses.

    Requirements that the software user provides data back to the customer even if the original software doesn’t make it available is overreaching.

    CAL has no mandatory functionality or method of compliance and instead describes what is required and having a mandatory technical structure is unwise.

    As a SaaS license, it was argued, it would not be usable by non-developers (e.g. Wordpress end-users) with compliance risks. It was offered that CAL goes against the spirit of open source software and so will continue advocating against the license.

    A suggestion was made to reject the license due to bad intentions: it would be better to focus on the license text without the classification of participants and assuming moral standards.

    Concern was voiced with the effect on downstream users.

    Clarification was offered that user data is defined as “data which the recipient has an existing right of ownership or possession” with references to the GDPR and the CCPA.

    The scope of CAL was questioned: forces apps that run on Holochain to use an open source license? Is the use of Holochain APIs, and nothing more considered distributing Modified Work?  Would social network software need to be under an open source license?

    It was suggested that the requirement to assert patents against interoperable open source software is a fundamental flaw.

    A case was made that though any party can assert a patent, open source projects don’t assert patents and that the difference with the CAL is that the network breaks if interoperable software under other open source licenses are allowed.

    One offered that the rewording strengthened the justification of the rights of users to their own data in terms of exercising user freedom, however, may be too narrow.

    CasperLabs Open Source License (COSL)

    The initial comment was that the license is not a good candidate for approval due to focus on a business model,  complexity without good reason, onerous obligations to the licensor, specific to distributed ledger technology, unstable links, ceding decision power to the licensor, clashes with OSDs 6, 8, and 10, that OSD 3 is not fully fulfilled.

    It was offered that the terms in the license are more appropriate for governance agreements, not software licenses.

    A question was posed on why GPLv3, AGPL, or the CAL are insufficient for the purposes of COSL?

    It was suggested the license violates OSD 5, 6, 7, and 9.

    As many people stated issues are unpassable it was proposed further discussion was no longer needed.

    A comment was made that the license privileges one set of contributors over others and allows expropriation.


    The BSD-1-Clause license was submitted for approval.

    This was identified as an obvious case for approval.


    The approval status of MIT-0 license was requested.

    An observation was made that the notation on the SPDX list may be inadvertent, noting originally listed as “not OSI-approved.”

    Recognition was made that the license author/steward is not claiming it is OSI-approved.


    If you'd like to participate on the lists, head over to for information on how to subscribe.

  5. License-Discuss mailing list topics for December 2019

    • the relevance of FRAND (fair, reasonable, and non-discriminatory) in the context of mobile communication standards, and
    • combining LGPL and MIT licenses under a single LGPL-licensed release.

    FRAND (Fair, Reasonable, and Non-Discriminatory) Relevancy

    Lawrence Rosen references a decision by the US Court of Appeals for the Federal Circuit (CAFC) involving the use of FRAND in utilizing patents around mobile communications standards and argues that FRAND fails in its attempt to bring logic to the process. Rosen also argues, based on feedback from a patent attorney, that it then significantly increases litigation costs.

    License Use Inquiry

    Marios Constantinou asks about whether it is possible to release software containing components released under the MIT license and the LGPL all together under a LGPL.

    Philippe Ombredanne confirms that it is possible.


    If you'd like to participate on the lists, head over to for information on how to subscribe.