18:00:31 <felixfontein> #startmeeting Ansible Community Meeting
18:00:31 <zodbot> Meeting started Wed Apr  7 18:00:31 2021 UTC.
18:00:31 <zodbot> This meeting is logged and archived in a public location.
18:00:31 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:31 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:31 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:31 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
18:00:34 <andersson007_> o/
18:00:37 * dericcrago waves
18:00:40 <felixfontein> #chair dmsimard andersson007_ dericcrago
18:00:40 <zodbot> Current chairs: andersson007_ dericcrago dmsimard felixfontein
18:00:43 <abadger1999> Bom dia!
18:00:50 <felixfontein> #chair abadger1999
18:00:50 <zodbot> Current chairs: abadger1999 andersson007_ dericcrago dmsimard felixfontein
18:00:53 <tadeboro> o/
18:00:57 <cyberpear> o/
18:01:03 <felixfontein> #chair tadeboro cyberpear
18:01:03 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear dericcrago dmsimard felixfontein tadeboro
18:01:45 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:01:48 <felixfontein> #topic Updates
18:02:09 <felixfontein> #info community.dns 0.1.0 has been released
18:02:09 * samccann waves
18:02:14 <felixfontein> #chair samccann
18:02:14 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear dericcrago dmsimard felixfontein samccann tadeboro
18:02:28 <felixfontein> #info Ansible 3.3.0 is planned for next week
18:02:30 <gundalow> Hi
18:02:56 <felixfontein> #info community.general 2.5.0 will be released beinning of next week, and it will be the last 2.x.0 minor release
18:02:59 <felixfontein> #chair gundalow
18:02:59 <zodbot> Current chairs: abadger1999 andersson007_ cyberpear dericcrago dmsimard felixfontein gundalow samccann tadeboro
18:03:04 <acozine> o/
18:03:13 <felixfontein> #chair acozine
18:03:13 <zodbot> Current chairs: abadger1999 acozine andersson007_ cyberpear dericcrago dmsimard felixfontein gundalow samccann tadeboro
18:03:56 <felixfontein> any more updates?
18:04:22 <tadeboro> Maybe a word or two about stable-2.11 branching?
18:04:28 <dmsimard> ansible-core 2.11.0rc1 is out and devel has branched out to 2.12
18:04:37 <felixfontein> oh right!
18:04:45 <abadger1999> #info ansible-core-2.11 has released its first release candidate
18:04:46 <gundalow> I hope to be able to share some positive news about Galaxy next week.
18:04:47 <felixfontein> #info ansible/ansible has a stable-2.11 branch
18:05:03 <felixfontein> #info ansible-core 2.11.0 rc2 has been released
18:05:25 <felixfontein> gundalow: that would be great :)
18:05:41 <felixfontein> (I hope it's not just renamed ;) )
18:06:25 <samccann> s/galaxy/nebula/g
18:06:28 <dmsimard> let's not go there :p
18:06:30 * samccann just kidding
18:06:41 <felixfontein> :D
18:07:12 <tadeboro> nebula is waaaay to short ;)
18:07:58 <felixfontein> the german word for nebula equals the german word for fog, which makes this even more interesting ;)
18:08:28 <andersson007_> (intriguing)
18:08:35 <dmsimard> I think we're good with updates, let's move on :D
18:08:45 <felixfontein> dmsimard: btw, do you want to continue the LTS discussion today, or should we discuss other topics first?
18:08:52 <felixfontein> #topic Meta: how to add things to the agenda
18:08:52 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/3
18:08:55 <felixfontein> #info Concrete proposal: https://github.com/ansible-community/community-topics/issues/3#issuecomment-811371592
18:09:01 <felixfontein> this is a continued discussion from last week
18:09:23 <felixfontein> I tried to distill the discussion from last week into a proposal
18:09:45 <dmsimard> felixfontein: I thought I would have a proposal ready but I don't and I'd like more time to get it right so it hopefully doesn't come back to bite us, we can chat about it if we have time at the end
18:09:57 <felixfontein> dmsimard: ok, then probably next week or so ;)
18:10:07 <abadger1999> +1
18:10:24 <acozine> can someone fill me in on the background? do we have a lot of agenda items and need a way to filter out the most important?
18:10:48 <abadger1999> It's great to have a set of rules to try out and then make them better as we encounter problems
18:10:49 <felixfontein> acozine: the idea is to avoid discussing items in the agenda issue
18:10:51 <acozine> is there some other problem/challenge we're trying to solve?
18:10:59 <tadeboro> I read the proposal and I am fine with the described process.
18:11:09 <felixfontein> so the agenda issue is only for meeting summaries (or important announcements like new meeting times)
18:11:28 <acozine> ah, so "keep the agenda issue as clean as possible, while still allowing community members to propose topics for each week's agenda"
18:11:44 <acozine> thanks
18:11:45 <andersson007_> exactly
18:11:45 <tadeboro> What I like the most about the proposal is the act of closing the issue once we converge on the topic.
18:11:52 <felixfontein> and instead of having a process of compiling a list of topics (which someone would have to do), the idea is to just use the list of open issues in https://github.com/ansible-community/community-topics/issues/
18:12:07 <cyberpear> maybe better as an issue, but I recently found that ansible will fail to install with pip if /tmp has low disk space, but it's not obvious that's why... apparently 512M isn't enought disk space to do the pip install (no such issue w/ ansible-core)
18:12:37 <andersson007_> we could also use labels to prioritize issues there as someone suggested
18:12:41 <felixfontein> cyberpear: could be that this is pip, not ansible, when creating a wheel
18:13:01 <cyberpear> fair enough... many ansible install issues are the fault of pip
18:13:29 <tadeboro> To be fair, ansible pypi package is quite large.
18:13:31 <felixfontein> andersson007_: yep, though I wouldn't add that to the process yet (except the next_meeting label), we should look at how this works for a couple of weeks (or longer) and then add more on labels once we figure out what would help
18:13:51 <andersson007_> +1
18:13:52 <dmsimard> cyberpear: the 3.2.0 tarball is currently ~31MB, it would be surprising that it would not fit within 512MB
18:14:02 <felixfontein> dmsimard: the extracted tarball is a lot bigger
18:14:09 <tadeboro> I would say we go with the bare-bones approach felixfontein described in the proposal and adjust it once it starts to fail on us.
18:14:27 <dmsimard> felixfontein: I would expect as much yes, text compresses very well
18:14:30 <aminvakil> o/
18:14:30 <dmsimard> but let's chat about it after :p
18:14:58 <felixfontein> dmsimard: `du -h` in the extracted tarball gives me 289M
18:15:08 <dmsimard> ugh
18:15:11 <acozine> #chair aminvakil
18:15:11 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cyberpear dericcrago dmsimard felixfontein gundalow samccann tadeboro
18:15:16 <felixfontein> ok, let's vote on it
18:15:25 <felixfontein> VOTE: accept proposal https://github.com/ansible-community/community-topics/issues/3#issuecomment-811371592
18:15:33 <dmsimard> +1
18:15:33 <tadeboro> +1
18:15:34 <felixfontein> +1
18:15:38 <acozine> +1
18:15:41 <abadger1999> +1
18:15:42 <andersson007_> +1
18:15:56 <cyberpear> +1
18:16:16 <dericcrago> +1
18:16:25 <bcoca> he, going back to how it was
18:16:27 <bcoca> +1
18:16:34 <felixfontein> #agreed proposal https://github.com/ansible-community/community-topics/issues/3#issuecomment-811371592 accepted
18:16:46 <gundalow> \o/
18:16:52 <felixfontein> bcoca: these issues will be a bit less heavy-weight I guess, but yeah :)
18:16:58 <felixfontein> great :)
18:17:08 <felixfontein> #topic Licenses for new collections: relax requirements?
18:17:08 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/2
18:17:09 * bcoca is still scrolling down current agenda ticket
18:17:11 <felixfontein> Background: hpe.nimble (https://github.com/ansible-collections/ansible-inclusion/discussions/13) is Apache 2.0 licensed (https://github.com/hpe-storage/nimble-ansible-modules/tree/master/ansible_collection/hpe/nimble#license)
18:17:15 <felixfontein> #info Proposal: https://github.com/ansible-collections/overview/pull/164
18:17:16 <github-linkbot> https://github.com/ansible-collections/overview/pull/164 | open, created 2021-04-07T16:42:43Z by abadger: Expand the licenses allowed in collections
18:17:20 <felixfontein> abadger1999: do you want to say something?
18:17:28 <abadger1999> Sure
18:17:52 <abadger1999> Last week we got a discussion item asking if a collection with Apache v2 licensed modules should be accepted.
18:18:31 <abadger1999> The current licensing guidelines would prohibit that but our intention seemed to be to open up to more open source licenses once we get approval from legal.
18:19:30 <abadger1999> From past discussions with legal in the fedora space, I think that allowing GPLv3 compatible licenses in addition to the GPLv3+ itself is unlikely to cause any problems when legal reviews.
18:19:39 <abadger1999> (Apache v2 is compatible with GPLv3)
18:19:55 <abadger1999> So I'm proposing that we relax that requirement for modules now.
18:20:20 <abadger1999> When legal gets back to us, they'll likely allow us to go much further.
18:20:23 <felixfontein> for modules and module_utils, and potentially other non-code files
18:20:40 <bcoca> that might have distros not package the ansible pypi package anymore and opt for the minimal, when they are more strict about licenses *cough* debian *cough*
18:21:01 <cyberpear> bcoca: can you explain?
18:21:24 <felixfontein> I would expect them to package things that have GPL compatible licenses
18:21:29 <bcoca> for example, debian has locked to lower ansible version in past due to our more lax licensing/tagging of files
18:21:54 <abadger1999> <nod> Yeah.  non-code files aren't mentioned in the update.  The current guidelines might cover non-code files as must be gplv3 although it's unclear to me.
18:21:58 <bcoca> they do, but then it might go outside the base repos and require opt in
18:22:39 <abadger1999> The interaction of non-code files with code is something I only have a few examples of so I'd be uncomfortable proposing a policy for that without legal review.
18:23:07 <bcoca> doc_fragments can be considered code, since we do use them for arg evaluation in plugins
18:23:35 <cyberpear> did we ever solve getting a non-GPL module template/example so folks don't have to do it from first principles?
18:24:45 <cyberpear> debian sid currently has ansible-2.10.7... checking now whether it's ansible-base or ansible
18:25:01 <felixfontein> debian has a page which says which licenses are ok: https://wiki.debian.org/DFSGLicenses
18:25:59 <bcoca> ^ they are the most strict i know of, but its always a consideration with other distros .. not sure any others are popular enough for anyone to care
18:26:07 <cyberpear> sid looks like it's full-blown ansible since `redhat_subscription` module is available
18:26:29 <felixfontein> cyberpear: that's very important for debian installations ;)
18:26:32 <abadger1999> cyberpear: Cool
18:26:40 <bcoca> we fixed the issues a while back, but for a time they were using 2 versions older than stable due to licensing issues
18:26:45 <cyberpear> just picked one not in core :P
18:27:11 <bcoca> im just using them as example ...and likely problem child everytime licenses are discussed
18:27:28 <felixfontein> we could (at least for now) require that all licenses that are not BSD and GPLv3 are both allowed by Fedora's list and Debian's list
18:27:54 <tadeboro> I am fine with what abadger1999 proposed for now since as far as I can tell, this unblocks the nimble stuff and allows things to start moving in the right direction.
18:28:06 <abadger1999> <nod>  An and would be fine if we feel we need it.
18:28:48 <felixfontein> (and if we stick to licenses allowed by both Debian and Fedora, we should have no problem with any distro based on these)
18:28:58 <cyberpear> felixfontein: +1
18:29:05 * abadger1999 checks whether the DFSG shows gpl compatibility or only free-software-ness
18:29:53 <abadger1999> Okay, they only show whether the licenses are considered free or not.
18:30:31 <felixfontein> abadger1999: yes, looks like. so if they accept the license as free, and Fedora declares it as GPL compatible, it should definitely be ok
18:30:44 <felixfontein> https://www.debian.org/legal/licenses/ seems to be a better list for Debian
18:30:49 <abadger1999> <nod>
18:30:53 <felixfontein> the other list I linked above is more informal
18:31:41 <felixfontein> bcoca: do you remember whether the problematic files were code or other files (tests, docs, test data, etc.)?
18:32:42 <bcoca> the main ones pointed at by debian issue were code
18:34:22 <felixfontein> abadger1999: should we do some polls on some of the main questions so we can update the proposal for next time?
18:34:36 <abadger1999> felixfontein: Sure.
18:34:41 <felixfontein> like licenses from which list(s) are ok, what about non-code files, what about doc fragments
18:34:53 <abadger1999> I can probably update the roposal now if people agree to what they want.
18:35:59 <cyberpear> do we want to suggest doc fragments be dual-licensed as one of the CC licenses in addition to whatever code license might be using it?
18:36:12 <felixfontein> POLL: all licenses must be on the following list(s) (use one or multiple letters): a) GPL-comptible according to https://fedoraproject.org/wiki/Licensing:Main#Software_License_List, b) included in Debian main according to https://www.debian.org/legal/licenses/, c) another source?
18:36:34 <felixfontein> a) + b)
18:37:13 <felixfontein> hmm, ok, maybe that Debian license list is a bit short... maybe https://wiki.debian.org/DFSGLicenses would be better
18:37:31 <cyberpear> (I've heard that code licenses don't do so well for documentation, but maybe that's not true...)
18:37:34 <abadger1999> a) +1 b) +0, c) -1
18:37:39 <felixfontein> POLL: all licenses must be on the following list(s) (use one or multiple letters): a) GPL-comptible according to https://fedoraproject.org/wiki/Licensing:Main#Software_License_List, b) included in Debian main according to https://www.debian.org/legal/licenses/, c) free according to https://wiki.debian.org/DFSGLicenses, d) another source?
18:37:42 <cyberpear> I'd say a+b... which ever licenses are on both lists
18:38:10 <felixfontein> witht he new choices, I'd say: a) +1, b) -1, c) +1
18:38:27 <abadger1999> cyberpear: I've heard that too.  The Fedora page has a separate list for documentation-specific licenses.  I just don't know what will need to be done for things that are both code and documentation yet (like doc_fragments)
18:38:55 <tadeboro> I would vote a) since that one seems to be the safest option.
18:39:01 <mariolenz> i don't want to spoil your fun, but i'm not sure if the debian guys are really the ones to decide if apache2 and gplv3 are compatible. but according to gnu, apache2 and gplv3 are compatible: https://www.gnu.org/licenses/license-list.en.html#apache2
18:39:15 * acozine abstains due to lack of expertise
18:39:32 * samccann huddles in the unlicensed corner w/ acozine for this one
18:39:33 <abadger1999> mariolenz: Yeah, the fedora list is generated from information that was given to fedora from red hat legal.
18:40:23 <abadger1999> In general, compatibility on the fedora list should agree with what is on the gnu list.
18:41:18 <abadger1999> For new list: a) +1, b) -1, c) +0, d) -1
18:41:28 <bcoca> cyberpear: copyright licensing applies to anything written, code is a special case, docs was the 'normal case'
18:43:05 <felixfontein> abadger1999: do you want more input on this question, or should we continue with another one?
18:43:35 <abadger1999> That's fine
18:43:42 <felixfontein> POLL: should we a) require GPLv3 compatible licenses for non-code files? b) require them to be GPLv3+? c) something else?
18:43:53 <mariolenz> i'm just an amateur on licensing, but if red hat legal approves i guess it's ok.
18:43:58 <abadger1999> And I've pushed an update to the proposal for those two things
18:44:08 <felixfontein> a)
18:44:31 <cyberpear> abadger1999: link?
18:44:53 <aminvakil> cyberpear: https://github.com/ansible-collections/overview/pull/164
18:44:57 <mariolenz> does gpl even cover non-code files?
18:45:23 <abadger1999> I think b) is the status quo.
18:45:40 <acozine> it's simple to explain/document
18:46:09 <abadger1999> I think legal will allow GPLv3+ compatible licensing for everything but the safe option is to continue with (b) (which is what the non-module plugins are using)
18:46:41 <cyberpear> "all other code"  I'd suggest that test plugins and filter plugins should be allowed as BSD since those are jinja extensions and jinja is BSD
18:46:44 <felixfontein> why allow GPLv3+ compatible licenses for modules, when not allowing them for other non-code files?
18:46:52 <acozine> b) for the sake of ease/simplicity of explaining/enforcing
18:47:23 <abadger1999> felixfontein: I don't yet know what legal will find important about non-code files.
18:47:48 * acozine takes back her vote, since b) is not as simple as she originally thought
18:47:51 <aminvakil> acozine: i'm not sure, but doesn't this choice restricts users from adding their content?
18:47:51 <abadger1999> For instance, will they consider doc_fragments non-code?  Will they consider data files that are loaded by code to have different rules?
18:48:23 * cyberpear votes a)
18:49:00 <felixfontein> hmm
18:49:11 <abadger1999> cyberpear: Re: test and filter plugins: That's a change from the status quo.  I think that legal would allow it but I'd prefer to wait for legal to say "GPLv3 compatible licenses are allowable for all categories" and update it then.
18:49:17 <felixfontein> I wouldn't have expected that non-code files can be more complicated than code files, but it looks like they can...
18:50:15 <cyberpear> (providing newer jinja tests and filters in a collection is useful for compat w/ older distro versions, for example, just copying the relevant jinja code)
18:50:18 <abadger1999> yeah... Although, to be fair, it's mainly that non-code files are asked about less, so I'm less sure of what cornercases exist than with code.
18:51:10 <abadger1999> cyberpear: yeah.  but the work as a whole can be licensed GPLv3+ (there's a small wrapper that you have to put around them to make ansible load them)
18:52:33 <abadger1999> aminvakil: yes, choosing (b) does restrict what collection owners can add.  However, it is also the status quo (what the guidelines currently allow and prohibit)
18:52:41 <abadger1999> So it's not a new restriction.
18:53:23 <aminvakil> abadger1999: sorry if i wasn't clear enough, i meant if it's possible let's not just go with an easier choice that restricts users from adding their content
18:53:38 <felixfontein> I would like to have a), but I'd still vote for b) until we find out more from RH legal
18:53:57 <abadger1999> felixfontein or cyberpear : Do we have any things that fall into this category so far? (non-code files which are licensed gplv3 compatible)?
18:54:14 <tadeboro> DOes it really matter if we go with the stricter variant for now and relax it once we know it is safe to do so?
18:54:19 <felixfontein> and I'll soon submit a collection that will challenge this by having a data file with another license ;)
18:54:40 <felixfontein> abadger1999: included in Ansible? not that I know of
18:55:16 <felixfontein> tadeboro: I think that's currently the safer approach, as allowing something that turns out to be illegal isn't great :)
18:55:29 <abadger1999> Yeah, one that's not gplv3 compatible, right?
18:55:35 <abadger1999> Right.
18:55:38 <mariolenz> it looks like you can use gpl for non-code files, although it's probably not the best choice afair. actually, i think most people don't use a different license for their non-code files. so this discussion is a bit academic.
18:55:40 <mariolenz> even if they do, as long as it's compatible with gpl it should be fine. if a gpl compatible license is ok for code, it should also be ok for non-code.
18:55:42 <abadger1999> yeah, I agree with tadeboro too
18:55:54 <tadeboro> And none of the collections I reviewed for inclusion thus far had any non-code files.
18:56:24 <tadeboro> I am a bit pragmatic here: what abadger1999 proposed allows us to move on with the inclusions while we wait for the legal.
18:56:44 <felixfontein> abadger1999: it's a gplv3 compatible one
18:57:00 <abadger1999> Oh it's MPL v2.0 <nod>
18:57:41 <abadger1999> Cool.
18:57:45 <felixfontein> yep, and without the 'explicit incompatible' amendmend :)
18:57:52 <aminvakil> tadeboro: i guess it's good to discuss this matter here, as maybe even if the legal team approves the gpl comptabile licenses, there may be another reasons not to include them in ansible
18:57:55 <jillr> oh dear, did this meeting time change?  uh, hi!
18:58:04 <abadger1999> Hi jillr  :-)
18:58:09 <felixfontein> jillr: yes, it did (from last week on) :)
18:58:11 <felixfontein> #chair jillr
18:58:11 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cyberpear dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:58:16 <jillr> ah, I was out last week
18:59:23 <felixfontein> should we vote on the proposal? or defer this to next week?
19:00:02 <tadeboro> I suggest we vote.
19:00:33 <abadger1999> Okay... I have another thought.  I can't think of any reason, given past precedent, that legal will find that gplv3+ compatible for everything would be disallowed.  Restricting it to modules + module_utils is jsut to give the addded safety to us of the process boundary (which the GPL defintiely doesn't cross).
19:01:12 <abadger1999> So if people are comfortable with that, we could propose that all content ust be gplv3+ compatible rather than this mixture of gplv3+ compatible and gplv3+-only
19:02:08 <felixfontein> don't "regular" plugins need to be gplv3+ itself (and not just compatible)?
19:02:08 <cyberpear> I'd be happy w/ "compatible"
19:02:09 <tadeboro> Is it really OK for the inventory plugin to be licensed under Apache 2.0 for example?
19:02:20 <abadger1999> I would vote yes for either one of those directions.  But we'll need enough steering committee members to vote yes to pass the update so.... which one does everyone else prefer?
19:02:33 <cyberpear> maybe it's a good reason to move back to inventory scripts?
19:02:33 <tadeboro> Compatibility between GPL and Apache is only in one way IIRC.
19:03:01 <felixfontein> tadeboro: I think so to (but IANAL)
19:03:49 <tadeboro> felixfontein: I am pretty sure our meeting would be even longer if any one of us would be lawyer ;)
19:03:58 <felixfontein> I'd prefer to keep the strict GPLv3+ for non-module / non-module_utils plugins for now
19:04:23 <felixfontein> tadeboro: definitely likely :)
19:04:30 <abadger1999> tadeboro: From past information from legal, GPLv3+ compatible means that you can use GPLv3+ code and the compatibly licensed code together.  The work as a whole is considered to be under the GPLv3+ then (ie: when an end user runs it).  The ability to use this other license becomes important if they are distributed separately, or a portion of the code is removed for use in an entirely separate project.  In those cases, the
19:04:30 <abadger1999> code can be used under the compatible license instead of the GPL if they want
19:06:07 <abadger1999> Okay, if we're all okay with the strict-gpl for most things and gpl-compat for just modules and module_utils until legal weighs in, then I think the proposal as is is ready for a vote.
19:06:29 <tadeboro> Again, I would err or the safe side here. Our legal told me that "using Apache in GPL program is OK", "using GPL in apache program is no-go".
19:06:34 <samccann> cyb-clock-simulator sez we are 1 hr into the meeting and close to that on this topic
19:07:42 <felixfontein> VOTE: should we allow GPLv3-compatible licenses for everything (+1), or keep it safe and only allow them for modules and module_utils, and require GPLv3+ for everything else (-1)?
19:07:53 <felixfontein> -0.9 ;)
19:08:04 <abadger1999> felixfontein: and the concreate implementation is in my PR.
19:08:06 <tadeboro> Does that mean that if I do "import ansible.utils.foo" in my inventory plugins, my inventory cannot be licensed under apache 2? I do not know to be honest.
19:08:17 <tadeboro> -1
19:08:18 <abadger1999> https://github.com/ansible-collections/overview/pull/164/files
19:08:18 <cyberpear> +1
19:08:34 <abadger1999> -1
19:08:55 <dmsimard> I don't feel qualified to vote, licensing is hard :(
19:09:03 <abadger1999> Scratch what I said about concrete implementation.  I guess that would be the next vote)
19:09:11 <jillr> I want to defer to legal
19:09:33 <felixfontein> jillr: -1 is essentially "let's keep status quo until legal explicitly says +1 is ok"
19:09:33 * geerlingguy agrees with dmsimard + jillr
19:09:41 <acozine> -1
19:10:00 <jillr> felixfontein: that then, but I want it explicitly noted why I'm -1  :)
19:10:17 <jillr> in case of deposition, be on the record  ;)
19:10:22 <acozine> let's not roll out a brand new rule if there's a chance it will be squashed within weeks/months
19:11:48 <felixfontein> https://github.com/ansible-collections/overview/pull/164/files is a bit more flexible than the current rules (by allowing more licenses for module_utils and modules), but doesn't allow more for anything else
19:12:18 <felixfontein> this should be enough to allow hpe.nimble in, without allowing too much that RH legal might not allow
19:12:56 <abadger1999> Yep.
19:13:05 <abadger1999> Shall we vote on the proposal itself?
19:13:13 <tadeboro> Yes.
19:13:34 <felixfontein> VOTE: accept proposal https://github.com/ansible-collections/overview/pull/164/files
19:13:39 <abadger1999> if  you're on the steering committee, and you don't want to vote definitively to update or not update, please vote 0 so that we can make sure whether we've hit quorum.  (Wanting to defer to legal could be either -1 or 0..... -1 means, "I think we need to wait for legal to weigh in", 0 means, "I don't know the answer but I'm comfortable enough with what's being proposed that I think it's okay to go ahead without legal
19:13:39 <abadger1999> approval", 1 probably means, "I'm pretty sure the answer is that this is okay."
19:14:03 <tadeboro> +1
19:14:20 <felixfontein> +1
19:14:24 <andersson007_> +1
19:14:26 <abadger1999> +1  I think legal will be fine with this both because the licenses are GPL compatible and because we're shielded by the code for modules being run in a separate process
19:14:39 <gundalow> As Toshio
19:14:49 <samccann> abstaining cuz i'm clueless
19:15:00 <felixfontein> I would like GPLv3-compatible also for other plugins and other files, but not without an explicit OK from RH legal
19:15:07 <felixfontein> #chair
19:15:07 <zodbot> Current chairs: abadger1999 acozine aminvakil andersson007_ cyberpear dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:15:11 <acozine> 0
19:15:17 * samccann only steers a little blue sedan...mostly in the right lanes
19:15:19 <jillr> -1
19:15:54 * cyberpear re-reviewing
19:16:30 <cyberpear> +1, but I think eventually test and filter plugins should also be alowed flexibly licensed
19:16:34 <abadger1999> So far, we have +1:5, 0:1, -1:1   out of 11 steering committee members.
19:16:53 <abadger1999> Okay, that makes +1: 6
19:17:45 <abadger1999> If my ocunt is right, the vote succeeds.
19:18:01 <tadeboro> I counted the same.
19:18:12 <felixfontein> hmm, if the 4 remaining steering committee members vote -1, it would be pretty tight
19:18:39 <andersson007_> "silence is a sign of agreement"
19:19:03 <felixfontein> or not knowing what crazy stuff the others are coming up with ;)
19:19:10 <samccann> heh
19:19:26 <abadger1999> actually, just 3 remaining members.
19:19:57 <abadger1999> But yeah, it could be +6, -4, 0:1
19:19:58 <felixfontein> ah right. I missed the 0:1 ;)
19:20:00 <samccann> did steering committee decide what constitutes a quorum?
19:20:22 <abadger1999> zbr, cidrblock Do you want to vote on updating the licensing criteria?
19:21:05 <abadger1999> Not officially, but I did mention in one of the video chat meetings that we should make sure that more people had oted for it than could possibly vote against it.
19:21:45 <tadeboro> IIRC, we said that the thing is accepted once there is no theoretical way of changing the majority outcome.
19:22:10 <abadger1999> Yeah, so we have reached that level.
19:22:14 <tadeboro> So in this case, the "worst case scenario" is +6, 0, -4
19:22:41 <felixfontein> jillr: do you agree with this? (since you voted -1)
19:22:57 <jillr> felixfontein: yep
19:23:16 <abadger1999> Cool
19:23:17 <jillr> vaya con queso!
19:23:23 <felixfontein> #agreed https://github.com/ansible-collections/overview/pull/164/files should be merged
19:23:54 <felixfontein> ok, since we're already 83 minutes into this meeting, I guess we should continue with open floor :)
19:24:05 <felixfontein> or is there anything else that someone considers urgent?
19:24:10 <felixfontein> #topic Open Floor
19:24:38 <gundalow> Nothing else from me
19:26:20 <felixfontein> for next week, we have a proposal to stop suggestiing Python 2.6 support (https://github.com/ansible-collections/overview/pull/165, https://github.com/ansible-community/community-topics/issues/6)
19:26:21 <github-linkbot> https://github.com/ansible-collections/overview/pull/165, | open, created 2021-04-07T16:50:26Z by abadger: RHEL6 went EOL on November 30, 2020.
19:26:42 <felixfontein> and eventually we have to continue the 'new content for c.g/c.n' discussion (https://github.com/ansible-community/community-topics/issues/4)
19:26:49 <abadger1999> <nod>
19:27:35 <felixfontein> everyone can already start thinking (again) about these ;)
19:27:57 <abadger1999> yeah.  And discussion can go on inside of the tickets before the meeting :-)
19:28:22 <tadeboro> Do we close the issues we "resolved"?
19:28:33 <tadeboro> I am looking at https://github.com/ansible-community/community-topics/issues/3
19:29:01 <felixfontein> tadeboro: I'll resolve it once I've 'implemented' it (i.e. put these rules somewhere)
19:29:11 <abadger1999> Sounds like a good plan to me
19:29:49 <tadeboro> I was just about to ask where should this info go now.
19:29:55 <felixfontein> should we keep https://github.com/ansible-community/community-topics/issues/2 open or close it? hpe.nimble also has docs fragments with Apache license I think, so it's only 99% resolved
19:30:05 <felixfontein> #endmeeting