[Collection will end on 2022-09-09] Questions to Legal

[Andersson007]

Summary

Please formulate your questions to legal and put them here.

• Questions should be as full, simple, short and clear as possible w/o specific technical details (i.e. as abstract as possible).
• Ideally the questions should imply yes/no answers.

I believe the more the questions satisfy the above the more chances that we'll get answers.

[acozine]

The main legal question I keep hearing is this:
Are we violating any licensing requirements if we fail to include every single file from a repository in the associated collection we distribute?
Or to put the same question another way:
Can we leave files that exist in the repository (for example, test files or documentation) out of the distributed collection based on that repository without violating the license?
The main goal of leaving files out would be to make the distributed collection smaller. See #126.

[gotmax23]

The other question is whether the community can build from source the collections that are part of the ansible bundle. I would say that is a basic tenet of open source, but it wouldn't hurt to ask.

[anweshadas]

The main legal question I keep hearing is this: Are we violating any licensing requirements if we fail to include every single file from a repository in the associated collection we distribute? Or to put the same question another way: Can we leave files that exist in the repository (for example, test files or documentation) out of the distributed collection based on that repository without violating the license? The main goal of leaving files out would be to make the distributed collection smaller. See #126.

As per my understanding, this does not affect or violate the terms of Licensing. The source code repositories contain many other files/things other than the direct source code of the project. Say examples, test files or data, presentations on/about the project, and old logos. And each of these files can be licensed under a license different than the project license, like presentations licensed under Creative Commons. None of these files are required for the actual project use case (eg, Collection). So we should not be worried about this.

[Andersson007]

@anweshadas thank you for the input! I hope our Legal team will officially confirm what you written ASAP.

[Andersson007]

The following is the final message. How does it look? Haven't we missed anything important?

Title: Can we leave out files living in a source code repository of the distributed piece of software without violating the law?

The context of the question:
- The Ansible Community package consists of ansible-core plus a set of collections.
- A collection is a pluggable piece of software that can be created by a third-party subject.
- Collection's content can be licensed with The GNU General Public License v3.0 or higher, BSD-2 License or
with another GPL v3+ compatible license.
- Example of a source code repository: https://github.com/ansible-collections/community.general
- Example of the related distributed artifact: https://galaxy.ansible.com/community/general (currently this is almost identical to the release tags in the source code repo, the only differences are that `galaxy.yml` is converted to `MANIFEST.json`, and `FILES.json` is created. We would like to make it smaller if we can)
- Collections' repositories contain source code files and other files like documentation, tests, etc. which often have a larger size than source code itself.
- Non-source code files are not a part of the collection's functionality.
- We want to exclude those files from collection archives (tarballs). The main goal of leaving the files out will be to make the distributed collection and, respectively, the whole Ansible Community Package smaller. See https://github.com/ansible-community/community-topics/issues/126 for details.

The final question is "Can we leave files that exist in the repository (for example, test files or documentation) out of the distributed collection based on that repository without violating the law (for example, related to license)?"

Please send the official Legal answer to [email protected]

If there are no objections, I'll send it to Legal 2022-10-12

[acozine]

Overall looks good. I'd add a link to Galaxy so they can compare the distributed piece of software with the code repository. I'd replace:
- Example of a collection: https://github.com/ansible-collections/community.general
with:

- Example of a source code repository: https://github.com/ansible-collections/community.general
- Example of the related distributed artifact: https://galaxy.ansible.com/community/general (currently this is identical to the source code repo, we would like to make it smaller if we can)

[felixfontein]

I would change the second sentence in @acozine's suggestion to

- Example of the related distributed artifact: https://galaxy.ansible.com/community/general (currently this is almost identical to the release tags in the source code repo, the only differences are that `galaxy.yml` is converted to `MANIFEST.json`, and `FILES.json` is created. We would like to make it smaller if we can)

---

BTW, while comparing the 5.7.0 tarball to the 5.7.0 release tag, I noticed that the tarball contains some files that are not in the git repo:

