Topics

Updated License and Attribution policy

James.White2@...
 

Toby and Tony,

 

Thanks for the comments and proposed changes.  I have incorporated those changes to the License and Attribution policy and have attached an update in PDF form with revisions highlighted.  Tony – to your question on Apache 2.0 policy, that was specified in the original and I have highlighted that in blue, but let me know if you think more is needed.

 

If there are no other additions or recommendations on this, I will update the Wiki and send out for a re-vote.

 

Thanks and have a good weekend everyone.

Jim

 

From: Tony Espy [mailto:espy@...]
Sent: Thursday, December 13, 2018 6:00 PM
To: White2, James; edgex-tsc@...
Subject: Re: [Edgex-tsc] TSC vote on License and Attribution policy

 

[EXTERNAL EMAIL]

On 12/13/18 12:57 AM, James.White2@... wrote:

TSC members,

 

Per today’s TSC meeting, please review and vote on the proposed License and Attribution Files policy found here:  https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=21823866

 

If you are in favor of this clarification to our contributor process and guidelines, please respond to this email with a +1.

If you would like to modify the wording, please respond with your proposed changes.

1) "Ubuntu Snap" --> "snap package"

2) I think this needs some re-wording:

When ever a contributor adds a product or dependency on another 3rd party tool, library, package, or other product to EdgeX...

In particular the "library, package, or other product".  What we're really concerned about are library dependencies which result in code being copied into EdgeX binaries, and thus being re-distributed by EdgeX. Examples include a golang import which statically links library code into a binary, a new C statically linked library, a Java package import (which causes compiled class files to get copied into Jars), ...

That said, code linked dynamically needs to be treated more akin to tools or applications as explained below, however I'd like a second opinion on this.

So I'd suggest:

Whenever a contributor adds a new dependency on a 3rd party programming library (i.e. C library, Golang/Java package, ...) to EdgeX...

That said, with respect to our container artifacts, if new non-EdgeX tools or applications are required at runtime, then the licenses of those products need to be included, but not in an Attribition.txt file.

Does that make sense?

3) Contributors must create an Attribution.txt file when submitting the initial Pull Request for any new EdgeX Foundry repository.

I would say "for each binary or external library package built from the repository". For instance our edgex-go has multiple Attribution.txt files for each service binary, and for its exported packages.

3) This Attribution file should contain any used/referenced open source in the repository (see Contents below).

Suggest: This Attribution file should enumerate all used/referenced 3rd party libraries for a given binary or library.

Also is it our policy that all 3rd party libraries used by the core EdgeX code are open source, as long the license is compatible with Apache 2.0? I think the answer is yes, but wanted to double check whether we've explicitly stated this anywhere?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Library_(computing)

 

 

 

Non-TSC members of the EdgeX community are encouraged to provide a non-binding vote or suggest modifications as well.

 

Thanks,

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

espy
 

On 12/14/18 3:09 PM, James.White2@... wrote:

Toby and Tony,

 

Thanks for the comments and proposed changes.  I have incorporated those changes to the License and Attribution policy and have attached an update in PDF form with revisions highlighted.  Tony – to your question on Apache 2.0 policy, that was specified in the original and I have highlighted that in blue, but let me know if you think more is needed.

 

If there are no other additions or recommendations on this, I will update the Wiki and send out for a re-vote.

Much improved, especially the bit about libraries & Attribution.txt!

A couple of minor comments still...

/t

---

1) License

This file will be named LICENSE.

Note, a number of repositories use "LICENSE-2.0.txt" (eg. device-random, device-modbus-go, device-mqtt-go, device-sdk-go).

Also, I didn't check *every* repository, but I did notice that there's no LICENSE in security-secret-store. We might want to perform some sort of audit on the rest of our repos.

2) Responsibilities

 - there seems to be a stray "EdgeX" on the line preceding this section. Is that intentional?

 - last <p> "Ubuntu Snap" -> "snap package"


 

Thanks and have a good weekend everyone.

Jim

 

From: Tony Espy [mailto:espy@...]
Sent: Thursday, December 13, 2018 6:00 PM
To: White2, James; edgex-tsc@...
Subject: Re: [Edgex-tsc] TSC vote on License and Attribution policy

 

[EXTERNAL EMAIL]

On 12/13/18 12:57 AM, James.White2@... wrote:

TSC members,

 

Per today’s TSC meeting, please review and vote on the proposed License and Attribution Files policy found here:  https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=21823866

 

If you are in favor of this clarification to our contributor process and guidelines, please respond to this email with a +1.

If you would like to modify the wording, please respond with your proposed changes.

1) "Ubuntu Snap" --> "snap package"

2) I think this needs some re-wording:

When ever a contributor adds a product or dependency on another 3rd party tool, library, package, or other product to EdgeX...

In particular the "library, package, or other product".  What we're really concerned about are library dependencies which result in code being copied into EdgeX binaries, and thus being re-distributed by EdgeX. Examples include a golang import which statically links library code into a binary, a new C statically linked library, a Java package import (which causes compiled class files to get copied into Jars), ...

That said, code linked dynamically needs to be treated more akin to tools or applications as explained below, however I'd like a second opinion on this.

So I'd suggest:

Whenever a contributor adds a new dependency on a 3rd party programming library (i.e. C library, Golang/Java package, ...) to EdgeX...

That said, with respect to our container artifacts, if new non-EdgeX tools or applications are required at runtime, then the licenses of those products need to be included, but not in an Attribition.txt file.

Does that make sense?

3) Contributors must create an Attribution.txt file when submitting the initial Pull Request for any new EdgeX Foundry repository.

I would say "for each binary or external library package built from the repository". For instance our edgex-go has multiple Attribution.txt files for each service binary, and for its exported packages.

3) This Attribution file should contain any used/referenced open source in the repository (see Contents below).

Suggest: This Attribution file should enumerate all used/referenced 3rd party libraries for a given binary or library.

Also is it our policy that all 3rd party libraries used by the core EdgeX code are open source, as long the license is compatible with Apache 2.0? I think the answer is yes, but wanted to double check whether we've explicitly stated this anywhere?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Library_(computing)

 

 

 

Non-TSC members of the EdgeX community are encouraged to provide a non-binding vote or suggest modifications as well.

 

Thanks,

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...

 

James.White2@...
 

Thanks Tony.  I’ll clean up these bits, perform an audit and get file corrections in place, and then rerun the final document for vote early next week.

j

 

From: EdgeX-TSC@... [mailto:EdgeX-TSC@...] On Behalf Of espy
Sent: Friday, December 14, 2018 6:16 PM
To: White2, James; edgex-tsc@...; tobias.mosby@...
Subject: Re: [Edgex-tsc] Updated License and Attribution policy

 

[EXTERNAL EMAIL]

On 12/14/18 3:09 PM, James.White2@... wrote:

Toby and Tony,

 

Thanks for the comments and proposed changes.  I have incorporated those changes to the License and Attribution policy and have attached an update in PDF form with revisions highlighted.  Tony – to your question on Apache 2.0 policy, that was specified in the original and I have highlighted that in blue, but let me know if you think more is needed.

 

If there are no other additions or recommendations on this, I will update the Wiki and send out for a re-vote.

Much improved, especially the bit about libraries & Attribution.txt!

A couple of minor comments still...

/t

---

1) License

This file will be named LICENSE.

Note, a number of repositories use "LICENSE-2.0.txt" (eg. device-random, device-modbus-go, device-mqtt-go, device-sdk-go).

Also, I didn't check *every* repository, but I did notice that there's no LICENSE in security-secret-store. We might want to perform some sort of audit on the rest of our repos.

2) Responsibilities

 - there seems to be a stray "EdgeX" on the line preceding this section. Is that intentional?

 - last <p> "Ubuntu Snap" -> "snap package"

 

 

Thanks and have a good weekend everyone.

Jim

 

From: Tony Espy [mailto:espy@...]
Sent: Thursday, December 13, 2018 6:00 PM
To: White2, James; edgex-tsc@...
Subject: Re: [Edgex-tsc] TSC vote on License and Attribution policy

 

[EXTERNAL EMAIL]

On 12/13/18 12:57 AM, James.White2@... wrote:

TSC members,

 

Per today’s TSC meeting, please review and vote on the proposed License and Attribution Files policy found here:  https://wiki.edgexfoundry.org/pages/viewpage.action?pageId=21823866

 

If you are in favor of this clarification to our contributor process and guidelines, please respond to this email with a +1.

If you would like to modify the wording, please respond with your proposed changes.

1) "Ubuntu Snap" --> "snap package"

2) I think this needs some re-wording:

When ever a contributor adds a product or dependency on another 3rd party tool, library, package, or other product to EdgeX...

In particular the "library, package, or other product".  What we're really concerned about are library dependencies which result in code being copied into EdgeX binaries, and thus being re-distributed by EdgeX. Examples include a golang import which statically links library code into a binary, a new C statically linked library, a Java package import (which causes compiled class files to get copied into Jars), ...

That said, code linked dynamically needs to be treated more akin to tools or applications as explained below, however I'd like a second opinion on this.

So I'd suggest:

Whenever a contributor adds a new dependency on a 3rd party programming library (i.e. C library, Golang/Java package, ...) to EdgeX...

That said, with respect to our container artifacts, if new non-EdgeX tools or applications are required at runtime, then the licenses of those products need to be included, but not in an Attribition.txt file.

Does that make sense?

3) Contributors must create an Attribution.txt file when submitting the initial Pull Request for any new EdgeX Foundry repository.

I would say "for each binary or external library package built from the repository". For instance our edgex-go has multiple Attribution.txt files for each service binary, and for its exported packages.

3) This Attribution file should contain any used/referenced open source in the repository (see Contents below).

Suggest: This Attribution file should enumerate all used/referenced 3rd party libraries for a given binary or library.

Also is it our policy that all 3rd party libraries used by the core EdgeX code are open source, as long the license is compatible with Apache 2.0? I think the answer is yes, but wanted to double check whether we've explicitly stated this anywhere?

Regards,
/tony

[1] https://en.wikipedia.org/wiki/Library_(computing)

 

 

 

Non-TSC members of the EdgeX community are encouraged to provide a non-binding vote or suggest modifications as well.

 

Thanks,

Jim White

Distinguished Engineer, IoT Platform Development Team Lead

EdgeX Foundry Technical Steering Committee Vice Chairman

Dell Technologies | IoT Solutions Division

Office +1 512-723-6139, mobile/text +1 612-916-6693

james_white2@...