Dual / Relicence under EPL2.0 / Contribute to Eclipse

[laeubi]

Dual / Relicence under EPL2.0 / Contribute to Eclipse

[mihnita]

First, I must apologize for being unresponsive.

The last few months have been "a bit busy", and in fact I think that will still be the case until end of August or so.

I will check with all contributors if adding an Eclipse license would be OK.

I initially choose Apache 2 because it is permissive.
I've considered the Eclipse license, being an Eclipse plugin, but I did not like the copyleft aspect of it.
So I would rather dual license (if that is possible), instead of "taking away rights"

---

The lack or responsiveness also accounts for a bit of my reluctance to include this in Eclipse proper.
I would like to do it, but I am afraid that if / when something goes wrong I will be the only one "on the hook" to fix it, under pressure.
And with a full time job and a family I would rather have the freedom to say "sorry, please uninstall / downgrade" to the few thousands that installed this plugin, rather than all of Eclipse users.

I don't think of this as dodging responsibility, but more like the responsible thing to do
(don't over-promise, then get Eclipse in trouble by not being able to deliver).

---

Last, there are a couple of issues that I would like to solve before "inflicting" this plugin on all the Eclipse users:

• Issue #66 (which I don't think it's mine, and looks like it will be fixed in Eclipse, after all :-)
• Issue #50, which someone seems to already have contributed a pull request (that I didn't have time to look at :-( )

---

All this being said, I would be really happy to help integrate this into Eclipse, if someone wants to take the lead.
And also help maintaining and improving it, if I am not the only one :-)

[mihnita]

Example of dual license Apache 2 / Eclipse 2:
jetty/jetty.project#5784

[laeubi]

@mihnita no problem and thanks for your feedback, dual license would at least allow for others to take the code and integrate it, but would mostly make sense if you choose to keep this as a separate project.
I'm really interested what rights do you think are "taken away" by the EPL 2.0 on contrast to the APL? e.g one might choose EPL 2.0 with GPL as a "Secondary License", this should give as many freedom as possible I think, but I'm not a licensing expert :-)

Assuming this would be integrated in eclipse, I think it would make more sense to abandon the standalone project and give a reference to eclipse to prevent confusion / diverge of the project.

About responsibilities I think no one will or can put anything on you unless he pays you for that and you accept that offer, but for sure it would be helpful to give some guidance here and there. Beside that I think once this is integrated in eclipse there is also a wider audience of people who can help with fixing and reviewing / merging code so this probably even gets away some responsibilities from you as there are others that could help (don't know if you are probably the only one with write access to this repository).

[mihnita]

That was fast :-) Thank you!

I am no license expert either.
But looking at the Wikipedia "Comparison of free and open-source software licenses"
my first impression is that "Permissive" (Apache 2) is more open than Copylefted (EPL 2)

Not that it really matters... If this becomes part of Eclipse proper I don't see any reason to
continue to exist as a standalone project.
Keep it for a while, until people move to the new Eclipse versions, and then I would probably archive it.

---

About responsibilities I think no one will or can put anything on you

Well, I put it on myself :-)
If I do something and it breaks, and it wastes people's time, then I hold it on myself to fix it.
And with more visibility comes more responsibility :-)

I would be happy to continue supporting it as part of Eclipse (if you guys want me to).
(and I also need some guidance to learn the "Eclipse ropes" :-)

[laeubi]

Well, I put it on myself :-)
If I do something and it breaks, and it wastes people's time, then I hold it on myself to fix it.
And with more visibility comes more responsibility :-)

I just wanted to say that you are not alone, so even if you are absent and there are bug / problems others could jump in, if not the problem might not be that serve anyway ;-)

I would be happy to continue supporting it as part of Eclipse (if you guys want me to).
(and I also need some guidance to learn the "Eclipse ropes" :-)

Eclipse has recently moved to github, so everything you need is to sign the ECA and are ready to contribute (not only console code of course), bigger contributions require an IP clearance but thats nothing you need to care of right now, if you could get in contact with the other contributors and the agree to publish an EPL 2.0 licende variant this could be done in this repository I think.

If you like to support more directly it should even be possible to nominate you as a committer for eclipse once your code contribution was accepted.

[mihnita]

I've contacted all people who contributed anything to this project.
Most approved a pull request to add EPL, but 2 of them did not:
#74

One contributor only had small changes to the README.md file:

• https://github.com/mihnita/ansi-econsole/pull/4/files
• https://github.com/mihnita/ansi-econsole/pull/7/files
• https://github.com/mihnita/ansi-econsole/pull/18/files

And one added an Export-Package directive to MANIFEST.MF:

• https://github.com/mihnita/ansi-econsole/pull/8/files

