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