[RESOLVED] Collection licensing clarifications + Ansible inclusion

[gundalow]

1. For content to be uploaded to Galaxy what license requirements are there
2. For a Collection to be included in ACD, what license requirements are there.
3. Clarify if the content was previously in ansible/ansible then it must continue to be GPLv3+

At a minimum, it would be good to clarify GPLv3 and MIT

[robynbergeron]

Related: ansible-community/collection_migration#386

[jamescassell]

I'd keep it the same as, or at least compatible ansible core. I.e., module_utils at least as permissive as BSD-2-Clause, modules can be GPLv3.

[snecklifter]

@gundalow as per IRC discussion, we have an ongoing PR - oVirt/ovirt-ansible-collection#26 - with a query around the header, specifically:

#
# Copyright (c) 2016 Red Hat, Inc.
#
# This file is part of Ansible

[gundalow]

For Ansible 2.10 we will only include collections that contain content that was previously in ansible/ansible. This list is defined in acd.in

[geerlingguy]

@gundalow - Quick question: In the community.kubernetes collection, version 0.9.0 roughly matches what was in 2.9, but we've added two sets of new modules, in 0.10.0 and again in 0.11.0.

Since it seems that ACD will include the collection itself, what should we do about new modules in the collection that weren't in Ansible 2.9?

[felixfontein]

@geerlingguy as long as it is in the same collection that also contains content from 2.9, it will be included. The whole collection will be included, so also the new modules. What does not happen is that the new modules can be used with short names (as the old modules); FQCN (or the collections keyword) must be used for them.

[geerlingguy]

@felixfontein - It seems like it could be a bit of a documentation challenge, for users of the Kubernetes modules at least—"if you have an old playbook it doesn't have to change if you use ACD/2.10, but you can change it, but for these modules which have existed before 2.10 in the collection you have to use the FQCN even if you don't have the collection installed independently".

Also, if someone uses the collection keyword or FQCN and in some playbooks they have the community.kubernetes collection installed, and in others they don't, but they use ACD/2.10 that has the collection prepackaged, it could be a crap-shoot which version of a module they'll get :-/

[felixfontein]

It seems like it could be a bit of a documentation challenge, for users of the Kubernetes modules at least—"if you have an old playbook it doesn't have to change if you use ACD/2.10, but you can change it, but for these modules which have existed before 2.10 in the collection you have to use the FQCN even if you don't have the collection installed independently".

I'm not sure what you mean here. For modules which existed before 2.10 (i.e. in 2.9 and earlier), you never have to use FQCN, no matter whether the collection was installed by ACD, installed manually, or not installed at all (in the last case you get an error of course).

Also, if someone uses the collection keyword or FQCN and in some playbooks they have the community.kubernetes collection installed, and in others they don't, but they use ACD/2.10 that has the collection prepackaged, it could be a crap-shoot which version of a module they'll get :-/

If they have ACD, then they have the community.kubernetes collection installed. ACD installs it (in a different place where collections are "usually" installed though). If both ACD is installed and a manually installed verison of community.kubernetes, Ansible will always* use the latter for all kubernetes modules - no matter whether the user uses the short name for 2.9 modules, the FQCN for 2.9 modules, or the FQCN for new modules.

(* - assuming the user didn't do strange things to their Ansible collections search path - in the worst case, it would always use ACD's collection, and not the user-installed one, if the user configured Ansible to do that.)

[gundalow]

Done