<div dir="ltr">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).<div>
Its still trivial to resolve.</div><div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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".</div><div><br></div><div>b) For copyright information for code that other people are writing I believe the policy we settled on was:</div>
<div><ol><li>Most of the code that we get into Juju core is going to be Copyright Canonical from the Harmony license.</li><li>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.</li>
<li>We are happy to have 3rd parties maintain and support their provider implementations as external code, for most other things we'd prefer assignment.</li><li>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.</li>
</ol><div>At least, that has been my understanding from the discussions I've been part of.</div><div><br></div><div>John</div><div>=:-></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 10:32 AM, Dimiter Naydenov <span dir="ltr"><<a href="mailto:dimiter.naydenov@canonical.com" target="_blank">dimiter.naydenov@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>As we're on copyright headers topic, is there a clear policy what<br>
headers to use for contributed code, like the one Joyent did or<br>
CloudSigma ?<br>
<br>
Should it be:<br>
<br>
// Copyright 2014 Canonical Ltd.<br>
// Copyright 2014 CONTRIBUTOR-XYZ..<br>
<div class="">// Licensed under the AGPLv3, see LICENCE file for details.<br>
<br>
</div>Or:<br>
<br>
// Copyright 2014 CONTRIBUTOR-XYZ..<br>
<div class="">// Licensed under the AGPLv3, see LICENCE file for details.<br>
<br>
</div>Or even:<br>
<br>
// Copyright 2014 Canonical Ltd.<br>
<div class="">// Licensed under the AGPLv3, see LICENCE file for details.<br>
<br>
</div>That to me seems more important than should we update the year when we<br>
change the file.<br>
<div class=""><br>
On  4.09.2014 03:04, Andrew Wilkins wrote:<br>
> On Thu, Sep 4, 2014 at 5:50 AM, Ian Booth <<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:ian.booth@canonical.com">ian.booth@canonical.com</a>>> wrote:<br>
><br>
> Hi folks<br>
><br>
> The question recently came up in reviews as to whether we should<br>
> be updating the date in the copyright statement in the file header<br>
> when we make a change to the code in that file. I sought<br>
> clarification from Robie Basak, who previously had provided input<br>
> on licensing issues and compliance for getting Juju included in<br>
> trusty. Below is what he said.<br>
><br>
> TL;DR; It doesn't really matter, we just need to agree on a policy.<br>
> It is suggested though that we do update the date when we make a<br>
> change. Agree?<br>
><br>
> <snip><br>
>><br>
>> What's our policy for dates in copyright headers?<br>
>><br>
>> // Copyright 2012, 2013 Canonical Ltd. // Licensed under the<br>
>> AGPLv3, see LICENCE file for details.<br>
><br>
> From the point of view of acceptability for Ubuntu, it doesn't<br>
> particularly matter, and I don't believe it'll cause any issue for<br>
> us whatever you do here. I'll certainly be happy to upload whether<br>
> or not you update the date.<br>
><br>
> I'll try to explain my perspective on this, but I'm not entirely<br>
> confident that there isn't something I'm missing for the broader<br>
> picture, so note that I Am Not A Lawyer, etc.<br>
><br>
>> For the above, do we need to add 2014 if we modify the file this<br>
>> year? Or is the date just meant to be the year the file was first<br>
>> published?<br>
><br>
> I think it's meant to be the sum of all the copyright claims on<br>
> the file. So if you add some new code, you have a copyright claim<br>
> on the new code in the newer year in which you made it.<br>
><br>
> AIUI, the purpose of the date is that since copyright expires<br>
> (theoretically, anyway), updating the date updates the copyright<br>
> claim, which would give us more control in the (eventual) event<br>
> that copyright expires.<br>
><br>
> In practice, IMHO this is never going to matter since nobody is<br>
> going to care about the copyright on a piece of software that is<br>
> that old anyway. But I suppose laws could change, so the right<br>
> thing to do would be to add a new year whenever you make a change<br>
> in a new year on a per-file file basis. BTW, it's common to fold<br>
> "2012, 2013, 2014" to just "2012-2014".<br>
><br>
> But I don't particularly care for upload purposes.<br>
><br>
><br>
> Depending on the country, copyright notices require the first year<br>
> of publication. I'm not aware of any that *require* the full range,<br>
> but in some cases it is recommended to have it on ongoing works as<br>
> a claim of authorship. As Gustavo says, we have this in revision<br>
> control. We work in the open. Let's not get distracted with<br>
> unnecessary work.<br>
><br>
><br>
<br>
<br>
</div></div><div class="">- --<br>
Dimiter Naydenov <<a href="mailto:dimiter.naydenov@canonical.com">dimiter.naydenov@canonical.com</a>><br>
juju-core team<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
</div>iQEcBAEBAgAGBQJUCAeJAAoJENzxV2TbLzHw9S4IAKn3xfbzaoIrGweWgtUE9jxS<br>
0c6/Hwluwnekj4ERjkDvO6fN2zCGcMOi55Itq6IuBpR8zKnT5bhNORTJbi0KKIiF<br>
qh3gFpfDmju2u3fo3LFNxmRxSI7CWpeOf6fuRzcGk45P1v6RafrfQQjxKAorDtxe<br>
iNRZswvTY3RfYHZwGo92zxENGLsJm0oQ8BA3YBDa5mNVyBk/SFuI1jLJSNzvCSCQ<br>
pD+kzrWr2JMV/hHscba/OcZuZtvWPwYTWP1zeRRVJKiU9HPsDtKhfl2kCtF5olqO<br>
zl1gHIyetzwdNalJjfkHs1o5Trrvi0EkYpp++CXHRU8H5KZz22AhzRG5qULbIfs=<br>
=IotS<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br></div></div></div>