Fix license headers in a number of files

Fix license headers in a number of files

These headers now match the regex used in the presubmit check.

This will simplify adding a tool to check license compatibility for the Android
WebView build.

BUG=138921
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=149222

[Nico, 2012-07-27 16:57:16]

LGTM

Mind numbed.

[jar (doing other things), 2012-07-27 17:36:09]

It sure seems like it is better to change the regex, than to change all these
strings <sigh>.

If there has already been a giant political debate on chromium-dev.... then I'll
leave it alone... and L G T M for base.

If not... then realize that this assault on the tree will, if you persist, need
to repeated each year <sigh>.  Touching files has many painful ramifications,
and I'd *really* vote against this more generally.

If I'm in the minority... then I will relent and proved a base L G T M to help
in your quest.

Can you clarify why you decided on this (questionable) quest, rather than
changing the regex???

[Nico, 2012-07-27 17:38:31]

The regex just disallows the range notation, it doesn't require
updating the year every year.

On Fri, Jul 27, 2012 at 10:36 AM,  <jar@chromium.org> wrote:
> It sure seems like it is better to change the regex, than to change all
> these
> strings <sigh>.
>
> If there has already been a giant political debate on chromium-dev.... then
> I'll
> leave it alone... and L G T M for base.
>
> If not... then realize that this assault on the tree will, if you persist,
> need
> to repeated each year <sigh>.  Touching files has many painful
> ramifications,
> and I'd *really* vote against this more generally.
>
> If I'm in the minority... then I will relent and proved a base L G T M to
> help
> in your quest.
>
> Can you clarify why you decided on this (questionable) quest, rather than
> changing the regex???
>
> http://codereview.chromium.org/10835019/

[jar (doing other things), 2012-07-27 17:40:02]

It sure seems easy to make a regex support the range notation. Why not fix
it??


On Fri, Jul 27, 2012 at 10:38 AM, Nico Weber <thakis@chromium.org> wrote:

> The regex just disallows the range notation, it doesn't require
> updating the year every year.
>
> On Fri, Jul 27, 2012 at 10:36 AM,  <jar@chromium.org> wrote:
> > It sure seems like it is better to change the regex, than to change all
> > these
> > strings <sigh>.
> >
> > If there has already been a giant political debate on chromium-dev....
> then
> > I'll
> > leave it alone... and L G T M for base.
> >
> > If not... then realize that this assault on the tree will, if you
> persist,
> > need
> > to repeated each year <sigh>.  Touching files has many painful
> > ramifications,
> > and I'd *really* vote against this more generally.
> >
> > If I'm in the minority... then I will relent and proved a base L G T M to
> > help
> > in your quest.
> >
> > Can you clarify why you decided on this (questionable) quest, rather than
> > changing the regex???
> >
> > http://codereview.chromium.org/10835019/
>

[Nico, 2012-07-27 17:42:17]

On Fri, Jul 27, 2012 at 10:40 AM, Jim Roskind <jar@chromium.org> wrote:
> It sure seems easy to make a regex support the range notation. Why not fix
> it??

The new notation is simpler, already used by the vast majority of
files, and as you note this has already been discussed to death
several times. I'm not sure a new discussion will add much.

>
>
> On Fri, Jul 27, 2012 at 10:38 AM, Nico Weber <thakis@chromium.org> wrote:
>>
>> The regex just disallows the range notation, it doesn't require
>> updating the year every year.
>>
>> On Fri, Jul 27, 2012 at 10:36 AM,  <jar@chromium.org> wrote:
>> > It sure seems like it is better to change the regex, than to change all
>> > these
>> > strings <sigh>.
>> >
>> > If there has already been a giant political debate on chromium-dev....
>> > then
>> > I'll
>> > leave it alone... and L G T M for base.
>> >
>> > If not... then realize that this assault on the tree will, if you
>> > persist,
>> > need
>> > to repeated each year <sigh>.  Touching files has many painful
>> > ramifications,
>> > and I'd *really* vote against this more generally.
>> >
>> > If I'm in the minority... then I will relent and proved a base L G T M
>> > to
>> > help
>> > in your quest.
>> >
>> > Can you clarify why you decided on this (questionable) quest, rather
>> > than
>> > changing the regex???
>> >
>> > http://codereview.chromium.org/10835019/
>
>

[rvargas (doing something else), 2012-07-27 18:04:40]

http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h
File net/disk_cache/file_block.h (right):

http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h...
net/disk_cache/file_block.h:1: // Copyright (c) 2012 The Chromium Authors. All
rights reserved.
You should change this to 2008* instead, given that it looks like that the file
has not been modified since 2008.

(*) applies everywhere, with the last year on each file.

[Nico, 2012-07-27 18:06:40]

On Fri, Jul 27, 2012 at 11:04 AM,  <rvargas@chromium.org> wrote:
>
> http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h
> File net/disk_cache/file_block.h (right):
>
>
http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h...
> net/disk_cache/file_block.h:1: // Copyright (c) 2012 The Chromium
> Authors. All rights reserved.
> You should change this to 2008* instead, given that it looks like that
> the file has not been modified since 2008.
>
> (*) applies everywhere, with the last year on each file.

Previous threads on this issue agreed that the year should be set to
the current year if a file is touched for any reason (presubmit even
checks for that). This CL touches these files.

[rvargas (doing something else), 2012-07-27 18:08:54]

