Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] Type A vs Type B IP due diligence

Hi,

 

Thanks for the info, I didn’t realize the types of the CQ  also affects the type of RDF4J release itself…

 

If type A would be the default, it would indeed make it somewhat easier and probably much faster

(especially when piggybacking a CQ entered by another project, then I guess it doesn’t matter if the CQ being piggybacked is A or B)

 

AFAIK most of the external libraries used by RDF4J are hosted by the ASF or Elastic,

so I assume that the source code of these dependencies was already scrutinized by their respective organizations anyway...

 

 

Best regards

 

Bart

 

 

From: rdf4j-dev-bounces@xxxxxxxxxxx <rdf4j-dev-bounces@xxxxxxxxxxx> On Behalf Of Jeen Broekstra
Sent: zaterdag 26 januari 2019 2:08
To: rdf4j developer discussions <rdf4j-dev@xxxxxxxxxxx>
Subject: [rdf4j-dev] Type A vs Type B IP due diligence

 

As some of you may know, Eclipse offers two types of CQ review for third party dependencies: Type A, and Type B. You can read more about this in the Project Handbook, but summarizing:

  • Type A reviews involve a license compatibility check, are fairly straightforward and in most cases are handled automatically: if the license is an approved compatible license, the CQ is considered license-certified.
  • Type B reviews are a far more exhaustive due diligence check, which in addition to the license check also look at code provenance and various other anomalies. It's a manual code review process on the dependency itself, performed by the Eclipse legal team, and naturally involves a lot of work and takes time. A ype B CQ that is successful is considered approved.

Eclipse projects are free to choose what kind of CQs they use - a project can be a "Type A project", meaning that its releases are (mostly) Type A, and are publicly marked as such, or it can be a "Type B project", meaning that it ensures in its releases that all prerequisites are Type B / approved. A mix is also possible: we can freely choose to do some type A releases, then get our ducks in a row later and do the occassional type B release.

 

In the past, we've chosen to be a full Type B project - meaning that the Eclipse IP team perform full Type B due diligence for all our dependencies, for every release. At least partly this was because the Eclipse process in the past was stricter (and unless I just missed something in the documentation, Type A may actually not have been available as an option for a new project at the time).

 

I've noticed that several of our newly logged CQs have actually been done as Type A. This is not a real problem, except insofar as that if we do a release that involves Type A CQs, our release needs to be publicly marked as Type A (as you can see here, our 2.5 release is currently marked as Type B). I can fix that easily enough, so no worries.

 

So here's the thing: there is value in having full diligence done. However, for the vast majority of our users, this is all academic, and a simple license compatibility check is more than enough. So it boils down to a simple question: going forward, should we make life easier on ourselves and by default log our CQs as Type A (making us effectively a Type A project - license-certified only)?

 

I personally believe this is a good idea. If there is some interested party that prefers full due diligence (e.g. a software vendor that relies on Eclipse's provenance review), we can still choose to do the occasional Type B release, by working with the Eclipse IP team to "bump" our type A CQs.

 

Jeen

 

 


Back to the top