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 <a...@rosien.net> Sent: Thursday, September 9, 2021 12:44 PM To: dev@daffodil.apache.org <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 <a...@rosien.net> wrote: > I can relay the list of dependencies and their licenses. > > On Thu, Sep 9, 2021 at 9:20 AM Steve Lawrence <slawre...@apache.org> > 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 it until they are replaced. Do you have a list of the >> dependencies? >> >> >> On 9/9/21 11:16 AM, Beckerle, Mike wrote: >> > So the daffodil-vscode code-base wants to be granted to become part of >> the >> > Daffodil project. >> > >> > One question arises which is "what is the contribution?" exactly. >> > >> > The normal way this is identified is by creating a tarball of the >> source files >> > and specifying an sha or md5 hash of that file. >> > >> > However, this code base is perhaps different from usual. >> > >> > It started by creating a detached fork of the vscode debugger example >> code base. >> > This is MIT-Licensed which is a compatible license. >> > >> > The files are then edited. There are around 100 commits on top of the >> base that >> > came from the vscode debugger repository. >> > >> > So the contribution is that set of 100 commits - the >> patches/change-sets they >> > represent. >> > >> > These commits often edit the original files of the vscode debugger >> example to >> > add the daffodil-specific functionality. That is, the contribution >> material is >> > in several cases intermingled in the lines of the existing files. >> That's ok I >> > think so long as the modified file had MIT license. >> > >> > There's some value in preserving the 100 commits by our contributors, >> not >> > squashing it down to one commit, though if it's really not sensible to >> proceed >> > otherwise, we can choose to squash it down to one commit. >> > >> > Furthermore, the vscode debugger example repo itself had many commits >> in it. The >> > current daffodil-vscode repo preserves all these commits as well. I >> don't see >> > value in preserving these commits, and would rather they were squashed >> into a >> > single "starting point" commit, with a dependencies file specifying the >> githash >> > where we forked from, just so we can refer back if necessary. >> > >> > So as a starting suggestion (subject to discussion of other >> alternatives) is this: >> > >> > Plan A: >> > >> > 1. squash all commits up to and including the last Microsoft commit, >> together >> > into one. >> > 2. rebase the remaining commits on top of that. >> > 1. I'm a bit worried about this rebase. There are merge commits, >> etc. in >> > the history. I'm not sure this will just all rebase while >> preserving all >> > the commits, but maybe it will "just work" >> > 3. create a "patch set" corresponding to the 100 or so commits that >> make up the >> > "contribution". >> > 1. I don't know if this is even feasible for this many commits. >> > 4. create a tar/zip of this aggregate patch set. >> > 5. compute an md5 of this patch set. >> > >> > The patch set tar/zip file and its md5 hash are "the granted software". >> > >> > The problem with this idea is that there's no obvious way to review a >> patch set, >> > shy of applying it. >> > >> > A better way may be to change steps 3 - 5 above to >> > >> > Plan B: >> > >> > 3. push the main branch to a new empty git repository >> > The point of this is to remove all historic stuff from the >> repository, >> > i.e., have a minimal git repo that contains only the contribution >> and the >> > single other commit it must be based on. >> > >> > 4. create a tarball of this git repository, and md5 hash of it >> > >> > 5. document that the contribution is from githash X (after the >> first commit) >> > to githash Y (the final commit) of this repository >> > >> > >> > This has the advantage that the contribution is a self-contained >> review-able thing. >> > >> > Other ideas are welcome. (Plans C, D, etc) The only requirements I know >> of are: >> > >> > 1. a single file containing the contribution, and its md5 hash >> > 2. a sensible way one can review the contents of this contribution file >> > 3. preserve history of derivation from the vscode debugger example. >> > >> > >> > >> > >> > >> > >> > >> > >> > Mike Beckerle | Principal Engineer >> > >> > mbecke...@owlcyberdefense.com <mailto:bhum...@owlcyberdefense.com> >> > >> > P +1-781-330-0412 >> > >> >>
