[License-discuss] [Non-DoD Source] notes on a systematic approach to "popular" licenses

Karan, Cem F CIV USARMY RDECOM ARL (US) cem.f.karan.civ at mail.mil
Tue Jan 10 19:08:43 UTC 2017


Got it, thank you for the clarification.

Thanks,
Cem Karan

> -----Original Message-----
> From: License-discuss [mailto:license-discuss-bounces at opensource.org] On Behalf Of Luis Villa
> Sent: Tuesday, January 10, 2017 2:01 PM
> To: license-discuss at opensource.org
> Subject: Re: [License-discuss] [Non-DoD Source] notes on a systematic approach to "popular" licenses
> 
> I may not have been clear - under this proposal, the "special purpose licenses" category would continue to exist, and could be used for
> licenses like the ones you describe, Cem. Same with categories with more negative connotation, like "redundant", non-reusable,
> superseded, etc.
> 
> 
> It's not entirely clear what level of scrutiny should be applied to new licenses proposed in these older categories. I tend to think less
> (reserving the highest scrutiny for those proposed as significantly innovative general-purpose licenses), but Richard may tend to think
> more, and I've not thought it through very carefully.
> 
> 
> Luis
> 
> 
> On Tue, Jan 10, 2017 at 10:28 AM Karan, Cem F CIV USARMY RDECOM ARL (US) <cem.f.karan.civ at mail.mil < Caution-
> mailto:cem.f.karan.civ at mail.mil > > wrote:
> 
> 
> 	I agree with the idea of this, but there will always be niche licenses that are needed and won't make it into the popular list.  E.g.,
> licenses that can be used on public domain software (like US Government works, which generally don't have copyright).  These will need
> to be handled carefully, as for some of us these are the only licenses we're permitted to use, but we'd still like to be Open Sourcing our
> stuff.  So, is there a method of weighting the list based on unavoidable factors?
> 
> 	Thanks,
> 	Cem Karan
> 
> 	> -----Original Message-----
> 	> From: License-discuss [Caution-mailto:license-discuss-bounces at opensource.org < Caution-mailto:license-discuss-
> bounces at opensource.org > ] On Behalf Of Luis Villa
> 	> Sent: Tuesday, January 10, 2017 11:08 AM
> 	> To: License Discuss <license-discuss at opensource.org < Caution-mailto:license-discuss at opensource.org > >
> 	> Subject: [Non-DoD Source] [License-discuss] notes on a systematic approach to "popular" licenses
> 	>
> 	> All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all
> links
> 	> contained within the message prior to copying and pasting the address to a Web browser.
> 	>
> 	>
> 	> ________________________________
> 	>
> 	>
> 	>
> 	> [Apparently I got unsubscribed at some point, so if you've sent an email here in recent months seeking my feedback, please
> resend.]
> 	>
> 	>
> 	> Hey, all-
> 	>
> 	> I promised some board members a summary of my investigation in '12-'13 into updating, supplementing, or replacing the
> "popular
> 	> licenses" list. Here goes.
> 	>
> 	>
> 	> tl;dr
> 	>
> 	> I think OSI should have an data-driven short license list with a replicable and transparent methodology, supplemented by a new-
> and-
> 	> good(?) list that captures licenses that aren't yet popular but are high quality and have some substantial improvement that
> advances the
> 	> goals of OSI.
> 	>
> 	>
> 	> Purposes of non-comprehensive lists
> 	>
> 	> If you Google "open source licenses", OSI pages are the top two hits. Historically, those pages were not very helpful unless you
> already
> 	> knew something about open source. Having a shorter "top" list can help make the OSI website more useful to newcomers by
> suggesting a
> 	> starting place for their exploration and education about open source.
> 	>
> 	> In addition, third parties often look to OSI as a trusted (neutral?) source for "top" or "best" licenses that they can incorporate
> into
> 	> products. (The full OSI-approved list is not practical for many applications.) For example, if OSI had an up-to-date short list, it
> might have
> 	> been the basis for GitHub's license chooser.
> 	>
> 	>
> 	> A list that is purely based on popularity would freeze open source in a particular time, likely making it hard for new licenses with
> 	> important innovations to get adoption. However, a list based on more subjective criteria is hard to create and update.
> 	>
> 	>
> 	> Past attempts
> 	>
> 	> The proliferation report attempted to address this problem by categorizing existing licenses. These categories were,
> intentionally or not,
> 	> seen as the "popular or strong communities list" and "everything else". Without a process or clear set of criteria to update the
> "popular"
> 	> list, however, it became frozen in time. It is now difficult to credibly recommend the list to newcomers or third parties (MPL 1.1
> is
> 	> deprecated; no mention of Blackduck #4 GPL v3; etc.).
> 	>
> 	>
> 	> There was also substantial work done towards a license "chooser" or "wizard". However, this runs into some of the same
> problems - either
> 	> the chooser is opinionated (and so pisses off people, and potentially locks the licenses in time) or is borderline-useless for
> newcomers
> 	> (because it still requires substantial additional research after using it).
> 	>
> 	>
> 	> Data-driven "popular" list
> 	>
> 	>
> 	> With all that in mind, I think that OSI needs a (mostly) data-driven "popular" shortlist, based on a scan of public code +
> application of
> 	> (mostly?) objective rules to the outcome of that scan.
> 	>
> 	>
> 	> To maintain OSI's reputation as being (reasonably) neutral and independent, OSI should probably avoid basing this on third-
> party license
> 	> surveys (e.g., Black Duck < Caution-Caution-https://www.blackducksoftware.com/top-open-source-licenses < Caution-
> https://www.blackducksoftware.com/top-open-source-licenses >  > ) unless their methodologies and data
> 	> sources are well-documented. Ideally someone will write code so that the "survey" can be run by OSI and reproduced by others.
> 	>
> 	> Hard decisions on how to collect and "process" the data will include:
> 	>
> 	>
> 	> *     choice of data sources: What data sources are drawn on? Key Linux distros? GitHub? per-language repos like maven, cpan,
> npm,
> 	> etc?
> 	>
> 	> *     what are you counting? Projects? (May favor small, throwaway projects?) Lines of code? (May favor the largest, most
> complex
> 	> projects?) ... ?
> 	>
> 	> *     which license tools? Some scanners are more aggressive in trying to identify something, while others prefer accuracy over
> 	> comprehensiveness. In 2013 there was no good answer to this, but my understanding is that fossology now has three different
> scanners,
> 	> so for OSI's purposes it may be sufficient to take those three and average.
> 	>
> 	>
> 	>       *       Could throw in Black Duck or other non-transparent surveys as a fourth, fifth, etc.?
> 	>
> 	>
> 	> *     new versions? If a new version exists but isn't widely adopted yet, how does the list reflect that? e.g., MPL 1.1 still shows up
> in
> 	> Black Duck's survey; should OSI replace 1.1 with 2.0 in the "processed" list? What about GPL v2 v. v3? BSD/MIT v. UPL?
> 	> *     gaps/"mistakes": What happens when the board thinks the data is incorrect? :) e.g., should ISC be listed?
> 	>
> 	>
> 	> Part of why we didn't go very far in 2013 is because there are no great answers for these - different answers will reflect
> different values,
> 	> and have different engineering impact. They're all hard choices for the board, the developers, hopefully license-discuss, and
> perhaps a
> 	> broader community.
> 	>
> 	>
> 	> Hat tip: Daniel German was invaluable to me in thinking through these questions.
> 	>
> 	>
> 	> Supplementing with high-quality, value-adding options
> 	>
> 	> To encourage progress, while still avoiding proliferation, I'd suggest a second list of licenses that are good but not (yet?) popular.
> "Good"
> 	> would be defined as something like:
> 	>
> 	>
> 	> 1.    meets the OSD
> 	>
> 	> 2.    isn't on the data-driven popularity list
> 	>
> 	> 3.    drafted by an attorney (at minimum) or by a collaborative, public drafting process with clear support from a sponsoring-
> 	> maintaining organization (ideal)
> 	> 4.    has a new "feature" that is firmly in keeping with the overall goals of open source and can be concisely explained in a few
> 	> sentences (e.g., for UPL, "GPL-compatible permissive license with explicit patent grant")
> 	>
> 	>
> 	>       1.      but not "just for a particular community" - has to be at least plausible applicable to most open source projects
> 	>       2.      this is unavoidably subjective; suggest having it fall to the board with pre-discussion on license-review.
> 	>
> 	>
> 	> #4 allows for some innovation (and OSI support of such innovation) while #3 applies a quality filter. (Both #3 and #4 have anti-
> 	> proliferation effects.) Hopefully licenses that meet #3 and #4 would eventually move into #2, but you could imagine placing a
> time limit
> 	> on this list; if you're not in the top 10 most popular within five years, then you get retired? But not sure that's a good idea at all
> - just
> 	> throwing it out as one option.
> 	>
> 	>
> 	> If a new license meets #1, but not #3 and #4, then OSI's formal policy should be to approve, but bury it in one of the other
> proliferation list
> 	> groups. (Those groups are actually quite good, and should be fairly non-controversial — once you have a good policy for what
> gets in the
> 	> more "favored" groups.) I don't think a new "deprecated" group is necessary - the proliferation categories are basically a good
> list of that
> 	> already.
> 	>
> 	> This is still a somewhat subjective process, and if it had been in place in '99-'06, it would have been fairly fraught. However, I
> think most of
> 	> the "action" in open source organization has moved on to other areas (e.g., foundation structure, CoCs, etc.), and the field has
> matured in
> 	> other ways, so I think this is now a practicable approach in ways it would not have been a decade or even five years ago.
> 	>
> 	>
> 	> Miscellaneous notes
> 	>
> 	> *     I don't recommend merely updating the existing "popular and..." list through a subjective or one-time process. The politics
> of that
> 	> will be messy, and without a documented, mostly-objective, data-driven method, it'll again become an outdated mess.
> 	>
> 	> *     The OSD should probably be updated. At the least this should be by addressing things like whether a formal patent grant is
> 	> required of new licenses; more ambitiously it might follow Open Data Definition 2.x < Caution-Caution-
> http://opendefinition.org/od/2.1/en/ < Caution-http://opendefinition.org/od/2.1/en/ >  >  by
> 	> splitting out open licenses from open works.
> 	>
> 	> *     With SPDX and Fedora providing more comprehensive lists of FOSS licenses, it might make sense for OSI to link to those as
> 	> "extended" resources, to reduce pressure from obscure license authors to get their license approved.
> 	> *     The biggest pressure on this process will continue to be licenses that try to open up space for new commercial business
> models
> 	> (e.g., Fair Source). The more OSI can write/document/buttress OSD #1, the better.
> 	> *     I used to think a license wizard was a good idea, but I don't any more. I thought copyleft spectrum was really the only
> important
> 	> decision-making factor, which made the idea plausible, but non-copyleft factors matter much more than I once thought, and
> make
> 	> simplifying to a "wizard" too hard for OSI (though perhaps still plausible for a third party).
> 	>
> 	> *     Documentation of what the copyleft spectrum is, what the key licenses on it are, and what other factors might be relevant,
> is still
> 	> a good idea, but are secondary to getting the basic lists right.
> 	>
> 	> HTH-
> 	>
> 	> Luis
> 	>
> 
> 	_______________________________________________
> 	License-discuss mailing list
> 	License-discuss at opensource.org < Caution-mailto:License-discuss at opensource.org >
> 	Caution-https://lists.opensource.org/cgi-bin/mailman/listinfo/license-discuss < Caution-https://lists.opensource.org/cgi-
> bin/mailman/listinfo/license-discuss >
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5559 bytes
Desc: not available
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20170110/157944e1/attachment.p7s>


More information about the License-discuss mailing list