Re: daffodil-vscode - how to package and identify the contribution - some git questions
I think I have a good example for you to use. The plc4x apache project played around with daffodil and created a DFDL schema for an industrial control protocol called s7. So it's a not too difficult binary data format. But it is a real format. Everything is already apache licensed, and at Owl we test it against every Daffodil release, so we know it continues to work. tarball attached. From: Beckerle, Mike Sent: Thursday, September 16, 2021 2:56 PM To: dev@daffodil.apache.org Subject: Re: daffodil-vscode - how to package and identify the contribution - some git questions Suggest you just excise this file, and any tests that depend on it for now. We can wire in a new example workspace and add in tests subsequently before the first "release" of this. From: John Wass Sent: Thursday, September 16, 2021 10:48 AM To: dev@daffodil.apache.org Subject: Re: daffodil-vscode - how to package and identify the contribution - some git questions > I know of one file in the repo which will have to be removed which is the jpeg.dfdl.xsd file, which is there just as an example workspace. I assume this issue remains, and needs to be addressed prior to giving this the done stamp. We could just remove that sample workspace, the setup is trivial and is addressed in the docs, but that schema and jpg also exist for unit tests. Looking through the test resources in Daffodil now, any suggestions on a good candidate are welcomed. On Thu, Sep 9, 2021 at 2:11 PM Beckerle, Mike wrote: > I know of one file in the repo which will have to be removed which is the > jpeg.dfdl.xsd file, which is there just as an example workspace. > > The copyright and provisions of that are not compatible with Apache > licensing. > > We can find a DFDL schema that we created that has Apache license to use > instead. > > For the other files under src, server, and build, can we generate a list > of files identifying which are: > > (a) original MIT-licensed, unmodified > (b) new - can be ASL > (c) blended - started from MIT-licensed source, modified with > daffodil-vscode-specific changes. > > It is these blended files that are the problematic ones. > > > > > From: Steve Lawrence > Sent: Thursday, September 9, 2021 1:38 PM > To: dev@daffodil.apache.org > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > Correct. For more information about Apache license compatibility: > > https://www.apache.org/legal/resolved.html > > MIT is Category A and is fine. EPL is Category B and is also okay, but > generally only in its binary form. So these top-level dependencies look > okay, assuming their transitive dependencies are also okay. > > We'll also need to verify the licenses of all code in the repo. > Hopefully little of that is original microsoft MIT and can be granted to > ASF and relicensed. > > > On 9/9/21 1:30 PM, Beckerle, Mike wrote: > > The requirement, is that the entire dependency tree (transitively) > cannot depend on any software that has an Apache-incompatible (aka > restrictive) license. > > > > So we need the transitive closure of all dependencies. > > > > > > > > From: Adam Rosien > > Sent: Thursday, September 9, 2021 12:44 PM > > To: dev@daffodil.apache.org > > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > > > (I don't understand the requirements of licencing + transitive > > dependencies, so I'm giving some surface level license info) > > > > "ch.qos.logback" % "logback-classic" % "1.2.3" - EPL > > http://logback.qos.ch/license.html > > "com.microsoft.java" % "com.microsoft.java.debug.core" % "0.31.1" - EPL > 1.0 > > "co.fs2" %% "fs2-io" % "3.0.4" - MIT > > "com.monovore" %% "decline-effect" % "2.1.0" - APL 2.0 > > "org.typelevel" %% "log4cats-slf4j" % "2.1.0" - APL 2.0 > > > > On Thu, Sep 9, 2021 at 9:35 AM Adam Rosien wrote: > > > >> I can relay the list of dependencies and their licenses. > >> > >> On Thu, Sep 9, 2021 at 9:20 AM Steve Lawrence > >> wrote: > >> > >>> I personally don't care too much about having the existing git history > >>> once its part of ASF, especially if it makes thing any easier (as you > >>> mention, squash/rebase can be difficut through merges). So I'd say we > >>> just do plan B--create a tarball of the current state (without the git > >>> history), and the content of that tarball is what goes through the IP > >>> clearance process, and is the content of the inital commit when adding > >>> to the apache/daffodil-vscode repo. > >>> > >>> Note that I think the incubator will still want access to the existing > >>> repo so they can view the full git history. Understanding where > >>> everything came from and verifying the provenance is important to > >>> ensuring we have all the appropriate CLA's. So while the tarball is > >>> maybe what is officially
Re: daffodil-vscode - how to package and identify the contribution - some git questions
Suggest you just excise this file, and any tests that depend on it for now. We can wire in a new example workspace and add in tests subsequently before the first "release" of this. From: John Wass Sent: Thursday, September 16, 2021 10:48 AM To: dev@daffodil.apache.org Subject: Re: daffodil-vscode - how to package and identify the contribution - some git questions > I know of one file in the repo which will have to be removed which is the jpeg.dfdl.xsd file, which is there just as an example workspace. I assume this issue remains, and needs to be addressed prior to giving this the done stamp. We could just remove that sample workspace, the setup is trivial and is addressed in the docs, but that schema and jpg also exist for unit tests. Looking through the test resources in Daffodil now, any suggestions on a good candidate are welcomed. On Thu, Sep 9, 2021 at 2:11 PM Beckerle, Mike wrote: > I know of one file in the repo which will have to be removed which is the > jpeg.dfdl.xsd file, which is there just as an example workspace. > > The copyright and provisions of that are not compatible with Apache > licensing. > > We can find a DFDL schema that we created that has Apache license to use > instead. > > For the other files under src, server, and build, can we generate a list > of files identifying which are: > > (a) original MIT-licensed, unmodified > (b) new - can be ASL > (c) blended - started from MIT-licensed source, modified with > daffodil-vscode-specific changes. > > It is these blended files that are the problematic ones. > > > > > From: Steve Lawrence > Sent: Thursday, September 9, 2021 1:38 PM > To: dev@daffodil.apache.org > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > Correct. For more information about Apache license compatibility: > > https://www.apache.org/legal/resolved.html > > MIT is Category A and is fine. EPL is Category B and is also okay, but > generally only in its binary form. So these top-level dependencies look > okay, assuming their transitive dependencies are also okay. > > We'll also need to verify the licenses of all code in the repo. > Hopefully little of that is original microsoft MIT and can be granted to > ASF and relicensed. > > > On 9/9/21 1:30 PM, Beckerle, Mike wrote: > > The requirement, is that the entire dependency tree (transitively) > cannot depend on any software that has an Apache-incompatible (aka > restrictive) license. > > > > So we need the transitive closure of all dependencies. > > > > > > > > From: Adam Rosien > > Sent: Thursday, September 9, 2021 12:44 PM > > To: dev@daffodil.apache.org > > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > > > (I don't understand the requirements of licencing + transitive > > dependencies, so I'm giving some surface level license info) > > > > "ch.qos.logback" % "logback-classic" % "1.2.3" - EPL > > http://logback.qos.ch/license.html > > "com.microsoft.java" % "com.microsoft.java.debug.core" % "0.31.1" - EPL > 1.0 > > "co.fs2" %% "fs2-io" % "3.0.4" - MIT > > "com.monovore" %% "decline-effect" % "2.1.0" - APL 2.0 > > "org.typelevel" %% "log4cats-slf4j" % "2.1.0" - APL 2.0 > > > > On Thu, Sep 9, 2021 at 9:35 AM Adam Rosien wrote: > > > >> I can relay the list of dependencies and their licenses. > >> > >> On Thu, Sep 9, 2021 at 9:20 AM Steve Lawrence > >> wrote: > >> > >>> I personally don't care too much about having the existing git history > >>> once its part of ASF, especially if it makes thing any easier (as you > >>> mention, squash/rebase can be difficut through merges). So I'd say we > >>> just do plan B--create a tarball of the current state (without the git > >>> history), and the content of that tarball is what goes through the IP > >>> clearance process, and is the content of the inital commit when adding > >>> to the apache/daffodil-vscode repo. > >>> > >>> Note that I think the incubator will still want access to the existing > >>> repo so they can view the full git history. Understanding where > >>> everything came from and verifying the provenance is important to > >>> ensuring we have all the appropriate CLA's. So while the tarball is > >>> maybe what is officially voted on, they will want access to the repo. > >>> > >>> That said, I don't think we are going to get CLA's for any Microsoft > >>> contribute code. So either all Microsoft contributed code will need to > >>> be kept MIT, or removed from the codebase. And if feels a bit odd to > >>> grant something to ASF where the original codebase stays MIT and isn't > >>> part of that grant. > >>> > >>> I think understanding how much code still exists that is Microsoft/MIT > >>> is going to be important to getting this through the IP clearance > process. > >>> > >>> So I'm curious how much of that original Microsoft code still
Re: daffodil-vscode - how to package and identify the contribution - some git questions
> I know of one file in the repo which will have to be removed which is the jpeg.dfdl.xsd file, which is there just as an example workspace. I assume this issue remains, and needs to be addressed prior to giving this the done stamp. We could just remove that sample workspace, the setup is trivial and is addressed in the docs, but that schema and jpg also exist for unit tests. Looking through the test resources in Daffodil now, any suggestions on a good candidate are welcomed. On Thu, Sep 9, 2021 at 2:11 PM Beckerle, Mike wrote: > I know of one file in the repo which will have to be removed which is the > jpeg.dfdl.xsd file, which is there just as an example workspace. > > The copyright and provisions of that are not compatible with Apache > licensing. > > We can find a DFDL schema that we created that has Apache license to use > instead. > > For the other files under src, server, and build, can we generate a list > of files identifying which are: > > (a) original MIT-licensed, unmodified > (b) new - can be ASL > (c) blended - started from MIT-licensed source, modified with > daffodil-vscode-specific changes. > > It is these blended files that are the problematic ones. > > > > > From: Steve Lawrence > Sent: Thursday, September 9, 2021 1:38 PM > To: dev@daffodil.apache.org > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > Correct. For more information about Apache license compatibility: > > https://www.apache.org/legal/resolved.html > > MIT is Category A and is fine. EPL is Category B and is also okay, but > generally only in its binary form. So these top-level dependencies look > okay, assuming their transitive dependencies are also okay. > > We'll also need to verify the licenses of all code in the repo. > Hopefully little of that is original microsoft MIT and can be granted to > ASF and relicensed. > > > On 9/9/21 1:30 PM, Beckerle, Mike wrote: > > The requirement, is that the entire dependency tree (transitively) > cannot depend on any software that has an Apache-incompatible (aka > restrictive) license. > > > > So we need the transitive closure of all dependencies. > > > > > > > > From: Adam Rosien > > Sent: Thursday, September 9, 2021 12:44 PM > > To: dev@daffodil.apache.org > > Subject: Re: daffodil-vscode - how to package and identify the > contribution - some git questions > > > > (I don't understand the requirements of licencing + transitive > > dependencies, so I'm giving some surface level license info) > > > > "ch.qos.logback" % "logback-classic" % "1.2.3" - EPL > > http://logback.qos.ch/license.html > > "com.microsoft.java" % "com.microsoft.java.debug.core" % "0.31.1" - EPL > 1.0 > > "co.fs2" %% "fs2-io" % "3.0.4" - MIT > > "com.monovore" %% "decline-effect" % "2.1.0" - APL 2.0 > > "org.typelevel" %% "log4cats-slf4j" % "2.1.0" - APL 2.0 > > > > On Thu, Sep 9, 2021 at 9:35 AM Adam Rosien wrote: > > > >> I can relay the list of dependencies and their licenses. > >> > >> On Thu, Sep 9, 2021 at 9:20 AM Steve Lawrence > >> wrote: > >> > >>> I personally don't care too much about having the existing git history > >>> once its part of ASF, especially if it makes thing any easier (as you > >>> mention, squash/rebase can be difficut through merges). So I'd say we > >>> just do plan B--create a tarball of the current state (without the git > >>> history), and the content of that tarball is what goes through the IP > >>> clearance process, and is the content of the inital commit when adding > >>> to the apache/daffodil-vscode repo. > >>> > >>> Note that I think the incubator will still want access to the existing > >>> repo so they can view the full git history. Understanding where > >>> everything came from and verifying the provenance is important to > >>> ensuring we have all the appropriate CLA's. So while the tarball is > >>> maybe what is officially voted on, they will want access to the repo. > >>> > >>> That said, I don't think we are going to get CLA's for any Microsoft > >>> contribute code. So either all Microsoft contributed code will need to > >>> be kept MIT, or removed from the codebase. And if feels a bit odd to > >>> grant something to ASF where the original codebase stays MIT and isn't > >>> part of that grant. > >>> > >>> I think understanding how much code still exists that is Microsoft/MIT > >>> is going to be important to getting this through the IP clearance > process. > >>> > >>> So I'm curious how much of that original Microsoft code still exists? I > >>> assume since it was just example code it has mostly been replaced? If > >>> that's the case, we could potentially say Microsoft has no ownership of > >>> this code, and so their CLA and MIT license aren't necessary? > >>> > >>> We should also have a good understanding of the dependencies. If any of > >>> them are not compatible with ALv2, then going through this process > isn't > >>> even worth
