Update "Apple Computer, Inc." to "Apple Inc." in license texts

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Chris Jerdonek]

There is a report for check-webkit-style to check license texts:

https://bugs.webkit.org/show_bug.cgi?id=35465

That task will be simplified somewhat if we can update occurrences of the old name "Apple Computer, Inc." to the correct name "Apple Inc."  We can also bring copyright lines up to date while we're at it.

Here is a sample script to start from for examining occurrences:

find . -type f \
\( \
    -wholename '*' \) \
\! \( \
    -wholename '*.dat' -or \
    -wholename '*.gif' -or \
    -wholename '*.jpeg' -or \
    -wholename '*.png' -or \
    -wholename '*.tiff' -or \
    -wholename '*.plist' -or \
    -wholename '*.git*' -or \
    -wholename '*.svn*' -or \
    -wholename '*/WebKitBuild/*' -or \
    -wholename '*.dat' -or \
    -wholename '*ChangeLog*' \) \
-print0 | xargs -0 grep -i 'apple computer, inc\.'

FYI, while examining occurrences I came across these more unusual occurrences:

./WebCore/plugins/win/PluginDatabaseWin.cpp:    HRESULT result = SHGetValue(HKEY_LOCAL_MACHINE, TEXT("Software\\Apple Computer, Inc.\\QuickTime"), TEXT("InstallDir"), &type, (LPBYTE)&installationDirectoryStr, &installationDirectorySize);
./WebKitTools/FindSafari/FindSafari.cpp:    LPCTSTR installPathKeyString = TEXT("SOFTWARE\\Apple Computer, Inc.\\Safari");
./WebKitTools/FindSafari/FindSafari.cpp:    LPCTSTR installPathWin64KeyString = TEXT("SOFTWARE\\Wow6432Node\\Apple Computer, Inc.\\Safari");
./WebKitTools/WebKitLauncherWin/WebKitLauncherWin.cpp:    return applePathFromRegistry(TEXT("SOFTWARE\\Apple Computer, Inc.\\Safari"), TEXT("InstallDir"));
./WebKitTools/WebKitLauncherWin/WebKitLauncherWin.cpp:    return applePathFromRegistry(TEXT("SOFTWARE\\Apple Computer, Inc.\\Safari"), TEXT("BrowserExe"));

These can be addressed separately from this report.

[Chris Jerdonek]

The diff for the change is about ~3MB:

3137 files changed, 9003 insertions(+), 5757 deletions(-)

(The excess in insertions is because of ChangeLog additions.)

I'm not sure if it makes sense to upload such a large file to bugs.webkit.org.  Would it make more sense to split this into a few patches (e.g. by certain top-level directories)?  Let me know how you'd like me to proceed.

For future reference, the following script seems to suffice, with manual attention to the following files as mentioned in comment 0:

* WebCore/plugins/win/PluginDatabaseWin.cpp
* WebKitTools/FindSafari/FindSafari.cpp
* WebKitTools/WebKitLauncherWin/WebKitLauncherWin.cpp

find . -type f \
\( \
    -wholename '*' \) \
\! \( \
    -wholename '*.dat' -or \
    -wholename '*.gif' -or \
    -wholename '*.jpeg' -or \
    -wholename '*.png' -or \
    -wholename '*.tiff' -or \
    -wholename '*.plist' -or \
    -wholename '*.git*' -or \
    -wholename '*.svn*' -or \
    -wholename '*/WebKitBuild/*' -or \
    -wholename '*ChangeLog*' \) | \
sed -e 's/ /\\ /g' | \
xargs grep -l -i 'apple computer, inc\.' | \
xargs sed -i '' 's/Apple Computer, Inc\./Apple Inc\./'

And the same command again with the last line replaced by--

xargs sed -i '' 's/APPLE COMPUTER, INC\./APPLE INC\./'

[Mark Rowe (bdash)]

Please do not modify Apple’s copyright notices.  These notices are only to be updated when Apple updates the files in some manner.  In general it’s not appropriate for someone to modify a copyright notice that is not their own.

[Chris Jerdonek]

