Hello @olexii4
Do you have examples such of jub for NodeJs project ?

@olexii4

• 99 % of the che-code dependencies are VS Code dependencies.
• I believe che-code dependencies should be as close to upstream as possible - this guarantees stability of the che-code assembly

So, could you clarify please:

• what's the benefit of adding this Github check?
• are you going to support that Github check?
• let's say you are going to change just a version of a lib - but actually - it's VS Code dependency - are you going to contribute such change directly to the upstream? If so - then probably it makes sense to propose adding this Github action to VS Code?

I just want to get a whole picture...
thanks in advance for your answers!

@RomanNikitenko As Eclipse-Che developers, we are responsible for the third-party software components used in your product. So, we need to be sure about the licenses. We need to know about the license issues before we provide our product to customers. It is our responsibility.

We will see all the licenses. If we find a license issue, we can discuss and decide what to do about it. We need to know what we will use in our product.

Do you agree with this?

@ibuziuk WDYT?

@olexii4
My point is:

• 99 % of the che-code dependencies are VS Code dependencies
• che-code dependencies should be as close to the upstream as possible - it's question of the che-code assembly stability

@tolusha I prepare a draft PR as a sample che-incubator/che-code#527

@olexii4 My point is:

• 99 % of the che-code dependencies are VS Code dependencies
• che-code dependencies should be as close to the upstream as possible - it's question of the che-code assembly stability

@RomanNikitenko It is a problem of a 'che-editor'. VS Code just a one third-party software components that is used as one of our 'che-editor'.

@olexii4

VS Code just a one third-party software components that is used as one of our 'che-editor'.

this component hardly depends on the upstream

but sorry, I just trying to understand what is the plan

let's say a dependency is added on the VS Code side (as usual)
this check is failed for that dependency

what's the plan?

• reimplement the corresponding logic using another dependency?

@RomanNikitenko We have several che-editors, one of which is che-code which depends on third-party software components(VS Code).
I suggest adding an automatic check of the license when updating third-party software components. After this check, we could analyze the results and discuss what to do with it.

@ibuziuk Is it worth having this information before product release? WDYT?

@olexii4
as far as I understand there is a ready for review report in your draft https://github.com/che-incubator/che-code/pull/527/files
could you analyze that report and provide your review for it?

do you have any thoughts/suggestions about my question in the previous comment?

Since we are part of the Eclipse Foundation, we should fall back on the official tools and processes

• https://github.com/eclipse-dash/dash-licenses
• https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab
• https://www.eclipse.org/lists/eclipse.org-members-committers/msg01284.html

I don't know if it matters in this matter, but:

• che-code was moved from the eclipse-che to the che-incubator
• maybe it was done as che-code - is a fork of the VS Code and as I mentioned above 99 % deps - are VS Code deps

anyway, it looks like no one has the answer on the question - what is the plan about those VS Code dependencies...(see #23363 (comment))

is a fork of the VS Code, and as I mentioned above 99 % deps - are VS Code deps

@RomanNikitenko it would be interesting, though to track 1% somehow - for VS Code deps we should be safe and piggyback on Visual Studio Code - Open Source ("Code - OSS") which is MIT

is a fork of the VS Code, and as I mentioned above 99 % deps - are VS Code deps

@RomanNikitenko it would be interesting, though to track 1% somehow - for VS Code deps we should be safe and piggyback on Visual Studio Code - Open Source ("Code - OSS") which is MIT

for this goal, I believe, it's enough to track few extensions with the che- prefix: https://github.com/che-incubator/che-code/tree/main/code/extensions