Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add copyright header to each source files to pass Debian's licensecheck.pl script #1132

Closed
kjellander-unity opened this issue Apr 28, 2015 · 9 comments

Comments

@kjellander-unity
Copy link

I'm quoting @maruel's excellent description from https://github.com/kennethreitz/requests/issues/1610 since this feature request is identical:

It is a side effect of using requests in the Chromium project.

We have over 100 third party libraries in the codebase. While we audit all of their licenses, it's also helpful for Open Source Distributions like Debian and others to at least semi-automatically see what licenses apply to our 100+ libraries. For a team of volunteers this is a pretty big task, and having license headers in each file is helpful. Note that it doesn't need to be a full text of the license. For example in Chromium project we use this:

// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

Still, it's preferred to use a full header if possible to help avoid any ambiguity. When people copy your library around, and bundle it as part of other third party project (the nesting can be 1 or even 2 levels deep), finding the right scope of a LICENSE file can be tricky, especially if it's missing (fortunately not the case here, but in general nothing is guaranteed). And then is it LICENSE, LICENSE.txt, COPYING, COPYING.txt and so on - it's trivial for people, but becomes increasingly non-trivial to automate.

Also see the following for recommendations (not all directly related to BSD, but still):

http://producingoss.com/en/license-quickstart.html

"The standard way to do this is to put the full license text in a file called COPYING (or LICENSE) included with the source code, and then put a short notice in a comment at the top of each source file, naming the copyright date, holder, and license, and saying where to find the full text of the license."

http://www.gnu.org/licenses/gpl-howto.html

"This statement should go near the beginning of every source file, close to the copyright notices."

http://www.mozilla.org/MPL/2.0/FAQ.html

"To apply the Mozilla Public License to software that you have written, add the header from Exhibit A of the license to each source code file in your project."

@marcphilipp
Copy link
Member

-1 from me

@junit-team/junit-committers What is your opinion on this?

@dsaff
Copy link
Member

dsaff commented May 20, 2015

@hkjellander,

Would you mind amending the description to highlight the precise benefit of the requested change?

I'm a little confused whether it's being requested by Chromium, or by Debian; knowing that can help us determine whether any change we make is going to actually help.

@kjellander-unity
Copy link
Author

This request is purely from Chromium's perspective. We just happen to be using Debian's licensecheck.pl script to check for licenses.
We cannot enforce this in any way, but we can at least ask for license headers to be added to third party libraries when bringing them in (I referenced this ticket at https://code.google.com/p/chromium/codesearch#chromium/src/tools/checklicenses/checklicenses.py&l=221)

@kcooney
Copy link
Member

kcooney commented May 20, 2015

-1 from me as well. Asking contributors to add copyright to new files would introduce additional unnecessary back-and-forth in pull requests. Enforcing that new files have this header in a platform-neutral way would be difficult.

Couldn't Chromium's checklicenses.py use "EPL" instead of "UNKNOWN" for third_party/junit/src?

@kjellander-unity
Copy link
Author

@kcooney I can certainly do that: https://codereview.chromium.org/1154023002/

I understand that changing all the existing source code and enforcing license headers for all new files adds additional work for your project. I just needed to at least try encouraging you as that's the way these things are handled for all third party code in Chromium.

@kcooney
Copy link
Member

kcooney commented May 23, 2015

Thanks, @hkjellander

Closing this bug. If there's pushback from the Chromium team on your change, feel free to reopen.

@kcooney kcooney closed this as completed May 23, 2015
@kjellander-unity
Copy link
Author

I misunderstood how the checklicenses.py script was working so my CL wasn't applicable.

I don't understand your concern of having headers "in a platform-neutral way", all we're suggesting here is that all source files have a header that states the kind of license used, e.g. http://www.eclipse.org/legal/copyrightandlicensenotice.php

@kcooney
Copy link
Member

kcooney commented Jun 3, 2015

Sorry I wasn't clear. I was trying to say that I would be slightly less concerned about requiring this header comment on every file if someone could write an automated test to verify that no one added new files without the header. Getting such a test to work on all platforms that JUnit is built on may be challenging (that was the "platform-neutral" part).

I still think the maintenance cost of what you are asking is high.

Edit: As far as I can tell, EPL doesn't require a header (the link you sent appears to be Eclipse Foundation's guide for source files managed by the Eclipse Foundation). It's hard to see what's recommended vs required, though (see http://programmers.stackexchange.com/questions/125836/do-you-have-to-include-a-license-notice-with-every-source-file)

Could you please try to fix the script to allow an override?

@Stephan202
Copy link
Contributor

[...] if someone could write an automated test to verify that no one added new files without the header.

You could probably use the license:check goal of the license-maven-plugin for that. But even then there's non-zero additional maintenance cost. So I agree it's better to fix the script itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants