Good morning TAC team,

 

I would like to discuss the following item with you.

 

As you might know, ONAP is released under the Apache 2.0 License.

 

During our last ONAP License review with Steven Winslow (LF Legal representative), we have got the feedback that ONAP source code should not contain any ODL source code

since ODL is released under EPL i.e. Weak Copy left.

 

It generates some concerns since we would like to avoid to make a fork of ODL then have to put ODL source code outside LF repositories on github in order to consume it back to ONAP L.

 

For the ONAP Casablanca release, ONAP TSC will be requested to approve a waiver.

Nevertheless, would it be possible to address this concern at the TAC team level as a medium/long term plan?

 

Many thanks & regards

Catherine

 

Catherine Lefèvre AVP Software Development & Engineering   AT&T Labs – Network Cloud & Infrastructure D2 Platform & Systems Development ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA ONAP TSC Chair     Phone: +32 2 418 49 22 Mobile: +32 475 77 36 73 catherine.lefevre@...   TEXTING and DRIVING… It Can Wait

AT&T BUROGEST OFFICE PARK SA Avenue des Dessus-de-Lives, 2 5101 Loyers (Namur) Belgium

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

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

 

From: TAC@... [mailto:TAC@...] On Behalf Of Daniel Farrell
Sent: Wednesday, October 24, 2018 2:48 PM
To: TAC <TAC@...>
Cc: Steve Winslow <swinslow@...>; Close, Pierre <pierre.close@...>; tsc <tsc@...>
Subject: Re: [TAC-public] ODL Licensing (EPL) and ONAP's (Apache 2.0)

 

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 community on the issue and start discussing possible plans?

 

https://wiki.opendaylight.org/view/TSC:Meeting#Meeting_Schedule_and_Logistics

 

I've CC'd the ODL TSC list to go ahead and put this on everyone's radar.

 

Thanks,
Daniel

 

On Wed, Oct 24, 2018 at 7:56 AM Catherine LEFEVRE <catherine.lefevre@...> wrote:

Good morning TAC team,

 

I would like to discuss the following item with you.

 

As you might know, ONAP is released under the Apache 2.0 License.

 

During our last ONAP License review with Steven Winslow (LF Legal representative), we have got the feedback that ONAP source code should not contain any ODL source code

since ODL is released under EPL i.e. Weak Copy left.

 

It generates some concerns since we would like to avoid to make a fork of ODL then have to put ODL source code outside LF repositories on github in order to consume it back to ONAP L.

 

For the ONAP Casablanca release, ONAP TSC will be requested to approve a waiver.

Nevertheless, would it be possible to address this concern at the TAC team level as a medium/long term plan?

 

Many thanks & regards

Catherine

 

Catherine Lefèvre AVP Software Development & Engineering   AT&T Labs – Network Cloud & Infrastructure D2 Platform & Systems Development ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA ONAP TSC Chair     Phone: +32 2 418 49 22 Mobile: +32 475 77 36 73 catherine.lefevre@...   TEXTING and DRIVING… It Can Wait

AT&T BUROGEST OFFICE PARK SA Avenue des Dessus-de-Lives, 2 5101 Loyers (Namur) Belgium

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

Hello Catherine and Ed:

On Wed, Oct 24, 2018 at 12:27 PM Edward Warnicke via Lists.Lfnetworking.Org <eaw=cisco.com@...> wrote:

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 longer true, I’d suggest working with ODL to get it true again :)

The only thing worse than a fork is not being able to have one in a pinch.  ODL was designed to be very modular, so it should be possible for you guys to just keep code for you own AAA component, and plug that in with existing binaries.  And of course, your ODL plugins can be licensed any way ONAP wants.

 

/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 licenses, and in some cases participating in their drafting.  Regardless, it is neither our place, nor our legal authority to provide you or your respective companies with legal advice.  As a representative of the Linux Foundation I strongly encourage you to seek advice on this matter from your corporate legal counsel and to consider Ed's statement below as his personal opinion.

/////////////////

Be careful not to misunderstand the weak copy left of EPL… its not contaminating.  If you write a new ODL plugin you can license it however you want… its only if you change existing ODL code that those changes must remain under EPL.

