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