RFR [9] 8077332: tidy warnings from javax/xml

huizhe wang huizhe.wang at oracle.com
Mon Apr 13 18:19:46 UTC 2015


On 4/13/2015 4:42 AM, Alan Bateman wrote:
> On 13/04/2015 12:22, alexander stepanov wrote:
>> Hello Joe,
>>
>> Thank you for the notes;
>>
>> > Copyright year shall not be changed.
>>
>> That seems to be a bit controversial point; sometimes (while cleaning 
>> docs) I was asked to do that, other times - not to do that. Our 
>> internal policy seemingly assigns to change the 2nd date every time 
>> the sources were touched (but that may be a question of ambiguous 
>> interpretation).
>>
>> But of course I can easily revert these changes if you're totally 
>> sure it should be done.
>>
> This has always been confusing. Some areas insist on updating the 
> copyright dates, others don't. AFAIK, it has always been optional. I 
> think the original assumption was that the update_copyright_year 
> script (in the top-level repo) be run periodically to do bulk updates. 
> Unfortunately that script doesn't seem to be run very often now and 
> this strengthens the case to update the dates on a continuous basis. I 
> have not come across the argument that html tidy tasks that don't 
> change the javadoc should not update the copyright date. The general 
> topic probably should move to jdk9-dev and get this decided once and 
> documented in the developer guide.

I think the key question to ask is: is this the code I can claim 
Copyright with? To me, format, code style, html tags and other minor 
changes, these are not code changes one can claim copyright with.

The date of a Copyright establishes how far back the claim is made. In 
case where the work is substantially revised, a new Copyright claim is 
established, which is what the 2nd year is about.

In this case, esp. for the JAXP API (e.g. javax.xml.datatype), I'd like 
to see the years maintained because those are the years the API was 
designed and modified. The "tidy warnings" change did not change the API.

-Joe

>
> -Alan




More information about the core-libs-dev mailing list