//////////////// 

PJR/

The reason I’m looking for other solutions here is that because each contributor retains the copyright to their own work, relicensing, while not impossible, can be a very protracted and expensive undertaking, its not as simple as the ODL TSC (or even the LFN board) making a decision to relicense ODL code: you need permission from each copyright holder in that code.

One other avenue to explore is that the board *does* have the ability to grant you waivers on this issue if memory serves for the use of EPL code in ONAP.  

Ed

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE (catherine.lefevre@...) wrote:

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 integrate it into ONAP. For example, suppose that we wanted to swap out OpenDaylight’s AAA module in ONAP for one that is integrated with ONAP AAF (we don’t have to right now, since ODL’s AAA supports plugins, but suppose this turns out to be needed in a future release). It would be nice if we had the flexibility to just create a fork of that component and distribute it as part of ONAP. However, if we did that, that fork would have to be licensed under EPL – not Apache – since it is derived from EPL code.

To conclude, the purpose of this request would be to seek if there is any opportunity to harmonize the licenses under LFN.

 

 

Concerning the issue raised by Steve Winslow, additional work will be required from the ONAP community since DLUX has been forked, package name should be pointed to ONAP and not ODL.

No action for the ODL community.

 

Many thanks & regards

Catherine

 

From: TAC@... [mailto:TAC@...] On Behalf Of Edward Warnicke
Sent: Wednesday, October 24, 2018 3:12 PM
To: TAC@...
Cc: Steve Winslow <swinslow@...>; Close, Pierre <pierre.close@...>; tsc <tsc@...>
Subject: Re: [TAC-public] ODL Licensing (EPL) and ONAP's (Apache 2.0)

 

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

 

Ed

 

On Wed, Oct 24, 2018 at 7:53 AM Catherine LEFEVRE <catherine.lefevre@...> wrote:

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

 

From: TAC@... [mailto:TAC@...] On Behalf Of Daniel Farrell
Sent: Wednesday, October 24, 2018 2:48 PM
To: TAC <TAC@...>
Cc: Steve Winslow <swinslow@...>; Close, Pierre <pierre.close@...>; tsc <tsc@...>
Subject: Re: [TAC-public] ODL Licensing (EPL) and ONAP's (Apache 2.0)

 

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 community on the issue and start discussing possible plans?

 

https://wiki.opendaylight.org/view/TSC:Meeting#Meeting_Schedule_and_Logistics

 

I've CC'd the ODL TSC list to go ahead and put this on everyone's radar.

 

Thanks,
Daniel

 

On Wed, Oct 24, 2018 at 7:56 AM Catherine LEFEVRE <catherine.lefevre@...> wrote:

Good morning TAC team,

 

I would like to discuss the following item with you.

 

As you might know, ONAP is released under the Apache 2.0 License.

 

During our last ONAP License review with Steven Winslow (LF Legal representative), we have got the feedback that ONAP source code should not contain any ODL source code

since ODL is released under EPL i.e. Weak Copy left.

 

It generates some concerns since we would like to avoid to make a fork of ODL then have to put ODL source code outside LF repositories on github in order to consume it back to ONAP L.

 

For the ONAP Casablanca release, ONAP TSC will be requested to approve a waiver.

Nevertheless, would it be possible to address this concern at the TAC team level as a medium/long term plan?

 

Many thanks & regards

Catherine

 

Catherine Lefèvre AVP Software Development & Engineering   AT&T Labs – Network Cloud & Infrastructure D2 Platform & Systems Development ECOMP/RUBY/SPP-NEAM-Appl. Servers/SIA ONAP TSC Chair     Phone: +32 2 418 49 22 Mobile: +32 475 77 36 73 catherine.lefevre@...   TEXTING and DRIVING… It Can Wait

AT&T BUROGEST OFFICE PARK SA Avenue des Dessus-de-Lives, 2 5101 Loyers (Namur) Belgium

 

NOTE: This email (or its attachments) contains information belonging to the sender, which may be confidential. proprietary and/or legally privileged. The information is intended only for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient, you are hereby notified that any disclosure, distribution or taking of any action in reliance on the content of this is strictly forbidden. If you have received this e-mail in error please immediately notify the sender identified above

 

