Copyright information in headers

Thu Sep 4 07:07:38 UTC 2014

a) As long as we are consistent, Copyright lines don't conflict. The only
chance they do is if you have one long lived branch, and a file was created
in 2012, in one long lived branch it gets updated in 2013, and then in the
other it is updated again in 2014 and then you merge that long lived branch
in (so one side sees 2012 => 2012-2013 and the other says 2012-2014).
Its still trivial to resolve.

If we go with "largest spanning range" and don't worry about whether a file
was actually touched in a given year. (eg, changed in 2012, 2014 and not in
2013 still gets 2012-2014.)

If we want to do the exact ranges, I know I wrote a pre-commit plugin in
Bazaar to do exactly that (look at the VCS history, update the headers with
exactly the right dates). I'm sure it could be done in Git. But I'd rather
just do the spanning range and go with it.

However, I'm happy for this to be a "best effort when you see it" sort of
thing, and not a "must be done always".

b) For copyright information for code that other people are writing I
believe the policy we settled on was:

   1. Most of the code that we get into Juju core is going to be Copyright
   Canonical from the Harmony license.
   2. For things that people are going to maintain 3rd party copyright on,
   it should be in the 3rdparty directory, and Copyright whoever is claiming
   to control it.
   3. We are happy to have 3rd parties maintain and support their provider
   implementations as external code, for most other things we'd prefer
   assignment.
   4. To date, most implementers have assigned the provider-code-in-Juju to
   Copyright Canonical, and kept copyright on their library. Which is easier
   and a clear delineation, but isn't required.

At least, that has been my understanding from the discussions I've been
part of.

John
=:->

On Thu, Sep 4, 2014 at 10:32 AM, Dimiter Naydenov <
dimiter.naydenov at canonical.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> As we're on copyright headers topic, is there a clear policy what
> headers to use for contributed code, like the one Joyent did or
> CloudSigma ?
>
> Should it be:
>
> // Copyright 2014 Canonical Ltd.
> // Copyright 2014 CONTRIBUTOR-XYZ..
> // Licensed under the AGPLv3, see LICENCE file for details.
>
> Or:
>
> // Copyright 2014 CONTRIBUTOR-XYZ..
> // Licensed under the AGPLv3, see LICENCE file for details.
>
> Or even:
>
> // Copyright 2014 Canonical Ltd.
> // Licensed under the AGPLv3, see LICENCE file for details.
>
> That to me seems more important than should we update the year when we
> change the file.
>
> On  4.09.2014 03:04, Andrew Wilkins wrote:
> > On Thu, Sep 4, 2014 at 5:50 AM, Ian Booth <ian.booth at canonical.com
> > <mailto:ian.booth at canonical.com>> wrote:
> >
> > Hi folks
> >
> > The question recently came up in reviews as to whether we should
> > be updating the date in the copyright statement in the file header
> > when we make a change to the code in that file. I sought
> > clarification from Robie Basak, who previously had provided input
> > on licensing issues and compliance for getting Juju included in
> > trusty. Below is what he said.
> >
> > TL;DR; It doesn't really matter, we just need to agree on a policy.
> > It is suggested though that we do update the date when we make a
> > change. Agree?
> >
> > <snip>
> >>
> >> What's our policy for dates in copyright headers?
> >>
> >> // Copyright 2012, 2013 Canonical Ltd. // Licensed under the
> >> AGPLv3, see LICENCE file for details.
> >
> > From the point of view of acceptability for Ubuntu, it doesn't
> > particularly matter, and I don't believe it'll cause any issue for
> > us whatever you do here. I'll certainly be happy to upload whether
> > or not you update the date.
> >
> > I'll try to explain my perspective on this, but I'm not entirely
> > confident that there isn't something I'm missing for the broader
> > picture, so note that I Am Not A Lawyer, etc.
> >
> >> For the above, do we need to add 2014 if we modify the file this
> >> year? Or is the date just meant to be the year the file was first
> >> published?
> >
> > I think it's meant to be the sum of all the copyright claims on
> > the file. So if you add some new code, you have a copyright claim
> > on the new code in the newer year in which you made it.
> >
> > AIUI, the purpose of the date is that since copyright expires
> > (theoretically, anyway), updating the date updates the copyright
> > claim, which would give us more control in the (eventual) event
> > that copyright expires.
> >
> > In practice, IMHO this is never going to matter since nobody is
> > going to care about the copyright on a piece of software that is
> > that old anyway. But I suppose laws could change, so the right
> > thing to do would be to add a new year whenever you make a change
> > in a new year on a per-file file basis. BTW, it's common to fold
> > "2012, 2013, 2014" to just "2012-2014".
> >
> > But I don't particularly care for upload purposes.
> >
> >
> > Depending on the country, copyright notices require the first year
> > of publication. I'm not aware of any that *require* the full range,
> > but in some cases it is recommended to have it on ongoing works as
> > a claim of authorship. As Gustavo says, we have this in revision
> > control. We work in the open. Let's not get distracted with
> > unnecessary work.
> >
> >
>
>
> - --
> Dimiter Naydenov <dimiter.naydenov at canonical.com>
> juju-core team
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUCAeJAAoJENzxV2TbLzHw9S4IAKn3xfbzaoIrGweWgtUE9jxS
> 0c6/Hwluwnekj4ERjkDvO6fN2zCGcMOi55Itq6IuBpR8zKnT5bhNORTJbi0KKIiF
> qh3gFpfDmju2u3fo3LFNxmRxSI7CWpeOf6fuRzcGk45P1v6RafrfQQjxKAorDtxe
> iNRZswvTY3RfYHZwGo92zxENGLsJm0oQ8BA3YBDa5mNVyBk/SFuI1jLJSNzvCSCQ
> pD+kzrWr2JMV/hHscba/OcZuZtvWPwYTWP1zeRRVJKiU9HPsDtKhfl2kCtF5olqO
> zl1gHIyetzwdNalJjfkHs1o5Trrvi0EkYpp++CXHRU8H5KZz22AhzRG5qULbIfs=
> =IotS
> -----END PGP SIGNATURE-----
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140904/68d3acfd/attachment.html>