> All your points are well taken.  My point which I didn't make
> clear was what licenses are we going to reject out of hand for
> Schemeregistry,

That makes sense. Sorry I didn't catch your intent.

> particularly for lists of useful things with
> pointers to their home pages, repos, and/or tarballs (and
> ideally our backups of those).  I suggest we accept anything
> that's accepted by Open Source Initiative, it's criteria are
> here: https://opensource.org/osd
>
> This covers every licence I've seen as of late that claims to be
> "open" with the exception of some new ones that fail criteria 5
> and/or 6, "No Discrimination Against Persons or Groups" and "No
> Discrimination Against Fields of Endeavor."  The latter an old
> issue, e.g. what does it mean that your work can "only be used
> for good" purposes?
>
> Note the above criteria limitations have the RMS seal of approval.

Those are all good criteria. However, I still feel we're making
something too complex out of it.

I've learned over the years to fight pretty hard to trim inventions down
to their essence, especially social inventions such as processes and
recommendations. The natural tendency for most of us is to be
freewheeling about the scope of things but that easily leads to scope
creep which reduces the efficiency of process. We've seen that over the
last year with SRFI which is a wonderful process but we've learned that
it's not really well suited for large documents. The successful SRFIs
tend to be quite narrowly scoped, and when we've reduced the scope of
things like SRFI 170 the result has been a boost in clarity, efficiency,
morale. I've been lax with the scope of my own SRFIs and those stagnated
as well.

I expect that unless we have a pretty clearly defined format for what
goes into the registry, its scope will expand as well. That complicates
questions like storage and licensing which we are discussing here.

I would prefer to put things of a similar scope into similar projects.
For example, code snippets could go into the cookbook that schemedoc is
resurrecting and updating. Or in SRFIs, specifications or manuals if the
snippet is about a pertinent topic.

To import ready-made lists from other sources, John's opinion is that an
alphabetized list is not copyrightable. Lists with a significant amount
of explanatory text might be? In any case, it might be easiest if the
entire collection is public domain equivalent and we enforce that by any
means necessary. After all, they're meant to be just lists.

More complex licensing is reasonable for more complex content. To keep
the registry simple, I'd prefer to house that content with a other
projects prepared to tackle complexity on that level.