Re: Proposal

[Fischers Fritz]

An API key is an example of secret information. It is a popular
approach in the web these days for someone making a web request
to identify oneself. It is especially popular in services as software
substitutes. Technically it is usually a long random string that needs
to be included in each web request.

Since you weren't familiar with API keys, I suspect others may not be.
Moreover, I see other problems with the second line of the wording
I came up with. Perhaps this wording would be better if we remove
the second line, keeping only the first line ("Can be used as the
package's canonical source in a free package manager").



Below I understand the logic of my suggested wording, which I believe
will explain the relevance of API keys. Please read on if the topic
of API keys remains unclear. It turns out, I believe my explanation
below demonstrates why I think this should be part of grade C rather
than grade B (as proposed) or A+ (as present), so also please
read on if that interests you.



The current criterion is this:
> Allows visitors to look and download without authenticating.

I am trying to keep the intent of the current criterion
but word it more clearly, to account for the authentication considerations.
My phrasing has two lines. I will explain them separately.

Here is the first line:
> Can be used as the package's canonical source in a free package manager

In a free package manager, we have a short configuration file for each
package that says, for example, the name, the dependencies, and where
to download the source. We build binaries from this configuration and
share the binaries with our friends so they don't have to spend time
compiling.

Now I will say how this criterion requires that an ethical software
host allow visitors to look and download without authenticating.

First, our software host cannot require secret information for looking
and downloading. The package manager developer is packaging our free
software, so it needs to be able to provide this configuration file
to anyone who uses the binaries. Thus the configuration file cannot have
any secret information.

Second, it has to be very easy to automate the looking and downloading,
since the free package manager developer will likely want to rebuild
thousands of packages regularly, so the process has to be easy
to automate.

(In practice, if I were packaging a software and ran in to either of the
above problems, I would mirror the source code in order not to deal
with the problems.)

The second line:

> e.g., without authentication, API key, or CAPTCHA.

With the added context from the first line, I thought it was fine
to include the vague word "authentication" to mean something like
putting in a public name and a secret password. If the package manager
configuration file includes this, the package manager developer can't
practically publish the configuration file.

API key is another type of secret information. It differs from a name
and password in that it is typically a random string provided by the
web service, so the same string serves both to identify the account
and check for access. It is especially popular among proprietary
dis-services. If the package manager configuration file includes this,
the package manager developer can't practically publish
the configuration file either.

CAPTCHA is an example of the second part, impediment to automation.
It would be impractical to automate the process for acquiring the source
code from the software host if this would involve answering a CAPTCHA,
even a free software CAPTCHA.

Having reviewed this, I see other problems with the second line.
One could restrict source code access with other ways, like
by internet address or TLS client certificate; those are covered
by the first line but may become ambiguous because of their
absense from the second line.