On 07/03/2023 07:14, Han Li wrote:
On Mar 7, 2023, at 14:39, Konstantin Kolinko <knst.koli...@gmail.com> wrote:
вт, 7 мар. 2023 г. в 09:17, <li...@apache.org <mailto:li...@apache.org>>:
This is an automated email from the ASF dual-hosted git repository.
lihan pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 1fc4b7c95d Align with spec
1fc4b7c95d is described below
commit 1fc4b7c95dce1db3d86db9393c78023b93725f63
Author: lihan <li...@apache.org>
AuthorDate: Tue Mar 7 14:16:53 2023 +0800
Align with spec
-1 (veto)
Please revert.
Ok.
The text of the specification comes with a license.
I have not checked recently (with the spec is managed by Eclipse
Foundation), but in earlier times (for specs copyrighted by Oracle) it
was clear that you were not allowed to copy their text as you wish.
You are not the first one to make such changes. There were similar
discussions in earlier years.
I probably understand what means, and I have another question that if I just
align code with spec there’s no problem, right?
That is generally problematic too.
It is OK to copy the stuff we have to copy to implement the spec - i.e.
the method signatures.
While there may be other parts of the code where copyright does not
apply, that judgement is a subjective one. The only place to get a
definitive answer is in the courts.
Generally, we should not be copying anything apart from the message
signatures from the specifications.
It is worth mentioning a couple of complicating factors:
- A long time ago the specification projects were based at the ASF so
some of the code has ASF license headers and copyrights.
- I am a committer both here and for most of the specifications that
Tomcat implements so it is possible for me to commit the same changes
to both projects under different licenses. It is not possible for
someone else to take my work from one project and commit to the other
and change the license. If anyone else does that, the original license
has to be retained (which creates legal hoops for folks to jump
through if the copy is taken in either direction).
One of the tests in the TCK is to ensure that the spec has the correct
public API. Tomcat passes those tests for all stable versions so there
should not be any changes in the public API between Tomcat and the
specification projects.
You may occasionally see differences in the public API in the current
development branch. That is usually because I am working on a change to
the specification.
There are differences in implementation detail. These are expected given
that the implementation has been developed in separate projects by
(mostly) different teams.
If you identify differences in functional behavior then that is worth
looking at a little more closely. Usually the change history and
associated comments provides and explanation. To give a couple of examples:
- There are a couple of Tomcat specific features that required changes
in the specification classes.
- If the specification language was ambiguous, the specification project
and the Tomcat may interpret the language differently resulting in
slightly different behavior (the specification projects are trying to
clarify these as they find them).
- You might have found a bug.
Sorry this turned out to be such a long email. If you got this far,
thanks for taking the time to read it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
