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.
|