Okay, thanks for the details Alexis and Catherine. Looking forward to working together to come to a good cross-project solution. Daniel

Phil is correct on this point. Thank you Phil for making it :) I usually phrase it somewhat flippantly as "I do not have capital O opinions" :) I have been through the relicensing process in other

As Catherine said, we noticed we’re forking DLUX (as of few hours ago). Prior concerns were actually regarding applications created on top of ODL, using ODL package name and licence, which is wrong

I agree. The forking part is not the right way to do this. —Tom

Yeah, my thoughts exactly. This is the first I've heard about ONAP forking DLUX, or talking about forking any part of ODL. Catherine, instead of the complex and inefficient mess I think it would be to

[snip] I think this case deserves thorough TAC-level analysis. We (ODL) have discontinued support for DLUX due to there not being anyone in our community to support it. Yet, since ONAP has chosen

Quoting the console: [...] has the wrong version (should be 4.2.1) because the multipatch job has not picked up the int/dist patch (again) -- making this a tooling issue. int/dist will work just

Hello Catherine and Ed: /PJR Catherine and members of the TAC, please note, that neither I, nor Ed are lawyers although we have both spent inordinate amounts of time with lawyers combing through these

Thank you for the explanation :) +1 for flexibility… at one point I recall the AAA component being swappable at binary level (ie, you just plugged in a different implementation). If that’s no

All the individual projects compiled fine but distribution failed SFT in

Ed, Daniel, Let me provide additional clarifications since I was not clear in my previous request. If some future release, ONAP CCSDK project needed to fork an ODL component in order to

Yest that's right. Yellow / UNSTABLE means CLM successfully ran but found some issues / vulnerabilities in the scan which projects can review at their leisure. Regards, Thanh

+1, are there any examples of ODL *source* code being present in ONAP? It there are, we should work on upstreaming that code. If there are not, I feel this is a non-issue. Thanks, Robert

As far as I know, ONAP doesn’t fork ODL. We consume released artifacts, in which case EPL licence is not an issue. Alexis

Question: Why not simply consume the ODL binary artifacts rather than forking the source code? Ed

Good morning Dan, Thanks a lot for your prompt feedback. I will check with the concerned parties today and will let you know. Best regards Catherine

Hello Catherine, Thanks for bringing this to ODL's attention. Would it be possible for you and the other relevant ONAP/LF folks to join ODL's TSC meeting this week (Thurs 9AM PT) to brief the

IMHO at this point in time it would be best to start merging patches already. -Lori

It would seem that the patch series is getting broken and requires ongoing maintenance. Is there anything left blocking it? Unless there is a compelling reason not to, can we merge it up, so we can

On Tue, Oct 23, 2018 at 9:05 PM Thanh Ha <thanh.ha@...> wrote: [...] > All projects should double check their CLM jobs (make sure the latest run was from today onwards, if not force a