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-boun...@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.i...@avoinelama.fi; license-discuss@lists.opensource.org; Josh Berkus <j...@berkus.org> Cc: Karan, Cem F CIV USARMY CCDC ARL (USA) <cem.f.karan....@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.
_______________________________________________ The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