--

Phil Robb

VP Operations - Networking & Orchestration, The Linux Foundation

(O) 970-229-5949

(M) 970-420-4292

Skype: Phil.Robb

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 and probably coming from ODL’s archetype that was used to generate the initial scaffolding.

The fork is here: https://gerrit.onap.org/r/gitweb?p=ccsdk/apps.git;a=tree;f=sdnr/wireless-transport/code-Carbon-SR1/apps/dlux;h=2e405dcdef369883a3f9bd970b9fd6a1d8450495;hb=HEAD but I’m not too sure how much of the code we fork, as I’m very un-aware of DLUX’s code.

Point is, we’re actively looking to understand whether such fork is required, if so, we will come back to ODL community to see what can be mitigation plan; e.g. fix ODL’s DLUX and revive that project, or have a waiver granting ONAP to fork DLUX.

Regards,

Alexis

On Oct 24, 2018, at 1:28 PM, Thomas Nadeau <tnadeau@...> wrote:

On Oct 24, 2018, at 12:57 PM, Robert Varga <nite@...> wrote:

On 24/10/2018 18:41, Phil Robb wrote:

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE
(catherine.lefevre@... <mailto:catherine.lefevre@...>)
wrote:

[snip]

Concerning the issue raised by Steve Winslow, additional work will be
required from the ONAP community since DLUX has been forked, package
name should be pointed to ONAP and not ODL.

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 to fork it, it would seem there are resources
within the larger LFN community to support it.

I believe it is vitally important for both the TAC and ODL TSC to
understand ONAP's reasons for forking the codebase rather than picking
up maintenance/development of DLUX in its original place (ODL).

Regards,
Robert

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

—Tom

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

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 and probably coming from ODL’s archetype that was used to generate the initial scaffolding.

The fork is here: https://gerrit.onap.org/r/gitweb?p=ccsdk/apps.git;a=tree;f=sdnr/wireless-transport/code-Carbon-SR1/apps/dlux;h=2e405dcdef369883a3f9bd970b9fd6a1d8450495;hb=HEAD but I’m not too sure how much of the code we fork, as I’m very un-aware of DLUX’s code.

Point is, we’re actively looking to understand whether such fork is required, if so, we will come back to ODL community to see what can be mitigation plan; e.g. fix ODL’s DLUX and revive that project, or have a waiver granting ONAP to fork DLUX.

Regards,

Alexis

On Oct 24, 2018, at 1:28 PM, Thomas Nadeau <tnadeau@...> wrote:

On Oct 24, 2018, at 12:57 PM, Robert Varga <nite@...> wrote:

On 24/10/2018 18:41, Phil Robb wrote:

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE
(catherine.lefevre@... <mailto:catherine.lefevre@...>)
wrote:

[snip]

Concerning the issue raised by Steve Winslow, additional work will be
required from the ONAP community since DLUX has been forked, package
name should be pointed to ONAP and not ODL.

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 to fork it, it would seem there are resources
within the larger LFN community to support it.

I believe it is vitally important for both the TAC and ODL TSC to
understand ONAP's reasons for forking the codebase rather than picking
up maintenance/development of DLUX in its original place (ODL).

Regards,
Robert

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

—Tom

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Thanks Alexis & Catherine. As others (Robert, Daniel & Tom) have already said, it will be a better outcome if you have folks interested in reviving the OpenDaylight DLUX project rather than maintaining a fork of it in ONAP.

Also please let me know if we should add this as an agenda item for the next week's OpenDaylight TSC call? I will not add it for this week's (Thursday) to give you guys some time to figure out. 

 

In the TSC meeting we usually keep individual topics to max 10-15 minutes. If you guys want to have a deeper two-way technical discussion with the ODL technical community on how to handle this, we can discuss it in the Technical Work Stream (TWS) meeting. 

TSC meeting info: https://wiki.opendaylight.org/view/TSC:Meeting.

TWS meeting info: https://wiki.opendaylight.org/view/Tech_Work_Stream:Main.

Regards,

Abhijit

On Wed, Oct 24, 2018 at 10:56 AM Alexis de Talhouët <adetalhouet89@...> wrote:

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 and probably coming from ODL’s archetype that was used to generate the initial scaffolding.

