To do some foreshadowing, the Working Group that was formed to make
recommendations for improving the license review process will soon be
publishing its recommendation. This was originally within their remit,
but the group agreed that it was complex enough (and frankly I think we
were all a little tired at this point) that it should be a separate
undertaking. Personally, I think the OSI has to tread carefully to avoid
unintended consequences and therefore needs to have a lot more
information before deciding whether and how to delist a license, such as:
How many projects are using the licenses
How significant they are
How many downstream users there are, and whether they have relied on the
status as "open source" in some way, e.g., suddenly a component will
have to be removed because it no longer has an "open source" license
Whether anyone is doing marketing around the term "open source" for a
license considered for delisting
I'm sure with more thought there is other information that would be
relevant.
So McCoy, are you volunteering to head up a working group to work on
this question? 😁
Pam
Chair, License Committee
Open Source Initiative
On 12/14/2022 11:30 AM, McCoy Smith wrote:
From: License-discuss <license-discuss-boun...@lists.opensource.org> On Behalf
Of Lawrence Rosen
Sent: Tuesday, December 13, 2022 7:48 PM
To: license-discuss@lists.opensource.org
Subject: [License-discuss] Retroactively disapproving licenses
For what my own limited opinion is worth, I certainly do not delegate to him, nor to the
OSI board of directors, the right to retroactively disapprove my own licenses along with my
own carefully-considered >>jurisdictional provisions. And I readily admit, I do not
profess to be an authority on German or French licenses capable to telling them to change
their provisions. Brad and the OSI have ONLY the authority to >>determine whether
licenses satisfy the Open Source Definition AND NOTHING MORE.
FWIW, I've got to disagree with Larry on some of this. I think it is within the power of
the OSI board of directors to "disapprove" previously approved licenses (i.e.,
remove them from the approve license list), and in fact, there are a handful of licenses
(none of them written by Larry) which I -- and I believe others -- maintain should not
have been approved by the OSI because they have provisions that violate the OSD. I also
think that there are other factors, beyond OSI conformance, that can, and should, go into
license approval (for example, a license is so poorly or ambiguously drafted that it can
create problems for users, or -- for example -- it explicitly omits certain rights --
like patent -- that can result in them being non-open).
In fact, a couple of years ago, I ran for the OSI board with this issue as one
of my platform positions:
https://wiki.opensource.org/bin/Main/OSI%20Board%20of%20Directors/Board%20Member%20Elections/2020%20Individual%20and%20Affiliate%20Elections/Smith2020
Of course, I wasn't elected so I suspect the OSI board has no interest in
pursuing my ideas, but I do believe the Board can -- if it wants -- remove
license from the list or indicate that a particular licenses have problematic
or disfavorable provisions or results and not approve them or flag them for
potential users.
_______________________________________________
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
_______________________________________________
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
