19:02:12 <bcoca> #startmeeting ansible public core irc meeting 19:02:12 <zodbot> Meeting started Tue May 14 19:02:12 2019 UTC. 19:02:12 <zodbot> This meeting is logged and archived in a public location. 19:02:12 <zodbot> The chair is bcoca. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:02:12 <zodbot> The meeting name has been set to 'ansible_public_core_irc_meeting' 19:02:18 <jillr> o/ 19:02:26 <nitzmahone> o/ 19:02:44 <bcoca> topic https://github.com/ansible/community/issues/456#issuecomment-492012045 licensing 19:02:54 <bcoca> #topic https://github.com/ansible/community/issues/456#issuecomment-492012045 licensing 19:03:00 * bcoca is having one of those days 19:03:01 * nitzmahone runs 19:04:32 <bcoca> @nalsaber ? 19:04:35 <nalsaber> yes 19:05:04 <bcoca> your request/show 19:05:06 <nalsaber> Can you please let me know if we can have the license exception? 19:05:20 <bcoca> is the code copied from existing lib already gpl? 19:05:28 <bcoca> are you sole author? 19:05:44 <nalsaber> Oracle is the sole author 19:06:03 <bcoca> fyi, we are also having issues with the existing files, being revertd/not for 2.8 since they were dual licensed 19:06:30 <bcoca> what restricts you from pushing as bsd for module_utils? 19:06:34 <nalsaber> I can change all files to GPL v3 19:06:49 <bcoca> well, all other files SHOULD be gpl3 19:07:03 <bcoca> jsut module_utils is kept as bsd to allow 3rd party distribution 19:07:09 <nalsaber> yes I mean without dual license 19:07:15 <bcoca> with least ammount of restriction 19:07:26 <nalsaber> Our legal team has given us permission to use GPL it will be hard to get approval for BSD 19:07:36 <bcoca> even just for that single file? 19:07:45 <bcoca> so this is a corp issue not a licensing from existing lib? 19:08:46 <nalsaber> I have to verify if there is any issues from the existing lib but it is mainly a corp issue 19:09:10 <bcoca> any one else have questions? comments? 19:09:51 <nalsaber> I changed the license as you requested in this PR: https://github.com/ansible/ansible/pull/56410 19:10:01 <sdoran> Are abadger1999 and mattclay around? 19:10:21 * cyberpear in the peanut gallery thinks it should be BSD 19:10:36 <sdoran> They'd be the only other ones that may have input. 19:11:35 <abadger1999> nalsaber: Thanks, making it non-dual licensed makes our decisions simpler :-) 19:11:42 <bcoca> well, core team voted a while back to allow exceptions but for diff reasons, not corp inflexibility but 'existing lib with many authors and infeasability for change' 19:12:12 <abadger1999> The question around GPL and module_utils is a policy decision so we need to discuss that, I think. 19:12:25 <bcoca> why we are here 19:12:59 <bcoca> personally im fine with gpl in module_utils, but that has been a minority view for most of the project 19:13:08 <nitzmahone> Going forward I think the bar for exceptions should be much higher (ie, ship a collection if you don't like our terms) 19:13:41 <bcoca> i agree with that, but collections are not 'ready now' 19:13:44 <nitzmahone> Right 19:13:54 <nitzmahone> Just saying it's less a problem going forward IMO 19:14:05 <bcoca> was just trying to say, this does not fall under previous exception, so we need to vote in a new exception 19:14:10 <bcoca> nitzmahone: agreed 19:16:12 <maxamillion> .hello2 19:16:13 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com> 19:16:18 * maxamillion is super late 19:17:05 * alongchamps o/ 19:17:08 <mattclay> Sorry, I'm here now. 19:17:17 <mattclay> Too many conversations at once. 19:17:27 * mattclay reads scrollback 19:17:31 <maxamillion> cyberpear: not sure if I should troll the peanut gallery and throw a "but MIT!" in the mix but that seems not productive .... >.> 19:18:41 <bcoca> any pros/cons from anyone else? 19:18:52 <bcoca> peanut gallery can chime in 19:19:28 <mattclay> Any exceptions we make will slightly complicate any automated license checking we do -- but for a single file that's a very minor issue. 19:19:35 <maxamillion> I think if a module_util is in service of a module or set of modules from a single vendor and that vendor prefers GPL over BSD, that should be mostly fine ... however, I think the "general use" module_utils should always be BSD so we don't accidentally limit the use of them as a by product of the license choice 19:19:44 <flowerysong> The code is targeted at a single vendor, so I don't think it's a big deal to have a license variance. 19:20:37 <cyberpear> I'm in favor of a concrete policy with rare exceptions 19:20:53 <alongchamps> +1 with cyberpear for the sake of simplicity 19:21:06 <cyberpear> so what maxamillion says about 'single vendor use who prefers GPL' is probably fine 19:21:43 <bcoca> well, but is that what project users prefer? 19:22:06 <bcoca> other authors that want to leverage the code and not be subject to viral license (main reason BSD was adopted for module_utils) 19:22:40 * cyberpear prefers liberal licenses in most cases 19:22:54 <bcoca> well, main project is gpl3 19:23:18 <bcoca> the issue with module_utils was always aobut 3rd party independant distribution (all modules in ansible are gpl) 19:24:01 <nalsaber> boca: exactly this is the main issue for legal 19:24:21 <agaffney> is the GPL "viral" even in the case of runtime "linking", such as with importing python modules? 19:24:34 <bcoca> agaffney: afaik, yes 19:24:38 <bcoca> but ANAL 19:24:43 <bcoca> IANAL 19:24:46 <jborean93> depends on who you ask 19:24:55 <jborean93> I've had 2 legal people give different opinions 19:25:18 <bcoca> like all legal opinions, the one that matters is the judge's opinion 19:25:50 <cyberpear> the benefit of BSD for module_utils is that no one is likely to argue that the GPL applies for runtime (or otherwise) in that case 19:26:32 <bcoca> original gpl was mostly written to deal with compiled code, lot of the language reflects that, v3 has updated a lot but not clarified these issue to the way 'non legal minds' have agreed on what it means .. and if 'legal minds' dont agree .... 19:27:47 <abadger1999> agaffney: Depends on the lawyer you ask and the phase of the moon when you do. 19:28:18 <abadger1999> red hat's lawyers said it was not viral at one time. But we'd want to ask them again if we were planning on depending on that. 19:28:36 <abadger1999> (many years ago so the make up of the legal team has changed) 19:29:26 <jborean93> yea, just last week I got the 2 different opinions. Who knows what would happen today :( 19:29:56 <nitzmahone> That's where you keep the paper trail for the most convenient option and go with it ;) 19:30:23 <agaffney> "but you said..." 19:31:10 <bcoca> k, before we diverge more, let me try to sumarize what i get as pros/cons 19:31:18 <bcoca> pros: we get shared oci stuff for oracle cloud 19:31:31 <bcoca> - others might want to contribute if they can make shared code gpl 19:31:37 <bcoca> cons: more complex license handling 19:32:07 <bcoca> - others might not want to write and districute modules since shared code is gpl 19:32:15 <bcoca> ^ did i miss anything? 19:33:59 <maxamillion> I don't think so 19:35:56 <bcoca> last chance to add your arguments to this topic 19:37:04 <bcoca> so i see 3 options a) allow any file to be gpl on module_utils b) only allow tech/service specific files to be gpl in module_utils c) dont make new exceptions 19:37:54 <bcoca> not sure if we need more narrow def for b) .. since basically that could cover everything outside of common/ 19:39:21 <bcoca> k, if no more comments, lets vote 19:39:23 <jillr> I feel like being more explicit/narrow in b) couldn't hurt, and very well could save problems down the road. 19:39:41 <maxamillion> jillr: +1 19:39:54 * bcoca suspects jillr shows at shop at 8.01 pm to buy groceries 19:40:10 <jillr> 9:30 last night - what? :) 19:40:16 <bcoca> jillr, maxamillion any proposals on the language 19:40:19 <bcoca> ? 19:40:21 <maxamillion> I'm alright with exceptions for explicit use cases with narrow scope but don't want to open the flood gates and accidental paint ourselves and the project into a corner 19:40:29 <jillr> still chewing on that though, hence slow typing 19:41:38 <nitzmahone> "thou shalt not GPL unless explicit approval has been granted by the core team for shared code that applies narrowly to a specific technology stack" 19:41:53 <maxamillion> "Code contributed to module_utils is BSD licenced by default, however GPLv3 exceptions can be granted for explicit purposes in service of narrow scope modules (e.g. - service provider or vendor that requires GPL)" 19:42:05 <jillr> nitzmahone++ 19:42:06 <zodbot> jillr: Karma for nitzmahone changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:42:32 <nitzmahone> hey, when did zodbot get karma support? 19:42:48 <bcoca> so to recap a) allow any file to be gpl on module_utils b) what nitz said c) nope 19:43:14 <bcoca> and if b, we then need to vote on the specific case presented today 19:43:17 <jborean93> -1 for a, 0 for b, +1 for c 19:43:32 <bcoca> a+1, b 0, c 0 19:43:47 <nitzmahone> +1 for b (and in 2.9+ there'd better be a damn good reason) 19:43:54 <sivel> I got way too distracted elsewhere... 19:44:05 <jillr> a) -1 b) +1 c) +0.25 19:44:11 <cyberpear> b 19:44:22 <sivel> +1 for b 19:44:39 <sivel> I thought that was the rule anyway 19:44:44 <maxamillion> +1 for b 19:44:48 <sivel> but I guess we didn't document well enough 19:44:49 <sdoran> +1 for b 19:45:05 <bcoca> so b wins by large margin 19:45:10 <maxamillion> sivel: yeah, I think that's been the rule "in effect" but it was never written 19:45:13 <bcoca> #action nitzmahone to update license docs, ping acozine 19:45:26 <maxamillion> nitzmahone: +1 to "in 2.9+ there'd better be a damn good reason" 19:45:29 <bcoca> maxamillion: we did have it written but was unclear 19:45:32 <maxamillion> nitzmahone++ 19:45:32 <zodbot> maxamillion: Karma for nitzmahone changed to 2 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 19:45:33 <acozine> bcoca: you rang? 19:45:36 <maxamillion> bcoca: ahhh ok 19:45:44 <bcoca> ^ acozine nitzmahone has text for the license stuff for you 19:46:01 <acozine> excellent 19:46:05 <bcoca> ok, 2nd vote, do we allow exception (under b just approved) for the file at hand? 19:46:09 <bcoca> +1 19:46:17 <jillr> +1 19:46:44 <bcoca> ^ moar votes needed 19:46:46 <jborean93> this is the Oracle module_util rights? 19:46:46 <nitzmahone> yes 19:46:47 <nitzmahone> +1 19:46:50 <maxamillion> +1 19:46:52 <sivel> there too much context missing for me to answer. I suck and wasn't paying attention 19:47:01 <nitzmahone> sivel: just nod and smile ;) 19:47:02 <bcoca> +1 to sivel sucking 19:47:06 <sivel> lol 19:47:09 <maxamillion> uggghhhh sivel ... *jeeeeeez* 19:47:16 <nitzmahone> bcoca_hr_violations++ 19:47:20 <maxamillion> :) 19:47:31 <agaffney> sivel: just +1 it. everybody else is doing it 19:47:31 <sivel> I was having too much fun with a crazy vault issue 19:47:33 <maxamillion> stand back everyone, we are professionals 19:48:07 <sivel> I think there are enough votes without me :) 19:48:20 <sivel> jborean93: as far as I can tell, yes. 19:48:25 <bcoca> k, approved, nalsaber you got green light 19:48:37 <nalsaber> Great thx guy 19:48:38 <bcoca> #topic https://github.com/ansible/proposals/issues/105 19:48:54 <nalsaber> Can we also back port the changes to 2.8? 19:49:08 <bcoca> that is a @abadger1999 question 19:49:24 <bcoca> ^ he is release manager 19:49:35 <abadger1999> nalsaber: What is the change precisely? 19:49:36 <bcoca> flowerysong ? 19:49:49 <sivel> I don't really like the name "denotify" but over all I'd be ok with adding such functionality 19:49:53 <bcoca> nalsaber, abadger1999 #ansible-devel, we are on other topic here now 19:50:07 <bcoca> sivel: i just find adding a conditional to the handler as a better option 19:50:25 <bcoca> when: allgood, set_fact: allgood= False 19:50:26 <sivel> bcoca: hrm, true. I already do that exact thing 19:50:52 <flowerysong> There's been some public interest in this functionality and a couple of people within UMich have asked me about it. There's an updated POC at https://github.com/ansible/ansible/pull/56070 that uses 'cancel' instead of denotify. 19:50:53 <nitzmahone> The only corner case I can think of there is multiple triggers- do we have to refcount the thing, or does it stay a boolean and one "denotify" (or some other name please ;) ) globally untrigger it regardless of how many times it was notified? 19:51:14 <agaffney> does the example implementation properly support denotifying a handler when something else still needs to notify it? 19:51:18 <agaffney> what nitzmahone said ^^ 19:51:25 <sivel> I don't like that in the case of the proposal, that `denotify` works like `notify`, where it is dependent on a task changing 19:51:27 <felixfontein> I would expect that denotify cancels all of them 19:51:30 <nitzmahone> I'd personally prefer the conditional as well, since it allows arbitrarily complex behavior as necessary 19:51:43 <bcoca> also note that a handler can be triggered at dif f phases, does this 'denotify' per phase or globally? 19:51:50 <bcoca> i.e pre_tasks/roles/tasks/post_tasks 19:52:05 <sivel> bcoca and nitz have swayed me. due to my lack of thought previously 19:52:08 <bcoca> when: notified - denotified > 0 19:52:18 <jborean93> we could have it as a specific task and we use when conditionals 19:52:19 <nitzmahone> I'd assume it doesn't completely disable the handler, so it'd basically just reset the notified state as it was 19:52:23 <agaffney> there seem to be a few dragons here 19:52:35 <bcoca> a few 19:52:36 <sivel> I feel like a conditional on the handler is the way forward 19:52:50 <bcoca> @flowerysong ?? 19:52:52 <flowerysong> It uses the same rules as notifying a handler initially, so if you cancel a handler it doesn't matter how many times it was notified previously or if it was notified using that particular name. 19:53:01 <nitzmahone> Yeah, the potential trip hazards seem worse than just making it conditional 19:53:44 <nitzmahone> I could get behind a simple `meta: reset_handler` or something 19:53:51 <bcoca> i can even see 'notify intermediate hanlder that decides' 19:54:06 <agaffney> nitzmahone: that would be too large of a hammer if you can't choose which handlers 19:54:14 <bcoca> nitzmahone: meta is 'run once' 19:54:21 <bcoca> also would need parameter for specific handler 19:54:22 <agaffney> and 'meta' doesn't support args, afaik 19:54:24 <sivel> Pending some new idea that really changes my mind, I feel we are likely ready to vote 19:54:28 <bcoca> (s) 19:54:44 <nitzmahone> agaffney: yeah, I was assuming we'd pass a name/list 19:54:59 <nitzmahone> but yeah, that gets ugly with meta 19:58:01 <bcoca> a) yes, b) no, c) maybe, but needs diff approach 19:58:04 <bcoca> a+1 19:58:11 <bcoca> sorry, b+1 19:58:11 <jborean93> c+1 19:58:22 <agaffney> c+1 19:58:24 <nitzmahone> b +0.5, c+0.5 19:58:49 <sivel> +1 b 19:58:53 <Pilou> b+1 (not convinced by the examples) 19:59:22 <agaffney> actually, b +0.5 and c +0.5 19:59:47 * nitzmahone -> WWG 20:00:05 <bcoca> so 0, 4, 2 on my count 20:00:28 <bcoca> so i think its possible to sway some of us if good implementation is given, but for now i think conditinals can handle most cases better than what is proposed 20:00:43 <cyberpear> +1 c 20:00:53 <maxamillion> +1 c 20:01:12 <bcoca> so tied at this point 20:01:14 <maxamillion> I like the idea of the feature but there's some more bikeshedding to be done around implementation decisions 20:01:44 <bcoca> i would not call that bikeshedding, since those will have real impact and importance 20:01:55 <sdoran> b +1 20:01:58 <bcoca> fighting on the feature name .. yeah, totally bikeshed 20:02:04 <bcoca> 0,5,4 20:03:09 <bcoca> flowerysong: so sorry, seems like a strong no to current implementation, but some are willing to revise proposal with diff approach 20:03:25 <flowerysong> Ah, well. So life goes. 20:03:26 <bcoca> Pilou: examples for or against? 20:03:51 <sdoran> No need to be sorry. The idea has merit, it's just fleshing it out fully and entirely gets complicated. 20:04:16 <bcoca> flowerysong: nothing risked, nothing gained 20:04:35 <bcoca> i understand wanting this, i just think we can already do same/better with current facilities 20:06:46 <bcoca> #endmeeting