_compliant should be _approved about licenses

If I understand this correctly, Unlicense will have "false" for both OKD and OSD approved fields (as per linked issue), but still listed... presumably because it's compliant. :)

Or will it no longer be accepted for listing at all?

I'm not sure what is the outer bound of licenses list.

[mlinksva]

Yes it would have to be false for both at this point.

[jonschlinkert]

IMHO approved and compliant are both valuable and necessary. Having one does not imply or suggest the other, so why try to consolidate them both to one?

[rufuspollock]

@mlinksva seems like we might want to consider both fields - though worried that could be confusing. Perhaps we should just have _approved and leave compliant out.

[mlinksva]

I'd go with approved and leave compliant out. If a license is thought to be compliant, it should be submitted to relevant compliance approval process. Compliant just means approved-by-whoever-submitted-patch. :)

But I'm also not sure approved should be boolean. There's approved, rejected, and not reviewed (the default if not present). Hmm, maybe the field should be compliant and those should be the values?

[hlainchb]

Currently the licenses directory in the repository has /licenses/inreview
and /licenses/conformant.

The field could be named "compliance" and the values could be "inreview",
"approved", "rejected", "not reviewed"

And, then we could rename /licenses/conformant to /licenses/approved to be
consistent.

On Mon, Mar 31, 2014 at 11:36 AM, Mike Linksvayer
[email protected]:

I'd go with approved and leave compliant out. If a license is thought to
be compliant, it should be submitted to relevant compliance approval
process. Compliant just means approved-by-whoever-submitted-patch. :)

But I'm also not sure approved should be boolean. There's approved,
rejected, and not reviewed (the default if not present). Hmm, maybe the
field should be compliant and those should be the values?

Reply to this email directly or view it on GitHubhttps://github.com//issues/16#issuecomment-39124652
.

Herb Lainchbury, Dynamic Solutions
250.704.6154
http://www.dynamic-solutions.com

[mlinksva]

@hlainchb that sounds reasonable. note that other license approvers don't all have the same process/statuses, eg I don't know that OSI ever formally rejects a license, it just doesn't approve. But 99% of users should just be looking for "approved" anyway; any other value users should just reject the license. :)

[tieguy]

There is no formal rejection at OSI, that's correct. But I think it is
useful to have a list of things not-accepted.

[jonschlinkert]

any other value users should just reject the license. :)

Lol, @tieguy responded as I was typing the opposite. I respectfully disagree with @mlinksva on this. Remember that every good cause has a champion, likewise, (the good) unapproved licenses will only ever get approved if they get the support they require. e.g. users need to know about them and where they stand.

So with that in mind, I guess the real question though is "what kind of value should this service provide?". If this project seeks to provide a service that allows users to make decisions based on the information they require, I see no reason to be so limiting regarding the fields of information as long as it's 100% clear what each field means. So what if there is one more field (or 20 for that matter)? It's just JSON ;-)

However, if a hard line is to be drawn, since it's already inferred that a license isn't approved if it's not on the list, then only approved licenses should be on the list. just my 2c

[jonschlinkert]

for the record, I'm not really pushing for one or the other, just trying to figure out what the real goal is here...

[mlinksva]

FTR, this has been addressed by changing names and values to od/osd_compliance and approved/rejected/not reviewed.

[jonschlinkert]

👍

[rufuspollock]

👍 @mlinksva

[hlainchb]

👍 @mlinksva

[mlinksva]

Thanks for thumbs ups.

To keep notes in one place, I realize as stated above OSI does not formally "reject" licenses. We could add "not approved" (or just use "reject" even though not precisely mapping to OSI process) to licenses that have actually been considered but not approved, though what considered means is fuzzy -- discussed on their mailing list? There is also the odd case of CC0, which was withdrawn from review :) ... could have "withdrawn from review" value.

Anyway approved/rejected/not reviewed seems to work fine for OD; if anyone feels urge to address OSD conformance with more precision than "not reviewed" for anything not approved, feel free to discuss and reopen or send pull request.