I've pinged them twice, no answer...

But the changes are minor, I doubt anyone can claim copyright on that.
And those files would not end up in the Eclipse code if merged anyway.

If debatable I can just revert those changes.

All contributors that helped with code approved the PR already.

So, what do you think is best:

1. it's OK to merge that PR with the current approvals (adding EPL 2)
2. should I continue "pinging" the 2 contributors
3. revert their changes, then change the license?

Thank you,
Mihai

[laeubi]

Thanks for your all your effort, I think it is safe to merge and just keep it in mind once we ask for IP approval at Eclipse, they can then decide if any action is required, as you said the Export-Package is nothing one really can 'license' as it is a technical necessity, I also think the REAME changes are not qualify for any IP concerns (and the redme might not be included anyways) so go ahead!

@waynebeaton please correct me if I'm wrong here :-)

[HannesWell]

I've contacted all people who contributed anything to this project. Most approved a pull request to add EPL, but 2 of them did not: #74

Great! Thanks a lot.

After this licensing issue has been finally resolved, is there already a plan how to continue (with Bug 112948)?
@mihnita do you plan/prefer to work on the direct integration into Eclipse or should somebody else from the Eclipse-platform team take care of this?

[waynebeaton]

When you bring the content to the attention of the Eclipse IP Team, be sure to tell them about the license change and point to this discussion. If you have questions/concerns, they can help.

I am not a lawyer and this should not be considered legal advice.

My understanding is that, in the absence an explicit grant of rights (e.g., a CLA) to unilaterally make the change, all copyright holders must agree to a license change. That agreement should be recorded on some durable record (e.g., a GitHub issue).

Note that there is no rule that requires that content contributed to an Eclipse project be contributed under the Eclipse Public License. If some content is contributed under a different license than that of the project (e.g., Apache-2.0 content contributed to a project that distributes content under the EPL-2.0) we would request that you take steps to ensure that the content under the different license is clearly separate (so that contributors can very clearly understand the different licensing terms). Ideally, content under a license that is different from the project license should be kept in a separate repository (or a separate directory at least).

[mihnita]

OK, merged the PR.

[mihnita]

When you bring the content to the attention of the Eclipse IP Team, be sure to tell them about the license change and point to this discussion. If you have questions/concerns, they can help.

Thank you!

I am not a lawyer and this should not be considered legal advice.

Ack :-)

[mihnita]

@mihnita do you plan/prefer to work on the direct integration into Eclipse or should somebody else from the Eclipse-platform team take care of this?

Sorry, I am completely unfamiliar with the Eclipse code and processes.

I don't know if this would be merged almost "as is" (changing namespaces in the process, I assume :-)
(from all I see from the outside the whole Eclipse project is a collection of plugins)

Or it will be "dismantled" and integrated directly in some of the existing *Console classes?

Maybe someone familiar with the Eclipse code can take a look and decide what is the hight level plan.

Then (probably faster) that "someone" can do the work, and I can help as much as I can
(explaining things, who does what and why, and so on).
Or I can try to take a stab at integrating it myself.

You have a lot more experience doing this than I have.
And I will try to play by the rules, with as little hand-holding as I can :-)

[mihnita]

That agreement should be recorded on some durable record (e.g., a GitHub issue).

