[License-discuss] February 2020 License-Discuss Summary

Travin Keith travin.keith at opensource.org
Tue Jul 21 02:32:59 UTC 2020 

Hi all,

In February 2020, the License-Discuss mailing list went over the following:

   - OSD and compulsory user reporting
   - Delisting of licenses
   - MIT-Clone and concern on the copyright notice
   - GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)
   - CERN Open Hardware License 2.0
   - Ethical Open Source Licensing – Persona non Grata Preamble
   - Fairness vs Mission Objectives of the OSI
   - Ethical open source licensing - Dual Licensing for Justice
   - Discouraging governments from creating bespoke licenses
   - Psychological relationship between an author and the work

*OSD and Compulsory User Reporting*

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

Answer that it wouldn’t and referenced the Desert Island test for whether
people on a desert island could distribute the software among themselves.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021228.html

*Delisting of Licenses*

Concern that delisting would be unfair and give a bad look for the OSI.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021222.html

Suggestion for a threshold of lack of use and a deprecation period.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021223.html

Statement that licenses that lack use would mean that leaving them alone
also has little impact.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021224.html

Concern regarding how the body of licenses affect the interpretation of the
OSD.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021226.html

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

*MIT-Clone and concern on the copyright notice*

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

Suggestion to amend to add additional copyright holders as it is common to
add another line below the original notice.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021231.html

Avoidance of the word “copyright” has no actual effect.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021233.html

*GDPR/CCPA and the Cryptographic Autonomy License (Beta 4)*

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

Reference to US constitutional regulation of interstate commerce which is
to congress and not the states due to complications.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021235.html

*CERN Open Hardware License 2.0*

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

*Ethical Open Source Licensing – Persona non Grata Preamble*

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

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

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

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

Question on who defines who is being discouraged and shamed.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021239.html

Question on whether disclaimers will need to be made for end users.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021241.html

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

Suggestion for a proxy clause to be added for the delegation of the ability
to update the preamble, such as a non-profit steward.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021266.html

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

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

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

Clarification that propagation requires that it can’t be removed.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021250.html

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

Statement that OSI should not be involved with social justice and that its
responsibilities lies with protecting a narrow and particular set of
liberties.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021312.html

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

Response that the preamble does not make software proprietary as there is
no assertion of exclusive ownership rights.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021323.html

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

Statement that political language or advocacy should only be considered
acceptable if it is to accomplish the defense or advocacy of open-source
cooperation.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021313.html

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

Reference to the similarities with badgeware licenses where the mailing
list pointed out that the attribution requirements discouraged exercising
the derivative work right.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021252.html

Statement on lack of legal enforceability if the new terms need to be
legally enforceable.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021399.html

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

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

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

*Fairness vs Mission Objectives of the OSI*

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

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

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

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

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

Statement that projects can’t be rejected as they’re not accepted in the
first place.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021297.html

Clarification on the differences between deprecating and decertification
while highlighting that the latter requires a higher level of requirements.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021310.html

Recommendation to also have an affirmative effort to certify licenses even
without affirmative submission.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021299.html

Suggestion to have a tag for new licenses that says “Not recommended for
general use.”
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021306.html

Statement that deprecation as a first step has precedent with Intel’s
request for removal of one of its open source licenses in 2005.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021327.html

Suggestion of deprecation as a first step with an understanding that it may
be decertified based on further data.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021287.html

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

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

Clarification that the term “open source” was not used to describe licenses
before the OSI was founded.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021289.html

*Ethical open source licensing - Dual Licensing for Justice*

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

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

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

Counter-argument that it isn’t necessary and instead counterproductive.
Clarification that the OSD and FSD are set up to solve software-related
problems.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021315.html

Statement that ethical license proposals are fundamentally irreconcilable
with the non-discrimination values in the OSD.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021316.html

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

*Discouraging governments from creating bespoke licenses*

Request for resources regarding the discouraging governments and similar
agencies from creating bespoke licenses.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021349.html

Recommendation for Iain Mitchell’s chapter in the book Free and Open Source
Software.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021351.html

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

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

Issue regarding determining the viability of creating a lawsuit as well as
the costs stemming from fighting them.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021382.html

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

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

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

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

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

Recommendation that people who write the licenses should be the ones
explaining it on license-review and not proxies.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021387.html

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

*Psychological relationship between the author and the work*

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

Personal interpretation that code created isn’t perceived as theirs and
that code belongs to all and shouldn’t be “owned” once its Open.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021374.html

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

Clarification that pride and recognition are not taken away in an ownerless
perspective.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021379.html

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

Comment that as one becomes less afraid of what happens to the code, the
desire to control goes away and possessive thinking stops.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021395.html

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

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

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

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.
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021405.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200721/fb2aec77/attachment-0001.html>

More information about the License-discuss mailing list