• .github/ISSUE_TEMPLATE/ci_report.yml (https://github.com/ansible-collections/community.general/tree/5.7.0/.github/ISSUE_TEMPLATE does not contain it)
• .github/workflows/docs-pr.yml (https://github.com/ansible-collections/community.general/tree/5.7.0/.github/workflows does not contain it)
• .github/workflows/docs-push.yml (https://github.com/ansible-collections/community.general/tree/5.7.0/.github/workflows does not contain it)

While the main branch has .github/workflows/docs-pr.yml, neither of the other two files are in there (https://github.com/ansible-collections/community.general/tree/main/.github/ISSUE_TEMPLATE, https://github.com/ansible-collections/community.general/tree/main/.github/workflows). This is scary.

These extra files seem to belong to community.aws. @goneri since community.general is published by Zuul, could it be that some files in .github are not properly removed and thus could end up in the released version of another collection?

Edit: it looks like I did something wrong on my machine. Maybe I had some files still lying around when extracting the tarball (probably the most likely cause) - I thought I did everything in a newly created directory, but I guess I didn't. At least when trying this again in a newly created directory, I couldn't find these traces anymore. Sorry!

[felixfontein]

@Andersson007 another point is that we only know for collections released by Zuul that the release tag corresponds to the collection tarball on GitHub. We do not have that guarantee for other collections. (And also for Zuul released collections, (a) there is the above issue, and (b) you can delete and re-create tags on GitHub.) We do require that the tags correspond to the releases, but there have been violations in the past (see for example CheckPointSW/CheckPointAnsibleMgmtCollection#84). I guess this is also why @gotmax23's Fedora packaging guidelines for collections require the collection to be rebuilt from the git tag, instead of taking the Galaxy tarball.

This makes the whole question probably more complicated.

[gotmax23]

another point is that we only know for collections released by Zuul that the release tag corresponds to the collection tarball on GitHub. We do not have that guarantee for other collections. (And also for Zuul released collections, (a) there is the above issue, and (b) you can delete and re-create tags on GitHub.) We do require that the tags correspond to the releases, but there have been violations in the pas

I'm not sure that is super relevant here. There is no guarantee right now that the Galaxy release corresponds to the git tag, and there's no guarantee that it will if we remove tests from Galaxy archives. This is the nature of package registries, whether it's PyPI or Ansible Galaxy. How would removing tests make this issue any better or worse?

---

Other not legal related ramblings:

I wish there would be Galaxy metadata entries that had the exact commit hash and a link to download the full source e.g. https://github.com/ansible-collections/community.general/archive/5.7.0/community.general-5.7.0.tar.gz. Either way, it's not really our fault if collection maintainers misrepresent collection versions and give two different things the same version name. This is the case whether the antsibull-build downloads collection sources from Ansible Galaxy or directly from Github|Gitlab|whatever.

As I've said before, I think there should be a separate source archive for the ansible package containing all of the tests before we start removing them from Galaxy collection artifacts. Not having all of the full sources together will break Debian's packaging which runs these tests and limit our ability to run sanity tests for all collections.

[Andersson007]

Thanks everyone, sent:)

[Andersson007]

The essence of Legal's official response to #131 (comment) (note that it's not the original response; if I get the clear permission to publish it here as-is, I'll do it):

Test files and documentation files can be excluded from the distribution.

Files that should not be excluded:
* license files
* the galaxy.yml file (or MANIFEST.json or whatever you convert that
to) -- at least in cases where that is the only indication of how the
content is licensed
* Makefiles and other files somehow necessary to functionally rebuild, install and modify the code: it may
be necessary to include it -- if you distribute binary/object code in the GPL sense, otherwise, if you distribute only source code, Makefiles can be excluded.

[mariolenz]

IANAL, but this is more or less what I expected. Looks OK for us, doesn't it? Are we happy?

[Andersson007]

closing this as complete, feel free to object/reopen if needed