I'm an attorney in private practice in Portland, Oregon, U.S.A.  My history with OSI goes pretty far back (I was on the License Proliferation Committee in 2004-2006, for example), and have been a regular, albeit sporadic, commenter on the license-review and license-discuss mailing lists for many years. I wrote and successfully submitted to the OSI one license for approval, and arranged for the voluntary deprecation of another (which may have been the first ever license to have been voluntarily deprecated).  I led the open source legal function at a Fortune 50 technology company (one that is a substantial contributor to the open source ecosystem) for close to 20 years, after which I retired to re-enter private practice of technology law, including legal services around open source licensing.  I also do quite a bit of lecturing around the world on intellectual property law in general, and the intersection of law and open source in particular.

I'm primarily an issues-based candidate.  I believe that the OSI should take the initiative to do the following things, and will commit to advocating to the Board that these things be done, if elected and during my term on the Board:

1. Review the current list of OSI-approved licenses to identify any licenses that are not conformant with the Open Source Definition (OSD) as currently understood, and have the Board take action to have them either voluntarily deprecated by their stewards, or involuntarily deprecated in the event their stewards cannot be found or do not elect to voluntarily deprecate.  Deprecation does *not* mean the licenses are removed from the OSI list or are determined to be non-open source; it merely puts those licenses in a category that discourages future users from adopting them, and might encourage current users to reconsider their continued use.

2. Produce more clear guidelines for the factors considered in approving new licenses to be added to the OSI license list.  The OSD sets the minimal conditions, but recent license submissions and the discussions around them have shown that there may be additional, "unwritten" rules that licenses must satisfy in order to be approved.  Having "unwritten" rules is contrary to a clear, transparent, and open process for determining if licenses are open source.  Any such rules should be written down, approved by the Board, and published by the OSI; if they are not, they should not serve as a basis for rejecting license submissions. As part of any such effort, the Board should also consider if there are any additional clarifications needed on any elements of the OSD to reduce confusion as to how and when licenses meet the OSD.  OSD 5 & 6 are examples of provisions for which there is current debate about how they apply to certain types of licenses (for example, "Ethical Open Source" licenses).  The OSI should make clear, open and transparent any interpretational rules that might guide license submitters in determining whether their licenses do or don't meet the OSD.

3. Take the contents of the mailing list archives (in particular the license-approval and license-discuss archives) -- including locating the part of the archives that was created prior to the currently-posted archives earliest date of December 12, 2007 -- and publish it in a format that is readily searchable, data-extractable, and data-analyzable.  By doing so, the OSI's processes, history, and rules will be more open and transparent, and scholars and researchers will be able to see the history of the open source movement -- as instantiated in its consideration of various licensing models -- how the process of analyzing and approving or rejecting licenses happens, and allow them to present that information for future generations of open source developers, project leaders, and lawyers so that may more readily learn from it. These mailing lists are the "source code" of the open source licensing movement; that source code should be truly "open."

If any (or all) of those issues are ones that you think would be of value, I would encourage you to vote for me.

If those issues do not resonate with you -- or indeed, if you think they would be counterproductive to OSI's overarching mission -- there are many other candidates seeking your vote, and I would encourage you to consider them instead. 

If you are not sure about these issues, and want to understand how I approach issues around the OSI's review of licenses, I'd encourage you to take a look at some of my postings on license-approval (particularly over the past year or so), to see if you think my approach to OSI's mission and processes is consistent with your own values or beliefs about OSI.

Tags:
Created by McCoySmith on 2020/02/26 23:41
    

Submit feedback regarding this wiki to webmaster@opensource.org

This wiki is licensed under a Creative Commons 2.0 license
XWiki 11.10.5 - Documentation