What are we doing about...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Copyright dates on 1.3/2.0/2.2 forthcoming releases?

AFAICT, sources are -all- still copyright 2005.  That's not right.

Even if we determine we'll -quit- updating the copyrights until they
are modified, we need to update them when we modify them.

Bill

Re: What are we doing about...

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 4/19/06, Colm MacCarthaigh <co...@stdlib.net> wrote:
> On Wed, Apr 19, 2006 at 03:19:39AM -0500, William A. Rowe, Jr. wrote:
> > Whoa - that's not correct(!)  Although the details are tricky, and although
> > copyright no longer requires 'registration' of the copyrighted material, you
> > still must claim it or lose it, afaik.  (IANAL)
>
> Nope, not in any signatory to the Berne convention. The Copyright is the
> personal property of the author, or the author's employer if the author
> is acting as an agent of the employer (usually, but that's going into
> employment law).
>
> In most countries, apart from a strict copyright assignment to some
> other person (in the legal sense, including a company), there is no way
> to "lose it", very few jurisdictions have the concept of a public domain
> (the US is an exception here, rather than a rule) and even when they do
> there is no automatic assignment to the PD just because you fail to
> "mark" it as copyrighted.
>
> So where I live, it's simply impossible to extinguish the copyright, the
> best someone could hope for is that I publish a covenant saying anything
> can do anything with it, and that the courts would enforce it as a
> unilateral contract (C.f. Carbolic Smoke Ball for the common law
> precedent - it's a fun case to read). That's pretty much how the ASL
> works here.
>
> IANAL either, but I am studying copyright law ;)

That is most correct.

(For OtherBill's reference, trademarks have to be defended or they are
lost; but not copyright.)

> Nope, in all cases where there is one - it's the lifetime of the
> original author. There are small exceptions, like in the case of
> automated computer generated works, the term is limited from the time of
> creation. So, where I live, our "configure" script copyright would last
> 70 years from the time of creation, rather than 70 years after the death
> of the last author of configure.in.
>
> Otherwise the ownership could keep being re-assigned and the copyright
> would simply never expire.

The issue here is that the ASF as a Foundation doesn't really care
about copyright lengths.  We're very happy to see things hit the
public domain.  Our users won't actually care because it won't matter
to them anyway as they can pretty much do whatever they like with the
code under the ALv2.  ;-)  -- justin

Re: What are we doing about...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Maxime Petazzoni wrote:
> 
> I'm not very keen on doing this because this would involve
> double-commits (aka each commit leads to another one used to recommit
> changes done to the copyright line date -when needed-).

Well, we've traditionally done that (all files, all at once), however
this proposal would only touch modified files with the stale copyright.
In fact, less of a flood of svn commit traffic than in prior years.

Re: What are we doing about...

[Maxime Petazzoni <ma...@bulix.org>]

* Colm MacCarthaigh <co...@stdlib.net> [2006-04-19 11:55:50]:

> On Wed, Apr 19, 2006 at 09:42:29AM +0100, Colm MacCarthaigh wrote:
> > > and autofixes them on commit?  Is that doable?
> > 
> > I never thought of that, it probably is, I'll take a look.
> 
> This can be made work, but we'd have to give a bot karma on the whole
> httpd tree.

I'm not very keen on doing this because this would involve
double-commits (aka each commit leads to another one used to recommit
changes done to the copyright line date -when needed-).

