Blink License Header?

[Nils Barth]

What license header should we be using for new Blink files?

At Coding Style it gives this 3-line one:

Copyright $YEAR The Chromium Authors. All rights reserved.

Use of this source code is governed by a BSD-style license that can be

found in the LICENSE file.

Can we just use this one, now that we're part of Chromium?

In Blink we've traditionally used a rather longer ~28-line one

(given below).

This came up b/c I've been writing some relatively short scripts, sufficiently short that the license header is about the length of the body of the script (!), and thus git get confused applying 50% similarity and produces a confusing diff off some unrelated other short script with the same license header (see CL 15959019).

If there's a good reason to use one or the other, I don't mind, but otherwise I'd prefer a short license header (ideally none), since it just adds noise (and it's redundant with the LICENSE file) and means I have to page down past boilerplate.

What say you, oh Blinkies?

Full traditional Blink-style header:

Copyright (C) 2013 Google Inc. All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions are

met:

    * Redistributions of source code must retain the above copyright

notice, this list of conditions and the following disclaimer.

    * Redistributions in binary form must reproduce the above

copyright notice, this list of conditions and the following disclaimer

in the documentation and/or other materials provided with the

distribution.

    * Neither the name of Google Inc. nor the names of its

contributors may be used to endorse or promote products derived from

this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR

A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT

OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT

LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

[Kenneth Rohde Christiansen]

Because Blink comes from WebKit, some files might be differently licensed, like for instance under the LGPL and with other copyright holders.

I am fine with how it is today

--
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆

[Adam Barth]

On Fri, May 31, 2013 at 4:41 AM, Nils Barth <nba...@chromium.org> wrote:

What license header should we be using for new Blink files?

At Coding Style it gives this 3-line one:

Copyright $YEAR The Chromium Authors. All rights reserved.

Use of this source code is governed by a BSD-style license that can be

found in the LICENSE file.

Can we just use this one, now that we're part of Chromium?

Unfortunately, we can't use this one yet.  The reason are related to some legal issues that are difficult to discuss on a public mailing list.

 

In Blink we've traditionally used a rather longer ~28-line one

(given below).

This came up b/c I've been writing some relatively short scripts, sufficiently short that the license header is about the length of the body of the script (!), and thus git get confused applying 50% similarity and produces a confusing diff off some unrelated other short script with the same license header (see CL 15959019).

We should tune the similarity parameter to help us avoid these silly diffs.

 

Adam

[Nils Barth]

Thanks for explaining Adam, and understand that legal issues can be tricky and time-consuming; glad to hear that there's desire to use a referential header.

This came up b/c I've been writing some relatively short scripts, sufficiently short that the license header is about the length of the body of the script (!), and thus git get confused applying 50% similarity and produces a confusing diff off some unrelated other short script with the same license header (see CL 15959019).

We should tune the similarity parameter to help us avoid these silly diffs.

Maybe not worth the bother?

(Especially if eventually move to a short header.)

Glancing at the man page for git-diff-index it looks it can only threshold on a fixed percentage (rather than "50% if at least 100 lines, otherwise 80%" or whatever), and using a higher similarity cutoff would miss some useful cases, like splitting a file in 2.

Also, missing an actual split is worse than having a silly match (for a new file), since you can just ignore the spurious match (after looking puzzled for a minute), while if it's missed you don't have the previous context.

Unless we have lots more new 50-line files than refactorings of 500-line (or 5000-line) files, probably should just accept.

(Given a short header this would only be an issue for new 5-line files, which I think is ok.)

[Adam Barth]

On Sat, Jun 1, 2013 at 1:56 AM, Nils Barth <nba...@chromium.org> wrote:

Thanks for explaining Adam, and understand that legal issues can be tricky and time-consuming; glad to hear that there's desire to use a referential header.

This came up b/c I've been writing some relatively short scripts, sufficiently short that the license header is about the length of the body of the script (!), and thus git get confused applying 50% similarity and produces a confusing diff off some unrelated other short script with the same license header (see CL 15959019).

We should tune the similarity parameter to help us avoid these silly diffs.

Maybe not worth the bother?

(Especially if eventually move to a short header.)

My understanding is that we're unlikely to move to the short license block unless/until we move into the main Chromium repository.  I don't fully understand the reasons.  I'm just repeating what I've been told by others who understand the the legal issues better than I do.

Adam

[Nils Barth]

Nils Barth:

Maybe not worth the bother?

