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

Policy for copyright statement in ODL #1398

Open
aringh opened this issue Jun 27, 2018 · 1 comment
Open

Policy for copyright statement in ODL #1398

aringh opened this issue Jun 27, 2018 · 1 comment

Comments

@aringh
Copy link
Member

aringh commented Jun 27, 2018

As pointed out in #1377, just as we have guidelines for how to write commit messages (#4), how to document the code (#279, #854), and how to write error messages (#446), we should also have a policy for how to maintain a proper copyright statement in the code.

  • How does the copyright statement we use look like?
  • Which code should include the statement?
  • What is our policy for updating a potential year given in the statement?
@kohr-h
Copy link
Member

kohr-h commented Sep 11, 2018

How does the copyright statement we use look like?

By default, use the short header as in any of our source files:

# Copyright 2014-2018 The ODL contributors
#
# This file is part of ODL.
#
# This Source Code Form is subject to the terms of the Mozilla Public License,
# v. 2.0. If a copy of the MPL was not distributed with this file, You can
# obtain one at https://mozilla.org/MPL/2.0/.

If the code loads some external resource, e.g., a dataset, the license of that resource should be mentioned as well. Example:

# The dataset is subject to the terms of the
# Creative Commons Attribution 4.0 International License.
#
# You should have received a copy of the license along with this
# work. If not, see https://creativecommons.org/licenses/by/4.0/.

Which code should include the statement?

All files except examples. Likely, they're covered anyway, but we want to avoid the boilerplate lines.


What is our policy for updating a potential year given in the statement?

I think we have settled for on-demand, i.e., when modifying a file with an outdated year range. As I pointed out in the discussion in #1377, what seems to matter is that the last revision is covered by the range, so if a file hasn't been modified since an earlier year, that's alright.

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

No branches or pull requests

2 participants