- Sam
-- 
Maxime Petazzoni (http://www.bulix.org)
 -- gone crazy, back soon. leave message.

Re: What are we doing about...

[Colm MacCarthaigh <co...@stdlib.net>]

On Wed, Apr 19, 2006 at 09:42:29AM +0100, Colm MacCarthaigh wrote:
> > and autofixes them on commit?  Is that doable?
> 
> I never thought of that, it probably is, I'll take a look.

This can be made work, but we'd have to give a bot karma on the whole
httpd tree.

> > Alternately, if svn can dump us a list of files touched in the present year,
> > we might be able to script that through our usual copyright update pass.  It
> > would be a pre-roll process, e.g. we would touch them as we roll a release.
> 
> That I like.

"svn -r {DATE}" seems to eat quite a bit of resources on the server side
:/

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: What are we doing about...

[Colm MacCarthaigh <co...@stdlib.net>]

On Wed, Apr 19, 2006 at 03:19:39AM -0500, William A. Rowe, Jr. wrote:
> Whoa - that's not correct(!)  Although the details are tricky, and although
> copyright no longer requires 'registration' of the copyrighted material, you
> still must claim it or lose it, afaik.  (IANAL)

Nope, not in any signatory to the Berne convention. The Copyright is the
personal property of the author, or the author's employer if the author
is acting as an agent of the employer (usually, but that's going into
employment law). 

In most countries, apart from a strict copyright assignment to some
other person (in the legal sense, including a company), there is no way
to "lose it", very few jurisdictions have the concept of a public domain
(the US is an exception here, rather than a rule) and even when they do
there is no automatic assignment to the PD just because you fail to
"mark" it as copyrighted. 

So where I live, it's simply impossible to extinguish the copyright, the
best someone could hope for is that I publish a covenant saying anything
can do anything with it, and that the courts would enforce it as a
unilateral contract (C.f. Carbolic Smoke Ball for the common law
precedent - it's a fun case to read). That's pretty much how the ASL
works here.

IANAL either, but I am studying copyright law ;)

> >The dates don't matter except as to establish
> >a minimum term for the copyright, but the real copyright is related to
> >when the author dies - not when the code was written (so we should
> >encourage young healthy committers! ;).
> 
> Uhmmm... yes and no, the maximum (not minimum) term is interrelated to the
> death of the copyright holder, AIUI.

Nope, in all cases where there is one - it's the lifetime of the
original author. There are small exceptions, like in the case of
automated computer generated works, the term is limited from the time of
creation. So, where I live, our "configure" script copyright would last
70 years from the time of creation, rather than 70 years after the death
of the last author of configure.in.

Otherwise the ownership could keep being re-assigned and the copyright
would simply never expire.

> Maybe a post-commit that looks at sources for expected patterns, e.g.
> /* Copyright nnnn-nnnn
> 
> and autofixes them on commit?  Is that doable?

I never thought of that, it probably is, I'll take a look.

> Alternately, if svn can dump us a list of files touched in the present year,
> we might be able to script that through our usual copyright update pass.  It
> would be a pre-roll process, e.g. we would touch them as we roll a release.

That I like.

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Re: What are we doing about...

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Colm MacCarthaigh wrote:
> On Wed, Apr 19, 2006 at 12:09:35AM -0500, William A. Rowe, Jr. wrote:
> 
>>AFAICT, sources are -all- still copyright 2005.  That's not right.
> 
> 
> The 1.3 branch is 2004, and it had a 2005 release ;)
> 
> 
>>Even if we determine we'll -quit- updating the copyrights until they
>>are modified, we need to update them when we modify them.
> 
> 
> Everytime we add a change we are updating the actual copyright. I don't
> know about policy, but the copyright notice itself doesn't really matter
> from a legal perspective, it merely serves as a courtesy of where to
> find potential licensors. 

Whoa - that's not correct(!)  Although the details are tricky, and although
copyright no longer requires 'registration' of the copyrighted material, you
still must claim it or lose it, afaik.  (IANAL)

> The dates don't matter except as to establish
> a minimum term for the copyright, but the real copyright is related to
> when the author dies - not when the code was written (so we should
> encourage young healthy committers! ;).

Uhmmm... yes and no, the maximum (not minimum) term is interrelated to the
death of the copyright holder, AIUI.

> Also there isn't a lack of material which would establish when some code
> was written.

Hehe, now that's true...

> Updating the copyright notice in each file sounds like way too much work
> :) I hate both the old yearly massive diff, and trying to remember to
> change the value every time. How about we embed $Date$ and leave it at
> that?
> 
> We can either just do something like;
> 
> /*
>  * Copyright the Apache Software Foundation or its licensors, as 
>  * applicable.
>  *
>  * $LastChangedDate$
>  * 
>  * Licensed ...
> 
> Or include the start date too. 
> 
> Well, by some means, I'm -0 on anything which isn't automated :)

Maybe a post-commit that looks at sources for expected patterns, e.g.
/* Copyright nnnn-nnnn

and autofixes them on commit?  Is that doable?

Alternately, if svn can dump us a list of files touched in the present year,
we might be able to script that through our usual copyright update pass.  It
would be a pre-roll process, e.g. we would touch them as we roll a release.

Bill

Re: What are we doing about...

[Colm MacCarthaigh <co...@stdlib.net>]

On Wed, Apr 19, 2006 at 12:09:35AM -0500, William A. Rowe, Jr. wrote:
> AFAICT, sources are -all- still copyright 2005.  That's not right.

The 1.3 branch is 2004, and it had a 2005 release ;)

> Even if we determine we'll -quit- updating the copyrights until they
> are modified, we need to update them when we modify them.

Everytime we add a change we are updating the actual copyright. I don't
know about policy, but the copyright notice itself doesn't really matter
from a legal perspective, it merely serves as a courtesy of where to
find potential licensors. The dates don't matter except as to establish
a minimum term for the copyright, but the real copyright is related to
when the author dies - not when the code was written (so we should
encourage young healthy committers! ;).

Also there isn't a lack of material which would establish when some code
was written.

Updating the copyright notice in each file sounds like way too much work
:) I hate both the old yearly massive diff, and trying to remember to
change the value every time. How about we embed $Date$ and leave it at
that?

We can either just do something like;

/*
 * Copyright the Apache Software Foundation or its licensors, as 
 * applicable.
 *
 * $LastChangedDate$
 * 
 * Licensed ...

Or include the start date too. 

Well, by some means, I'm -0 on anything which isn't automated :)

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Copyrights in /repos/asf/httpd/

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

William A. Rowe, Jr. wrote:
> Copyright dates on 1.3/2.0/2.2 forthcoming releases?
> 
> AFAICT, sources are -all- still copyright 2005.  That's not right.
> 
> Even if we determine we'll -quit- updating the copyrights until they
> are modified, we need to update them when we modify them.

This was the exact quote of my entire first-post on the topic.

Can we concur that we are asserting no new copyrights on 1.3 because there
is no further new authorship going into this branch?  (Only corrections, as
one would find between the first and second printing of a book?)

Can we concur that we are asserting no new copyrights on 2.0 because there
is no further new authorship going into this branch?

Can we concur that we are asserting no new copyrights on 2.2 because there
is no further new authorship going into this branch?

Leaving all prior copyrights (prior to this week) intact, that leaves us only
the question of trunk/ which we will have to determine, when 2.4 is released,
if this is a significantly new work.