Lit-element: duplicate licenses

Created on 25 Feb 2019  Â·  18Comments  Â·  Source: Polymer/lit-element

When I compile this the closure compiler I get duplicate licenses because different files have different dates. Do you really need to include the year in the @license comment?

/*

 Copyright (c) 2017 The Polymer Project Authors. All rights reserved.
 This code may only be used under the BSD style license found at
 http://polymer.github.io/LICENSE.txt
 The complete set of authors may be found at
 http://polymer.github.io/AUTHORS.txt
 The complete set of contributors may be found at
 http://polymer.github.io/CONTRIBUTORS.txt
 Code distributed by Google as part of the polymer project is also
 subject to an additional IP rights grant found at
 http://polymer.github.io/PATENTS.txt

    Copyright (c) 2019 The Polymer Project Authors. All rights reserved.
    This code may only be used under the BSD style license found at
    http://polymer.github.io/LICENSE.txt The complete set of authors may be found at
    http://polymer.github.io/AUTHORS.txt The complete set of contributors may be
    found at http://polymer.github.io/CONTRIBUTORS.txt Code distributed by Google as
    part of the polymer project is also subject to an additional IP rights grant
    found at http://polymer.github.io/PATENTS.txt

 Copyright (c) 2018 The Polymer Project Authors. All rights reserved.
 This code may only be used under the BSD style license found at
 http://polymer.github.io/LICENSE.txt
 The complete set of authors may be found at
 http://polymer.github.io/AUTHORS.txt
 The complete set of contributors may be found at
 http://polymer.github.io/CONTRIBUTORS.txt
 Code distributed by Google as part of the polymer project is also
 subject to an additional IP rights grant found at
 http://polymer.github.io/PATENTS.txt
*/
Low Bug

Most helpful comment

This is on our radar and high priority right now.

All 18 comments

I've run into this too. Can the inline repeated licence be moved to a
license file with a reference to it inline on other files?

We should unify the formatting and dates on the licences as much as possible. I'm not sure what to do with new files, but with existing code we can use the earliest date. I'll check with out open source office.

Is the copyright needed on every file? Can't it just reference a single license file somewhere?

If the future is ES Modules and not-bundling, then the future looks like downloading lots of the same copyright notices over, and over ...

(thinking about the same thing in lit-html, directives etc...)

Or maybe just tag it with @license in one file, and just use regular
comments in the others?

On Tue, Feb 26, 2019, 4:10 PM Simon Green notifications@github.com wrote:

Is the copyright needed on every file? Can't it just reference a single
license file somewhere?

If the future is ES Modules and not-bundling, then the future looks like
downloading lots of the same copyright notices over, and over ...

(thinking about the same thing in lit-html, directives etc...)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Polymer/lit-element/issues/590#issuecomment-467653333,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEaMTSM5jjEGBefF51Iu5qVgT4JTIowks5vRb7KgaJpZM4bQ9RU
.

Perhaps aligning the license format to something that can be extracted during bundling, e.g., https://www.npmjs.com/package/license-webpack-plugin. The Angular CLI, for example, uses that to produce a single file with all the licenses and attributions instead of having them in the bundle itself.

per-file copyright notices are overkill — no doubt a manifestation of some kind of paranoia

plenty sufficient, already one too many places, really

is there some reason to think this is not sufficient?

What we're doing is providing a LICENSE file for the root of the project.
All other files reference that LICENSE file.

We believe this satisfies the requirement for both Google, Apache, and
additional OSS licenes that are used if any.

If this does not satisfy the requirement with Compliance, please let us
know.

@chase-moskal

no doubt a manifestation of some kind of paranoia

Please don't use this kind of language on this project. We have policies for OSS, and we follow them. I don't pretend to be a lawyer and don't try to weigh in on the necessity of the policies.

I just added some color on #901 (closed now) (thanks @web-padawan)

@justinfagnani @graynorton do you have any official update regarding this one?

legally you are required to ship the licence text... also every project needs to decide for themselves how to handle licencing.

the only option that always works is to use a licence extractor
https://github.com/webpack-contrib/terser-webpack-plugin#extractcomments

As it is mostly the work from terser I am sure there are plugins for most bundlers.

This basically means it is removed from the source and it will not be part of the "loaded" js of a user - however it is still available on the webserver (e.g. to comply to the licence rules)

it will be just a file next to it like so

my-app.js
my-app.js.LICENCE

Other google projects seem to use @license tags without a date, so that the compiler will combine them together.

Closure Library:

/**
 * @license
 * Copyright The Closure Library Authors.
 * SPDX-License-Identifier: Apache-2.0
 */

Angular:

/**
 * @license
 * Copyright Google Inc. All Rights Reserved.
 *
 * Use of this source code is governed by an MIT-style license that can be
 * found in the LICENSE file at https://angular.io/license
 */

I've tried several scrubbers, but there's still dozens of license comments
duplicated in build files. Not necessary really, and it would save bytes to
removed all but the first, or like you said, have a LICENSE-xxx in the root
of the build that covers it.

This is on our radar and high priority right now.

We have robots.txt and humans.txt files, why not have a lawyers.txt file as well.

(there's a joke hidden in there)

Thanks Justin. Much appreciated.

Closure Library has been moving all their license blocks to this format

/**
 * @license
 * Copyright The Closure Library Authors.
 * SPDX-License-Identifier: Apache-2.0
 */

Note that they don't include a year so that all files have the same license block which gets combined into one by the closure compiler.

https://opensource.google/docs/thirdparty/javascript/#spdx

Is this still open ? I want to use LitElement for my project, but its a so big in bundle size than I would like, I would stick to my own custom elements for now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

antonioaltamura picture antonioaltamura  Â·  4Comments

chrismbeckett picture chrismbeckett  Â·  3Comments

minht11 picture minht11  Â·  4Comments

tamis-laan picture tamis-laan  Â·  4Comments

mercmobily picture mercmobily  Â·  3Comments