Patch to remove author and date comments

[ceeac]

This patch removes all "@author <name>", "<name>:", "@date" and similar comments from the code where possible (unless I missed some).
This reduces the number of non-ASCII characters in the code even further.
The patch is here and should apply cleanly to r8942. (Can't attach the patch due to attachment size restrictions)

[Mariculous]

What's wrong with @author and @date?

[jamespetts]

Is this patch compatible with the Artistic Licence 1.0?

[prissi]

Those are almost never correct any more; lots and lots of people worked on the code. Also many of these are at trivial location (like returning the name of the helpfile ...)

However, this is a little more critical, since it may break patch files. Not a show stopper though.

I assume you got this by using a script and then got through? In this case, sharing the script would be helpful too, as this could be applied to any patches and thus minimizing conflicts.

And why should it not be compatible. The information there was not correct in the first place.

[Leartin]

And why should it not be compatible. The information there was not correct in the first place.

For two reasons:
In paragraph 3, the license requires each change to be documented within the file. Technically, any undocumented change would not be covered by the license in the first place, so all @author and @date are a requirement.
In paragraph 1, the license requires you to duplicate all copyright notices. Where does it state those need to be 'correct'?

It seems to me that the "copyright holder" can ignore paragraph 3, and could also change the copyright notice that made them the copyright holder. But even assuming thats "The Simutrans Team" (and not Hajo, even though he is/was named everywhere), the 'team' as an entity can not make decisions. If it could, it could also eg. decide to use a different license.

[DrSuperGood]

What's wrong with @author and @date?

The SVN log is much more accurate at resolving who did what and when. Most functions and files have had many people work on them and individual parts may be updated by many people. It is far better to clean up the source code and leave SVN (or GIT for extended) to handle the crediting of individual pieces of code.

[prissi]

About 50% hold the files, and all the ones with Hajo also had a message with the Simutrans team. The recent change is just a clarification. Especially, it states in each file, see LICENSE.TXT

This is the beauty of an abstract person, rather than a name. Such an entity is composed whoever is active but still holds the copyright. Se we can change the sourcecode as we fit, as long as the license is not changed.

I think the artistic license can tolerate the code to be also under another license. But this is for lawyers as well.

[Phystam]

We can contact with the author of the code, basically. That is very important.
If you cannot understand what/why it is, you can ask. If removed, we can never get any information about that from the code or documentation.

[ceeac]

I assume you got this by using a script and then got through? In this case, sharing the script would be helpful too, as this could be applied to any patches and thus minimizing conflicts.

Unfortunately, there is not script - I used regexp search and replace for semi-automatic replacement and some manual fix-up afterwards.

To keep the size of the diff down and to make updating other patches easier I think it is best to commit this patch in parts when/if it gets committed (like one commit per directory). Hopefully this will also make reviewing the changes easier.

We can contact with the author of the code, basically. That is very important.
If you cannot understand what/why it is, you can ask. If removed, we can never get any information about that from the code or documentation.

But then again, svn log and svn blame are much more accurate in this regard than some comments which need to be kept in sync with the code.

[prissi]

Ok, incorporated in r8951. Now a similar thing is needed for experimental, or crossporting will become even more challenging ...