15:01:05 <bcoca> #startmeeting ansible  public core irc meeting
15:01:05 <zodbot> Meeting started Thu May 30 15:01:05 2019 UTC.
15:01:05 <zodbot> This meeting is logged and archived in a public location.
15:01:05 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:05 <zodbot> The meeting name has been set to 'ansible_public_core_irc_meeting'
15:01:25 <sdoran> o/
15:01:25 <shertel> hello
15:01:27 <bcoca> @piou
15:01:30 <bcoca> pilou
15:01:37 <mkrizek> o/
15:02:02 <alongchamps> o/
15:02:06 <bcoca> k, going to skip that topic for another meeting, i still dont think im reading that right
15:02:15 <albertom> o/
15:02:22 <bcoca> #topic https://github.com/ansible/ansible/pull/56891
15:02:31 <bcoca> ^ albertom?
15:03:03 <albertom> that one is simple, it adds two args that are missing to tower_workflow_template
15:03:15 <bcoca> but what do you want to discuss about it here?
15:03:16 <albertom> which funny enough they are present in tower_job_template
15:03:58 <albertom> ah it has been reviewed so i was expecting to have another pair of eyes on it to have it merged
15:04:33 <bcoca> k, mostly we leave that to tower team
15:05:50 <bcoca> i've pinged them, not much else we can do
15:06:03 <albertom> oh is there anyway to ping them? with core is easier with this meetings :)
15:06:24 <bcoca> #ansible-awx would be my best bet
15:06:35 <albertom> okay
15:06:37 <albertom> 10x !
15:06:52 <bcoca> #topic https://github.com/ansible/ansible/pull/53438
15:07:01 <bcoca> ^ allow bsd3 clause vs bsd2 clause we normally use
15:07:09 <rajeevarakkal> Hi becoca
15:07:09 <bcoca> @sajna?
15:07:15 <Sajna> Hi
15:07:47 <bcoca> not sure something we can answer here, at least i dont feel qualified
15:08:09 <rajeevarakkal> We have changed to BSD latest BSD3
15:08:18 <rajeevarakkal> is that fine right
15:08:22 <bcoca> idk
15:08:36 <bcoca> not a lawyer, not sure if we want to manage X BSD licences
15:08:44 <Sajna> The ansible guideline just says 'licensed under BSD'
15:08:52 <rajeevarakkal> right
15:08:57 <cyberpear> sounds like someone should ask a lawyer if it matters which BSD license is used
15:09:03 <bcoca> and iirc we point to the specific one later on
15:09:08 <cyberpear> bcoca: makes a good point about having a variety of licenses
15:09:42 <nitzmahone> We're set up to do that, but need to make sure the license still behaves in a compatible fashion, which requires legal to ok it
15:10:12 <cyberpear> i.e., "is BSD-3-Clause compatible w/ GPLv3+?"
15:10:12 <nitzmahone> (licenses dir and short links to it)
15:10:21 <nitzmahone> Exactly
15:10:50 <bcoca> which i would say 'yes', but IANAL
15:10:59 <bcoca> and im not going to make a legal call
15:11:17 <rajeevarakkal> As per our lawers, BSD licenses are compatible with GPL3.. but am not right person to coment on
15:11:29 <nitzmahone> bcoca: wimp ;)
15:11:41 <bcoca> its also not gpl3 compat that worries me, its reason we chose BSD 2 clause and not other forms
15:11:44 <maxamillion> .hell2
15:11:47 <maxamillion> errr
15:11:48 <maxamillion> .hello2
15:11:50 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
15:11:53 <nitzmahone> Our lawyers aren't going to trust yours, methinks :)
15:11:54 <maxamillion> sorry I'm late
15:12:07 <cyberpear> I think Red Hat is generally fine w/ BSD-3-Clause, as that's what was recently chosen for -security-guide: https://github.com/ComplianceAsCode/content/blob/master/LICENSE -- the specific question is GPLv3+ compat
15:12:15 <nitzmahone> Exactly
15:12:25 <nitzmahone> That's the thing we need the ok on
15:12:41 <rajeevarakkal> nitzmahone: that fine.. What are the options for us now?
15:12:43 <sivel> gnu.org seems to state that the 3-clause is not bad, but not exactly good either. https://www.gnu.org/licenses/license-list.en.html#ModifiedBSD
15:13:11 <bcoca> https://docs.ansible.com/ansible/latest/community/contributor_license_agreement.html#contributor-license-agreement <= aslo, does this just allow us to relicense once in repo?
15:13:48 <nitzmahone> Doubtful
15:14:03 <cyberpear> "pursuant to the license of the project." IANAL
15:14:18 <cyberpear> I'd never seen that page before, though
15:14:26 <bcoca> me either, seems to have been there for a while
15:14:29 <nitzmahone> Especially since it's not an explicit action
15:14:31 <bcoca> just stumbled on it
15:14:48 <nitzmahone> Even less teeth than a click through CLA
15:14:53 <cyberpear> It'd have more weight in my mind if it were a checkbox in the PR template, not checked by  default
15:15:12 <nitzmahone> Interesting idea now that such things are possible...
15:15:32 <bcoca> imho, by default i think we shoudl reject any new licensing we don't alreayd support
15:15:49 <bcoca> and if it is unclear which BSD license it is, that is a docs bug
15:15:56 <rajeevarakkal> right
15:15:59 <sivel> everyone loves a loophole :)
15:16:01 <nitzmahone> That's probably gonna have to be the deal for now. If you want to ship code in our project, you have to use one of our approved license forms
15:16:15 <rajeevarakkal> now i don't know how i will approach my legal again
15:16:31 <Sajna> @bcoca yes it's doc bug
15:16:53 <sivel> I am +1 for stating it's 2-clause BSD license, and not accepting new licenses
15:17:03 <bcoca> rajeevarakkal: if it is any consolation, yours seems to respond quite quickly .. not something i'm used to
15:17:15 <sivel> We can't spend this much time every week talking about accepting new licenses
15:17:20 <bcoca> agreed
15:18:28 <rajeevarakkal> BSD is the one we discussed last time.. We got permission for that as well.. in ansible doc we havn't got clue about BSD2 specific requiremens
15:18:57 <nitzmahone> We'll try to clarify that for the future.
15:19:01 <rajeevarakkal> we were not trying to introduce a new license rather trying to adhere to what we discussed last time
15:19:16 <cyberpear> likely a good idea to use SPDX license identifiers in most places to be specific
15:19:19 <bcoca> understood, as i said , our docs are unclear, we have to fix that
15:19:34 <bcoca> most others just copied the license from the existing files
15:19:51 <rajeevarakkal> bcoca: i will try my luck once again with our legal
15:19:53 <bcoca> we didnt think about someone just reading docs and using A BSD license vs, THE BSD license we have
15:20:03 <bcoca> rajeevarakkal: i'll make sure we update the docs
15:20:17 <bcoca> #action bcoca to get docs update to be specific on BSD license
15:20:21 <rajeevarakkal> Thanks bcoca :) thats cool
15:21:04 <rajeevarakkal> shall we wait till you get clarification whether BSD3 is fine? meantime i will check with our legal we can set back to BSD 2 as well
15:21:34 <bcoca> i'll check, but cannot promisse a response in time to make 2.9
15:21:46 <bcoca> #action bcoca to check with legal if bsd3 'is fine'
15:21:56 <rajeevarakkal> okies.. no issues
15:22:03 <bcoca> ^ i also need to check with team as implications might be diff for project
15:23:14 <sivel> I think at this point however, we're saying that only 2-clause BSD is acceptable. So we may not get a response back soon on any other licenses
15:23:19 <nitzmahone> Yep
15:23:31 <shertel> +1
15:23:40 <rajeevarakkal> right ..thanks all :)
15:23:41 <sivel> I am leaning towards not even contacting legal at this time
15:23:45 <nitzmahone> Your legal team appears more responsive and/or less busy than ours :)
15:24:12 <bcoca> i mean, im personally fine with the 3rd clause 'cannot use author to endorse/prmote'
15:24:35 <bcoca> but i really dont want to have a collection of licenses we support
15:25:13 <bcoca> i enjoy technical problems ... legal ones ... not as much
15:25:32 <nitzmahone> ... and then? ;)
15:25:56 <cyberpear> rabbit hole: It's BSD, so theoretically could we could add the third clause to all existing BSD code and make 3-clause standard?
15:25:56 <bcoca> k, moving on
15:26:02 <bcoca> #open floor
15:26:17 <bcoca> #topic open floor
15:27:14 <bcoca> cyberpear: im not a fan of having to relicense all existing bsd2c files ...
15:27:45 <cyberpear> was more of a theoretical... I'm not in favor either
15:28:26 <cyberpear> topic: boolean vars deprecation warning
15:28:46 <bcoca> #topic boolean vars deprecation warning
15:29:14 <cyberpear> This can be squashed today by opting-in to the new behavior... there has been activity on the bug report of folks complaining of having to tell all the consumers of their role to opt-in to the new default to squash the warning
15:29:16 * cyberpear looks for the bug
15:29:46 <sivel> I looked into a potential "fix" to limit the warning, but in the end, it just didn't make sense. In the end it is just a warning
15:30:07 <sivel> It's definitely a hard thing to explain
15:30:35 <cyberpear> #53428
15:30:44 <cyberpear> https://github.com/ansible/ansible/issues/53428
15:30:57 <sivel> The code we are removing had some very weird side effects, and it's hard to properly add logic that addresses the weird side effects
15:31:22 <sivel> and fwiw, I locked it because I didn't want that issue to get out of control
15:31:28 <cyberpear> The complaint is that even if my variable is a pure bool, not a string, I still get the bool warning.
15:31:43 <cyberpear> unless explicitly doing `| bool`
15:31:55 <sivel> cyberpear: but think of this, if the var can be configured by a user, and they are providing it from -e on the CLI like my_var=false
15:32:03 <sivel> it's more robust to use |bool anyway
15:32:40 <sivel> the way the code works that we are removing, could have made that behavior inconsistent when my_var=false and my_var is a string "false"
15:32:47 <sivel> when: my_var
15:32:48 <sivel> and
15:32:55 <sivel> when: not my_var then behave differently
15:32:57 <cyberpear> I fully understand the implications...
15:33:03 <cyberpear> would a PR be accepted to only display the warning if a non-bool is passed?
15:33:22 <cyberpear> (I won't be implementing it, but I'd like to update the ticket.)
15:33:44 <shertel> I was looking at this too. The warning is kind of confusing. I wrote this https://gist.github.com/s-hertel/e2b65ee2c4b23426e461dbda4306bf6b but not sure if it's quite right.
15:33:59 <cyberpear> I'd propose an update to the ticket: "core team has no interest in squashing this warning, but a PR would be accepted to squash it in cases where a pure boolean is passed in"
15:35:00 <sivel> shertel: I feel like that makes too many extra template calls that could cause a performance issue
15:35:39 <shertel> Yes, that's why I haven't made a PR. It does make the behavior reflect what I think should happen.
15:35:59 <shertel> there was another issue about this that I was looking at... maybe it's a duplicate of the closed one cyberpear linked.
15:36:02 * shertel looks for it
15:36:16 <sivel> I think it would be nice if we could clarify things further. Otherwise I wouldn't have looked into it
15:36:32 <sivel> but I am also ok with the warning staying as is, and just have people use |bool
15:36:36 <cyberpear> okay, so "core team has no interest in squashing this warning as doing so would have an undue performance impact"?
15:36:41 <shertel> ah, you commented on it :-) https://github.com/ansible/ansible/issues/56830
15:36:58 <sivel> and fwiw, we are in a disagreement with the ansible-lint rule stating you should just use `when: foo`
15:37:07 <sivel> that is a topic for another time though
15:37:20 <bcoca> many disagreements with linting tools here ...
15:37:58 <shertel> cyberpear I'm interested in squashing the warning. sivel had a suggestion here https://github.com/ansible/ansible/issues/56830#issuecomment-497027051
15:38:56 <sivel> we effectively regressed on that when delimiters bug
15:39:10 <sivel> since we re-changed the order
15:39:13 <shertel> yep
15:39:57 <cyberpear> It makes sense to me to only display the warning where behavior will actually change in the future... if I `when: myvar`after the default changes, I won't get this warning.  I shouldn't today either when I'm passing a pure bool since there will be no behavior change.
15:40:44 <cyberpear> so 2 questions: 1. Is core team willing to fix it?  2. If not, would a PR be accepted from the community?
15:41:26 <sivel> any warning that causes us to spend too much time triaging issues related to it, or discussing it, probably could use some tweaking
15:41:41 <sivel> I cannot commit to someone from the core team fixing it, but someone may
15:41:43 <shertel> I'd try to fix it. I would also be in favor of 2.
15:42:14 <cyberpear> (My personal interest here is that w/o a fix, I'll have to tell end-users of the ansible-lockdown roles to explicitly opt-in to the new behavior, but I can't spend the time to actually fix it myself.)
15:44:09 <sivel> or to ignore the warning. People do seem to get too attached to the fact that they must address warnings
15:44:36 <cyberpear> indeed
15:46:50 <sivel> but in short, we would potentially accept a PR to make the warning more specific, or to clarify it further
15:47:16 <sivel> it would just depend on implications of the change and the specific implementation
15:47:42 <sivel> Ok.  I'm going to end the meeting if no one has anything further
15:47:56 <bcoca> #endmeeting