[iot-pmc] [CQ 18809] com.augustcellars.cose.cose-java-0.9.7

[emo-ip-team@xxxxxxxxxxx]

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=18809





--- Comment #23 from Jens Reimann <jreimann@xxxxxxxxxx>  2019-02-06 04:27:36 ---
(In reply to comment #21)
> (In reply to comment #18)
> > That is my interpretation of the process. It becomes part of the Eclipse
> > project when it is being moved to "org.eclipse". Also, other people noting
> > "org.eclipse" would assume this code is part of the project.
> > 
> > I wonder why it is so hard to keep the original name. Why can't you stick with
> > the original package name?
> > 
> 
> Jens, apart from the specific circumstances of this CQ, I would really like to
> clarify the question whether there is any obligation to keep original package
> names so that we do not need to have the same discussion in the next CQ.
> 
> Here's what I think:
> 
> If the terms that the (third party) code is licensed under allows the usage,
> modification and redistribution then I do not see why an Eclipse project would
> be allowed to chose to consider the code part of their own code base. As long
> as the project adheres to the license terms (e.g. keeping the original
> copyright header etc), there should not be any problem. In fact, this is what
> we do in Hono as well with some classes from vertx-web which are licensed under
> ASL 2.0.

Well, you because it is done in Hono, doesn't make it right?!

> 
> One argument for keeping the original package name might be, that if the third
> party code is never being altered, then it might be easier to replace the
> existing code with a newer version of the third party code. However, whether a
> project wants to do this or not, should be completely up to the discretion of
> the project.

The argument is less about a technical issue, but more about what a consumer
can expect. Putting content under "org.eclipse.<project>" clearly indicates
that this is project content, which it actually is not. An Eclipse project has
a license assigned, which in this case is not correct.

And there is a process to get to be part of an Eclipse project. In the
development process you can find (4.2):

---
Namespaces are assigned to a Project by the EMO. All Project source code must
be organized in the assigned namespaces and Projects can only Release code
under their own namespace (that is, they cannot infringe on another Eclipse
Project’s namespace). Projects should work with their PMCs and the EMO to
request exceptions to this rule, and with their mentors and PMC if there are
questions regarding the use of the namespace.
---

"All Project source code must be organized in the assigned namespaces" -> that
indicates to me that all code organized in the assigned namespace, in fact is
project source code. And not a dependency.

> 
> Again, I have yet to see any place in the Eclipse IP process that would require
> a project to do as you say. So, unless you are able to produce the
> corresponding reference to the IP process, I think we should leave it up to the
> committers of the Californium project, in which package they want to include
> the code. Fair enough?

See above. Also, when it comes to making exceptions, the development clearly
states that EMO will make the decision. So IHMO it is not up to the project.

> 
> Again, this is not about being picky in this particular case. I would like to
> get this clarified once and for all because I am sure that it will affect other
> projects and CQs as well.

I agree this has nothing to do with this particular CQ, and I would appreciate
more explicit wording around this.

I think it would make sense to ask EMO for guidance.


-- 
Configure CQmail: http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the CQ.