[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