wrapper developed... what now?

[AlexanderLanin]

We wrote a little wrapper around dash-license.jar named dash-license-scan. It has started as a super thin wrapper around dash-license, simply to put lock file parsing into a common place. Over time it grew significantly. And now we need to decide how to continue.

Exemplary wrapper functions:

• We added support for more input formats (uv.lock, requirements.txt, spdx, cargo.lock, etc)
• We've added markdown and json output
• A GitHub action to provide automated PR feedback
• Comparison against eclipse foundation and apache software foundation whitelists, with the idea to provide your own license whitelists
• Split of production and dev dependencies
• etc...

Overall:

• source at https://github.com/eclipse-score/dash-license-scan/tree/dev
• The 1-line wrapper has grown to 1KLOC
• We have quite some more things we will put in there
• We lack sufficiently detailed output of the jar, this is the biggest constraint at the moment

What now?

• Option A: Keep as-is, develop dash-license-scan as a fat wrapper around dash-license
• Option A2: A + add detailed (e.g. json) output option to dash-license
• Option B: Given that we have GPTs we can potentially trivially transform the remainder of dash-license into python
• Option C: Given that we have GPTs we can potentially trivially transform all additions of dash-license-scan into Java - although personally I'm not a fan here

From an efficiency point of view A2 seems best. Unless you guys are interested in B or C?

Cross post from eclipse-score/dash-license-scan#6

[waynebeaton]

How does it compare/complement https://gitlab.eclipse.org/eclipse/technology/dash/ip-analysis ?

[AlexanderLanin]

@waynebeaton there is pretty much no overlap as far as I can tell.
Except that they had the same idea: wrap java-dash with python
And they suffer from the same problem: complex stdout parsing from dash, which does not give sufficient infos

We could extend the same question to cover all 3 tools.

[sschuberth]

Also some comparison to https://eclipse-apoapsis.github.io/ort-server/ might make sense, also it already covers a wide range of package managers thanks to ORT.

[waynebeaton]

@sschuberth I hesitate to put much effort into expanding the Eclipse Dash License Tool; we're actively investigating how we switch over to an Eclipse Apoapsis/ORT based solution. You may have noticed that members of our IP Team have been poking around...

We've discussed with the ETAC and during Committer Office Hours. Apparently, I need to do a better job of sharing our evil plans with the community...

[sschuberth]

we're actively investigating how we switch over to an Eclipse Apoapsis/ORT based solution.

That's very interesting to hear! Coincidentally, I was going through DASH's issues today, and found that quite a few of them either are already implemented in ORT (Server), or can be easily implemented.

So, would it maybe help with your investigations if I offer to label issues where ORT already provides a solution with something like "ORT investigation" or so, to get a better overview? The "how" could be described later, on demand.

Apparently, I need to do a better job of sharing our evil plans with the community...

Yes, please 😆 We (as the Double Open EF member organization) could also assist with closing the gap to DASH, e.g. by making ORT produce DASH-compatible output, to ease your investigations / any migrations.

Feel free top reach out to me directly to discuss any details!

[waynebeaton]

@sschuberth the team will continue this discussion elsewhere. This issue has a specific unrelated focus.

We'll make formal capture and dissemination our thinking and plan a goal for next quarter. We'll set up a meeting with you in early October.

The short version is that everything is on the table. I have not special affinity/love for Eclipse Dash or IPLab. In fact, I believe that we are best-served by their eventual retirement. My primary concerns are that we can correctly implement the IP Policy and that we make transition as seamless as possible for Eclipse project teams. We also acknowledge that adopting Eclipse Apoapsis/ORT will require some development investment from us as well.

Committers: Don't Panic. Any retirement will include a methodical deprecation plan and occur over a period of years.