(In reply to comment #2)
> Please do not modify Apple’s copyright notices.  These notices are only to be
> updated when Apple updates the files in some manner.  In general it’s not
> appropriate for someone to modify a copyright notice that is not their own.

Okay, thanks for your feedback, Mark.

Just so I don't seem presumptuous in opening this report, I did try seeking feedback on this from three other Apple employees off-list, and you're the first to say anything clearly negative (the others either didn't know, leaned positive, or did not respond).

To clarify, are your remarks limited only to the copyright line itself, or do you think I shouldn't modify the license texts either?  If the latter, I may have some follow-up questions.  Thanks.

[Mark Rowe (bdash)]

(In reply to comment #3)
> To clarify, are your remarks limited only to the copyright line itself, or do
> you think I shouldn't modify the license texts either?  If the latter, I may
> have some follow-up questions.  Thanks.

No, they’re not limited to the copyright line itself.  I think it’s reasonably obvious that references to a company or an individual in licenses or copyright information should only be modified with permission from that company or individual.

[Chris Jerdonek]

(In reply to comment #4)
> No, they’re not limited to the copyright line itself.  I think it’s reasonably
> obvious that references to a company or an individual in licenses or copyright
> information should only be modified with permission from that company or
> individual.

I agree with you.  That's why I CC'ed Darin and Alexey on the patch.  Isn't having the patch reviewed by an Apple employee a suitable way of getting such permission?  I thought I would be doing you guys a favor by taking on a somewhat mundane task.

As for why it would help to make this change--

One way people get license texts is by cutting and pasting license texts from existing files.  If the old Apple name is left, then it will probably continue to spread.

On a practical level, without correcting the names at the outset, it may not make sense for check-webkit-style to warn about the old Apple name (something that was suggested in the comments to bug 35465 and was the original impetus for this report).  The reason is that it may not be possible for check-webkit-style to distinguish reliably between new files and copied files.  And for copied files, we may be issuing warnings that the contributor should not themselves be fixing.

[Mark Rowe (bdash)]

(In reply to comment #5)
> (In reply to comment #4)
> > No, they’re not limited to the copyright line itself.  I think it’s reasonably
> > obvious that references to a company or an individual in licenses or copyright
> > information should only be modified with permission from that company or
> > individual.
> 
> I agree with you.  That's why I CC'ed Darin and Alexey on the patch.  Isn't
> having the patch reviewed by an Apple employee a suitable way of getting such
> permission?  I thought I would be doing you guys a favor by taking on a
> somewhat mundane task.

The information in the bug prior to my comment suggested that you’d decided that the references to Apple in existing copyright headers and licenses should be updated.  There was no mention at all to having run this past anyone from Apple.  I appreciate that you’re trying to help, but I’m not sure that it’s appropriate when it’s about something that’s a matter of an Apple policy.

> As for why it would help to make this change--
> 
> One way people get license texts is by cutting and pasting license texts from
> existing files.  If the old Apple name is left, then it will probably continue
> to spread.

On files derived from existing code, I would obviously expect the existing copyright notices and licenses to be preserved.  I would not expect anyone other than Apple to be referencing Apple within licenses on completely new files.   That seems like something which could be detected by looking for the presence of an Apple copyright line.

> On a practical level, without correcting the names at the outset, it may not
> make sense for check-webkit-style to warn about the old Apple name (something
> that was suggested in the comments to bug 35465 and was the original impetus
> for this report).  The reason is that it may not be possible for
> check-webkit-style to distinguish reliably between new files and copied files. 
> And for copied files, we may be issuing warnings that the contributor should
> not themselves be fixing.

A script dealing with copyright and licenses sounds like it could run in to many potential situations where it may issue advice that should not be followed.  It seems like an area that should be approached carefully.

[Chris Jerdonek]

(In reply to comment #6)
> > One way people get license texts is by cutting and pasting license texts from
> > existing files.  If the old Apple name is left, then it will probably continue
> > to spread.
> 
> On files derived from existing code, I would obviously expect the existing
> copyright notices and licenses to be preserved.  I would not expect anyone
> other than Apple to be referencing Apple within licenses on completely new
> files.   That seems like something which could be detected by looking for the
> presence of an Apple copyright line.

Unless I'm misinterpreting the text, the WebKit Committer Agreement that new
committers sign says that the license referencing Apple should be used:

"Committer agrees that for the majority of projects involved, the Apple BSD
License will serve both as the general contribution license for the WebKit
Project as well as the distribution license, unless otherwise determined by
Apple. You therefore agree that any and all Modifications that you
may create and contribute to the WebKit Project will be contributed either
(a) under an Apple BSD License for WebKit Projects that are already released
under the Apple BSD License ; or (b) the LGPL v.2.1 for WebKit
Projects that are already released under the LGPL v.2.1,..."

(The Apple BSD License, as opposed to a generic BSD-style license, is the
one that contains reference to Apple.  "WebKit Projects" refers to things
like WebCore, JavaScriptCore, etc.)

The web site also says the Apple BSD License is preferred for new files:

http://webkit.org/coding/contributing.html#writecode

(That text was added here: https://bugs.webkit.org/show_bug.cgi?id=34017 )

David Kilzer has also told me in the past to use the Apple style:

https://bugs.webkit.org/show_bug.cgi?id=33475#c7

> A script dealing with copyright and licenses sounds like it could run in to
> many potential situations where it may issue advice that should not be
> followed.  It seems like an area that should be approached carefully.

The approach I'm taking will be to extract from the code base a white list of
recognized texts, and to check this list or some subset of it into the
repository.  If check-webkit-style encounters new license text that does
not match text on the white list, then it will print a message stating that
the text does not match any of the recognized texts.  The exact wording of the
message can be discussed.

The discussion in this report has implications for whether licenses with
Apple's old name should be considered recognized.