Open Source Initiative Blog

  1. January 2020 License-Review Summary

    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
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004593.html

    Revised license submission
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004640.html

    Continued discussion on the Cryptographic Autonomy License (Beta 4)

    Questions on the license use, promulgation, and contributions
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004594.html

    Issue regarding proprietary relicensing seemingly being the primary use case
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004595.html

    Questions with regards to OSD compliance and user freedom, as well as further viewpoints and considerations with regards to data exportability 
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004631.html

    Statement that it is OSD compliant and that arguments against it are too situation-specific
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004636.html

    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. 
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004635.html

    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
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004637.html

    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
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004638.html

    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 
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-January/004643.html
     

  2. January 2020 License-Discuss Summary

    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
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021191.html

    Centralizing copyright licensing and not centralizing copyrights themselves 
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021192.html

    Single entity open source business model
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021204.html

    Copyright on APIs
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021193.html

    Doubt on article assumptions due to machine-readable interface description in the source code
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021194.html

    Decision process regarding license review submissions
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021195.html

    Suggestion to postpone OSI evaluation of new licenses until after some time of practical use
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021199.html

    The role of the OSI and defining norms
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021201.html

    Writing down all rules would be divisive and further enable bad actors 
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021207.html

    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."
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021203.html

    It is undesirable to have the OSI determine which licenses are better than others
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021208.html

    Concern with interim naming of a license while it is in use but before OSI evaluation
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021212.html

    AGPL evaluation and real-world license testing
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021197.html

    Copyleft-next is engaging in a public drafting process
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021198.html

    ZFS Kernel Code on Linux
    https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-January/021215.html
     

  3. Committing to Community throughout the COVID-19 Crisis

    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 EUvsVirus.org 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, much, much 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. December 2019 License-Review Summary

    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
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004450.html

    Mulan Permissive Software License v1 and v2

    The Mulan Permissive Software License, version 1 and version 2, were introduced.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004451.html

    It was noted that this may be similar to licenses like the BSD+patents. Ambiguity in which language is authoritative.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004452.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004453.html

    Possible for the authority of version to be different depending on the country in use.?
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004472.html

    Can the copyright holder decide which version is authoritative?
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004473.html

    Two possibilities were suggested: the Chinese version be authoritative in case of legal disputes, or users select either as the normative version.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004572.html

    LGPL-2+-KDE

    The LGPL-2+-KDE license was submitted.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004454.html

    A question asked, and confirmed: license falls outside the scope of the license review process.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004458.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html

    Concerns offered regarding the effectiveness of the license, terms preventing documentation, and Interoperability.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004456.html

    The lack of a patent grant and burdens placed on users for compliance was introduced.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004475.html

    The importance of clarity due to uncertainty when being evaluated at court was stressed.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004506.html

    Issues regarding difficulties in determining compliance were introduced and the CAL seems to be a special-purpose license only applicable to Holochain.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004509.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004523.html

    Requirements that the software user provides data back to the customer even if the original software doesn’t make it available is overreaching.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004529.html

    CAL has no mandatory functionality or method of compliance and instead describes what is required and having a mandatory technical structure is unwise.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004539.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004549.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004564.html

    Concern was voiced with the effect on downstream users.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004558.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004583.html

    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?
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004573.html

    It was suggested that the requirement to assert patents against interoperable open source software is a fundamental flaw.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004485.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004501.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004463.html

    CasperLabs Open Source License (COSL)

    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004508.html

    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.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004513.html

    It was offered that the terms in the license are more appropriate for governance agreements, not software licenses.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004527.html

    A question was posed on why GPLv3, AGPL, or the CAL are insufficient for the purposes of COSL?
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004521.html

    It was suggested the license violates OSD 5, 6, 7, and 9.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004530.html

    As many people stated issues are unpassable it was proposed further discussion was no longer needed.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004533.html

    A comment was made that the license privileges one set of contributors over others and allows expropriation.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004532.html

    BSD-1-Clause

    The BSD-1-Clause license was submitted for approval.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004510.html

    This was identified as an obvious case for approval.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004518.html

    MIT-0

    The approval status of MIT-0 license was requested.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004576.html

    An observation was made that the notation on the SPDX list may be inadvertent, noting originally listed as “not OSI-approved.”
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004578.html

    Recognition was made that the license author/steward is not claiming it is OSI-approved.
    https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004579.html.

    Note

    If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.

  5. December 2019 License-Discuss Summary

    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.

    Note

    If you'd like to participate on the lists, head over to https://opensource.org/lists for information on how to subscribe.