13:03:35 <dneary> #startmeeting Technical Community discussion
13:03:35 <collabot> Meeting started Thu Oct 13 13:03:35 2016 UTC.  The chair is dneary. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:35 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:03:35 <collabot> The meeting name has been set to 'technical_community_discussion'
13:03:59 <dneary> #chair ChrisPriceAB rpaik bryan_att
13:03:59 <collabot> Current chairs: ChrisPriceAB bryan_att dneary rpaik
13:04:17 <bin_> #info Bin Hu
13:04:25 <dneary> #chair bin_ ljlamers mtahhan_
13:04:25 <collabot> Current chairs: ChrisPriceAB bin_ bryan_att dneary ljlamers mtahhan_ rpaik
13:04:34 <dneary> #info Dave Neary
13:04:48 <rpaik> #info Ray Paik
13:05:46 <ChrisPriceAB> #info chris price
13:06:06 * ChrisPriceAB wonders if that was a playback...
13:06:24 <dneary> #topic Introductions and overview
13:06:34 <rpaik> #info Scott Nicholas notes that OPNFV IP Policy should be the guiding document for licensing questions
13:06:58 <rpaik> #link https://www.opnfv.org/about/bylaws-and-policies/ip-policy OPNFV IP Policy
13:07:05 <bryan_att> #info Bryan Sullivan
13:07:20 <ChrisPriceAB> #info scott notes that OPNFV default license is Apache 2.0 although it is possible to request exceptions from the board.
13:07:24 <dneary> #info Scott Nicholas, senior director for programs, and Karen Coberhaver from the Linux Foundation's legal team, are on the call
13:07:53 <dneary> rpaik, Did I get titles and surname spelling correct?
13:07:53 <rpaik> #info there are exception processes for non Apache 2 licenses (incl. Board exceptions)
13:08:10 <rpaik> #info Karen Copenhaver...
13:08:26 <rpaik> #undo
13:08:26 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2fc6290>
13:08:39 <dneary> #undo
13:08:39 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2c71e10>
13:08:45 <rpaik> dneary it's Karen Copenhaver
13:09:16 <rpaik> #info Scott notes that Fossology 3.0 is the tool used for license scanning
13:09:19 <dneary> #info Scott Nicholas, senior director for programs, and Karen Copenhaver from the Linux Foundation's legal team, are on the call
13:09:37 <dneary> #info there are exception processes for non Apache 2 licenses (incl. Board exceptions)
13:10:14 <dneary> rpaik, Not sure if I undid enough - there's probably a duplicate line there with just the typo correction
13:10:26 <bryan_att> #info Some of the config files do not support comments
13:11:15 <bryan_att> #info "Aty directory level" means the root directory only
13:11:15 <rpaik> #info best practice is to include license information in the file (not just at the directory level)
13:11:31 <bryan_att> #info But please make that clear
13:11:41 <bin_> #info Scott indicated that this is not any legal advice. For any legal advice, please work with respective corporate counsel
13:12:46 <bryan_att> #info By our policy licenses are "required" rather than "encouraged"
13:12:47 <dneary> bin_, While it is not legal advice, it is a statement of project IP policy
13:13:04 <rpaik> #info copyrightable material should include license info
13:13:07 <bryan_att> #info Unless there is some technical reason that a license cannot be included in the file
13:15:09 <morgan_orange> for copyright, as far as I remember, OpenStack removed them and created an authors.txt file
13:15:17 <MR_Sandvine> #info Manuel Rebellon
13:17:48 <morgan_orange> not everywhere just find a copyright NASA  and OpenStack but cannot find individual copyrights
13:17:48 <ulik> #info Uli Kleber
13:18:13 <bryan_att> #info The inclusion of third party-files (which needs to be defined) brings a risk factor that we need to manage; we should not modify those file licenses but we do need to ensure that the license is clear and compatible (within granted exceptions) to the OPNFV policy
13:18:33 <rpaik> #info general guide is that more information is better than less (incl. license information)
13:22:10 <bryan_att> #info the concept of "following the practice of upstream projects" is a slippery slope within OPNFV; even if the upstream community removes license/attribution (which violates OPNFV policy and the APL 2.0 license), that should not give OPNFV members a reason not to include the license in all contributions.
13:23:33 <dneary> I'm a bit lost
13:24:13 <bryan_att> #info APL: 2.0 says "You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; ..."
13:24:14 <dneary> If someone adds an OPNFV file to a project which is (say) MIT licensed, the new files must be Apache 2.0?
13:24:18 <rprakash> #info rprakash
13:25:53 <bryan_att> #info Since contributions to OPNFV require APL 2.0 license info, it would be inappropriate for an upstream community to remove that info; thus the practice of not putting license info into files because the upstream community may remove it, would violate OPNFV policy,
13:30:49 <bryan_att> #info 3-party code that is not intended to be part of some delivery in OPNFV or upstream, should be imported as needed and not live in the OPNFV repos; we need to discuss this at TSC and set a policy that there should be a high bar for that practice, to discourage it.
13:32:00 <bryan_att> #info it Also would increase the chance of "migration" of some parts of those 3rd-party utilities into the OPNFV code/folders; that's only human are would probably go unnoticed, thus a risk.
13:32:52 <dneary> rpaik, I would like to move to the "staging patches in clones of upstream projects" topic.
13:33:11 <bryan_att> #info what is SPDX?
13:33:25 <dneary> rpaik, It seemed to me that this was the principal question today, and we have only 20 minutes left to work through it
13:33:34 <dneary> bryan_att, License metadata
13:33:47 <dneary> bryan_att, Includes license versioning, variants, etc
13:33:47 <rpaik> #link https://spdx.org/licenses/ SPDX site
13:33:47 <bryan_att> #info reference to this somewhere?
13:33:54 <dneary> #unfo
13:34:02 <dneary> rpaik pasted it in
13:34:06 <dneary> #undo
13:34:06 <collabot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x2fd3490>
13:35:01 <rpaik> #info SPDX is not required, but is a shorter & standardized format
13:35:15 <bryan_att> #info That should be optional, I'm not sure that it would be used consistently
13:36:55 <dneary> bryan_att, It's an LF initiative, and the LF is understandably encouraging its adoption in LF hosted projects
13:37:00 <bryan_att> #info The point about scanning make sense though - that's a very complex process and this could simplify.
13:37:31 <rpaik> #info you can include both SPDX and conventional license indicators in the file
13:37:54 <bryan_att> #info I just want to be sure that we have clear guidelines for what licenses should look like, attribution, etc. So far I still think we are doing this inconsistently.
13:40:00 <bryan_att> #link https://github.com/blsaws/charm-congress
13:40:42 <rpaik> #info Scott notes the risk of external repo's that is not part of the formal open source project that have clear IP policies
13:42:08 <aricg> For apex, for example: git clone http://github.com/trozet/tacker -b SFC_colorado openstack-tacker-2015.2
13:42:44 <bryan_att> #info That is a fork of the Canonical JuJu charm (created with APL 2.0 and attribution) that is used when Congress is installed in OPNFV. We can move that into the Copper repo but the build process will need to change to clone the Copper repo - not impossible but it does have an impact.
13:42:45 <tallgren> Also, an external repo may not follow the release process.
13:45:05 <rpaik> #info Scott asks if there's a DCO when you go to external Github
13:45:43 <bryan_att> #info Really for Copper, it's just a matter of prioritizing time and things we *must* do.
13:45:52 <rpaik> #info ChrisPriceAB notes that some corporations prevent employees from contributing to personal Githubs
13:49:56 <rprakash> #link https://wiki.opnfv.org/display/apex/Apex
13:57:59 <rpaik> #info LF team can explore structural improvements to enable developers
13:59:39 <ChrisPriceAB> #info dneary describes that a potential solution could be to mirror upstream and allow project branching according to the listed ietms under https://wiki.opnfv.org/display/DEV/Licensing+and+External+repo%27s+discussion#LicensingandExternalrepo%27sdiscussion-ProposalforOPNFVrepomirroringtoGitHub
14:02:27 <rpaik> #info also need to consider technical impact (not just IP Policy)
14:02:51 <bin_> #info Ray, Scott and Karen will discuss the next step, and come back with suggestions
14:03:50 <bin_> #endmeeting