The fork is here: https://gerrit.onap.org/r/gitweb?p=ccsdk/apps.git;a=tree;f=sdnr/wireless-transport/code-Carbon-SR1/apps/dlux;h=2e405dcdef369883a3f9bd970b9fd6a1d8450495;hb=HEAD but I’m not too sure how much of the code we fork, as I’m very un-aware of DLUX’s code.

Point is, we’re actively looking to understand whether such fork is required, if so, we will come back to ODL community to see what can be mitigation plan; e.g. fix ODL’s DLUX and revive that project, or have a waiver granting ONAP to fork DLUX.

Regards,

Alexis

On Oct 24, 2018, at 1:28 PM, Thomas Nadeau <tnadeau@...> wrote:

On Oct 24, 2018, at 12:57 PM, Robert Varga <nite@...> wrote:

On 24/10/2018 18:41, Phil Robb wrote:

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE
(catherine.lefevre@... <mailto:catherine.lefevre@...>)
wrote:

[snip]

Concerning the issue raised by Steve Winslow, additional work will be
required from the ONAP community since DLUX has been forked, package
name should be pointed to ONAP and not ODL.

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 to fork it, it would seem there are resources
within the larger LFN community to support it.

I believe it is vitally important for both the TAC and ODL TSC to
understand ONAP's reasons for forking the codebase rather than picking
up maintenance/development of DLUX in its original place (ODL).

Regards,
Robert

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

—Tom

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

Adding Tim to thread as he has a fluorine build of dlux working but not merged since it is deprecated upstream. Sounds like it would be an easy effort to reenable the project upstream of someone is willing to maintain it.

On Wed, Oct 24, 2018, 7:14 PM Abhijit Kumbhare <abhijitkoss@...> wrote:

Thanks Alexis & Catherine. As others (Robert, Daniel & Tom) have already said, it will be a better outcome if you have folks interested in reviving the OpenDaylight DLUX project rather than maintaining a fork of it in ONAP.

Also please let me know if we should add this as an agenda item for the next week's OpenDaylight TSC call? I will not add it for this week's (Thursday) to give you guys some time to figure out. 

 

In the TSC meeting we usually keep individual topics to max 10-15 minutes. If you guys want to have a deeper two-way technical discussion with the ODL technical community on how to handle this, we can discuss it in the Technical Work Stream (TWS) meeting. 

TSC meeting info: https://wiki.opendaylight.org/view/TSC:Meeting.

TWS meeting info: https://wiki.opendaylight.org/view/Tech_Work_Stream:Main.

Regards,

Abhijit

On Wed, Oct 24, 2018 at 10:56 AM Alexis de Talhouët <adetalhouet89@...> wrote:

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 and probably coming from ODL’s archetype that was used to generate the initial scaffolding.

The fork is here: https://gerrit.onap.org/r/gitweb?p=ccsdk/apps.git;a=tree;f=sdnr/wireless-transport/code-Carbon-SR1/apps/dlux;h=2e405dcdef369883a3f9bd970b9fd6a1d8450495;hb=HEAD but I’m not too sure how much of the code we fork, as I’m very un-aware of DLUX’s code.

Point is, we’re actively looking to understand whether such fork is required, if so, we will come back to ODL community to see what can be mitigation plan; e.g. fix ODL’s DLUX and revive that project, or have a waiver granting ONAP to fork DLUX.

Regards,

Alexis

On Oct 24, 2018, at 1:28 PM, Thomas Nadeau <tnadeau@...> wrote:

On Oct 24, 2018, at 12:57 PM, Robert Varga <nite@...> wrote:

On 24/10/2018 18:41, Phil Robb wrote:

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE
(catherine.lefevre@... <mailto:catherine.lefevre@...>)
wrote:

[snip]

Concerning the issue raised by Steve Winslow, additional work will be
required from the ONAP community since DLUX has been forked, package
name should be pointed to ONAP and not ODL.

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 to fork it, it would seem there are resources
within the larger LFN community to support it.

I believe it is vitally important for both the TAC and ODL TSC to
understand ONAP's reasons for forking the codebase rather than picking
up maintenance/development of DLUX in its original place (ODL).