(Especially if eventually move to a short header.)

Adam Barth:

My understanding is that we're unlikely to move to the short license block unless/until we move into the main Chromium repository.  I don't fully understand the reasons.  I'm just repeating what I've been told by others who understand the the legal issues better than I do.

Got it -- in that case I'd consider a short license block as a nice benefit of moving into the main repo, but it's a minor issue and I assume won't bear much weight in such decisions.

[Colin Blundell]

Note that you can control the similarity parameter on a per-CL basis via "git cl upload --similarity=SIM" (caveat: this also sets the default for future uploads IIRC, so you would probably want to set it back to 50 afterwards). If your only concern on a particular CL is that legitimately new files are being treated as copies, you can use "git cl upload --no-find-copies" to avoid any of the files being treated as copies. Obviously things can get dicey if within a particular CL you have some files that you do want to be treated as renames/copies and some that you want to ensure are not :).

Best,

Colin

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
 
 
 

[Nils Barth]

Thanks Colin, that's fabulous!

(It's almost like someone ran into exactly this issue and solved it last October. Thanks Robbie!)

Documented at UsingGit: Tweaking similarity.

The "set default for future uploads" is on a per-branch basis, which makes sense – you want to use that value for future CLs in the same branch, since they're probably about the same similarity.

...and yeah, if you want to control similarity on a per-file basis, you may be better off breaking up your CL. (>.<)

[Colin Blundell]

Ah, never realized that it maintained state on a per-branch basis, that's awesome!

[Robert Iannucci]

Ha, I knew this would be useful to someone at some point :D

[Rick Byers]

Sorry to re-open this old thread.  But I see that the "full traditional Blink-style header" used in this thread doesn't match the recommendation on the blink coding style page: http://www.chromium.org/blink/coding-style#TOC-License (which, for example, lists only Apple as a copyright holder).  Just to clarify, for all new files we should use the header from http://www.chromium.org/blink/coding-style#TOC-License, right?  If not, can someone please update the coding-style page to have the recommended header?

Thanks,

   Rick

[Adam Barth]

On Thu, Jul 18, 2013 at 9:34 AM, Rick Byers <rby...@chromium.org> wrote:

Sorry to re-open this old thread.  But I see that the "full traditional Blink-style header" used in this thread doesn't match the recommendation on the blink coding style page: http://www.chromium.org/blink/coding-style#TOC-License (which, for example, lists only Apple as a copyright holder).

That's not a recommendation for a license.  That's the license for the style guide itself.

 

Just to clarify, for all new files we should use the header from http://www.chromium.org/blink/coding-style#TOC-License, right?  If not, can someone please update the coding-style page to have the recommended header?

I've added the correct license to the style guide and I've more clearly marked that the license that was there previously is the license for the style guide itself.

Adam

 

On Mon, Jun 3, 2013 at 3:21 PM, Robert Iannucci <iann...@chromium.org> wrote:

Ha, I knew this would be useful to someone at some point :D

On Mon, Jun 3, 2013 at 5:39 AM, Colin Blundell <blun...@chromium.org> wrote:

Ah, never realized that it maintained state on a per-branch basis, that's awesome!

On Mon, Jun 3, 2013 at 3:24 AM, Nils Barth <nba...@chromium.org> wrote:

Thanks Colin, that's fabulous!

(It's almost like someone ran into exactly this issue and solved it last October. Thanks Robbie!)

Documented at UsingGit: Tweaking similarity.

The "set default for future uploads" is on a per-branch basis, which makes sense – you want to use that value for future CLs in the same branch, since they're probably about the same similarity.

...and yeah, if you want to control similarity on a per-file basis, you may be better off breaking up your CL. (>.<)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_TiSaP0ZyDj3fhMRQbb9Wn7R8cAS0_2ybHefhfZSwiKQ%40mail.gmail.com.
 
 

[Rick Byers]

Perfect, thank you!

[Eric Seidel]

Per the recent PSA [1], it is now possible (and preferred) that new
files in Blink follow the Chromium File Header guidelines [2]. I've
updated the Blink Style Guildeines [3] to reflect this.

1. https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/oSaYHvSLg2M
2. http://www.chromium.org/developers/coding-style#TOC-File-headers
3. https://sites.google.com/a/chromium.org/dev/blink/coding-style

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-grYTVjMaDx%2Bm0t5Jom7%3D2Lwt%2B-46ktfcDYC_hmnYnDg%40mail.gmail.com.
>
>