Re: [Repo-criteria-discuss] Criteria updated to version 1.1

[Juuso Lapinlampi]

On Wed, Jul 13, 2016 at 03:40:11PM -0400, Zak Rogoff wrote:
> though. As I understand it, the specific goal of this criterion is to
> encourage repo services to make it impossible to post source files
> without clear licensing.

This may be impractical when creating a repository or submitting changes
is just a git-remote(1) and git-push(1) away to publish.

githooks(5) exists to implement server-side checks, but I don't know of
any implementation that would satisfy the goal as you describe it. Even
if there was some form of license checking in place as a Git hook on the
remote repository, there is no guarantee it to be accurate.

While I cannot be certain, I also believe it is possible to override
githooks(5) by doing a force push, effectively making the effort void.
As far as I understand it, there is also nothing to stop the user from
removing the server-side hook in their own repository if added by
default.

The alternative is to disallow force push altogether on the remote
repository, but that would cause some issues with branches like next and
pu per gitworkflows(7).

The way I interpret your interpretation would barrier hosting many
important free software projects, even if all of those files were really
free. I am concerned this may push back the goals of the Free Software
Foundation.

>From a service provider perspective, it would be absurd to disable
access to repositories such as linux-libre for not comforming to the A9
criteria if such thing was required to be enforced in terms of
service/acceptable use policy.

I am also doubtful that savannah.(non|)gnu.org would interpret the
criteria that way, yet repo-criteria-evaluation.html (version 1.0)
claims it to be A-grade.

Among good licensing practices is also to inform the user about
copyright assignments and how a non-legal entity cannot hold or enforce
its copyright. This is not a criteria, but a good guideline to licensing
like A9. But such guideline would be too infeasible to enforce.

Git is not the only version control system out there, but that's not the
point of my argument.