Regards,
Robert

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

—Tom

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

The code was removed from ONAP code-base, as it was un-used, and not even compiled: https://gerrit.onap.org/r/#/c/71461/

So that DLUX fork is no longer an issue.

Regards,

Alexis

On Nov 7, 2018, at 9:32 AM, Lefevre, Catherine <catherine.lefevre@...> wrote:

Good morning all,

 

My apologies for the delayed response on this e-mail thread.

It would be great if you could invite Brian Freeman and Alexis to your next ODL meeting so they can share additional information.

 

Many thanks & regards

Catherine

 

From: TAC@... [mailto:TAC@...] On Behalf Of Sam Hague
Sent: Thursday, October 25, 2018 2:27 AM
To: Abhijit Kumbhare <abhijitkoss@...>; Rozet, Tim <trozet@...>
Cc: Alexis de Talhouët <adetalhouet89@...>; TSC <tsc@...>; Steve Winslow <swinslow@...>; Close, Pierre <pierre.close@...>; Lefevre, Catherine <catherine.lefevre@...>; TAC@...
Subject: Re: [OpenDaylight TSC] [TAC-public] ODL Licensing (EPL) and ONAP's (Apache 2.0)

 

Adding Tim to thread as he has a fluorine build of dlux working but not merged since it is deprecated upstream. Sounds like it would be an easy effort to reenable the project upstream of someone is willing to maintain it.

 

On Wed, Oct 24, 2018, 7:14 PM Abhijit Kumbhare <abhijitkoss@...> wrote:

Thanks Alexis & Catherine. As others (Robert, Daniel & Tom) have already said, it will be a better outcome if you have folks interested in reviving the OpenDaylight DLUX project rather than maintaining a fork of it in ONAP.

 

Also please let me know if we should add this as an agenda item for the next week's OpenDaylight TSC call? I will not add it for this week's (Thursday) to give you guys some time to figure out. 

 

In the TSC meeting we usually keep individual topics to max 10-15 minutes. If you guys want to have a deeper two-way technical discussion with the ODL technical community on how to handle this, we can discuss it in the Technical Work Stream (TWS) meeting. 

 

TSC meeting info: https://wiki.opendaylight.org/view/TSC:Meeting.

TWS meeting info: https://wiki.opendaylight.org/view/Tech_Work_Stream:Main.

 

Regards,

Abhijit

 

On Wed, Oct 24, 2018 at 10:56 AM Alexis de Talhouët <adetalhouet89@...> wrote:

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 and probably coming from ODL’s archetype that was used to generate the initial scaffolding.

 

The fork is here: https://gerrit.onap.org/r/gitweb?p=ccsdk/apps.git;a=tree;f=sdnr/wireless-transport/code-Carbon-SR1/apps/dlux;h=2e405dcdef369883a3f9bd970b9fd6a1d8450495;hb=HEAD but I’m not too sure how much of the code we fork, as I’m very un-aware of DLUX’s code.

 

Point is, we’re actively looking to understand whether such fork is required, if so, we will come back to ODL community to see what can be mitigation plan; e.g. fix ODL’s DLUX and revive that project, or have a waiver granting ONAP to fork DLUX.

 

Regards,

Alexis

On Oct 24, 2018, at 1:28 PM, Thomas Nadeau <tnadeau@...> wrote:

 

On Oct 24, 2018, at 12:57 PM, Robert Varga <nite@...> wrote:

On 24/10/2018 18:41, Phil Robb wrote:

On October 24, 2018 at 9:56:16 AM, Catherine LEFEVRE
(catherine.lefevre@... <mailto:catherine.lefevre@...>)
wrote:

[snip]

Concerning the issue raised by Steve Winslow, additional work will be
required from the ONAP community since DLUX has been forked, package
name should be pointed to ONAP and not ODL.

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 to fork it, it would seem there are resources
within the larger LFN community to support it.

I believe it is vitally important for both the TAC and ODL TSC to
understand ONAP's reasons for forking the codebase rather than picking
up maintenance/development of DLUX in its original place (ODL).

Regards,
Robert

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

—Tom

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

 

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc