search

lit / lit-element

LEGACY REPO. This repository is for maintenance of the legacy LitElement library. The LitElement base class is now part of the Lit library, which is developed in the lit monorepo.
https://lit-element.polymer-project.org
BSD 3-Clause "New" or "Revised" License
4.49k stars 318 forks source link

duplicate licenses #590

Closed ribrdb closed 2 years ago

ribrdb commented 5 years ago

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
*/
logicalphase commented 5 years ago

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?

justinfagnani commented 5 years ago

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.

CaptainCodeman commented 5 years ago

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...)

ribrdb commented 5 years ago

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 .

emilio-martinez commented 5 years ago

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.

chase-moskal commented 5 years ago

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?

logicalphase commented 5 years ago

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.

justinfagnani commented 5 years ago

@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.

georges-gomes commented 4 years ago

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

web-padawan commented 4 years ago

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

daKmoR commented 4 years ago

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
ribrdb commented 4 years ago

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
 */
logicalphase commented 4 years ago

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.

justinfagnani commented 4 years ago

This is on our radar and high priority right now.

CaptainCodeman commented 4 years ago

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

(there's a joke hidden in there)

logicalphase commented 4 years ago

Thanks Justin. Much appreciated.

ribrdb commented 4 years ago

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

itssumitrai commented 3 years ago

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.

kevinpschaaf commented 2 years ago

Since this issue was opened, https://github.com/lit/lit/pull/1630 commonized all license headers to the concise SPDX format, however left copyright years.

@aomarks Was there a requirement to leave the years in this changeover? It seems like that is still an impediment to license deduping?

aomarks commented 2 years ago

@aomarks Was there a requirement to leave the years in this changeover? It seems like that is still an impediment to license deduping?

Yes, it is unfortunate. We tried to get a version of the SPDX headers approved that didn't include the copyright year for each individual file, but the Google open source office insisted that we preserve them. I'll send an internal link privately for reference.

aomarks commented 2 years ago

Also note that the duplicate headers compress very well since they are nearly identical, and javascript requests will almost always be served compressed. The parsing overhead of comments is also very small. So the practical impact of the extra headers should be pretty negligible, and I would encourage not making decisions based on raw byte size.

(But I do sympathize, and wish we were allowed to collapse all the copyright headers).