Re: A+ 0
I don't like the phrase "operate on projects", I don't think that is the key point. I think the key point is to access the projects at all. It's one thing if someone can see public stuff (see code history, issue tickets, download the source code etc) and another for someone to submit anything (create an issue ticket or send in a code patch or similar). Also, I still think "authentication" seems not specific enough. Is it "authentication" when GitLab.com does some cloudflare check that blocks the entire site from loading upon failure? Maybe something like this: "Access to any public parts of projects is not limited by any form of authentication of visitors." ? On 2023-12-20 8:25 p.m., "Svetlana Tkachenko" wrote: Hi Richard > I agree with the point, but I think those words don't make it totally > clear. I think these would be clearer. > > Does not impose any authentication requirements for visitors to operate > on projects, other than what the managers of each project have chosen. > > WDYT> Maybe this: Does not impose any authentication requirements for visitors to operate on projects, other than the requirements set by the managers of each project; provides a facility to host a project in which all such requirements are absent, allowing full public access.
Re: Proposal
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 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.
Are these keys also called "application keys"? I have heard of that
term. Each application is supposed to have and send its own key,
different from that of every other application.
The requirement to conceal each application key prohibits free
applications. Clearly a requirement for an application key is
unacceptable. Maybe our other criteria make that clear, or maybe not.
We should make sure it is clear.
> 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").
That may be correct, but it is not sufficient on its own, because it
is too abstract to give a concrete picture. What are the concrete
requirements for the "canonical source" in a free package manager?
I don't know.
Maybe your full proposal would be good, if suppliemented with a
concrete explanation of "API key".
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