They approved the pull request (#74)

[laeubi]

I don't know if this would be merged almost "as is" (changing namespaces in the process, I assume :-)
(from all I see from the outside the whole Eclipse project is a collection of plugins)

The process could be roughly like this:

1. We choose a project for the code to host this (https://github.com/eclipse-platform/eclipse.platform.debug seems suitable as it already contains the console stuff)
2. You fork that repository, put your bundles in and transform to the eclipse namespace, this should include AnsiConFeature, AnsiConsole and AnsiConTest
3. integrate them in the build and make sure it succeeds (let us know if you need any help with that!)
4. You open a PR to merge your code (link this issue as well)
5. the we will open a CQ for approval as your contribution is >1000 LOC and contains content not only created by you
6. It hopefully will be approved, we can merge and further proceed / decide / integrate, I think a first step would be to include this then in the usual EPPs gather feedback and fix bugs and then we might change the "standard" console to have ANSI on by default.

[HannesWell]

That sounds like a good plan.
As a zeroth step we could consider to take the relevant projects as they are and commit them to the target repository referencing the originating repository-URL and commit-id a second commit could then the changes suggested by Christoph.
This way we should trace 100% of the changes.
I'm not very familiar with the code but maybe it would be better to fully integrate the code into an existing plug-in. But that is something we can figure out in the process. :)

[laeubi]

As a zeroth step we could consider to take the relevant projects as they are and commit them to the target repository referencing the originating repository-URL and commit-id a second

Contributed code should be "copied" without the history if migrating code to eclipse.

I'm not very familiar with the code but maybe it would be better to fully integrate the code into an existing plug-in

A separate plugin would make sense here, we can move the code around later if desired, but that way one can 'opt-in' for a while to include ANSI or not.

[mihnita]

Thank you very much Hannes, Christoph.

Update: it all sounds good.
Separate plugin sounds easier, at least in the beginning.
And "take the relevant projects as they are" also sounds good.

I'll work on it, following the steps Christoph outlined. Seems straightforward.

---

For now though I am working to get a clearance from my employer.
I'm in US, and unfortunately the law is that by default whatever you do belongs to your employer.
Even if you do it on your own machine and time.
(OK, that's the gist. It is a bit more nuanced than that, and there are small differences between states, and the contract one might have signed when accepting the employment offer :-)

TLDR: I don't expect problems, except for some delay.
But I want to make sure I "dot all the i's and cross all the t's" from the legal side.

Regards,
Mihai

[HannesWell]

Great. Thanks for your effort.

I just noticed that you now have the https://github.com/mihnita/ansi-econsole/blob/main/AnsiConsole/src/mnita/ansiconsole/participants/AnsiConsoleMavenLaunchParticipant.java, which is very handy when ANSI-Console is installed separately.
But in the process of contributing this plug-in to eclipse(-debug probably) that part should be removed and instead contributed to eclipse-m2e directly. I had the plan to do something similar as soon as the Eclipse console supports ANSI-colors by default, but if you want to contribute it to m2e it is more than welcome.

[mihnita]

that part should be removed and instead contributed to eclipse-m2e directly

Thank you, yes, no problem, will do that.

There is another improvement that I have in mind, once that happen.
The log level is not colored with the Maven integrated in Eclipse, it is when you use an external Maven install.

[mihnita]

Status update

Still waiting for my employer's clearance, just in case.
Once that happens, I will go with the plan as outlined.

[mihnita]

Meantime, I am really angry about this:

• eclipse-platform/eclipse.platform.debug#40

Should I add copyright headers to all source files?

Thank you very much,
Mihai

[laeubi]

@mihnita I can understand that this might feel you mad, but it also shows two things:

1. the incident was cached early by @HannesWell (thanks for bringing it to attention) and was acted upon
2. obviously there are people eager to get ANSI into eclipse and work on the code

nerveless, about your question the EPL 2.0 FAQ recommends to add the following header to all source files:

/*********************************************************************
* Copyright (c) {date} {owner} [and others]
*
* This program and the accompanying materials are made
* available under the terms of the Eclipse Public License 2.0
* which is available at https://www.eclipse.org/legal/epl-2.0/
*
* SPDX-License-Identifier: EPL-2.0
**********************************************************************/

Still waiting for my employer's clearance

By the way, you might want to add {owner} = your company just in case they are concerned and add you name as a contributor in the header e.g.:

/*********************************************************************
* Copyright (c) {date} {your company} [and others]
*
* This program and the accompanying materials are made
* available under the terms of the Eclipse Public License 2.0
* which is available at https://www.eclipse.org/legal/epl-2.0/
*
* SPDX-License-Identifier: EPL-2.0
* 
* Contributors:
*  - [Mihai Nita](https://github.com/mihnita) (your company) - Initial Implementation and API
**********************************************************************/

Thats very common for eclipse code that is contributed by companies employ people to work on eclipse code.

[mihnita]

Yes, I've noticed.
Thank you very much @HannesWell, and all, I highly appreciate it.
My displeasure is not directed towards any of you.
Nobody (from the Eclipse team) did anything wrong.

Thank you for the suggestion to add the employer to the copyright notice.
Can't do really do that :-)
This is a project from before I started there (and the github history proves it)
I've initiated the approval process about 3 weeks ago, and the end result will be that
they will say they don't have any claim to copyright (or something along these lines)
A bit of bureaucracy, but better safe than sorry...

Thank you!
Mihai

[mihnita]

Update, with good news: I got the copyright waiver from my employer.
So I'm good to go.

I will start with this:
"As a zeroth step we could consider to take the relevant projects as they are and commit them to the target repository referencing the originating repository-URL and commit-id a second commit could then the changes suggested by Christoph."

So I will not change namespace, remove the MavenLaunchParticipant or anything else.
100% "as is"

Then we can take it from there...

---

"When you bring the content to the attention of the Eclipse IP Team, be sure to tell them about the license change and point to this discussion. If you have questions/concerns, they can help."

Should I do that somehow? Or one of you will add them to the initial pull request?

---

Thank you all,
Mihai

[laeubi]

When you open the PR a project committer has to create a CQ for IP clearance, so nothing you have to worry about.

[HannesWell]

I will start with this: "As a zeroth step we could consider to take the relevant projects as they are and commit them to the target repository referencing the originating repository-URL and commit-id a second commit could then the changes suggested by Christoph."

So I will not change namespace, remove the MavenLaunchParticipant or anything else. 100% "as is"

Then we can take it from there...

That's great news. :)

Yes that is at least my suggestion for a 100% traceable way. :)
Exactly, for the first commit, just copy it as it is to the corresponding folder in the org.eclipse.platform.debug repo and add the URL+commitId from this repo in the commit message and commit it just like that. Then in a second commit you can do all the renaming of the plug-ins and namespaces and the removal of then not wanted/needed elements (like the MavenLaunchParticipant). If this requires so much changes in single files that git loses track after renaming I suggest to do the clean up in a third commit and perform only renaming in commit No. 2. Then later we can think about integration the plug-in into an previously existing one, if it is suitable.

And regarding the 'incident' with the concurrent contribution attempt:
I fully understand your displeasure about the events, especially since you already invested effort/time into the the contribution and of course deserve the credit for that and all future work. That's why I tried to raise awareness for your work as soon as I Yannick's message+PR. Although it was probably ok from a legal perspective, I agree that you deserve to go first.
And we would really appreciate to have you and your experience at Eclipse for now and the future.

But I assume he did not act with bad intentions and it was mainly bad communication (which definitely could have been done better). Nevertheless if he or others provides quality contributions (with legal, own work) at Eclipse in the future we will accept that too. In general we accept and appreciate every constructive contribution that is beneficial for Eclipse, regardless who is providing it (given it is legal).
Furthermore I want to clarify that by contributing your code to Eclipse you will loose your full control that you have now. It won't be the case that everything will be changed arbitrarily and your contribution or assessment is ignored, the opposite will be the case, but you won't be able to have the final decision about actions in that part of the code. Even if you contribute regularly and become a committer (like Christoph or myself) you won't be in the position to make a final decision in case of disagreement, that right is at the Project Management Committee (PMC), but from my experience it is very rare that there is no consensus (or at least acceptance) between committers. And since you are the one with the most experience I expect that your assessment will have the most weight (but it won't be infinite). But I'm sure you are aware of that and this also has the positive effect that others can help maintaining the code.
I'm looking forward to the enhanced Eclipse console. It will be great, also because of your contribution. :)

[laeubi]

I think we can just start a commiter-election right after the PR is merged as it is a "larger contribution".

[mihnita]

But I assume he did not act with bad intentions and it was mainly bad communication

I tried not to assume anything, that's why I called those actions "missteps"

It can happen, especially between people who don't know each other, maybe from completely different cultures, maybe with different levels of experience.

you will loose your full control that you have now.

Absolutely!
I agree with the whole paragraph, and I would not expect anything else.
I will be part of the "Eclipse tribe" and follow the rules of the tribe :-)

