Add capability package

[kolyshkin]

This integrates github.com/kolyshkin/capability (which itself is a fork
of github.com/syndtr/gocapability) to github.com/moby/sys/capability,
as suggested in opencontainers/runc#4358 (comment)

Some of github.com/syndtr/gocapability users are (in an alphabetical order):

• https://github.com/canonical/lxd
• https://github.com/containers/buildah
• https://github.com/containers/podman
• https://github.com/containers/skopeo
• https://github.com/google/gvisor
• https://github.com/hashicorp/nomad
• https://github.com/linuxkit/linuxkit
• https://github.com/opencontainers/runc
• https://github.com/opencontainers/runtime-tools
• https://github.com/slimtoolkit/slim

The way it was done is:

# 1. Create a copy of a local repo: 
git clone --no-local capability capability-for-merge
 
# 2. Use git-filter-branch to:
#  - move contents to a subdirectory
#  - remove useless merge commits
#  - remote .github files
#  - add 'capability: ' prefix to commit messages
cd capability-for-merge
git filter-repo --prune-degenerate always --path-rename :capability/ \
    --path-match .github --invert-paths \
    --message-callback '
  prefix = b"capability: "
  if not message.startswith(prefix):
    message=prefix+message
  return message
'

# 3. Merge the above repo to moby/sys
cd ~/git/moby/sys
git checkout -b add-capability
git remote add cap-merge ../../capability-for-merge
git fetch cap-merge
git merge --allow-unrelated-histories --signoff -S cap-merge/main

[thaJeztah]

Thanks! Forgot to submit some comments I had

[thaJeztah]

I'm curious what the right approach is for this license file; currently this means that golang.org/moby/sys/capability will be licensed as MIT, but the LICENSE at the top of the repository is Apache2.

I know when vendoring other modules from this repository, go mod copies the LICENSE from the top-level, so I wonder what it does for this module (will it copy both? will it only use the MIT license?).

Reading these two StackOverflow answers;

• https://opensource.stackexchange.com/a/7391
• https://law.stackexchange.com/questions/6081/can-i-bundle-mit-licensed-components-in-a-apache-2-0-licensed-project

---

• At least the original license and copyright must be retained (see below)
• Possibly as a secondary file (?)
• Possibly included in a NOTICE file?

[kolyshkin]

I am now testing this PR in opencontainers/runc#4358, and from what I see, go mod vendor uses top-level LICENSE file for e.g. moby/sys/mount and other packages, and it uses directory-level LICENSE for moby/sys/capability. In other words, it works as it should.

I don't see any problem with this layout -- a LICENSE file in a subdirectory overwrites the upper level LICENSE. If they are compatible (as in our case), all is fine and dandy.

Disclaimer: IANAL.

[thaJeztah]

Yeah, I'm somewhat looking from a "module" perspective, because it may become somewhat ambiguous; for the GitHub repo, the license on the repo-level is Apache 2, with a subdirectory having the MIT license.

But from a module perspective, normally it would copy that license; in this case it only has the MIT license. And perhaps that's OK (so, the capabilities module having a different license than the other modules), but was wondering if we wanted to re-license the new module to use Apache 2.

[thaJeztah]

☝️ s/MIT/BSD 2-clause/ (I was confused)

[kolyshkin]

golang.org/moby/sys/capability will be licensed as MIT

For the sake of those reading this thread. This is actually a BSD 2-clause license, not the MIT license.
See https://opensource.org/license/bsd-2-clause

[tianon]

BSD-2-clause is different from Apache 2, but strictly less restrictive, so is probably OK. Trying to relicense is going to be a huge pain. 👍

This seems fine to me (currently discussing some minor suggested changes in the Moby maintainers meeting, but I don't think there's any strong opposition overall).

[thaJeztah]

LGTM

[thaJeztah]

@AkihiroSuda PTAL if this LGTY

[thaJeztah]

LGTM

[thaJeztah]

Also /cc @dims (FYI - you probably also have an interest in this)

[dims]

of course! this is a welcome development. thanks for the poke @thaJeztah

[kolyshkin]

Just pushed a new version, mostly addressing @AkihiroSuda's comments, i.e.

• fixed CHANGELOG.md to clarify the fork source and fix links to PRs.

But also:

• added the missing commit from the kolyshkin/capability repo which was lost before;
• fixed a small issue in a changelog (go version requirement was wrong).

All that (except for the missing commit addition) are added as the last 2 commits, so you are re-reviewing, you can only review these two.

[kolyshkin]

I think we can address any other concerns post-merge.

[thaJeztah]

Thanks 🙏