@QuentinÂ: I disagree, I think that having one
component undergo the license migration will help to debunk
The license migration for the main repo will be
a lot safer if we already did it once with SysML 1.4.
+1 for changing into Eclipse Papyrus
Weâll be waiting for the committee approval for
migrating the main repository and this will be the first to
undergo the migration. As for the auxiliary repositories
they should be treated afterwards as needed on a case by
case review until we have a satisfactory state across the
Ok for Eclipse Papyrus.
For papyrus we received the request to switch
to EPL2 for the next version during the review.
Before going to EPL2, I will inform our CEA
Each module of papyrus will change the license
little by little.
Thanks for all the answers.
âEclipse Papyrusâ is ok for me.
Does anyone have an objection?
I agree that moving everything to EPL2 in on go
would be the best but due to the size of the project and the
number of plugin, I donât think itâs possible. But if we
agree on the new license then we can
Change license for all incoming component
Change the license in Papyrus core/toolsmith
Can anyone confirm that there isnât any fishing
dual licensing stuff ?
I recall that once upon a time "Eclipse
Modeling Project" was very strongly recommended, but recent
practice has changed; Eclipse Xtext, Eclipse Mylyn, Eclipse
DLTK. I've migrated to Eclipse OCL, Eclipse QVTd. So I
suggest Eclipse Papyrus. "Project" is bloat.
On 26/06/2018 14:38,
Camille Letavernier wrote:
I've no opinion
for the license part; but projects should follow the
Eclipse <ProjectName> pattern . So it would
be either Eclipse Modeling (Project) or Eclipse
Papyrus (Project). Note that this is decided at the
PMC level , which is probably why we're using
Eclipse Modeling Project.
The provider name
should be the full project name. If the name does not
already do so, then prefix it with the name of the
forge, e.g. "Eclipse EGit", "Eclipse SWTBot", or
Every plug-in and
feature must specify a descriptive provider-name (for
features), or Bundle-Vendor header (for plug-ins), as
determined by the project's PMC (e.g. "Eclipse
Modeling Project" rather than "Eclipse.org")
Eclipse public license v1.0 is now
deprecated (see ), and itâs recommended to move
to EPL v2.
In my understanding when simply
moving from EPLv1 to EPLv2 there is no legal
and headers and other files should be
updated accordingly (See ).
Following Photon train release, I
will publish a SysML 1.4 version compatible with
Papyrus 4.0.0 (Photon)
This version will be number 1.3.0 and
I want to take this opportunity Âto update the
I created a dedicated bug  and
also a patch 
Any comments ? It would be nice if
someone can check the patch.
I discovered the shared
license concept in feature. (It would be nice to
use it in Papyrus core)
Can we agree to change the
name of Bundle-Vendor from Eclipse Modeling
Project to (one of them)
Eclipse Papyrus Project
(this are patterns used by
other projects but Iâm open to anything containing
=> The main reason is
to remove Papyrus prefix from the name of the
plugins (should improve the clarity)
mdt-papyrus.dev mailing list
To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
Senior Software Engineer
Manager: Remi Schnekenburger
Office:Â7 rue de la Croix Martre, 91120
Commercial RegisterÂ824 977
mdt-papyrus.dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit