Attendees: Karanbir Singh Jim Perrin Fabian Arrotin Johnny Hughes Ralph Angenendt Karsten Wade

Actions: Add a license field for every container entry Develop list of all licenses in the distro + per repo Add requirements for license field into the SIG guide Add verification check Messaging for unified git Write up proposal & submit to Board for discussion / approval

Notes: Registry.centos.org containers Who is vetting that things match the correct rules? Akin to SIGs -- they can go succeed but following the guidelines Need guidelines for this Containers may be more visible than other domains Licensing guidelines are already in https://wiki.centos.org/SpecialInterestGroup What is our response? Containers are acting separately from what SIGs do? Operate within Atomic SIG Who is responsible for content going into registry? BamaChrn Kundu & Container Eng team Action: Need a ‘License:’ field for every container entry Action: Make sure it is in the SIG guide & referenced from that SIG What do we put in the license field? License field should contain the license for the app that is the ‘purpose’ of the container All licenses need to be included in the container viewable when examining the container Make it clear to the SIGs what we are happy to host/not host Issue of how we build containers LIfecycle terms OK to just consume content Can take built binaries … Requiring restriction to come from RPMs would be a very high barrier for the upstreams we are working from Licenses we approve of … Verification check post-build? If we’re not checking / don’t have a way to check, we’re responsible. Unified git (NDA topic) Discussed at FOSDEM Buildroot for RHEL8 likely larger than shipped OS All source coming into CentOS To make this work with need a unified git with Fedora Result Git.centos.org maintained by us, pulls from common place as git.fedoraproject.org Effects No appreciable negative effects? Positive for certain type of maintainers Makes our future lives easier as stuff is changing anyway Modified packages How is this going to work if CentOS & Fedora have a common upstream git repo -- where do our changes go? Different branches - ‘f’ v ‘c’, so each group/hat worn pushes changes to their branches Some packagers may wear both hats How are the CentOS changes retained? The official branches ‘c7’ are for debranding only -- workflow stays in place. Johnny’s changes go through as they do currently We need to be better updating patches in alt-src E.g. c7-sig-altarch would be protected for project & SIG members via authentication, so no one from e.g. Fedora could step on something. Ideally this is a minimal changes to current workflow