<div dir="ltr"><p>Hi all,</p><p>In February 2020, the License-Discuss mailing list went over the following:</p><ul><li>OSD and compulsory user reporting</li><li>Delisting of licenses</li><li>MIT-Clone and concern on the copyright notice</li><li>GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)</li><li>CERN Open Hardware License 2.0</li><li>Ethical Open Source Licensing – Persona non Grata Preamble</li><li>Fairness vs Mission Objectives of the OSI</li><li>Ethical open source licensing - Dual Licensing for Justice</li><li>Discouraging governments from creating bespoke licenses</li><li>Psychological relationship between an author and the work</li></ul><p><strong>OSD and Compulsory User Reporting</strong></p><p>Question whether a license would be compliant with the OSD if it would require the provision of information regarding use of the software to the author or another party.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021221.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021221.html</a></p><p>Answer that it wouldn’t and referenced the Desert Island test for whether people on a desert island could distribute the software among themselves.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021228.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021228.html</a></p><p><strong>Delisting of Licenses</strong></p><p>Concern that delisting would be unfair and give a bad look for the OSI.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021222.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021222.html</a></p><p>Suggestion for a threshold of lack of use and a deprecation period.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021223.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021223.html</a></p><p>Statement that licenses that lack use would mean that leaving them alone also has little impact.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021224.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021224.html</a></p><p>Concern regarding how the body of licenses affect the interpretation of the OSD.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021226.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021226.html</a></p><p>Reminder of a previous suggestion to have an “Emeritus” license list to avoid invalidation and just clarify that they are not recommended for active use.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021227.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021227.html</a></p><p><strong>MIT-Clone and concern on the copyright notice</strong></p><p>Issue with the copyright notice as it refers to the author of the initial files but not the contributors. Suggestion to replace “copyright notice” with “attribution notice” and “created by me” instead of “copyright me”.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021230.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021230.html</a></p><p>Suggestion to amend to add additional copyright holders as it is common to add another line below the original notice.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021231.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021231.html</a></p><p>Avoidance of the word “copyright” has no actual effect.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021233.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021233.html</a></p><p><strong>GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)</strong></p><p>Question on which is the constitutional or statutory authority to control data used by a copyrighted or patented work of software if contractual law is solely relied on for restrictions on the use or distribution of data.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021234.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021234.html</a></p><p>Reference to US constitutional regulation of interstate commerce which is to congress and not the states due to complications.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021235.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021235.html</a></p><p><strong>CERN Open Hardware License 2.0</strong></p><p>Request for feedback on submitting the suite of licenses for OSI approval due to hardware and software tending to converge and much of the hardware has software elements like firmware.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021236.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021236.html</a></p><p><strong>Ethical Open Source Licensing – Persona non Grata Preamble</strong></p><p>Proposal regarding how licensing and ethical FOSS community policies can interact to discourage and shame certain potential users on the basis of morality where the community can give a statement about their values and who is not welcome. This preamble will be maintained in redistribution as it is part of the license.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021237.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021237.html</a></p><p>Statement that it does not belong in a license but rather in a Code of Conduct and that the addition of this into the license would make it lose its status as a Free Software license due to making it proprietary. Reference to OSD 5.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021238.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021238.html</a></p><p>Clarification that the proposal has no restrictions in place as only opinions of the licensor are preserved but that there is concern regarding the immortality of the preamble even if it loses relevancy.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021240.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021240.html</a></p><p>Concern that it may still break OSD 5 due to potential libel and defamation issues preventing developers from using code with an actionable statement to which they may be considered affiliated.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021268.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021268.html</a></p><p>Question on who defines who is being discouraged and shamed.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021239.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021239.html</a></p><p>Question on whether disclaimers will need to be made for end users.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021241.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021241.html</a></p><p>Answer that the licensors define who is being discouraged and shamed. Statement that end users would likely not see such a preamble in the user interface and a suggestion to have a requirement to display it. Concern that it would be easier to add names than remove old ones as anyone can add them but consensus is required to remove and that enabling the assignment for the right to relicense may be needed to prevent IP centralization.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021247.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021247.html</a></p><p>Suggestion for a proxy clause to be added for the delegation of the ability to update the preamble, such as a non-profit steward.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021266.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021266.html</a></p><p>Statement that most downstream licensees cannot be expected to update the copy of the preamble, as well as difficulties with upstream and “side-stream” copies updating their preamble.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021267.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021267.html</a></p><p>Concern around discrimination created by the preamble, which goes against both OSD 5 and OSD 6, regardless of permissions granted. Additional issues mentioned around the removability of the preamble if it is changeable, proliferation concerns due to multiple variations, and potentially negatively-viewed preambles.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021242.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021242.html</a></p><p>Statement that different treatment of different people already exists, licenses can be set to be copied freely but can’t be changed by anyone except the author, and that templates would be a practical approach.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021243.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021243.html</a></p><p>Clarification that propagation requires that it can’t be removed.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021250.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021250.html</a></p><p>Viewpoint that beliefs stated in the preamble don’t make a license noncompliant since every license that requires a notice regardless of ones own views is already forced speech. Request for information with regards to the sufficient legal risk to be considered that causes a violation against the OSD. Further statement regarding templating that OSI would approve the template and not anything else and that a versioning process should be in place.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021284.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021284.html</a></p><p>Statement that OSI should not be involved with social justice and that its responsibilities lies with protecting a narrow and particular set of liberties.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021312.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021312.html</a></p><p>Viewpoint that comparisons to software patent statements in open source licenses are irrelevant due to the preambles being directed at actions beyond the license rights to the software.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021324.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021324.html</a></p><p>Response that the preamble does not make software proprietary as there is no assertion of exclusive ownership rights.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021323.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021323.html</a></p><p>Issue that though some policy statements can be tolerated in a preamble with regards to OSD 5 and OSD 6, some may not be and go against their spirit.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021300.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021300.html</a></p><p>Statement that political language or advocacy should only be considered acceptable if it is to accomplish the defense or advocacy of open-source cooperation.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021313.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021313.html</a></p><p>Question on whether the effect of language choices in the preamble causing a group to avoid the software is essentially the same as outright prohibition against those groups.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021301.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021301.html</a></p><p>Reference to the similarities with badgeware licenses where the mailing list pointed out that the attribution requirements discouraged exercising the derivative work right.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021252.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021252.html</a></p><p>Statement on lack of legal enforceability if the new terms need to be legally enforceable.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021399.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021399.html</a></p><p>Question on whether discrimination against illegal activities has been tested in court, such as in the event that an open source library was a key contributor to empowering an illegal activity. Request for clarification on “the process” as stated in OSD 5.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021403.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021403.html</a></p><p>Answer that legal liability is on the licensee and not the licensor and that the license cannot contain a clause prohibiting use based on the licensor’s jurisdiction.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021404.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021404.html</a></p><p> Answer that crime is irrelevant for OSD 6 as it is relevant for law enforcement and that OSD 5 does not prevent the implementation of policies, such as with incoming pull requests.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021411.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021411.html</a></p><p><strong>Fairness vs Mission Objectives of the OSI</strong></p><p>Suggestion that licenses should be revoked if it is discovered that there was an error on the part of OSI and that it is not unfair to those who have adopted the license to do so as it is to minimize future harm.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021272.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021272.html</a></p><p>Agreement that licenses should be decertified if they did not meet the OSD requirements but pointed out that goals like minimizing license proliferation and redundancy are less clear-cut.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021274.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021274.html</a></p><p>Request for clarification if the proposal is to do a full revocation or just to deprecate and a suggestion for deprecation instead as it does not have immediate harsh consequences against its users while still discouraging future use. Further question with regards to how future license submissions would take into account precedence of revocation or deprecation of another similar license.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021277.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021277.html</a></p><p>Clarification that requests for deprecation by the license steward are already accepted either because it is no longer appropriate or if it has been superseded, which does not harm legacy applications. Suggestion that a process for deprecation initiated by someone who isn’t the license steward be created.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021278.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021278.html</a></p><p>Question on whether a review of current licenses is necessary and a suggestion for the process of doing so involving an evaluation of fixability, providing a clear explanation, multi-channel announcements, a waiting period where projects would not be allowed to use it, and a final move to a historical archive.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021296.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021296.html</a></p><p>Statement that projects can’t be rejected as they’re not accepted in the first place.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021297.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021297.html</a></p><p>Clarification on the differences between deprecating and decertification while highlighting that the latter requires a higher level of requirements.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021310.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021310.html</a></p><p>Recommendation to also have an affirmative effort to certify licenses even without affirmative submission.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021299.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021299.html</a></p><p>Suggestion to have a tag for new licenses that says “Not recommended for general use.”<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021306.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021306.html</a></p><p>Statement that deprecation as a first step has precedent with Intel’s request for removal of one of its open source licenses in 2005.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021327.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021327.html</a></p><p>Suggestion of deprecation as a first step with an understanding that it may be decertified based on further data.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021287.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021287.html</a></p><p>Argument that OSI is not right to assert that something isn’t open source when the term was around before the OSI and the OSD existed.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021279.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021279.html</a></p><p>Clarification that amending the OSD was done in the past with the addition of OSD #10 and that the OSI is not bound to always decide the current case like previous cases and changes can be made.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021281.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021281.html</a></p><p>Clarification that the term “open source” was not used to describe licenses before the OSI was founded.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021289.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021289.html</a></p><p><strong>Ethical open source licensing - Dual Licensing for Justice</strong></p><p>Idea around a copyleft license for software where the community would create a special exception to the license that provides greater permissiveness to all except for a specific list of entities. Questions around the compatibility with the FSD and the OSD, whether the special permission could be removed under any conditions, whether it can be expanded in other dimensions and still be FOSS, and the effect of it on copyleft as a concept.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021285.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021285.html</a></p><p>Question on why a single license exempting specific organizations isn’t just used instead and why it needs to be under the umbrella of open source.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021293.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021293.html</a></p><p>Answer that it would be an enforceable license but that it would not be FOSS and that a set of options that uphold the OSD and the FSD that allows the inclusion of other issues is necessary.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021304.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021304.html</a></p><p>Counter-argument that it isn’t necessary and instead counterproductive. Clarification that the OSD and FSD are set up to solve software-related problems.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021315.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021315.html</a></p><p>Statement that ethical license proposals are fundamentally irreconcilable with the non-discrimination values in the OSD.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021316.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021316.html</a></p><p>Challenge that it isn’t enforceable unless it allows or requires the exercise of the right and possibly duty to give copies of the software under the same license.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021318.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021318.html</a></p><p><strong>Discouraging governments from creating bespoke licenses</strong></p><p>Request for resources regarding the discouraging governments and similar agencies from creating bespoke licenses.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021349.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021349.html</a></p><p>Recommendation for Iain Mitchell’s chapter in the book Free and Open Source Software.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021351.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021351.html</a></p><p>Statement that all major open source licenses rely on copyright for protection, none of them have severability clauses to address what happens if one or more clauses in the license cannot be enforced, and that works authored by the US Government (USG) does not have copyright attached in the USA. Concern that if standard licenses are used, it is not known if the license will be struck completely or if only portions would be, as well as whether it would expose the government if a standard license is used when some clauses don’t apply.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021368.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021368.html</a></p><p>Example regarding digital editions of music in the Public Domain where information regarding the license is in the footer and the license terms in the metadata.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021376.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021376.html</a></p><p>Issue regarding determining the viability of creating a lawsuit as well as the costs stemming from fighting them.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021382.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021382.html</a></p><p>Suggestion that USG lawyers should become involved in the discussion in order to provide insight with regards to the operation of the Court of Federal Claims, the limits on private entity claims against the USG, and how the licenses propose the concerns.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021385.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021385.html</a></p><p>Clarification that the issue is with also protecting downstream users who may be sued for simply using the material distributed by the USG. Response that there is potentially a concern from USG lawyers regarding information provided being construed as legal advice.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021388.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021388.html</a></p><p>Provision of a solution to the concern where a notification is placed that legal advice is not being given, as well as that they only represent their clients and no one else reading the message and that people should consult their own attorneys, among other things.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021392.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021392.html</a></p><p>Correction that Mozilla 2.0 and Eclipse 2.0 both have severability clauses in Sec. 9 and Sec. 7, respectively. Issue that since open source licenses are founded upon copyright licensing, if copyright provisions are struck then there isn’t much left.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021378.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021378.html</a></p><p>Clarification that the concern is that the USG would need to address patents, liability, and warranty for itself and downstream users and that without a severability clause it is unclear if the non-copyright clauses would survive in court.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021381.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021381.html</a></p><p>Recommendation that people who write the licenses should be the ones explaining it on license-review and not proxies.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021387.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021387.html</a></p><p>Statement that the USG is so large that patent clauses have to be written in a way that one arm of it doesn’t inadvertently give away a patent created by another part and already licensed to another party. Suggestion that a license like CC0 with the explicit patent grant from ECL V2 exist with some broadening to the agency which the authors belong.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021362.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021362.html</a></p><p><strong>Psychological relationship between the author and the work</strong></p><p>Request for input with regards to the attachment to code developed by someone that they decide the terms under which another uses it in their solution.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021369.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021369.html</a></p><p>Personal interpretation that code created isn’t perceived as theirs and that code belongs to all and shouldn’t be “owned” once its Open.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021374.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021374.html</a></p><p>Counter interpretation that pride exists in work that is crafted while recognizing that they are “standing on the shoulders of giants” and thus publish under Copyfree terms.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021377.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021377.html</a></p><p>Clarification that pride and recognition are not taken away in an ownerless perspective.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021379.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021379.html</a></p><p>Statement that copy of one’s code remains theirs but that that the copy may or may not be the same and that there is a potential for one to consider it “our code” if modifications have been extensive but not overwhelming.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021375.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021375.html</a></p><p>Comment that as one becomes less afraid of what happens to the code, the desire to control goes away and possessive thinking stops.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021395.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021395.html</a></p><p>Statement that copyright law focuses on creative expression, which would be the implementation of the idea but that it does not protect things that are purely functional. Issues with determining creative expression on contributions depending on their significance.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021380.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021380.html</a></p><p>Analogy with paintings where one may paint their own work and has freedom and control as well as the risk, and comparing that with commissioned work where the painter does not have the risk but that the artist maintains a personal connection while the commissioner retains ownership.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021391.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021391.html</a></p><p>Clarification that this is why projects exist where the ownership is under the project and not the individual author, though they retain co-owner status.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021400.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021400.html</a></p><p>Viewpoint that while receiving credit is enjoyed, there is no proprietary feeling about the results of the work as the work gains more value the more it is built upon.<br><a href="https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021405.html" target="_blank">https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021405.html</a></p></div>