[License-discuss] Retroactively disapproving licenses

[Marc Jones]

On Thu, Dec 15, 2022 at 6:12 PM McCoy Smith <mccoy at lexpan.law> wrote:

> > -----Original Message-----
> > From: Nicholas Matthew Neft Weinstock <nweinsto at qti.qualcomm.com>
> > Sent: Thursday, December 15, 2022 11:01 AM
> > To: chris at dibona.com; license-discuss at lists.opensource.org;
> > mccoy at lexpan.law
> > Subject: RE: [License-discuss] Retroactively disapproving licenses
> >
> > One of the parts of my job is reviewing commercial contracts.  Some of
> those
> > contracts include references to Open Source.  For example, they might say
> > something like "Supplier will provide a list of all 3rd party software
> included
> > in the product that is under an Open Source License."  Or "Contractor may
> > only use 3rd party code subject to an Open Source License, not Commercial
> > or Freeware licenses."  In the majority of these contracts, the
> definition of an
> > "Open Source License" references the list of OSI-Approved Licenses.  I
> think
> > this is a good thing for OSI, as it enhances the organization's public
> image
> > and influence.
>
> I sort of feel like if you're using this sort of clause, and limiting it
> to only OSI-approved licenses, you're leaving a huge gap (compare the list
> of SPDX licenses to the OSI-approved licenses, for example).
> Nevertheless, I can't see a justification for keeping a license on the
> list if it in fact it does not meet the OSD. And, as I think some have
> argued on the approval list before, it opens you up for the argument that
> "you approved this OSD-non-compliant license in the past, so you should
> approve *my* OSD-non-compliant license now."
>
> > My suggestion is to think of the official list as a historical
> statement.  This is a
> > list of licenses that OSI has ever approved.  Then within that list,
> maybe there
> > could be a designation for licenses that the OSI board no longer
> supports.
> >
> This has been at least one suggestion for how to deal with licenses that
> are non-compliant. My guess is that you'd do something like what has been
> done for deprecated licenses -- say past uses are grandfathered, but that
> future uses are not recommended, and that projects that have used licenses
> deemed non-compliant are strongly encouraged to change to a different,
> compliant, license.
>

The fact that OSI is treating the approved listed as "a historical
statement" by default today is the reason why I am reluctant to agree in
contracts that someone can "use 3rd party code subject to an Open Source
License" where "Open Source license" means any license approved in the
history of OSI.

There are many licenses that OSI has approved that I do not want to
randomly be applied to code shipped to clients. At the very least I want to
think carefully before accepting code under some of the licenses that OSI
has approved in the past. Before agreeing to use any license included on a
list maintained by OSI in a contract, I would like to have either reviewed
the entire static list of licenses or have some confidence that OSI is
going to maintain the quality of the list going forward. To me it is a
question of OSI's reputation as a good steward of a resource.

Alternatively instead of fighting about the meaning of "approved", we could
build on the categories that OSI already puts some of the licenses into.
OSI could make license categories like "legacy," "currently endorsed," and
"deprecated" to go along with the categories created by the License
Proliferation report like "voluntarily retired" and "Non-reusable
licenses''. I don't think there was ever an expectation that the license
proliferation committee was going to be an ongoing effort, but  putting a
process in place to keep those categories up to date seems like a
worthwhile effort, regardless of if "approved" means approved at some point
in the past or if "approved" means current approval.

-Marc

-- 
Marc Jones, esq.
marc at joneslaw.io
860-916-6720

The information contained in this email may be confidential and/or legally
privileged. It has been sent for the sole use of the intended recipient(s).
If the reader of this message is not an intended recipient, you are hereby
notified that any unauthorized review, use, disclosure, dissemination,
distribution, or copying of this communication, or any of its contents, is
strictly prohibited. If you have received this communication in error,
please reply to the sender and destroy all copies of the message. To
contact us directly, send to marc at joneslaw.io. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20221215/02fd117a/attachment.html>