20:02:42 <ttx> #startmeeting tc
20:02:43 <openstack> Meeting started Tue Apr  9 20:02:42 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:46 <openstack> The meeting name has been set to 'tc'
20:03:03 <ttx> Before we dive into licensing subtleties... Last minute chance to opt out of the TC members dinner on Wednesday, April 17, 6:30pm at Olympic Provisions NW
20:03:15 <ttx> I know sdake can't join us... that would make 14 of us.
20:03:37 <markmc> that's a good crowd :)
20:03:50 <ttx> Anyone up to call them for booking for 14 ? Will be better if they have a US phone number on the registration :)
20:04:02 <ttx> #link http://www.olympicprovisions.com/northwest/reservations/
20:04:10 <jgriffith> ttx: I can call them
20:04:17 <annegentle> or I an
20:04:18 <ttx> jgriffith: thanks!
20:04:19 <annegentle> can even
20:04:40 <ttx> annegentle, jgriffith: just make sure one of you does it :)
20:04:42 <jgriffith> ttx: what time Pacific did we settle on?
20:04:56 <ttx> Wednesday, April 17, 6:30pm
20:05:01 <jgriffith> K.. doing it now
20:05:10 <ttx> #topic Discussion: Policy on use of GPL libraries
20:05:15 <annegentle> thanks jgriffith
20:05:15 <ttx> jgriffith: let us know if it fails :)
20:05:20 <ttx> markmc: care to introduce this one ?
20:05:26 <markmc> I guess I'll recap the background to start
20:05:41 <markmc> so, sdague noticed that cinder was using an AGPL library - rtslib
20:05:48 <markmc> it's not anymore, so that's a non-issue now
20:06:11 <markmc> but it did raise the question of what process we use for looking at the licensing of new dependencies
20:06:38 <markmc> especially given our bylaws statement about that the project must be distributable under the apache license
20:07:09 <ttx> will the central dependency process give us a sufficient barrier to entry so that we can add some validation process ?
20:07:10 <markmc> so, it's a question of process
20:07:11 <fontana> markmc: the bylaws don't say that exactly :-)
20:07:28 <markmc> fontana, ok :)
20:07:31 <ttx> markmc: see what you get when you invite lawyers :P
20:07:35 <markmc> hehe
20:07:37 <fontana> sorry
20:07:47 * fontana will try to restrain himself
20:07:49 <mikal> Morning
20:07:56 <gabrielhurley> it's also something that core reviewers/PTLs just need to be aware of
20:07:58 <markmc> ttx, the dependency process only enforces the checks we ask reviewers to enforce
20:08:18 <markmc> IMHO, it comes down to most permissive license are fine
20:08:20 <ttx> markmc: right, but at least we can insert more process than compared to, say, a mailing-list post
20:08:28 <markmc> ttx, absolutely
20:08:36 <gabrielhurley> yeah, it's really only an issue for GPL/AGPL/LGPL licenses (or esoteric ones)
20:08:38 <ttx> which was done about 20% of the time anyway
20:08:51 <markmc> but in the specific case of GPL/AGPL and maybe other copyleft licenses, we need to have a rule or a process
20:09:02 <markmc> and the more fontana explains the nuances
20:09:03 <fontana> I have noticed that OpenStack projects use quite a lot of LGPL dependencies
20:09:17 <markmc> I think we actually need a process to look at each case
20:09:28 <jgriffith> dependecies are fine but inclusion is sticky IMO
20:09:37 <gabrielhurley> that sounds like exactly the sort of the a Technical Committee would be responsible for... ;-)
20:09:42 <gabrielhurley> *thing
20:09:50 <markmc> gabrielhurley, right, exactly
20:10:01 <markmc> but do any of us want to make licensing calls on our own?
20:10:05 <ttx> gabrielhurley: sounds boring. Did we sign up to do boring ? :)
20:10:11 <markmc> or do we want the support of e.g. the Legal Affairs Committee
20:10:17 <dhellmann> new dependencies now need to go through the requirements list project, could a license check be part of that review process
20:10:23 <gabrielhurley> I'll make those decisions. unilaterally. because I can. ;-)
20:10:25 <markmc> dhellmann, absolutely
20:10:42 <fontana> I think it is important to understand something about the Legal Affairs Committee
20:10:52 <dhellmann> so at least there's a point where the review can happen, and every ptl (or core team) doesn't have to worry about it
20:10:55 <dolphm_> dwcramer: +1
20:11:01 <dolphm_> dhellmann: *
20:11:19 <mikal> fontana: explain away
20:11:23 <markmc> yeah
20:11:26 * markmc is more or less done
20:11:29 <gabrielhurley> dhellmann: point for inserting review: +1, PTLs/core reviewers *not* worrying about: -1
20:11:39 <markmc> and knows fontana has lots of interesting viewpoints on all of this
20:11:52 <fontana> Which is that the Legal Affairs Committee doesn't necessarily have more competence to make decisions on this than any of you do
20:11:57 <fontana> Trust me on that.
20:12:24 <fontana> If you want to pretend that it does, okay. I can tell you what the likely result will be.
20:12:25 <ttx> fontana: could the Legal Affairs Committee give guidelines on what should be acceptable, that reviewers could use in reviewing new dependencies proposed ?
20:12:35 <markmc> fontana, would you say a committee with that title should have that competence?
20:12:42 <jgriffith> ttx: I'll update on the reservation before we break
20:12:43 <gabrielhurley> ttx: I've seen that go very badly before. see NASA.
20:12:45 <fontana> markmc: I am not sure.
20:13:30 <mikal> I do think having some rules of thumb we share with the community is a good idea
20:13:41 <mikal> Otherwise we'll be starting the conversation from scratch for each dependancy
20:13:42 <markmc> indeed
20:13:55 <markmc> and I think we know roughly what the rule of thumb is
20:13:56 <gabrielhurley> I propose that the TC + Legal Affairs draft a general set of "what we know is acceptable, and what we know is *not* acceptable" and then deal with individual grey area cases as they arise. That'd cover the 90% case, right?
20:14:21 <fontana> I think the TC should be as involved in this as the Legal Affairs Committee
20:14:32 <markmc> fontana, agree on that
20:14:32 <gabrielhurley> +1
20:14:41 <markmcclain> +1
20:14:48 <mikal> +1
20:14:49 <fontana> Understand, the Legal Affairs Committee knows nothing about OpenStack, Python, etc
20:14:56 <fontana> Open source licensing.
20:15:00 <mikal> I think once we have a rhythmn of what to look for it shouldn't take too much time
20:15:00 <markmc> gabrielhurley, one idea fontana had is to compile the list of acceptable license by looking at our current set of dependencies
20:15:19 <markmc> gabrielhurley, any license in there is almost by definition acceptable
20:15:28 <gabrielhurley> markmc: that'd be a good place to start
20:15:54 <markmc> I have to say, though, I'm not sure at this point what I'd add to the *not* acceptable list
20:16:00 <markmc> well, AGPL say
20:16:22 <gabrielhurley> yeah, GPL variants. Anything the has a requirement that the code including it also be it's license type.
20:16:26 <fontana> I have expressed concern about discrimination against AGPL. There are lots of bad licenses out there.
20:16:41 <mordred> o/
20:16:54 <jgriffith> So we should probably seperate concerns regarding inclusion and dependencies
20:17:13 <gabrielhurley> fontana: what do you mean by "concern about discrimination against AGPL"?
20:17:16 <markmc> gabrielhurley, well, we're talking about libraries here - so, not 'including it' but (for python) 'importing it'
20:17:27 <fontana> jgriffiths: 'inclusion' = actually using code under some non-Apache license in an OpenStack project source tree?
20:17:37 <jgriffith> fontana: yes
20:18:03 <jgriffith> That's actually what started this in Cinder
20:18:12 <fontana> gabrielhurley: Like, all other conceivable licenses are okay other than AGPL. A license that says 'no commercial use allowed' is okay. Or an obscure license with an AGPL-like condition (there are several OSI-approved ones).
20:18:34 <markmc> jgriffith, cinder didn't include AGPL code, it used it as library
20:18:34 <gabrielhurley> fontana: that's what I thought you meant, just wanted to be sure. agreed.
20:18:40 <gabrielhurley> any copyleft license is a problem.
20:18:46 <jgriffith> markmc: yes, but that's not how this started
20:18:52 <fontana> gabrielhurley: Including LGPL?
20:19:02 <mordred> lgpl isn't copyleft
20:19:06 <dolphm_> gabrielhurley: is copyleft the source of the issue?
20:19:07 <fontana> LGPL is copyleft.
20:19:11 <markmc> hehe
20:19:12 <mordred> in the same way
20:19:22 <markmc> in the "viral" sense I guess mordred means
20:19:29 <fontana> Okay
20:19:33 <gabrielhurley> lgpl is "modified copyleft", not true copyleft
20:19:34 <markmc> that what all this comes down to, no?
20:19:36 <mordred> it does not require transferrance of copyright terms
20:19:45 <mordred> I believe 'viral' is the issue
20:19:49 <fontana> You are reasonably assuming that using an LGPL library has no frightening consequences for OpenStack
20:19:50 <gabrielhurley> that ^^^
20:20:01 <mordred> yes. I am
20:20:03 <fontana> The Apache Software Foundation would disagree with you. I don't disagree, at least in most cases.
20:20:08 <gabrielhurley> heh
20:20:10 <mordred> the LGPL is essentially the BSD
20:20:21 <mordred> and I don't agree with many things the apache foundation says
20:20:34 <fontana> mordred: that is probably a good thing
20:20:50 * gabrielhurley is with mordred on this one
20:21:17 <gabrielhurley> there may be intricacies that could be nasty, but again in the 90% case I believe it would be safe
20:21:20 <mordred> I think the problem is that we have chosen the apache license for our project and do not want to unwittingly wind up shipping a project which causes ours to be licensed differently, yeah?
20:21:21 <fontana> anyway the knowledge that many LGPL libraries are being used was what made me think of approaching this by seeing what is actually being done and working out a policy from that
20:21:31 <mordred> fontana: ++
20:21:42 <mikal> I certainly think an audit of the current state is required
20:21:49 <mikal> So that's not wasted effort
20:21:50 <markmc> fontana, I'd always assumed LGPL would be on the list of acceptable licenses for library dependencies
20:22:06 <mordred> pypi.openstack.org/openstack has the entirety of the dependencies that we use on a python basis
20:22:16 <mordred> including non-declared transtive
20:22:19 <fontana> Oh, that is useful
20:22:19 <markmc> question is whether (the TC thinks that) OpenStack can (ever?) use a GPL library and the result be that OpenStack must now be distributed under the GPL ?
20:22:28 <mordred> it does not include c librarises such as libxml or libvirt
20:22:28 <jeblair> (strictly speaking a superset because old ones are not purged)
20:22:46 <markmc> fontana, and I think you were (on the mailing list) making a reasonable case that we should consider each such case separately
20:22:52 <jeblair> (and so requires double checking of current state, but is otherwise a great start for what mordred suggested)
20:23:02 <mordred> markmc: I believe that gets down to what the author of that gpl library believes derivative work is
20:23:15 <fontana> markmc: I object to any legal conclusion that using a GPL library requires OpenStack to be distributed under the GPL. This is contradicted by the practices of numerous open source projects.
20:23:18 <mordred> markmc: since they are the ones licensing their work to us for our use under a set of terms
20:23:32 <dolphm_> i don't see an issue with LGPL's copyleft ... unless we're forking something distributed under LGPL and branding it as an openstack component
20:23:49 <mordred> fontana: MySQL/Oracle would argue the opposite, of course :)
20:24:06 <mordred> thus the specific licensing of libmysqlclient
20:24:14 <markmc> fontana, do you think the TC would be wise to add GPL to the list of "always acceptable" licenses?
20:24:16 <fontana> mordred: true
20:24:24 <mordred> I believe it's a grey area
20:24:29 <markmc> that using a GPL licensed library never has scary consequences for OpenStack?
20:24:29 <fontana> markmc: No
20:24:33 <markmc> right, cool
20:24:38 <markmc> grey area :)
20:24:50 <mordred> yay. because we need more grey areas here :)
20:24:51 <fontana> markmc: I just want to say that I think some of this is coming out of superstition
20:24:59 <mordred> fontana: ++
20:25:04 <markmc> fontana, I'm persuaded on that :)
20:25:18 <fontana> I recognize you have to deal with that superstition. You don't want licensing FUD to hurt OpenStack
20:25:21 <gabrielhurley> anything which is GPL (not LGPL) will absolutely need closer review, if not be denied.
20:25:44 <gabrielhurley> the GPL's terms are quite strict but also full of holes
20:25:52 <markmc> ok, so if we're all happy with this idea of a review process for grey areas like GPL libraries
20:25:57 <markmc> what should the review process be?
20:26:03 <dolphm_> gabrielhurley: +1
20:26:07 <markmc> if e.g. the TC wants to make that call itself?
20:26:11 <fontana> markmc: What I'd think is that in vast majority of cases GPL library would not be okay
20:26:24 <markmc> fontana, ok, interesting
20:26:26 <mikal> I think until we understand the parameters better covering additions in TC meetings is a good idea
20:26:28 <gabrielhurley> fontana: I second that
20:26:36 <mordred> mikal: ++
20:26:53 <mikal> Once we have it down to something routine, we can hand it off if we want to
20:26:56 <mordred> I believe we can safely say that new things licensed Apache2 or BSD or MIT are pretty safe, yeah?
20:27:03 <markmc> so, we come up with guidelines over time by looking at each case individually?
20:27:11 <mordred> and things licensed GPL need to come to the TC for further discussion?
20:27:13 <mikal> markmc: yeah
20:27:28 <markmc> sounds good
20:27:28 <fontana> Clearly anything Apache2 is safe  :-)
20:27:29 <mikal> Well, obviously correct things can be a one sentence email to the TC list
20:27:48 <mikal> That way there's a paper trail (for example if a dependancy changes its license later)
20:27:51 <markmc> do we want help for the grey area reviews from esteemed persons like fontana?
20:27:55 <markmc> or good doing it on our own?
20:27:59 <fontana> Another issue though is I do not know how accurate license designations for PyPI are
20:28:03 <dolphm_> who's core on openstack/requirements?
20:28:05 <ttx> also current analysis will go a long way to set expectations correctly
20:28:16 <mikal> ttx: agreed
20:28:20 <jeblair> fontana: often inaccurate, sometimes the metadata even contradicts itself
20:28:26 <mikal> markmc: I think we should escalate to experts whenever we feel the need to
20:28:26 <gabrielhurley> fontana: they're about 75% accurate in my experience
20:28:29 <fontana> jeblair: that was what I was afraid of
20:28:52 <gabrielhurley> I have definitely contacted authors in the past to clarify their licenses
20:29:03 <fontana> 75% is better than I thought
20:29:08 <mikal> We can use dnspython as a practise run!
20:30:34 <markmc> mikal, seems pretty clear cut permissive :)
20:30:41 <ttx> so, I think we first need to do a complete analysis of current deps
20:30:54 <ttx> and have a process in place when a new dep is added, so that licensing is at least considered
20:31:12 <mikal> I am a bit worried cores will forget to do this when something gets added to the pip files
20:31:17 <jeblair> i believe VanL was interested in a current-dep analysis as well
20:31:20 <ttx> which means, making openstack/requirement a necessary step for adding deps
20:31:33 <markmc> it already is, no?
20:31:39 <fontana> jeblair: yes, re VanL
20:31:45 <mordred> markmc: yes, it is
20:31:49 <mordred> we have a gating job for that now
20:31:53 <ttx> markmc: for all projects ? ok
20:32:07 <mordred> it runs when you change requires files
20:33:12 <mikal> I can't see a wiki page for openstack/requirement. Do we need one?
20:33:23 <ttx> who is working on current dependencies analysis ? Should we use some etherpad to share the load ?
20:33:32 <gabrielhurley> is it possible to add another field to gerrit for "license approved"? on the dependencies project?
20:33:34 <jeblair> mikal: i started a stub here: https://wiki.openstack.org/wiki/Requirements
20:33:59 <jeblair> mikal: if the requirements job fails, it links to that page
20:34:18 <mordred> gabrielhurley: we'd have to add that field for all projects :(
20:34:25 <gabrielhurley> darn. too bad
20:34:30 <mikal> jeblair: ahhh, cool
20:36:10 <ttx> fontana: did you start an analysis on the legal affairs committee side ?
20:36:39 <fontana> ttx: not sure, VanL talked about it in an email which you may have been on - I missed last couple of calls
20:37:02 <fontana> ttx: oh, if by analysis you mean the policy analysis... not really
20:37:26 <ttx> no, meant current dependency licensing lists
20:37:49 <fontana> ttx: I don't think so. VanL is in charge of seeing that that is done I guess
20:37:52 <ttx> ok, so it looks like we could add comments to the *-requires files about dep licensing when known
20:38:42 <ttx> markmc: anything you'd see as the next step ?
20:39:19 <markmc> ttx, just the review of current deps licenses
20:39:46 <markmc> I guess we need to let openstack/requirements folks know they should check licenses too
20:39:53 <ttx> markmc: would you rather etherpad it or submit comments to openstack/requirements ?
20:40:07 <ttx> the latter is a bit more painful but also lasts longer
20:40:12 <mikal> Comments sounds better to me
20:40:18 <dolphm_> could include the license of each dep as in the openstack/requirements repo, which will make it easy for reviewers to see that a particular license has already been reviewed as acceptable
20:40:38 <dolphm_> then you just have to double check that the author specified the correct license
20:40:59 <ttx> #action start licensing analysis by adding comments to *-requires files in openstack/requirements
20:41:16 <ttx> further discussion at the dependency management session at the Design Summit
20:41:28 <mordred> don't forget when doing analysis - transitive depends
20:41:47 <ttx> http://openstacksummitapril2013.sched.org/event/662c7d06e08b846e64c07efb41101c34
20:41:52 <ttx> So, now the bad news.
20:42:12 <mordred> uhoh
20:42:14 <ttx> The restaurant is full on Wednesday night
20:42:20 <ttx> until 9
20:42:20 <mordred> WHATT?
20:42:22 <gabrielhurley> ha
20:42:28 <mordred> do they know who we are?
20:42:32 <mordred> :)
20:42:37 <ttx> and let's say that the neighborhood for the RAX party isn't full of other options
20:42:47 <ttx> so...
20:42:56 <ttx> we can move to another day (probably a bad idea)
20:43:07 <ttx> we can have dinner at 9 (probably a bad idea)
20:43:37 <ttx> we can go to another restaurant and get to the RAX party by our own means
20:44:09 <annegentle> yeah find another restaurant. Boo hoo
20:44:49 <ttx> then hit on 6 cabs to run from there to the party, since public transport is not really an option
20:44:51 <gabrielhurley> there's plenty of good food in Portland... we can just grab a couple cabs.
20:45:15 <markwash> we can just eat donuts together in a parking lot
20:45:20 <mikal> LOL
20:45:24 <gabrielhurley> I prefer pie
20:45:30 <ttx> anyone has a suggestion for a restaurant ? Otherwise I'll do proper research tomorrow :)
20:46:07 <annegentle> sorry I don't, and your research is good research :)
20:46:31 <gabrielhurley> Portland City Grill is lovely, just to throw an option out there
20:46:33 <dolphm_> i've been told to go to http://www.yelp.com/biz/andina-portland
20:46:42 <ttx> dolphm_: been there, pretty good
20:47:04 <markwash> faint praise? or endorsement?
20:47:16 <markwash> nevermind
20:47:35 <ttx> I'll have a proposal up tomorrow :)
20:47:38 * markwash <3s peruvian
20:48:28 <markwash> mordred: should we talk about image-building in openstack?
20:49:11 <markwash> and where something like that should live, projectwise?
20:49:17 <mordred> markwash: we can - or we can just do it over beer next week
20:49:36 <markwash> as you wish
20:49:46 <ttx> OK, anything more before we close ?
20:50:57 <ttx> I guess not
20:51:12 <ttx> #endmeeting