[License-discuss] Generic process for removing approved licenses. Re: REMOVE AAL from list of approved licenses

[McCoy Smith]

This is similar to my take on the matter (as articulated in my unsuccessful
Board candidacy platform:
https://wiki.opensource.org/bin/Main/OSI+Board+of+Directors/Board+Member+Ele
ctions/2020+Individual+and+Affiliate+Elections/Smith2020 )

 

On your license proliferation concern, I think that ship sailed along time
ago when the license proliferation committee didn't remove any licenses back
in '06 when it did its report. https://opensource.org/proliferation  I doubt
that position would have changed since then, and the result of the LP
committee report - to have certain categories for licenses, including a few
that sort of say "this is open source and approved, but there are better
options on the list you should consider," but no removal of any - seems to
be the preferred solution.  It would be interesting to study whether the
results of the categorization had any appreciable effect on the adoption of
licenses afterwards.  In particular, did adoption of the licenses on the
"Licenses that are redundant with more popular licenses" tail off after
2007?  Seems like maybe not, at least for the AAL.

 

From: License-discuss <license-discuss-bounces at lists.opensource.org> On
Behalf Of Karan, Cem F CIV USARMY CCDC ARL (USA) via License-discuss
Sent: Monday, March 30, 2020 5:55 AM
To: henrik.ingo at avoinelama.fi; license-discuss at lists.opensource.org; Josh
Berkus <josh at berkus.org>
Cc: Karan, Cem F CIV USARMY CCDC ARL (USA) <cem.f.karan.civ at mail.mil>
Subject: Re: [License-discuss] Generic process for removing approved
licenses. Re: REMOVE AAL from list of approved licenses

 

(Comment below, I've heavily edited to focus in, please read earlier
portions of the thread for context)

 

 

Note that I believe that the process should only be about licenses that
don't conform to the OSD; using it as an excuse for pruning back licenses
due to license proliferation concerns is a terrible abuse of OSI's power.  I
personally believe that because of how complex the law is (more so due to
varying jurisdictions) and due to the fact that the law is constantly
changing, there will always be a need for new licenses.  Thus, for any
license that is proposed for decertification we should be able to clearly
articulate which of the OSD principles are being violated, and how they are
violated by the license.  This reasoning should be annotated to the license
in a clearly discoverable manner (e.g., each license has its own page), with
very specific explanations of which license clauses are in violation of the
OSD, and why.  This acts as both a historical record of the reasoning, and a
guide to others that wish to create new licenses of what not to do in their
own language.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200330/d5f01ec4/attachment.html>