And I don't expect commit rights, not until the existing team members decide that my contributions are good enough (quality & quantity)
Like most other open source projects :-)

There is no need to worry.
It if alleviates a bit the concerns, here is a link to the Okapi framework list of contributors:
https://www.openhub.net/p/OkapiFramework/contributors
I've been contributing there for 10 years.

But I hope you will see.

[mihnita]

I propose to close this and continue tracking at eclipse-platform/eclipse.platform.debug#47?

[HannesWell]

But I assume he did not act with bad intentions and it was mainly bad communication

I tried not to assume anything, that's why I called those actions "missteps"

It can happen, especially between people who don't know each other, maybe from completely different cultures, maybe with different levels of experience.

Yep, code is easy, people are hard.
Especially when you only have textual communication. But I think most understand your feelings and your reaction. But I think we have handled this unfortunate event now and the good part is coming closer.

you will loose your full control that you have now.

Absolutely! I agree with the whole paragraph, and I would not expect anything else. I will be part of the "Eclipse tribe" and follow the rules of the tribe :-)

Welcome to the tribe, it's great to have you on board. :-D

And I don't expect commit rights, not until the existing team members decide that my contributions are good enough (quality & quantity) Like most other open source projects :-)

This can happen faster than you think. ;-) From my experience (but I'm only on board for a little bit longer than a year) it is mainly about dedication and knowing the basic processes and rules. But I would say the rules are just 'normal' for a collaborative group; be nice to each other, if in doubt: ask, if something broke: ask for help to fix it. And being proficient in Java and Eclipse is also good, but you don't have to know everything, I think nobody does. :)

I propose to close this and continue tracking at eclipse-platform/eclipse.platform.debug#47?

Yes let's close this one. 👍🏽