| Re: [incubation] IP policy for transitive dependencies |
|
That makes sense. I just had a look at IPZilla. It appears that the result of a verification is neither captured on its own, nor re-used (e.g. search for “log4j
1.2.15”). If the intent is really to make sure license matches code and provenance, for a given library+version, shouldn’t that be capturable and re-usable? Any reason why this couldn’t be made public (currently it requires an eclipse login)? Thanks Moh From: incubation-bounces@xxxxxxxxxxx [mailto:incubation-bounces@xxxxxxxxxxx]
On Behalf Of Wayne Beaton I assume that by "this process" you mean the Eclipse IP Due Diligence Process. The short answer is that the Eclipse IP Policy requires it and the Eclipse Board of Directors requires that Eclipse Projects conform to the Eclipse IP Policy. You're right. We do more than Apache does. FWIW, we regularly feed issues that we discover back to Apache projects. I'll argue that--at least in the general case--the "legal status of both licenses and their inclusion" is not universally well-understood. At least in part, the Eclipse IP Process exists so that software developers don't have to think about
all the nitty-gritty nuances of licenses and such. Regardless, our policy requires that we have confidence that content is licensed correctly. We do frequently find, for example, content that is not clearly licensed or may have a different license on some files. Basically, we don't necessarily
trust that the declared license for third-party content matches the actual content. This is why we set up "Type A" Due Diligence for third party content to require the use of a tool (the tools allows us to process things more quickly than can be done manually,
with generally high confidence in the results). Capturing it all in CQs in IPZilla satisfies our accounting requirement. During more thorough review (which we do for all project code and "Type B" third party content due diligence), we validate that the provenance of the content is known, past relicensing exercises are valid, and all sorts of other things.
Again, the IP Team regularly finds anomalies that run counter to the declared license. The basic idea is to reduce the legal risk associated with adoption/consumption of the software. I spent a little time looking through our documents for a simple statement that might serve as a response, but didn't find one (It's late and I may just have not found it because I'm pretty tired). This seems like an obvious addition for
the
Legal FAQ or
Committer Due Diligence Guidelines document. I'll make sure that we add something. Wayne On Tue, Sep 26, 2017 at 10:49 PM, Rezaei, Mohammad A. <Mohammad.Rezaei@xxxxxx> wrote: I’ve been meaning to ask this for a while: why is this process in place given that the legal status
of both licenses and their inclusion is well understood? Apache certainly doesn’t do this. They just have a pretty clear page (https://www.apache.org/legal/resolved.html
) of what can and cannot be done. Only if something is not on that page does it require a review (after which, it’s added to that page).
For common licenses, this sort of thing is even listed on Wikipedia:
https://en.wikipedia.org/wiki/License_compatibility
I’m trying to be critical, just trying to understand what I’m (legally) missing here. Thanks Moh From:
incubation-bounces@xxxxxxxxxxx [mailto:incubation-bounces@xxxxxxxxxxx]
On Behalf Of Wayne Beaton All content must be taken through the Eclipse IP Due Diligence Process. This includes all dependencies, dependencies of dependencies, etc. [recursive]. FWIW, the operating system and virtual machine are technically dependencies, but we classify them "exempt pre-reqs" per the
Guidelines for the Review of Third Party Dependencies (implied, because we don't bother with actual CQs). This is easy to think about in the context of a monolithic packaged deliverable. Basically anything that's in that hypothetical monolithic package must be taken through the Eclipse
IP Due Diligence Process. It's a little harder to think about when you distribute, say, a Maven JAR. Strictly speaking, you are only distributing that one JAR. But in the process of resolving that JAR, the
consumer will need all sorts of other third party content; this content is all "pre-req dependencies" that we need the Eclipse IP Team to review. Perhaps the most general way of thinking about it is that you need a CQ for all third party content related to your project code that will end up in a product built using your project's
technology. It's on this basis that we can, for example, categorize
build and test dependencies as "works with". I suspect, however, that I'm venturing off topic... HTH, Wayne On Tue, Sep 26, 2017 at 8:07 AM, Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx> wrote: Hi, in the IoT PMC we often review CQs by projects for components which the project relies on during runtime (not optionally but as a full pre-req). Some of these components themselves rely on many other components. We are often asked, whether the project needs
to create CQs for all of these transitive dependencies as well (given that they are not optional but required during runtime).
The project handbook [1] states that "All third-party libraries required by project code will have to be checked and approved by the IP Team." Following is a list of cases which constitute a "library required by the project". That list is described as "non-exhaustive" and in fact does not explicitly mention transitive
dependencies. My understanding is that transitive deps definitely need to be checked/approved, but I would like to get some feedback e.g. frmo Wayne whether this is actually the case. Mit freundlichen Grüßen / Best regards Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB 148411 B
--
Wayne Beaton Director of Open Source Projects The Eclipse Foundation
-- Wayne Beaton Director of Open Source Projects The Eclipse Foundation |