On 2012/07/27 18:06:40, Nico wrote:
> On Fri, Jul 27, 2012 at 11:04 AM,  <mailto:rvargas@chromium.org> wrote:
> >
> >
http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h
> > File net/disk_cache/file_block.h (right):
> >
> >
>
http://codereview.chromium.org/10835019/diff/1556/net/disk_cache/file_block.h...
> > net/disk_cache/file_block.h:1: // Copyright (c) 2012 The Chromium
> > Authors. All rights reserved.
> > You should change this to 2008* instead, given that it looks like that
> > the file has not been modified since 2008.
> >
> > (*) applies everywhere, with the last year on each file.
> 
> Previous threads on this issue agreed that the year should be set to
> the current year if a file is touched for any reason (presubmit even
> checks for that). This CL touches these files.

And previous threads also stated to NOT change files just to update the
copyright dates, as this CL is effectively doing.

FWIW, I'm with Jar on updating the script instead.

[rvargas (doing something else), 2012-07-27 18:20:32]

On the other hand, I don't think this is particularly important one way or the
other, and I'm assuming a script was used to modify all the files. So what I
meant to say was that if it is easy to re-run the script to use the last year of
each pair, it would be better. By no means I expect someone to be changing all
files manually.

[Steve Block, 2012-07-30 13:09:47]

> Can you clarify why you decided on this (questionable) quest, rather than
> changing the regex???
That was my first approach, but it was suggested that I fix instances of
incorrect license headers to simplify the regex -
http://codereview.chromium.org/10816041/diff/2006/android_webview/tools/webvi....

I've updated the patch to leave out the files where the only change is to remove
a data range. I'll revisit the issue of date ranges if I get further push-back
on a regex to allow such ranges.

[Nico, 2012-07-30 23:31:59]

jar, rvargas: ping

On Mon, Jul 30, 2012 at 6:10 AM,  <steveblock@chromium.org> wrote:
> http://codereview.chromium.org/10835019/

[jar (doing other things), 2012-07-30 23:36:18]

Can you clarify what you want me to review?  I don't see anything that
requires my OWNER approval... but I could be missing it.




On Mon, Jul 30, 2012 at 4:31 PM, Nico Weber <thakis@chromium.org> wrote:

> jar, rvargas: ping
>
> On Mon, Jul 30, 2012 at 6:10 AM,  <steveblock@chromium.org> wrote:
> > http://codereview.chromium.org/10835019/
>

[Nico, 2012-07-30 23:47:10]

jar: You blocked this CL further up. steveblock changed something you
were opposed to.

On Mon, Jul 30, 2012 at 4:36 PM, Jim Roskind <jar@chromium.org> wrote:
> Can you clarify what you want me to review?  I don't see anything that
> requires my OWNER approval... but I could be missing it.
>
>
>
>
> On Mon, Jul 30, 2012 at 4:31 PM, Nico Weber <thakis@chromium.org> wrote:
>>
>> jar, rvargas: ping
>>
>> On Mon, Jul 30, 2012 at 6:10 AM,  <steveblock@chromium.org> wrote:
>> > http://codereview.chromium.org/10835019/
>
>

[rvargas (doing something else), 2012-07-30 23:47:24]

LGTM

[Steve Block, 2012-07-31 10:37:59]

+ bradnelson, dmichael for OWNERS

[dmichael (off chromium), 2012-07-31 12:50:39]

Rubber stamp lgtm for ppapi
On Jul 31, 2012 4:38 AM, <steveblock@chromium.org> wrote:

> + bradnelson, dmichael for OWNERS
>
>
http://codereview.chromium.**org/10835019/<http://codereview.chromium.org/108...
>

[binji, 2012-07-31 17:02:22]

On 2012/07/31 15:19:46, Steve Block wrote:

lgtm for native_client_sdk

[commit-bot: I haz the power, 2012-07-31 17:03:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/steveblock@chromium.org/10835019/13001

[commit-bot: I haz the power, 2012-07-31 17:03:38]

Presubmit check for 10835019-13001 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit Warnings **
This change modifies the extension docs but the generated docs have not been
updated properly. See chrome/common/extensions/docs/README.txt for more info.
 - Changes to sample
chrome/common/extensions/docs/examples/api/notifications/options.html have not
been re-zipped.
 - Changes to sample
chrome/common/extensions/docs/examples/apps/hello-java/HelloLicenseServlet.java
have not been re-zipped.
 - Changes to sample
chrome/common/extensions/docs/examples/apps/hello-java/workspace/HelloLicense/src/com/example/HelloLicenseServlet.java
have not been re-zipped.
 - Changes to sample
chrome/common/extensions/docs/examples/apps/hello-php/index.php have not been
re-zipped.
First build DumpRenderTree, then update the docs by running:
  chrome/common/extensions/docs/build/build.py --page-name=<apiName>

Presubmit checks took 2.1s to calculate.

[kjirousek1, 2017-04-17 22:56:51]

On 2012/07/31 17:03:38, commit-bot: I haz the power wrote:
> Presubmit check for 10835019-13001 failed and returned exit status 1.
> 
> Running presubmit commit checks ...
> 
> ** Presubmit Warnings **
> This change modifies the extension docs but the generated docs have not been
> updated properly. See chrome/common/extensions/docs/README.txt for more info.
>  - Changes to sample
> chrome/common/extensions/docs/examples/api/notifications/options.html have not
> been re-zipped.
>  - Changes to sample
>
chrome/common/extensions/docs/examples/apps/hello-java/HelloLicenseServlet.java
> have not been re-zipped.
>  - Changes to sample
>
chrome/common/extensions/docs/examples/apps/hello-java/workspace/HelloLicense/src/com/example/HelloLicenseServlet.java
> have not been re-zipped.
>  - Changes to sample
> chrome/common/extensions/docs/examples/apps/hello-php/index.php have not been
> re-zipped.
> First build DumpRenderTree, then update the docs by running:
>   chrome/common/extensions/docs/build/build.py --page-name=<apiName>
> 
> Presubmit checks took 2.1s to calculate.