Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

Ben can you start an new email thread with your motion?

I note that I am an officer of the foundation, for GeoTools. So of the PMC
approves your motion I can obtain funds for legal advice from the treasure,
or impose of one of the OSGeo members in the united states to do so.

I think that obtaining a clear answer would benefit other foundation
projects.

--
Jody Garnett

On 20 May 2016 at 18:06, Ben Caradoc-Davies  wrote:

> Jody,
>
> I am happy to proceed with file creation/contribution date despite my
> small reservations. I think that file creation/contribution date is the
> option that has consensus at this time; it will solve the date maintenance
> overhead problem that is the reason for this change.
>
> I move that you ask OSGeo to obtain legal advice on this matter. I see
> this as a low priority but I think it would be nice to get some advice for
> long-term guidance.
>
> And thanks to everyone for their contributions to this thread. It has
> clarified my views on copyright headers and and changed my views on @author
> tags.
>
> Kind regards,
> Ben.
>
>
> On 21/05/16 12:06, Jody Garnett wrote:
>
>> OSGeo is able to obtain legal advice, as PMC representative I can make
>> that
>> request on behalf of our project. As one of the early projects in OSGeo
>> other projects will be following our lead.
>>
>> To close this one out I would be content to update our policy to be file
>> creation/contribution date - and if you wish to make the motion Ben we can
>> formally ask OSGeo to obtain legal advice (they may do so directly or via
>> reaching out to another foundation with legal staff).
>> --
>> Jody Garnett
>>
>> On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
>>
>> Many stackexchange comments on common law copyright and registration
>>> relate to the US prior its accession to the Berne convention (1989).
>>> Please
>>> see later comments and this:
>>> https://www.law.cornell.edu/wex/copyright
>>>
>>> Furthermore, and I am not a lawyer, can you copyright an individual
>>> source
>>> code file? Is it not like the page of a book?
>>>
>>> As this is an OSGeo project, and OSGeo is incorporated in the United
>>> States, we should give consideration to US law.
>>>
>>> Jody, does OSGeo have a policy on whether dates are required in copyright
>>> headers? Does copyright reside in a single source code file or GeoTools
>>> as
>>> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>>>
>>> Kind regards,
>>> Ben.
>>>
>>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

I have outlined the changes to the developer guide on the proposal (ie in
order to document the practice).
-
https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

It mostly consists of changing a few sentences and removing the example of
updating a header.

I do not think we need to change existing headers.
--
Jody Garnett

On 20 May 2016 at 19:09, Justin Deoliveira  wrote:

> While my personal preference is the same as yours Ben (going with no date
> in the header) I think this is the best middle ground. And anything that
> moves us away from the constant burden on committers and contributors to
> update the headers when it has no tangible benefit is a win.
>
> So what is still unclear to me is what changes (if any) will be required
> if any to the existing headers. Someone correct me if I am wrong but if
> we’re going with just file creation date then we should be good? And the
> only remaining work will be to document the practice?
>
> On Fri, May 20, 2016 at 7:06 PM Ben Caradoc-Davies 
> wrote:
>
>> Jody,
>>
>> I am happy to proceed with file creation/contribution date despite my
>> small reservations. I think that file creation/contribution date is the
>> option that has consensus at this time; it will solve the date
>> maintenance overhead problem that is the reason for this change.
>>
>> I move that you ask OSGeo to obtain legal advice on this matter. I see
>> this as a low priority but I think it would be nice to get some advice
>> for long-term guidance.
>>
>> And thanks to everyone for their contributions to this thread. It has
>> clarified my views on copyright headers and and changed my views on
>> @author tags.
>>
>> Kind regards,
>> Ben.
>>
>> On 21/05/16 12:06, Jody Garnett wrote:
>> > OSGeo is able to obtain legal advice, as PMC representative I can make
>> that
>> > request on behalf of our project. As one of the early projects in OSGeo
>> > other projects will be following our lead.
>> >
>> > To close this one out I would be content to update our policy to be file
>> > creation/contribution date - and if you wish to make the motion Ben we
>> can
>> > formally ask OSGeo to obtain legal advice (they may do so directly or
>> via
>> > reaching out to another foundation with legal staff).
>> > --
>> > Jody Garnett
>> >
>> > On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
>> >
>> >> Many stackexchange comments on common law copyright and registration
>> >> relate to the US prior its accession to the Berne convention (1989).
>> Please
>> >> see later comments and this:
>> >> https://www.law.cornell.edu/wex/copyright
>> >>
>> >> Furthermore, and I am not a lawyer, can you copyright an individual
>> source
>> >> code file? Is it not like the page of a book?
>> >>
>> >> As this is an OSGeo project, and OSGeo is incorporated in the United
>> >> States, we should give consideration to US law.
>> >>
>> >> Jody, does OSGeo have a policy on whether dates are required in
>> copyright
>> >> headers? Does copyright reside in a single source code file or
>> GeoTools as
>> >> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>> >>
>> >> Kind regards,
>> >> Ben.
>> >>
>> >
>>
>> --
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
>>
>>
>> --
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data
>> untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

While my personal preference is the same as yours Ben (going with no date
in the header) I think this is the best middle ground. And anything that
moves us away from the constant burden on committers and contributors to
update the headers when it has no tangible benefit is a win.

So what is still unclear to me is what changes (if any) will be required if
any to the existing headers. Someone correct me if I am wrong but if we’re
going with just file creation date then we should be good? And the only
remaining work will be to document the practice?

On Fri, May 20, 2016 at 7:06 PM Ben Caradoc-Davies  wrote:

> Jody,
>
> I am happy to proceed with file creation/contribution date despite my
> small reservations. I think that file creation/contribution date is the
> option that has consensus at this time; it will solve the date
> maintenance overhead problem that is the reason for this change.
>
> I move that you ask OSGeo to obtain legal advice on this matter. I see
> this as a low priority but I think it would be nice to get some advice
> for long-term guidance.
>
> And thanks to everyone for their contributions to this thread. It has
> clarified my views on copyright headers and and changed my views on
> @author tags.
>
> Kind regards,
> Ben.
>
> On 21/05/16 12:06, Jody Garnett wrote:
> > OSGeo is able to obtain legal advice, as PMC representative I can make
> that
> > request on behalf of our project. As one of the early projects in OSGeo
> > other projects will be following our lead.
> >
> > To close this one out I would be content to update our policy to be file
> > creation/contribution date - and if you wish to make the motion Ben we
> can
> > formally ask OSGeo to obtain legal advice (they may do so directly or via
> > reaching out to another foundation with legal staff).
> > --
> > Jody Garnett
> >
> > On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
> >
> >> Many stackexchange comments on common law copyright and registration
> >> relate to the US prior its accession to the Berne convention (1989).
> Please
> >> see later comments and this:
> >> https://www.law.cornell.edu/wex/copyright
> >>
> >> Furthermore, and I am not a lawyer, can you copyright an individual
> source
> >> code file? Is it not like the page of a book?
> >>
> >> As this is an OSGeo project, and OSGeo is incorporated in the United
> >> States, we should give consideration to US law.
> >>
> >> Jody, does OSGeo have a policy on whether dates are required in
> copyright
> >> headers? Does copyright reside in a single source code file or GeoTools
> as
> >> a work as a whole? Is OSGeo able to obtain legal advice these matters?
> >>
> >> Kind regards,
> >> Ben.
> >>
> >
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Jody,

I am happy to proceed with file creation/contribution date despite my 
small reservations. I think that file creation/contribution date is the 
option that has consensus at this time; it will solve the date 
maintenance overhead problem that is the reason for this change.

I move that you ask OSGeo to obtain legal advice on this matter. I see 
this as a low priority but I think it would be nice to get some advice 
for long-term guidance.

And thanks to everyone for their contributions to this thread. It has 
clarified my views on copyright headers and and changed my views on 
@author tags.

Kind regards,
Ben.

On 21/05/16 12:06, Jody Garnett wrote:
> OSGeo is able to obtain legal advice, as PMC representative I can make that
> request on behalf of our project. As one of the early projects in OSGeo
> other projects will be following our lead.
>
> To close this one out I would be content to update our policy to be file
> creation/contribution date - and if you wish to make the motion Ben we can
> formally ask OSGeo to obtain legal advice (they may do so directly or via
> reaching out to another foundation with legal staff).
> --
> Jody Garnett
>
> On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:
>
>> Many stackexchange comments on common law copyright and registration
>> relate to the US prior its accession to the Berne convention (1989). Please
>> see later comments and this:
>> https://www.law.cornell.edu/wex/copyright
>>
>> Furthermore, and I am not a lawyer, can you copyright an individual source
>> code file? Is it not like the page of a book?
>>
>> As this is an OSGeo project, and OSGeo is incorporated in the United
>> States, we should give consideration to US law.
>>
>> Jody, does OSGeo have a policy on whether dates are required in copyright
>> headers? Does copyright reside in a single source code file or GeoTools as
>> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>>
>> Kind regards,
>> Ben.
>>
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

OSGeo is able to obtain legal advice, as PMC representative I can make that
request on behalf of our project. As one of the early projects in OSGeo
other projects will be following our lead.

To close this one out I would be content to update our policy to be file
creation/contribution date - and if you wish to make the motion Ben we can
formally ask OSGeo to obtain legal advice (they may do so directly or via
reaching out to another foundation with legal staff).
--
Jody Garnett

On 20 May 2016 at 13:50, Ben Caradoc-Davies  wrote:

> Many stackexchange comments on common law copyright and registration
> relate to the US prior its accession to the Berne convention (1989). Please
> see later comments and this:
> https://www.law.cornell.edu/wex/copyright
>
> Furthermore, and I am not a lawyer, can you copyright an individual source
> code file? Is it not like the page of a book?
>
> As this is an OSGeo project, and OSGeo is incorporated in the United
> States, we should give consideration to US law.
>
> Jody, does OSGeo have a policy on whether dates are required in copyright
> headers? Does copyright reside in a single source code file or GeoTools as
> a work as a whole? Is OSGeo able to obtain legal advice these matters?
>
> Kind regards,
> Ben.
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Justin,

I appreciate the work you have put into this one, especially your 
examination of other OSGeo projects, but in my view, copying the 
practices of other projects is another form of circling. Many of these 
practices trace their origin to the US pre-Berne. The first GPL licence 
was written in 1989, and the BSD code base is much older. Old habits die 
hard.

Under SCCS, RCS, and CVS, every file had its own revision. In Subversion 
and Git, the state of the whole code base as a single revision. It was 
also much more common in the olden days to export code from the VCS 
because of file-level locking of checkouts (oh, SCCS on Solaris, how do 
I hate thee). With Git, everyone can clone, and everyone has the file 
history. (Justin, this is for the benefit of the list: you taught me 
pretty much everything I know about Git.)

My fear is that file-level notices with dates is a practice that 
accommodates technologies that are no longer in use and conforms to laws 
that are no longer in effect. My preference is to centralise licence 
information and have a bare-bones statement without dates on files. I 
think we have a great opportunity to reduce duplication and simplify our 
workflow.

As at least one option has changed, I think we should re-vote.

I liked this comprehensive discussion of the issues:
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html

Kind regards,
Ben.


On 21/05/16 09:04, Justin Deoliveira wrote:
> We keep on going in circles on this one.  No OSGeo doesn’t have any rules
> to follow here, if they did we would be following them. If we want to
> “follow OSGeo rules” the best thing we can do is look at what the other
> established projects do. I looked at both MapServer and GDAL/OGR and they
> appear to do the same thing that has been proposed here: they only update
> dates in the copyright header when the copyright changes or a file is
> created. I gauged this by looking at bunch of recent commits and the
> headers in those files. If folks closer to this problem know otherwise
> please share.

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

We keep on going in circles on this one.  No OSGeo doesn’t have any rules
to follow here, if they did we would be following them. If we want to
“follow OSGeo rules” the best thing we can do is look at what the other
established projects do. I looked at both MapServer and GDAL/OGR and they
appear to do the same thing that has been proposed here: they only update
dates in the copyright header when the copyright changes or a file is
created. I gauged this by looking at bunch of recent commits and the
headers in those files. If folks closer to this problem know otherwise
please share.

On Fri, May 20, 2016 at 2:50 PM Ben Caradoc-Davies  wrote:

> Many stackexchange comments on common law copyright and registration
> relate to the US prior its accession to the Berne convention (1989).
> Please see later comments and this:
> https://www.law.cornell.edu/wex/copyright
>
> Furthermore, and I am not a lawyer, can you copyright an individual
> source code file? Is it not like the page of a book?
>
> As this is an OSGeo project, and OSGeo is incorporated in the United
> States, we should give consideration to US law.
>
> Jody, does OSGeo have a policy on whether dates are required in
> copyright headers? Does copyright reside in a single source code file or
> GeoTools as a work as a whole? Is OSGeo able to obtain legal advice
> these matters?
>
> Kind regards,
> Ben.
>
> On 21/05/16 04:42, Jonathan Moules wrote:
> > I can see the appeal of having "2011-present" or similar, but I'm not
> sure it is valid.
> > I believe the point of the date is to establish when a version was
> published for copyright law purposes. This means if a file isn't touched
> for several years, it will have an invalid publication date ("present")
> from the perspective of copyright law.
> > This had a few useful insights:
> >
> http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated
> >
> > Being that the copyright on even the oldest part of GeoServer's code is
> probably not going to expire until everyone who reads this has snuffed it
> (unless there are some *very* young GeoTools developers!), I think the
> Google ethos is simplest:
> > "Google doesn't update their copyright dates because they don't care
> whether some page they started in 1999 and updated this year falls into the
> public domain in 2094 or 2109."
> > Cheers,
> > Jonathan
> >
> >  On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira &
> lt;jdeol...@gmail.com wrote 
> >
> > Thanks Ben. I am going to go ahead with this and update the proposal.
> Thanks for the input everyone.
> >
> > On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz
> wrote:
> >
> > A fixed date might imply that this was the last time the file changed.
> >   Could we write this to start with the file creation year but make it an
> >   open date range?
> >
> >   (C) 2011-, Open Source Geospatial Foundation (OSGeo)
> >
> >   or
> >
> >   (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
> >
> >   as the en-dash (open number range) might otherwise be incorrectly
> parsed
> >   as an em-dash (a pause in text).
> >
> >   If the project ever undergoes another copyright ownership change, we
> can
> >   locate all these "-present," elements and rewrite them to the date that
> >   the change occurs, and add a new open-ended copyright line for the new
> >   owner.
> >
> >   Kind regards,
> >   Ben.
> >
> >   On 20/05/16 07:36, Torben Barsballe wrote:
> >Copyright header with file creation date sounds like a good idea,
> although
> >a would assume we would still want aspects of option B here -
> specifically,
> >if there is ever a copyright transfer event, all the headers
> would need
> >updating. I assume we would do something similar to the following:
> >   
> >/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >  * (c) 2001 - 2013 OpenPlans
> >  */
> >   
> >Where 2001 is the file creation date, and 2014 is the copyright
> transfer
> >date (Example taken from GeoServer).
> >   
> >Torben
> >   
> >On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira &
> lt;jdeol...@gmail.com
> >wrote:
> >   
> >To be clear option C is not to drop the copyright header all
> together,
> >just the date that lives in the header.
> >   
> >I am for any option that doesn’t require us to continuously
> change the
> >header for every commit. So I am +1 with a copyright header
> that contains
> >the file creation date.
> >   
> >On Thu, May 19, 2016 at 11:42 AM Andrea Aime &
> lt;andrea.a...@geo-solutions.it
> >wrote:
> >   
> >On Thu, May 19, 2016 at 7:37 PM, Jody Garnett &
> lt;jody.garn...@gmail.com
> >wrote:
> >   
> >Putting those two tensions together can I recommend a
> compromise -
> >   
> >"Copyright header using file creation date"
> >   
> >This compromise provides copyright header and does
> not require ongoing
> >extra effort to maintain.
> >   
> 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Many stackexchange comments on common law copyright and registration 
relate to the US prior its accession to the Berne convention (1989). 
Please see later comments and this:
https://www.law.cornell.edu/wex/copyright

Furthermore, and I am not a lawyer, can you copyright an individual 
source code file? Is it not like the page of a book?

As this is an OSGeo project, and OSGeo is incorporated in the United 
States, we should give consideration to US law.

Jody, does OSGeo have a policy on whether dates are required in 
copyright headers? Does copyright reside in a single source code file or 
GeoTools as a work as a whole? Is OSGeo able to obtain legal advice 
these matters?

Kind regards,
Ben.

On 21/05/16 04:42, Jonathan Moules wrote:
> I can see the appeal of having "2011-present" or similar, but I'm not sure it 
> is valid.
> I believe the point of the date is to establish when a version was published 
> for copyright law purposes. This means if a file isn't touched for several 
> years, it will have an invalid publication date ("present") from the 
> perspective of copyright law.
> This had a few useful insights:
> http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated
>
> Being that the copyright on even the oldest part of GeoServer's code is 
> probably not going to expire until everyone who reads this has snuffed it 
> (unless there are some *very* young GeoTools developers!), I think the Google 
> ethos is simplest:
> "Google doesn't update their copyright dates because they don't care whether 
> some page they started in 1999 and updated this year falls into the public 
> domain in 2094 or 2109."
> Cheers,
> Jonathan
>
>  On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira 
> jdeol...@gmail.com wrote 
>
> Thanks Ben. I am going to go ahead with this and update the proposal. Thanks 
> for the input everyone.
>
> On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz 
> wrote:
>
> A fixed date might imply that this was the last time the file changed.
>   Could we write this to start with the file creation year but make it an
>   open date range?
>
>   (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>
>   or
>
>   (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>
>   as the en-dash (open number range) might otherwise be incorrectly parsed
>   as an em-dash (a pause in text).
>
>   If the project ever undergoes another copyright ownership change, we can
>   locate all these "-present," elements and rewrite them to the date that
>   the change occurs, and add a new open-ended copyright line for the new
>   owner.
>
>   Kind regards,
>   Ben.
>
>   On 20/05/16 07:36, Torben Barsballe wrote:
>Copyright header with file creation date sounds like a good idea, 
> although
>a would assume we would still want aspects of option B here - 
> specifically,
>if there is ever a copyright transfer event, all the headers would need
>updating. I assume we would do something similar to the following:
>   
>/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
>  * (c) 2001 - 2013 OpenPlans
>  */
>   
>Where 2001 is the file creation date, and 2014 is the copyright 
> transfer
>date (Example taken from GeoServer).
>   
>Torben
>   
>On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
> jdeol...@gmail.com
>wrote:
>   
>To be clear option C is not to drop the copyright header all 
> together,
>just the date that lives in the header.
>   
>I am for any option that doesn’t require us to continuously change 
> the
>header for every commit. So I am +1 with a copyright header that 
> contains
>the file creation date.
>   
>On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
> andrea.a...@geo-solutions.it
>wrote:
>   
>On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> jody.garn...@gmail.com
>wrote:
>   
>Putting those two tensions together can I recommend a 
> compromise -
>   
>"Copyright header using file creation date"
>   
>This compromise provides copyright header and does not 
> require ongoing
>extra effort to maintain.
>   
>   
>I'd second this one too (based on my previous research about 
> foundations,
>and finding
>none that recommends having no copyright headers)
>   
>Cheers
>Andrea
>   
>--
>==
>GeoServer Professional Services from the experts! Visit
>http://goo.gl/it488V for more information.
>==
>   
>Ing. Andrea Aime
>@geowolf
>Technical Lead
>   
>GeoSolutions S.A.S.
>Via di Montramito 3/A
>55054  Massarosa (LU)
>phone: +39 0584 962313
>fax: +39 0584 1660272
>mob: +39  339 8844549
>   
>http://www.geo-solutions.it
>http://twitter.com/geosolutions_it
>   
>*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>   
>Le informazioni contenute in questo messaggio di posta 
> elettronica e/o
>nel/i file/s allegato/i sono da considerarsi strettamente 
> riservate. Il
>

Re: [Geotools-devel] Copyright header policy

[Jonathan Moules]

I can see the appeal of having "2011-present" or similar, but I'm not sure it 
is valid.
I believe the point of the date is to establish when a version was published 
for copyright law purposes. This means if a file isn't touched for several 
years, it will have an invalid publication date ("present") from the 
perspective of copyright law.
This had a few useful insights:
http://stackoverflow.com/questions/2390230/do-copyright-dates-need-to-be-updated

Being that the copyright on even the oldest part of GeoServer's code is 
probably not going to expire until everyone who reads this has snuffed it 
(unless there are some *very* young GeoTools developers!), I think the Google 
ethos is simplest:
"Google doesn't update their copyright dates because they don't care whether 
some page they started in 1999 and updated this year falls into the public 
domain in 2094 or 2109."
Cheers,
Jonathan

 On Fri, 20 May 2016 14:48:08 +0100 Justin Deoliveira 
jdeol...@gmail.com wrote  

Thanks Ben. I am going to go ahead with this and update the proposal. Thanks 
for the input everyone.

On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies b...@transient.nz 
wrote:

A fixed date might imply that this was the last time the file changed.
 Could we write this to start with the file creation year but make it an
 open date range?
 
 (C) 2011-, Open Source Geospatial Foundation (OSGeo)
 
 or
 
 (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
 
 as the en-dash (open number range) might otherwise be incorrectly parsed
 as an em-dash (a pause in text).
 
 If the project ever undergoes another copyright ownership change, we can
 locate all these "-present," elements and rewrite them to the date that
 the change occurs, and add a new open-ended copyright line for the new
 owner.
 
 Kind regards,
 Ben.
 
 On 20/05/16 07:36, Torben Barsballe wrote:
  Copyright header with file creation date sounds like a good idea, although
  a would assume we would still want aspects of option B here - 
specifically,
  if there is ever a copyright transfer event, all the headers would need
  updating. I assume we would do something similar to the following:
 
  /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
* (c) 2001 - 2013 OpenPlans
*/
 
  Where 2001 is the file creation date, and 2014 is the copyright transfer
  date (Example taken from GeoServer).
 
  Torben
 
  On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
jdeol...@gmail.com
  wrote:
 
  To be clear option C is not to drop the copyright header all together,
  just the date that lives in the header.
 
  I am for any option that doesn’t require us to continuously change the
  header for every commit. So I am +1 with a copyright header that 
contains
  the file creation date.
 
  On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
andrea.a...@geo-solutions.it
  wrote:
 
  On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
jody.garn...@gmail.com
  wrote:
 
  Putting those two tensions together can I recommend a 
compromise -
 
  "Copyright header using file creation date"
 
  This compromise provides copyright header and does not 
require ongoing
  extra effort to maintain.
 
 
  I'd second this one too (based on my previous research about 
foundations,
  and finding
  none that recommends having no copyright headers)
 
  Cheers
  Andrea
 
  --
  ==
  GeoServer Professional Services from the experts! Visit
  http://goo.gl/it488V for more information.
  ==
 
  Ing. Andrea Aime
  @geowolf
  Technical Lead
 
  GeoSolutions S.A.S.
  Via di Montramito 3/A
  55054  Massarosa (LU)
  phone: +39 0584 962313
  fax: +39 0584 1660272
  mob: +39  339 8844549
 
  http://www.geo-solutions.it
  http://twitter.com/geosolutions_it
 
  *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
 
  Le informazioni contenute in questo messaggio di posta 
elettronica e/o
  nel/i file/s allegato/i sono da considerarsi strettamente 
riservate. Il
  loro utilizzo è consentito esclusivamente al destinatario del 
messaggio,
  per le finalità indicate nel messaggio stesso. Qualora riceviate 
questo
  messaggio senza esserne il destinatario, Vi preghiamo 
cortesemente di
  darcene notizia via e-mail e di procedere alla distruzione del 
messaggio
  stesso, cancellandolo dal Vostro sistema. Conservare il messaggio 
stesso,
  divulgarlo anche in parte, distribuirlo ad altri soggetti, 
copiarlo, od
  utilizzarlo per finalità diverse, costituisce comportamento 
contrario ai
  principi dettati dal D.Lgs. 196/2003.
 
 
 
  The information in this message and/or attachments, is intended 
solely
  for the attention and use of the named addressee(s) and may be 
confidential
  or proprietary in nature or covered by the provisions of privacy 
act
  (Legislative Decree June, 30 2003, no.196 - Italy's New Data 
Protection
  Code).Any use not in accord with its purpose, any disclosure, 
reproduction,
  copying, distribution, or either dissemination, either whole or 
partial, is
  strictly forbidden except previous formal approval 

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

I think I did that yesterday while waiting for a build.

--
Jody Garnett

On 20 May 2016 at 06:48, Justin Deoliveira  wrote:

> Thanks Ben. I am going to go ahead with this and update the proposal.
> Thanks for the input everyone.
>
> On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies 
> wrote:
>
>> A fixed date might imply that this was the last time the file changed.
>> Could we write this to start with the file creation year but make it an
>> open date range?
>>
>> (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>>
>> or
>>
>> (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>>
>> as the en-dash (open number range) might otherwise be incorrectly parsed
>> as an em-dash (a pause in text).
>>
>> If the project ever undergoes another copyright ownership change, we can
>> locate all these "-present," elements and rewrite them to the date that
>> the change occurs, and add a new open-ended copyright line for the new
>> owner.
>>
>> Kind regards,
>> Ben.
>>
>> On 20/05/16 07:36, Torben Barsballe wrote:
>> > Copyright header with file creation date sounds like a good idea,
>> although
>> > a would assume we would still want aspects of option B here -
>> specifically,
>> > if there is ever a copyright transfer event, all the headers would need
>> > updating. I assume we would do something similar to the following:
>> >
>> > /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
>> >   * (c) 2001 - 2013 OpenPlans
>> >   */
>> >
>> > Where 2001 is the file creation date, and 2014 is the copyright transfer
>> > date (Example taken from GeoServer).
>> >
>> > Torben
>> >
>> > On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira > >
>> > wrote:
>> >
>> >> To be clear option C is not to drop the copyright header all together,
>> >> just the date that lives in the header.
>> >>
>> >> I am for any option that doesn’t require us to continuously change the
>> >> header for every commit. So I am +1 with a copyright header that
>> contains
>> >> the file creation date.
>> >>
>> >> On Thu, May 19, 2016 at 11:42 AM Andrea Aime <
>> andrea.a...@geo-solutions.it>
>> >> wrote:
>> >>
>> >>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett > >
>> >>> wrote:
>> >>>
>>  Putting those two tensions together can I recommend a compromise -
>> 
>>  "Copyright header using file creation date"
>> 
>>  This compromise provides copyright header and does not require
>> ongoing
>>  extra effort to maintain.
>> 
>> >>>
>> >>> I'd second this one too (based on my previous research about
>> foundations,
>> >>> and finding
>> >>> none that recommends having no copyright headers)
>> >>>
>> >>> Cheers
>> >>> Andrea
>> >>>
>> >>> --
>> >>> ==
>> >>> GeoServer Professional Services from the experts! Visit
>> >>> http://goo.gl/it488V for more information.
>> >>> ==
>> >>>
>> >>> Ing. Andrea Aime
>> >>> @geowolf
>> >>> Technical Lead
>> >>>
>> >>> GeoSolutions S.A.S.
>> >>> Via di Montramito 3/A
>> >>> 55054  Massarosa (LU)
>> >>> phone: +39 0584 962313
>> >>> fax: +39 0584 1660272
>> >>> mob: +39  339 8844549
>> >>>
>> >>> http://www.geo-solutions.it
>> >>> http://twitter.com/geosolutions_it
>> >>>
>> >>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>> >>>
>> >>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> >>> nel/i file/s allegato/i sono da considerarsi strettamente riservate.
>> Il
>> >>> loro utilizzo è consentito esclusivamente al destinatario del
>> messaggio,
>> >>> per le finalità indicate nel messaggio stesso. Qualora riceviate
>> questo
>> >>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> >>> darcene notizia via e-mail e di procedere alla distruzione del
>> messaggio
>> >>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio
>> stesso,
>> >>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo,
>> od
>> >>> utilizzarlo per finalità diverse, costituisce comportamento contrario
>> ai
>> >>> principi dettati dal D.Lgs. 196/2003.
>> >>>
>> >>>
>> >>>
>> >>> The information in this message and/or attachments, is intended solely
>> >>> for the attention and use of the named addressee(s) and may be
>> confidential
>> >>> or proprietary in nature or covered by the provisions of privacy act
>> >>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data
>> Protection
>> >>> Code).Any use not in accord with its purpose, any disclosure,
>> reproduction,
>> >>> copying, distribution, or either dissemination, either whole or
>> partial, is
>> >>> strictly forbidden except previous formal approval of the named
>> >>> addressee(s). If you are not the intended recipient, please contact
>> >>> immediately the sender by telephone, fax or e-mail and delete the
>> >>> information in this message that has been received in error. The
>> sender
>> >>> does not give any warranty or accept liability as the content,
>> accuracy or
>> >>> completeness of sent 

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Ben. I am going to go ahead with this and update the proposal.
Thanks for the input everyone.

On Thu, May 19, 2016 at 5:19 PM Ben Caradoc-Davies  wrote:

> A fixed date might imply that this was the last time the file changed.
> Could we write this to start with the file creation year but make it an
> open date range?
>
> (C) 2011-, Open Source Geospatial Foundation (OSGeo)
>
> or
>
> (C) 2011-present, Open Source Geospatial Foundation (OSGeo)
>
> as the en-dash (open number range) might otherwise be incorrectly parsed
> as an em-dash (a pause in text).
>
> If the project ever undergoes another copyright ownership change, we can
> locate all these "-present," elements and rewrite them to the date that
> the change occurs, and add a new open-ended copyright line for the new
> owner.
>
> Kind regards,
> Ben.
>
> On 20/05/16 07:36, Torben Barsballe wrote:
> > Copyright header with file creation date sounds like a good idea,
> although
> > a would assume we would still want aspects of option B here -
> specifically,
> > if there is ever a copyright transfer event, all the headers would need
> > updating. I assume we would do something similar to the following:
> >
> > /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
> >   * (c) 2001 - 2013 OpenPlans
> >   */
> >
> > Where 2001 is the file creation date, and 2014 is the copyright transfer
> > date (Example taken from GeoServer).
> >
> > Torben
> >
> > On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
> > wrote:
> >
> >> To be clear option C is not to drop the copyright header all together,
> >> just the date that lives in the header.
> >>
> >> I am for any option that doesn’t require us to continuously change the
> >> header for every commit. So I am +1 with a copyright header that
> contains
> >> the file creation date.
> >>
> >> On Thu, May 19, 2016 at 11:42 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >> wrote:
> >>
> >>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> >>> wrote:
> >>>
>  Putting those two tensions together can I recommend a compromise -
> 
>  "Copyright header using file creation date"
> 
>  This compromise provides copyright header and does not require ongoing
>  extra effort to maintain.
> 
> >>>
> >>> I'd second this one too (based on my previous research about
> foundations,
> >>> and finding
> >>> none that recommends having no copyright headers)
> >>>
> >>> Cheers
> >>> Andrea
> >>>
> >>> --
> >>> ==
> >>> GeoServer Professional Services from the experts! Visit
> >>> http://goo.gl/it488V for more information.
> >>> ==
> >>>
> >>> Ing. Andrea Aime
> >>> @geowolf
> >>> Technical Lead
> >>>
> >>> GeoSolutions S.A.S.
> >>> Via di Montramito 3/A
> >>> 55054  Massarosa (LU)
> >>> phone: +39 0584 962313
> >>> fax: +39 0584 1660272
> >>> mob: +39  339 8844549
> >>>
> >>> http://www.geo-solutions.it
> >>> http://twitter.com/geosolutions_it
> >>>
> >>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
> >>>
> >>> Le informazioni contenute in questo messaggio di posta elettronica e/o
> >>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> >>> loro utilizzo è consentito esclusivamente al destinatario del
> messaggio,
> >>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> >>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> >>> darcene notizia via e-mail e di procedere alla distruzione del
> messaggio
> >>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio
> stesso,
> >>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> >>> utilizzarlo per finalità diverse, costituisce comportamento contrario
> ai
> >>> principi dettati dal D.Lgs. 196/2003.
> >>>
> >>>
> >>>
> >>> The information in this message and/or attachments, is intended solely
> >>> for the attention and use of the named addressee(s) and may be
> confidential
> >>> or proprietary in nature or covered by the provisions of privacy act
> >>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> >>> Code).Any use not in accord with its purpose, any disclosure,
> reproduction,
> >>> copying, distribution, or either dissemination, either whole or
> partial, is
> >>> strictly forbidden except previous formal approval of the named
> >>> addressee(s). If you are not the intended recipient, please contact
> >>> immediately the sender by telephone, fax or e-mail and delete the
> >>> information in this message that has been received in error. The sender
> >>> does not give any warranty or accept liability as the content,
> accuracy or
> >>> completeness of sent messages and accepts no responsibility  for
> changes
> >>> made after they were sent or for other risks which arise as a result of
> >>> e-mail transmission, viruses, etc.
> >>>
> >>> ---
> >>>
> >>
> >>
> >>
> 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

A fixed date might imply that this was the last time the file changed. 
Could we write this to start with the file creation year but make it an 
open date range?

(C) 2011-, Open Source Geospatial Foundation (OSGeo)

or

(C) 2011-present, Open Source Geospatial Foundation (OSGeo)

as the en-dash (open number range) might otherwise be incorrectly parsed 
as an em-dash (a pause in text).

If the project ever undergoes another copyright ownership change, we can 
locate all these "-present," elements and rewrite them to the date that 
the change occurs, and add a new open-ended copyright line for the new 
owner.

Kind regards,
Ben.

On 20/05/16 07:36, Torben Barsballe wrote:
> Copyright header with file creation date sounds like a good idea, although
> a would assume we would still want aspects of option B here - specifically,
> if there is ever a copyright transfer event, all the headers would need
> updating. I assume we would do something similar to the following:
>
> /* (c) 2014 Open Source Geospatial Foundation (OsGeo)
>   * (c) 2001 - 2013 OpenPlans
>   */
>
> Where 2001 is the file creation date, and 2014 is the copyright transfer
> date (Example taken from GeoServer).
>
> Torben
>
> On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
> wrote:
>
>> To be clear option C is not to drop the copyright header all together,
>> just the date that lives in the header.
>>
>> I am for any option that doesn’t require us to continuously change the
>> header for every commit. So I am +1 with a copyright header that contains
>> the file creation date.
>>
>> On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
>> wrote:
>>
>>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
>>> wrote:
>>>
 Putting those two tensions together can I recommend a compromise -

 "Copyright header using file creation date"

 This compromise provides copyright header and does not require ongoing
 extra effort to maintain.

>>>
>>> I'd second this one too (based on my previous research about foundations,
>>> and finding
>>> none that recommends having no copyright headers)
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility  for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>> ---
>>>
>>
>>
>> --
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data
>> untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>> 

Re: [Geotools-devel] Copyright header policy

[Torben Barsballe]

Copyright header with file creation date sounds like a good idea, although
a would assume we would still want aspects of option B here - specifically,
if there is ever a copyright transfer event, all the headers would need
updating. I assume we would do something similar to the following:

/* (c) 2014 Open Source Geospatial Foundation (OsGeo)
 * (c) 2001 - 2013 OpenPlans
 */

Where 2001 is the file creation date, and 2014 is the copyright transfer
date (Example taken from GeoServer).

Torben

On Thu, May 19, 2016 at 10:47 AM, Justin Deoliveira 
wrote:

> To be clear option C is not to drop the copyright header all together,
> just the date that lives in the header.
>
> I am for any option that doesn’t require us to continuously change the
> header for every commit. So I am +1 with a copyright header that contains
> the file creation date.
>
> On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
> wrote:
>
>> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
>> wrote:
>>
>>> Putting those two tensions together can I recommend a compromise -
>>>
>>> "Copyright header using file creation date"
>>>
>>> This compromise provides copyright header and does not require ongoing
>>> extra effort to maintain.
>>>
>>
>> I'd second this one too (based on my previous research about foundations,
>> and finding
>> none that recommends having no copyright headers)
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility  for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> ---
>>
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

To be clear option C is not to drop the copyright header all together, just
the date that lives in the header.

I am for any option that doesn’t require us to continuously change the
header for every commit. So I am +1 with a copyright header that contains
the file creation date.

On Thu, May 19, 2016 at 11:42 AM Andrea Aime 
wrote:

> On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
> wrote:
>
>> Putting those two tensions together can I recommend a compromise -
>>
>> "Copyright header using file creation date"
>>
>> This compromise provides copyright header and does not require ongoing
>> extra effort to maintain.
>>
>
> I'd second this one too (based on my previous research about foundations,
> and finding
> none that recommends having no copyright headers)
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Andrea Aime]

On Thu, May 19, 2016 at 7:37 PM, Jody Garnett 
wrote:

> Putting those two tensions together can I recommend a compromise -
>
> "Copyright header using file creation date"
>
> This compromise provides copyright header and does not require ongoing
> extra effort to maintain.
>

I'd second this one too (based on my previous research about foundations,
and finding
none that recommends having no copyright headers)

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

So yeah, the vote boils down to a tension between two things:
- have a copy right header (A,B,D) or not (C) - we appear split on this
issue based on where "C" appears in PSC ranking
- require ongoing extra effort (A,B) or no effort (C,D) - this appears
important based on this proposal itself, and where "C,D" appear in PSC
ranking

Putting those two tensions together can I recommend a compromise -

"Copyright header using file creation date"

This compromise provides copyright header and does not require ongoing
extra effort to maintain.


--
Jody Garnett

On 19 May 2016 at 05:55, Justin Deoliveira  wrote:

> All the votes are in. Thanks everyone.
>
> If D is still on the table then it looks like it is the winner… but as
> previously discussed I am not sure how feasible that option is. Taking D
> out of the equation C (dropping the date from the copyright header all
> together) becomes the winner.
>
> So unless someone in the (D) camp can come up with good way to achieve
> this I’ll go ahead and update the proposal with a plan to implement C.
>
> On Wed, May 18, 2016 at 5:47 PM Justin Deoliveira 
> wrote:
>
>> Thanks Ben. I am agreement about option D. So unless one of the folks who
>> made it there first choice wants to put some time into proving it’s
>> feasibility I suggest we remove it from the vote.
>>
>> I’ll also start reaching out directly to Jody and Christian to fill in
>> there votes.
>>
>> On Tue, May 17, 2016 at 1:25 PM Ben Caradoc-Davies 
>> wrote:
>>
>>> I do not think option D can work with a distributed version control
>>> system. I think this option is unimplementable with git. If we eliminate
>>> D, then C is the winner.
>>>
>>> Kind regards,
>>> Ben.
>>>
>>> On 18/05/16 07:05, Ben Caradoc-Davies wrote:
>>> > Instant runoff voting give a win for D:
>>> > https://en.wikipedia.org/wiki/Instant-runoff_voting
>>> >
>>> > Round 1: A eliminated
>>> > Round 2: B eliminated
>>> > Round 3: D wins with 3/5 votes
>>> >
>>> > Kind regards,
>>> > Ben.
>>> >
>>> > On 18/05/16 01:21, Justin Deoliveira wrote:
>>> >> Thanks for kicking this one Andrea.
>>> >>
>>> >> Using a simple weighted scoring where first pick gets 4 points,
>>> second 3,
>>> >> etc… the current votes come out to:
>>> >>
>>> >> A: 5
>>> >> B: 12
>>> >> C: 12
>>> >> D: 11
>>> >>
>>> >> Which means a tie between methods B and C… so ideally the other PSC
>>> members
>>> >> could get there votes in on this one so things can move forward.
>>> >>
>>> >> It also looks like D is getting some traction. I am trying to think
>>> about
>>> >> how that option might work in practice… I understand git post commit
>>> hooks
>>> >> but I don’t think I’ve ever seen them used to actually modify the
>>> contents
>>> >> of a file being committed. Questions I have are:
>>> >>
>>> >> - Is this even possible? And if git does allow it does github support
>>> it?
>>> >> - Since change you are committing isn’t the actual diff that results
>>> in the
>>> >> main repository how will this play out when it comes to merging?
>>> Since the
>>> >> diff you made locally won’t be the same as what gets stored on the
>>> server?
>>> >> - Does this mean that after every commit you have to remember to pull
>>> so
>>> >> you can grab the latest version of the file?
>>> >>
>>> >> It might be worth trying to flesh that option out a bit more if folks
>>> are
>>> >> going to be voting that way.
>>> >>
>>> >> On Mon, May 16, 2016 at 11:17 AM Andrea Aime <
>>> andrea.a...@geo-solutions.it>
>>> >> wrote:
>>> >>
>>> >>> Hi,
>>> >>> thanks Ian, updated
>>> >>>
>>> >>> Cheers
>>> >>> Andrea
>>> >>>
>>> >>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton 
>>> wrote:
>>> >>>
>>>  Github won't let my phone login so I vote. D, c, b, a.
>>> 
>>>  Ian
>>> 
>>> >>> On 16 May 2016 17:24, "Andrea Aime" 
>>> wrote:
>>> 
>>> >>> Hi,
>>> > looked at the proposal, seems it got stuck?
>>> > Could the other PSC members provide a preference list too?
>>> >
>>> >
>>> >
>>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>> >
>>> > Cheers
>>> > Andrea
>>> >
>>> >
>>> > On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
>>> > andrea.a...@geo-solutions.it> wrote:
>>> >
>>> >> Hi Justin,
>>> >> I made a bit of research as this is one topic that foundations
>>> probably
>>> >> have guidance on.
>>> >> Found these for the moment:
>>> >>
>>> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>>> >>
>>> >>
>>> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
>>> >> http://www.apache.org/legal/src-headers.html
>>> >>
>>> >> The official guidance for these foundations seem to suggest at
>>> least
>>> >> one year should show up in the headers.
>>> >> I found little evidence that our current approach has benefits,
>>> 

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

All the votes are in. Thanks everyone.

If D is still on the table then it looks like it is the winner… but as
previously discussed I am not sure how feasible that option is. Taking D
out of the equation C (dropping the date from the copyright header all
together) becomes the winner.

So unless someone in the (D) camp can come up with good way to achieve this
I’ll go ahead and update the proposal with a plan to implement C.

On Wed, May 18, 2016 at 5:47 PM Justin Deoliveira 
wrote:

> Thanks Ben. I am agreement about option D. So unless one of the folks who
> made it there first choice wants to put some time into proving it’s
> feasibility I suggest we remove it from the vote.
>
> I’ll also start reaching out directly to Jody and Christian to fill in
> there votes.
>
> On Tue, May 17, 2016 at 1:25 PM Ben Caradoc-Davies 
> wrote:
>
>> I do not think option D can work with a distributed version control
>> system. I think this option is unimplementable with git. If we eliminate
>> D, then C is the winner.
>>
>> Kind regards,
>> Ben.
>>
>> On 18/05/16 07:05, Ben Caradoc-Davies wrote:
>> > Instant runoff voting give a win for D:
>> > https://en.wikipedia.org/wiki/Instant-runoff_voting
>> >
>> > Round 1: A eliminated
>> > Round 2: B eliminated
>> > Round 3: D wins with 3/5 votes
>> >
>> > Kind regards,
>> > Ben.
>> >
>> > On 18/05/16 01:21, Justin Deoliveira wrote:
>> >> Thanks for kicking this one Andrea.
>> >>
>> >> Using a simple weighted scoring where first pick gets 4 points, second
>> 3,
>> >> etc… the current votes come out to:
>> >>
>> >> A: 5
>> >> B: 12
>> >> C: 12
>> >> D: 11
>> >>
>> >> Which means a tie between methods B and C… so ideally the other PSC
>> members
>> >> could get there votes in on this one so things can move forward.
>> >>
>> >> It also looks like D is getting some traction. I am trying to think
>> about
>> >> how that option might work in practice… I understand git post commit
>> hooks
>> >> but I don’t think I’ve ever seen them used to actually modify the
>> contents
>> >> of a file being committed. Questions I have are:
>> >>
>> >> - Is this even possible? And if git does allow it does github support
>> it?
>> >> - Since change you are committing isn’t the actual diff that results
>> in the
>> >> main repository how will this play out when it comes to merging? Since
>> the
>> >> diff you made locally won’t be the same as what gets stored on the
>> server?
>> >> - Does this mean that after every commit you have to remember to pull
>> so
>> >> you can grab the latest version of the file?
>> >>
>> >> It might be worth trying to flesh that option out a bit more if folks
>> are
>> >> going to be voting that way.
>> >>
>> >> On Mon, May 16, 2016 at 11:17 AM Andrea Aime <
>> andrea.a...@geo-solutions.it>
>> >> wrote:
>> >>
>> >>> Hi,
>> >>> thanks Ian, updated
>> >>>
>> >>> Cheers
>> >>> Andrea
>> >>>
>> >>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton 
>> wrote:
>> >>>
>>  Github won't let my phone login so I vote. D, c, b, a.
>> 
>>  Ian
>> 
>> >>> On 16 May 2016 17:24, "Andrea Aime" 
>> wrote:
>> 
>> >>> Hi,
>> > looked at the proposal, seems it got stuck?
>> > Could the other PSC members provide a preference list too?
>> >
>> >
>> >
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>> >
>> > Cheers
>> > Andrea
>> >
>> >
>> > On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
>> > andrea.a...@geo-solutions.it> wrote:
>> >
>> >> Hi Justin,
>> >> I made a bit of research as this is one topic that foundations
>> probably
>> >> have guidance on.
>> >> Found these for the moment:
>> >> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>> >>
>> >>
>> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
>> >> http://www.apache.org/legal/src-headers.html
>> >>
>> >> The official guidance for these foundations seem to suggest at
>> least
>> >> one year should show up in the headers.
>> >> I found little evidence that our current approach has benefits,
>> >> although some practices seem to imply
>> >> a mass header change per (major) release... which does not make all
>> >> that much sense to me, but
>> >> would at least be easy to automate :-p
>> >>
>> >> Cheers
>> >> Andrea
>> >>
>> >>
>> >>
>> >> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira <
>> jdeol...@gmail.com>
>> >> wrote:
>> >>
>> >>> Thanks for the input everyone. I put together a proposal with all
>> of
>> >>> the options put forth on this thread. Apologies if I missed one,
>> if I did
>> >>> just let me know.
>> >>>
>> >>>
>> >>>
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>> >>>
>> >>> Like I said before this proposal involves listing 

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Ben. I am agreement about option D. So unless one of the folks who
made it there first choice wants to put some time into proving it’s
feasibility I suggest we remove it from the vote.

I’ll also start reaching out directly to Jody and Christian to fill in
there votes.

On Tue, May 17, 2016 at 1:25 PM Ben Caradoc-Davies  wrote:

> I do not think option D can work with a distributed version control
> system. I think this option is unimplementable with git. If we eliminate
> D, then C is the winner.
>
> Kind regards,
> Ben.
>
> On 18/05/16 07:05, Ben Caradoc-Davies wrote:
> > Instant runoff voting give a win for D:
> > https://en.wikipedia.org/wiki/Instant-runoff_voting
> >
> > Round 1: A eliminated
> > Round 2: B eliminated
> > Round 3: D wins with 3/5 votes
> >
> > Kind regards,
> > Ben.
> >
> > On 18/05/16 01:21, Justin Deoliveira wrote:
> >> Thanks for kicking this one Andrea.
> >>
> >> Using a simple weighted scoring where first pick gets 4 points, second
> 3,
> >> etc… the current votes come out to:
> >>
> >> A: 5
> >> B: 12
> >> C: 12
> >> D: 11
> >>
> >> Which means a tie between methods B and C… so ideally the other PSC
> members
> >> could get there votes in on this one so things can move forward.
> >>
> >> It also looks like D is getting some traction. I am trying to think
> about
> >> how that option might work in practice… I understand git post commit
> hooks
> >> but I don’t think I’ve ever seen them used to actually modify the
> contents
> >> of a file being committed. Questions I have are:
> >>
> >> - Is this even possible? And if git does allow it does github support
> it?
> >> - Since change you are committing isn’t the actual diff that results in
> the
> >> main repository how will this play out when it comes to merging? Since
> the
> >> diff you made locally won’t be the same as what gets stored on the
> server?
> >> - Does this mean that after every commit you have to remember to pull so
> >> you can grab the latest version of the file?
> >>
> >> It might be worth trying to flesh that option out a bit more if folks
> are
> >> going to be voting that way.
> >>
> >> On Mon, May 16, 2016 at 11:17 AM Andrea Aime <
> andrea.a...@geo-solutions.it>
> >> wrote:
> >>
> >>> Hi,
> >>> thanks Ian, updated
> >>>
> >>> Cheers
> >>> Andrea
> >>>
> >>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton 
> wrote:
> >>>
>  Github won't let my phone login so I vote. D, c, b, a.
> 
>  Ian
> 
> >>> On 16 May 2016 17:24, "Andrea Aime" 
> wrote:
> 
> >>> Hi,
> > looked at the proposal, seems it got stuck?
> > Could the other PSC members provide a preference list too?
> >
> >
> >
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
> >
> > Cheers
> > Andrea
> >
> >
> > On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
> > andrea.a...@geo-solutions.it> wrote:
> >
> >> Hi Justin,
> >> I made a bit of research as this is one topic that foundations
> probably
> >> have guidance on.
> >> Found these for the moment:
> >> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
> >>
> >>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
> >> http://www.apache.org/legal/src-headers.html
> >>
> >> The official guidance for these foundations seem to suggest at least
> >> one year should show up in the headers.
> >> I found little evidence that our current approach has benefits,
> >> although some practices seem to imply
> >> a mass header change per (major) release... which does not make all
> >> that much sense to me, but
> >> would at least be easy to automate :-p
> >>
> >> Cheers
> >> Andrea
> >>
> >>
> >>
> >> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira <
> jdeol...@gmail.com>
> >> wrote:
> >>
> >>> Thanks for the input everyone. I put together a proposal with all
> of
> >>> the options put forth on this thread. Apologies if I missed one,
> if I did
> >>> just let me know.
> >>>
> >>>
> >>>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
> >>>
> >>> Like I said before this proposal involves listing out in order of
> >>> preference the various options. Feel free to update the proposal
> or just
> >>> reply to this thread and I’ll happily make the update on your
> behalf.
> >>>
> >>> Thanks!
> >>>
> >>> -Justin
> >>>
> >>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett <
> jody.garn...@gmail.com>
> >>> wrote:
> >>>
>  You asked where I was uncomfortable, not if it made sense :)
> 
>  --
>  Jody Garnett
> 
>  On 25 April 2016 at 09:37, Justin Deoliveira 
>  wrote:
> 
> > I can see how the original date could be useful for 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

I do not think option D can work with a distributed version control 
system. I think this option is unimplementable with git. If we eliminate 
D, then C is the winner.

Kind regards,
Ben.

On 18/05/16 07:05, Ben Caradoc-Davies wrote:
> Instant runoff voting give a win for D:
> https://en.wikipedia.org/wiki/Instant-runoff_voting
>
> Round 1: A eliminated
> Round 2: B eliminated
> Round 3: D wins with 3/5 votes
>
> Kind regards,
> Ben.
>
> On 18/05/16 01:21, Justin Deoliveira wrote:
>> Thanks for kicking this one Andrea.
>>
>> Using a simple weighted scoring where first pick gets 4 points, second 3,
>> etc… the current votes come out to:
>>
>> A: 5
>> B: 12
>> C: 12
>> D: 11
>>
>> Which means a tie between methods B and C… so ideally the other PSC members
>> could get there votes in on this one so things can move forward.
>>
>> It also looks like D is getting some traction. I am trying to think about
>> how that option might work in practice… I understand git post commit hooks
>> but I don’t think I’ve ever seen them used to actually modify the contents
>> of a file being committed. Questions I have are:
>>
>> - Is this even possible? And if git does allow it does github support it?
>> - Since change you are committing isn’t the actual diff that results in the
>> main repository how will this play out when it comes to merging? Since the
>> diff you made locally won’t be the same as what gets stored on the server?
>> - Does this mean that after every commit you have to remember to pull so
>> you can grab the latest version of the file?
>>
>> It might be worth trying to flesh that option out a bit more if folks are
>> going to be voting that way.
>>
>> On Mon, May 16, 2016 at 11:17 AM Andrea Aime 
>> wrote:
>>
>>> Hi,
>>> thanks Ian, updated
>>>
>>> Cheers
>>> Andrea
>>>
>>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton  wrote:
>>>
 Github won't let my phone login so I vote. D, c, b, a.

 Ian

>>> On 16 May 2016 17:24, "Andrea Aime"  wrote:

>>> Hi,
> looked at the proposal, seems it got stuck?
> Could the other PSC members provide a preference list too?
>
>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>
> Cheers
> Andrea
>
>
> On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> Hi Justin,
>> I made a bit of research as this is one topic that foundations probably
>> have guidance on.
>> Found these for the moment:
>> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>>
>> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
>> http://www.apache.org/legal/src-headers.html
>>
>> The official guidance for these foundations seem to suggest at least
>> one year should show up in the headers.
>> I found little evidence that our current approach has benefits,
>> although some practices seem to imply
>> a mass header change per (major) release... which does not make all
>> that much sense to me, but
>> would at least be easy to automate :-p
>>
>> Cheers
>> Andrea
>>
>>
>>
>> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira 
>> wrote:
>>
>>> Thanks for the input everyone. I put together a proposal with all of
>>> the options put forth on this thread. Apologies if I missed one, if I 
>>> did
>>> just let me know.
>>>
>>>
>>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>>
>>> Like I said before this proposal involves listing out in order of
>>> preference the various options. Feel free to update the proposal or just
>>> reply to this thread and I’ll happily make the update on your behalf.
>>>
>>> Thanks!
>>>
>>> -Justin
>>>
>>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
>>> wrote:
>>>
 You asked where I was uncomfortable, not if it made sense :)

 --
 Jody Garnett

 On 25 April 2016 at 09:37, Justin Deoliveira 
 wrote:

> I can see how the original date could be useful for cases like this
> but have you ever seen a situation where something was marked (for 
> example)
> (c) 2010 and from 2010 to the current date of when you were doing the 
> audit
> the copyright changed in some meaningful way? I am of course not 
> counting
> any transfer of copyright to OSGeo, etc… since I would expect that to
> result in a new copyright timestamp.
>
> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <
> jody.garn...@gmail.com> wrote:
>
>> The part that is making me uneasy is the few times I have done code
>> audits on this 

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Instant runoff voting give a win for D:
https://en.wikipedia.org/wiki/Instant-runoff_voting

Round 1: A eliminated
Round 2: B eliminated
Round 3: D wins with 3/5 votes

Kind regards,
Ben.

On 18/05/16 01:21, Justin Deoliveira wrote:
> Thanks for kicking this one Andrea.
>
> Using a simple weighted scoring where first pick gets 4 points, second 3,
> etc… the current votes come out to:
>
> A: 5
> B: 12
> C: 12
> D: 11
>
> Which means a tie between methods B and C… so ideally the other PSC members
> could get there votes in on this one so things can move forward.
>
> It also looks like D is getting some traction. I am trying to think about
> how that option might work in practice… I understand git post commit hooks
> but I don’t think I’ve ever seen them used to actually modify the contents
> of a file being committed. Questions I have are:
>
> - Is this even possible? And if git does allow it does github support it?
> - Since change you are committing isn’t the actual diff that results in the
> main repository how will this play out when it comes to merging? Since the
> diff you made locally won’t be the same as what gets stored on the server?
> - Does this mean that after every commit you have to remember to pull so
> you can grab the latest version of the file?
>
> It might be worth trying to flesh that option out a bit more if folks are
> going to be voting that way.
>
> On Mon, May 16, 2016 at 11:17 AM Andrea Aime 
> wrote:
>
>> Hi,
>> thanks Ian, updated
>>
>> Cheers
>> Andrea
>>
>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton  wrote:
>>
>>> Github won't let my phone login so I vote. D, c, b, a.
>>>
>>> Ian
>>>
>> On 16 May 2016 17:24, "Andrea Aime"  wrote:
>>>
>> Hi,
 looked at the proposal, seems it got stuck?
 Could the other PSC members provide a preference list too?


 https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

 Cheers
 Andrea


 On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> Hi Justin,
> I made a bit of research as this is one topic that foundations probably
> have guidance on.
> Found these for the moment:
> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
> http://www.apache.org/legal/src-headers.html
>
> The official guidance for these foundations seem to suggest at least
> one year should show up in the headers.
> I found little evidence that our current approach has benefits,
> although some practices seem to imply
> a mass header change per (major) release... which does not make all
> that much sense to me, but
> would at least be easy to automate :-p
>
> Cheers
> Andrea
>
>
>
> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira 
> wrote:
>
>> Thanks for the input everyone. I put together a proposal with all of
>> the options put forth on this thread. Apologies if I missed one, if I did
>> just let me know.
>>
>>
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>
>> Like I said before this proposal involves listing out in order of
>> preference the various options. Feel free to update the proposal or just
>> reply to this thread and I’ll happily make the update on your behalf.
>>
>> Thanks!
>>
>> -Justin
>>
>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
>> wrote:
>>
>>> You asked where I was uncomfortable, not if it made sense :)
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 25 April 2016 at 09:37, Justin Deoliveira 
>>> wrote:
>>>
 I can see how the original date could be useful for cases like this
 but have you ever seen a situation where something was marked (for 
 example)
 (c) 2010 and from 2010 to the current date of when you were doing the 
 audit
 the copyright changed in some meaningful way? I am of course not 
 counting
 any transfer of copyright to OSGeo, etc… since I would expect that to
 result in a new copyright timestamp.

 On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <
 jody.garn...@gmail.com> wrote:

> The part that is making me uneasy is the few times I have done code
> audits on this codebase the headers were very useful. While I did 
> have to
> duck out to git history on a few occasions it was a rare occurrence - 
> in
> part because the team here has done a good job.
>
> --
> Jody Garnett
>
> On 24 April 2016 at 08:13, Justin Deoliveira 
> wrote:
>

Re: [Geotools-devel] Copyright header policy

[Daniele Romagnoli]

Hi,
I'm not a PSC so I'm not voting, but when taking a look at the options just
out of curiosity, I had the same doubt reported by Justin in relation to D.
Wondering If with approach D, the auto-change on commit, you are basically
always out of sync?

Cheers,
Daniele

On Tue, May 17, 2016 at 3:21 PM, Justin Deoliveira 
wrote:

> Thanks for kicking this one Andrea.
>
> Using a simple weighted scoring where first pick gets 4 points, second 3,
> etc… the current votes come out to:
>
> A: 5
> B: 12
> C: 12
> D: 11
>
> Which means a tie between methods B and C… so ideally the other PSC
> members could get there votes in on this one so things can move forward.
>
> It also looks like D is getting some traction. I am trying to think about
> how that option might work in practice… I understand git post commit hooks
> but I don’t think I’ve ever seen them used to actually modify the contents
> of a file being committed. Questions I have are:
>
> - Is this even possible? And if git does allow it does github support it?
> - Since change you are committing isn’t the actual diff that results in
> the main repository how will this play out when it comes to merging? Since
> the diff you made locally won’t be the same as what gets stored on the
> server?
> - Does this mean that after every commit you have to remember to pull so
> you can grab the latest version of the file?
>
> It might be worth trying to flesh that option out a bit more if folks are
> going to be voting that way.
>
> On Mon, May 16, 2016 at 11:17 AM Andrea Aime 
> wrote:
>
>> Hi,
>> thanks Ian, updated
>>
>> Cheers
>> Andrea
>>
>> On Mon, May 16, 2016 at 7:08 PM, Ian Turton  wrote:
>>
>>> Github won't let my phone login so I vote. D, c, b, a.
>>>
>>> Ian
>>>
>> On 16 May 2016 17:24, "Andrea Aime"  wrote:
>>>
>> Hi,
 looked at the proposal, seems it got stuck?
 Could the other PSC members provide a preference list too?


 https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

 Cheers
 Andrea


 On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> Hi Justin,
> I made a bit of research as this is one topic that foundations probably
> have guidance on.
> Found these for the moment:
> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
> http://www.apache.org/legal/src-headers.html
>
> The official guidance for these foundations seem to suggest at least
> one year should show up in the headers.
> I found little evidence that our current approach has benefits,
> although some practices seem to imply
> a mass header change per (major) release... which does not make all
> that much sense to me, but
> would at least be easy to automate :-p
>
> Cheers
> Andrea
>
>
>
> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira  > wrote:
>
>> Thanks for the input everyone. I put together a proposal with all of
>> the options put forth on this thread. Apologies if I missed one, if I did
>> just let me know.
>>
>>
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>
>> Like I said before this proposal involves listing out in order of
>> preference the various options. Feel free to update the proposal or just
>> reply to this thread and I’ll happily make the update on your behalf.
>>
>> Thanks!
>>
>> -Justin
>>
>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
>> wrote:
>>
>>> You asked where I was uncomfortable, not if it made sense :)
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 25 April 2016 at 09:37, Justin Deoliveira 
>>> wrote:
>>>
 I can see how the original date could be useful for cases like this
 but have you ever seen a situation where something was marked (for 
 example)
 (c) 2010 and from 2010 to the current date of when you were doing the 
 audit
 the copyright changed in some meaningful way? I am of course not 
 counting
 any transfer of copyright to OSGeo, etc… since I would expect that to
 result in a new copyright timestamp.

 On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <
 jody.garn...@gmail.com> wrote:

> The part that is making me uneasy is the few times I have done
> code audits on this codebase the headers were very useful. While I 
> did have
> to duck out to git history on a few occasions it was a rare 
> occurrence - in
> part because the team here has done a good job.
>
> --
> Jody Garnett

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks for kicking this one Andrea.

Using a simple weighted scoring where first pick gets 4 points, second 3,
etc… the current votes come out to:

A: 5
B: 12
C: 12
D: 11

Which means a tie between methods B and C… so ideally the other PSC members
could get there votes in on this one so things can move forward.

It also looks like D is getting some traction. I am trying to think about
how that option might work in practice… I understand git post commit hooks
but I don’t think I’ve ever seen them used to actually modify the contents
of a file being committed. Questions I have are:

- Is this even possible? And if git does allow it does github support it?
- Since change you are committing isn’t the actual diff that results in the
main repository how will this play out when it comes to merging? Since the
diff you made locally won’t be the same as what gets stored on the server?
- Does this mean that after every commit you have to remember to pull so
you can grab the latest version of the file?

It might be worth trying to flesh that option out a bit more if folks are
going to be voting that way.

On Mon, May 16, 2016 at 11:17 AM Andrea Aime 
wrote:

> Hi,
> thanks Ian, updated
>
> Cheers
> Andrea
>
> On Mon, May 16, 2016 at 7:08 PM, Ian Turton  wrote:
>
>> Github won't let my phone login so I vote. D, c, b, a.
>>
>> Ian
>>
> On 16 May 2016 17:24, "Andrea Aime"  wrote:
>>
> Hi,
>>> looked at the proposal, seems it got stuck?
>>> Could the other PSC members provide a preference list too?
>>>
>>>
>>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 Hi Justin,
 I made a bit of research as this is one topic that foundations probably
 have guidance on.
 Found these for the moment:
 https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

 https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
 http://www.apache.org/legal/src-headers.html

 The official guidance for these foundations seem to suggest at least
 one year should show up in the headers.
 I found little evidence that our current approach has benefits,
 although some practices seem to imply
 a mass header change per (major) release... which does not make all
 that much sense to me, but
 would at least be easy to automate :-p

 Cheers
 Andrea



 On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira 
 wrote:

> Thanks for the input everyone. I put together a proposal with all of
> the options put forth on this thread. Apologies if I missed one, if I did
> just let me know.
>
>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>
> Like I said before this proposal involves listing out in order of
> preference the various options. Feel free to update the proposal or just
> reply to this thread and I’ll happily make the update on your behalf.
>
> Thanks!
>
> -Justin
>
> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
> wrote:
>
>> You asked where I was uncomfortable, not if it made sense :)
>>
>> --
>> Jody Garnett
>>
>> On 25 April 2016 at 09:37, Justin Deoliveira 
>> wrote:
>>
>>> I can see how the original date could be useful for cases like this
>>> but have you ever seen a situation where something was marked (for 
>>> example)
>>> (c) 2010 and from 2010 to the current date of when you were doing the 
>>> audit
>>> the copyright changed in some meaningful way? I am of course not 
>>> counting
>>> any transfer of copyright to OSGeo, etc… since I would expect that to
>>> result in a new copyright timestamp.
>>>
>>> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett <
>>> jody.garn...@gmail.com> wrote:
>>>
 The part that is making me uneasy is the few times I have done code
 audits on this codebase the headers were very useful. While I did have 
 to
 duck out to git history on a few occasions it was a rare occurrence - 
 in
 part because the team here has done a good job.

 --
 Jody Garnett

 On 24 April 2016 at 08:13, Justin Deoliveira 
 wrote:

> What is it specifically that is making you uneasy? I thought Ben
> made a pretty strong argument that any dates in the copyright don’t 
> really
> mean anything when it comes to actual legal stuff.
>
> Doing it periodically via a script does seem like a better
> compromise… although from everything I have heard here I still don’t 

Re: [Geotools-devel] Copyright header policy

[Andrea Aime]

Hi,
looked at the proposal, seems it got stuck?
Could the other PSC members provide a preference list too?

https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

Cheers
Andrea


On Wed, Apr 27, 2016 at 10:15 AM, Andrea Aime 
wrote:

> Hi Justin,
> I made a bit of research as this is one topic that foundations probably
> have guidance on.
> Found these for the moment:
> https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
> http://www.apache.org/legal/src-headers.html
>
> The official guidance for these foundations seem to suggest at least one
> year should show up in the headers.
> I found little evidence that our current approach has benefits, although
> some practices seem to imply
> a mass header change per (major) release... which does not make all that
> much sense to me, but
> would at least be easy to automate :-p
>
> Cheers
> Andrea
>
>
>
> On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira 
> wrote:
>
>> Thanks for the input everyone. I put together a proposal with all of the
>> options put forth on this thread. Apologies if I missed one, if I did just
>> let me know.
>>
>>
>> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>>
>> Like I said before this proposal involves listing out in order of
>> preference the various options. Feel free to update the proposal or just
>> reply to this thread and I’ll happily make the update on your behalf.
>>
>> Thanks!
>>
>> -Justin
>>
>> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
>> wrote:
>>
>>> You asked where I was uncomfortable, not if it made sense :)
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 25 April 2016 at 09:37, Justin Deoliveira  wrote:
>>>
 I can see how the original date could be useful for cases like this but
 have you ever seen a situation where something was marked (for example) (c)
 2010 and from 2010 to the current date of when you were doing the audit the
 copyright changed in some meaningful way? I am of course not counting any
 transfer of copyright to OSGeo, etc… since I would expect that to result in
 a new copyright timestamp.

 On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
 wrote:

> The part that is making me uneasy is the few times I have done code
> audits on this codebase the headers were very useful. While I did have to
> duck out to git history on a few occasions it was a rare occurrence - in
> part because the team here has done a good job.
>
> --
> Jody Garnett
>
> On 24 April 2016 at 08:13, Justin Deoliveira 
> wrote:
>
>> What is it specifically that is making you uneasy? I thought Ben made
>> a pretty strong argument that any dates in the copyright don’t really 
>> mean
>> anything when it comes to actual legal stuff.
>>
>> Doing it periodically via a script does seem like a better
>> compromise… although from everything I have heard here I still don’t see
>> why initial creation date isn’t enough.
>>
>> Once this thread “quiets down” I’ll summarize all of the options that
>> folks have put forth and throw them into the proposal and we can vote for
>> the options we like best. Since there are a handful of options on the 
>> table
>> I think perhaps having people rank options 1,2,3 might work best.
>>
>>
>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
>> wrote:
>>
>>> Yeah the longer I think about this one the more I am made
>>> uncomfortable.  We would be back to "significant" changes needing the
>>> header updated -
>>>
>>> As an alternative wow do you feel about updating the headers once
>>> each year (via a script) so that individual pull requests are not held 
>>> up?
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 12:05, Justin Deoliveira 
>>> wrote:
>>>
 Cool. I'll write up a quick one.

 On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett <
 jody.garn...@gmail.com> wrote:

> If you would like to make that proposal we can update the
> developers guide and get it done ...
>
> --
> Jody Garnett
>
> On 22 April 2016 at 11:38, Justin Deoliveira 
> wrote:
>
>> Thanks Jody. That helps me understand.
>>
>> My thought is that the day to day overhead is not worth being
>> able to rest assured that in 75 years GeoTools will still be in good
>> standing with regard to copyright ;)
>>
>> My vote would be to change to a process where the copyright is
>> set to the current year that the file is created 

Re: [Geotools-devel] Copyright header policy

[Andrea Aime]

Hi Justin,
I made a bit of research as this is one topic that foundations probably
have guidance on.
Found these for the moment:
https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
http://www.apache.org/legal/src-headers.html

The official guidance for these foundations seem to suggest at least one
year should show up in the headers.
I found little evidence that our current approach has benefits, although
some practices seem to imply
a mass header change per (major) release... which does not make all that
much sense to me, but
would at least be easy to automate :-p

Cheers
Andrea



On Wed, Apr 27, 2016 at 4:15 AM, Justin Deoliveira 
wrote:

> Thanks for the input everyone. I put together a proposal with all of the
> options put forth on this thread. Apologies if I missed one, if I did just
> let me know.
>
>
> https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy
>
> Like I said before this proposal involves listing out in order of
> preference the various options. Feel free to update the proposal or just
> reply to this thread and I’ll happily make the update on your behalf.
>
> Thanks!
>
> -Justin
>
> On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett 
> wrote:
>
>> You asked where I was uncomfortable, not if it made sense :)
>>
>> --
>> Jody Garnett
>>
>> On 25 April 2016 at 09:37, Justin Deoliveira  wrote:
>>
>>> I can see how the original date could be useful for cases like this but
>>> have you ever seen a situation where something was marked (for example) (c)
>>> 2010 and from 2010 to the current date of when you were doing the audit the
>>> copyright changed in some meaningful way? I am of course not counting any
>>> transfer of copyright to OSGeo, etc… since I would expect that to result in
>>> a new copyright timestamp.
>>>
>>> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
>>> wrote:
>>>
 The part that is making me uneasy is the few times I have done code
 audits on this codebase the headers were very useful. While I did have to
 duck out to git history on a few occasions it was a rare occurrence - in
 part because the team here has done a good job.

 --
 Jody Garnett

 On 24 April 2016 at 08:13, Justin Deoliveira 
 wrote:

> What is it specifically that is making you uneasy? I thought Ben made
> a pretty strong argument that any dates in the copyright don’t really mean
> anything when it comes to actual legal stuff.
>
> Doing it periodically via a script does seem like a better compromise…
> although from everything I have heard here I still don’t see why initial
> creation date isn’t enough.
>
> Once this thread “quiets down” I’ll summarize all of the options that
> folks have put forth and throw them into the proposal and we can vote for
> the options we like best. Since there are a handful of options on the 
> table
> I think perhaps having people rank options 1,2,3 might work best.
>
>
> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
> wrote:
>
>> Yeah the longer I think about this one the more I am made
>> uncomfortable.  We would be back to "significant" changes needing the
>> header updated -
>>
>> As an alternative wow do you feel about updating the headers once
>> each year (via a script) so that individual pull requests are not held 
>> up?
>>
>> --
>> Jody Garnett
>>
>> On 22 April 2016 at 12:05, Justin Deoliveira 
>> wrote:
>>
>>> Cool. I'll write up a quick one.
>>>
>>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>>> wrote:
>>>
 If you would like to make that proposal we can update the
 developers guide and get it done ...

 --
 Jody Garnett

 On 22 April 2016 at 11:38, Justin Deoliveira 
 wrote:

> Thanks Jody. That helps me understand.
>
> My thought is that the day to day overhead is not worth being able
> to rest assured that in 75 years GeoTools will still be in good 
> standing
> with regard to copyright ;)
>
> My vote would be to change to a process where the copyright is set
> to the current year that the file is created or undergoes a major
> overhaul/rewrite. I
>
> $0.02
>
> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
>> jody.garn...@gmail.com> wrote:
>>
>>> If the PMC wants to make this decision I would be -0, I
>>> understand that it would assist with 

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks for the input everyone. I put together a proposal with all of the
options put forth on this thread. Apologies if I missed one, if I did just
let me know.


https://github.com/geotools/geotools/wiki/Updates-to-Copyright-Header-Policy

Like I said before this proposal involves listing out in order of
preference the various options. Feel free to update the proposal or just
reply to this thread and I’ll happily make the update on your behalf.

Thanks!

-Justin

On Tue, Apr 26, 2016 at 2:50 PM Jody Garnett  wrote:

> You asked where I was uncomfortable, not if it made sense :)
>
> --
> Jody Garnett
>
> On 25 April 2016 at 09:37, Justin Deoliveira  wrote:
>
>> I can see how the original date could be useful for cases like this but
>> have you ever seen a situation where something was marked (for example) (c)
>> 2010 and from 2010 to the current date of when you were doing the audit the
>> copyright changed in some meaningful way? I am of course not counting any
>> transfer of copyright to OSGeo, etc… since I would expect that to result in
>> a new copyright timestamp.
>>
>> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
>> wrote:
>>
>>> The part that is making me uneasy is the few times I have done code
>>> audits on this codebase the headers were very useful. While I did have to
>>> duck out to git history on a few occasions it was a rare occurrence - in
>>> part because the team here has done a good job.
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 24 April 2016 at 08:13, Justin Deoliveira  wrote:
>>>
 What is it specifically that is making you uneasy? I thought Ben made a
 pretty strong argument that any dates in the copyright don’t really mean
 anything when it comes to actual legal stuff.

 Doing it periodically via a script does seem like a better compromise…
 although from everything I have heard here I still don’t see why initial
 creation date isn’t enough.

 Once this thread “quiets down” I’ll summarize all of the options that
 folks have put forth and throw them into the proposal and we can vote for
 the options we like best. Since there are a handful of options on the table
 I think perhaps having people rank options 1,2,3 might work best.


 On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
 wrote:

> Yeah the longer I think about this one the more I am made
> uncomfortable.  We would be back to "significant" changes needing the
> header updated -
>
> As an alternative wow do you feel about updating the headers once each
> year (via a script) so that individual pull requests are not held up?
>
> --
> Jody Garnett
>
> On 22 April 2016 at 12:05, Justin Deoliveira 
> wrote:
>
>> Cool. I'll write up a quick one.
>>
>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>> wrote:
>>
>>> If you would like to make that proposal we can update the developers
>>> guide and get it done ...
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 11:38, Justin Deoliveira 
>>> wrote:
>>>
 Thanks Jody. That helps me understand.

 My thought is that the day to day overhead is not worth being able
 to rest assured that in 75 years GeoTools will still be in good 
 standing
 with regard to copyright ;)

 My vote would be to change to a process where the copyright is set
 to the current year that the file is created or undergoes a major
 overhaul/rewrite. I

 $0.02

 On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
> jody.garn...@gmail.com> wrote:
>
>> If the PMC wants to make this decision I would be -0, I
>> understand that it would assist with github pull requests, but I 
>> feel we
>> would do so by cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be
> automated (see Kevin's GeoServer script), but yeah, it's really 
> annoying to
> require
> every single time a pull request comes in to update the copyright
> headers...
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

You asked where I was uncomfortable, not if it made sense :)

--
Jody Garnett

On 25 April 2016 at 09:37, Justin Deoliveira  wrote:

> I can see how the original date could be useful for cases like this but
> have you ever seen a situation where something was marked (for example) (c)
> 2010 and from 2010 to the current date of when you were doing the audit the
> copyright changed in some meaningful way? I am of course not counting any
> transfer of copyright to OSGeo, etc… since I would expect that to result in
> a new copyright timestamp.
>
> On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
> wrote:
>
>> The part that is making me uneasy is the few times I have done code
>> audits on this codebase the headers were very useful. While I did have to
>> duck out to git history on a few occasions it was a rare occurrence - in
>> part because the team here has done a good job.
>>
>> --
>> Jody Garnett
>>
>> On 24 April 2016 at 08:13, Justin Deoliveira  wrote:
>>
>>> What is it specifically that is making you uneasy? I thought Ben made a
>>> pretty strong argument that any dates in the copyright don’t really mean
>>> anything when it comes to actual legal stuff.
>>>
>>> Doing it periodically via a script does seem like a better compromise…
>>> although from everything I have heard here I still don’t see why initial
>>> creation date isn’t enough.
>>>
>>> Once this thread “quiets down” I’ll summarize all of the options that
>>> folks have put forth and throw them into the proposal and we can vote for
>>> the options we like best. Since there are a handful of options on the table
>>> I think perhaps having people rank options 1,2,3 might work best.
>>>
>>>
>>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
>>> wrote:
>>>
 Yeah the longer I think about this one the more I am made
 uncomfortable.  We would be back to "significant" changes needing the
 header updated -

 As an alternative wow do you feel about updating the headers once each
 year (via a script) so that individual pull requests are not held up?

 --
 Jody Garnett

 On 22 April 2016 at 12:05, Justin Deoliveira 
 wrote:

> Cool. I'll write up a quick one.
>
> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
> wrote:
>
>> If you would like to make that proposal we can update the developers
>> guide and get it done ...
>>
>> --
>> Jody Garnett
>>
>> On 22 April 2016 at 11:38, Justin Deoliveira 
>> wrote:
>>
>>> Thanks Jody. That helps me understand.
>>>
>>> My thought is that the day to day overhead is not worth being able
>>> to rest assured that in 75 years GeoTools will still be in good standing
>>> with regard to copyright ;)
>>>
>>> My vote would be to change to a process where the copyright is set
>>> to the current year that the file is created or undergoes a major
>>> overhaul/rewrite. I
>>>
>>> $0.02
>>>
>>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
 jody.garn...@gmail.com> wrote:

> If the PMC wants to make this decision I would be -0, I understand
> that it would assist with github pull requests, but I feel we would 
> do so
> by cutting a corner.
>

 I don't feel strongly either way, copyright updates can be
 automated (see Kevin's GeoServer script), but yeah, it's really 
 annoying to
 require
 every single time a pull request comes in to update the copyright
 headers...

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/it488V for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions S.A.S.
 Via di Montramito 3/A
 55054  Massarosa (LU)
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob: +39  339 8844549

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica
 e/o nel/i file/s allegato/i sono da considerarsi strettamente 
 riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del 
 messaggio,
 per le finalità indicate nel messaggio stesso. Qualora riceviate questo
 messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
 darcene notizia via e-mail e di procedere alla distruzione del 
 messaggio
 stesso, 

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

I can see how the original date could be useful for cases like this but
have you ever seen a situation where something was marked (for example) (c)
2010 and from 2010 to the current date of when you were doing the audit the
copyright changed in some meaningful way? I am of course not counting any
transfer of copyright to OSGeo, etc… since I would expect that to result in
a new copyright timestamp.

On Mon, Apr 25, 2016 at 12:12 AM Jody Garnett 
wrote:

> The part that is making me uneasy is the few times I have done code audits
> on this codebase the headers were very useful. While I did have to duck out
> to git history on a few occasions it was a rare occurrence - in part
> because the team here has done a good job.
>
> --
> Jody Garnett
>
> On 24 April 2016 at 08:13, Justin Deoliveira  wrote:
>
>> What is it specifically that is making you uneasy? I thought Ben made a
>> pretty strong argument that any dates in the copyright don’t really mean
>> anything when it comes to actual legal stuff.
>>
>> Doing it periodically via a script does seem like a better compromise…
>> although from everything I have heard here I still don’t see why initial
>> creation date isn’t enough.
>>
>> Once this thread “quiets down” I’ll summarize all of the options that
>> folks have put forth and throw them into the proposal and we can vote for
>> the options we like best. Since there are a handful of options on the table
>> I think perhaps having people rank options 1,2,3 might work best.
>>
>>
>> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
>> wrote:
>>
>>> Yeah the longer I think about this one the more I am made
>>> uncomfortable.  We would be back to "significant" changes needing the
>>> header updated -
>>>
>>> As an alternative wow do you feel about updating the headers once each
>>> year (via a script) so that individual pull requests are not held up?
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 12:05, Justin Deoliveira  wrote:
>>>
 Cool. I'll write up a quick one.

 On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
 wrote:

> If you would like to make that proposal we can update the developers
> guide and get it done ...
>
> --
> Jody Garnett
>
> On 22 April 2016 at 11:38, Justin Deoliveira 
> wrote:
>
>> Thanks Jody. That helps me understand.
>>
>> My thought is that the day to day overhead is not worth being able to
>> rest assured that in 75 years GeoTools will still be in good standing 
>> with
>> regard to copyright ;)
>>
>> My vote would be to change to a process where the copyright is set to
>> the current year that the file is created or undergoes a major
>> overhaul/rewrite. I
>>
>> $0.02
>>
>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett <
>>> jody.garn...@gmail.com> wrote:
>>>
 If the PMC wants to make this decision I would be -0, I understand
 that it would assist with github pull requests, but I feel we would do 
 so
 by cutting a corner.

>>>
>>> I don't feel strongly either way, copyright updates can be automated
>>> (see Kevin's GeoServer script), but yeah, it's really annoying to 
>>> require
>>> every single time a pull request comes in to update the copyright
>>> headers...
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica
>>> e/o nel/i file/s allegato/i sono da considerarsi strettamente 
>>> riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio 
>>> stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The 

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

The part that is making me uneasy is the few times I have done code audits
on this codebase the headers were very useful. While I did have to duck out
to git history on a few occasions it was a rare occurrence - in part
because the team here has done a good job.

--
Jody Garnett

On 24 April 2016 at 08:13, Justin Deoliveira  wrote:

> What is it specifically that is making you uneasy? I thought Ben made a
> pretty strong argument that any dates in the copyright don’t really mean
> anything when it comes to actual legal stuff.
>
> Doing it periodically via a script does seem like a better compromise…
> although from everything I have heard here I still don’t see why initial
> creation date isn’t enough.
>
> Once this thread “quiets down” I’ll summarize all of the options that
> folks have put forth and throw them into the proposal and we can vote for
> the options we like best. Since there are a handful of options on the table
> I think perhaps having people rank options 1,2,3 might work best.
>
>
> On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett 
> wrote:
>
>> Yeah the longer I think about this one the more I am made uncomfortable.
>> We would be back to "significant" changes needing the header updated -
>>
>> As an alternative wow do you feel about updating the headers once each
>> year (via a script) so that individual pull requests are not held up?
>>
>> --
>> Jody Garnett
>>
>> On 22 April 2016 at 12:05, Justin Deoliveira  wrote:
>>
>>> Cool. I'll write up a quick one.
>>>
>>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>>> wrote:
>>>
 If you would like to make that proposal we can update the developers
 guide and get it done ...

 --
 Jody Garnett

 On 22 April 2016 at 11:38, Justin Deoliveira 
 wrote:

> Thanks Jody. That helps me understand.
>
> My thought is that the day to day overhead is not worth being able to
> rest assured that in 75 years GeoTools will still be in good standing with
> regard to copyright ;)
>
> My vote would be to change to a process where the copyright is set to
> the current year that the file is created or undergoes a major
> overhaul/rewrite. I
>
> $0.02
>
> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett > > wrote:
>>
>>> If the PMC wants to make this decision I would be -0, I understand
>>> that it would assist with github pull requests, but I feel we would do 
>>> so
>>> by cutting a corner.
>>>
>>
>> I don't feel strongly either way, copyright updates can be automated
>> (see Kevin's GeoServer script), but yeah, it's really annoying to require
>> every single time a pull request comes in to update the copyright
>> headers...
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica
>> e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. 
>> Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended
>> solely for the attention and use of the named addressee(s) and may be
>> confidential or proprietary in nature or covered by the provisions of
>> privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data
>> Protection Code).Any use not in accord with its purpose, any disclosure,
>> reproduction, copying, distribution, or either dissemination, either 
>> whole
>> or partial, is strictly forbidden except previous formal approval of the
>> named addressee(s). If you are not the intended recipient, please contact
>> 

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

The main thing about the author tag is the "name in lights" effect of being
able to show your boss your contribution on the published geotools
javadocs, and our author tags often also note the employer if appropriate.
This kind of encouragement can be very encouraging when starting out in
open source.

--
Jody Garnett

On 24 April 2016 at 13:00, Ben Caradoc-Davies  wrote:

> Torben,
>
> I think these are strong arguments and I am now tempted to avoid @author.
> It seems cleaner and more elegant to me to keep all metadata (authorship,
> version history, and copyright) outside the source code itself. The
> downside is that this information is not visible to non-revision-aware
> consumers (web browsers, search engines) and is lost on export from the
> revision control system, but the upside is that the code base becomes
> cleaner and easier to maintain.
>
> Kind regards,
> Ben.
>
>
> On 23/04/16 11:53, Torben Barsballe wrote:
>
>> My thoughts on the @author tag:
>> I feel like the git commit log gives a clearer and more usefull picture of
>> this sort of information - You can see the initial author, as well as the
>> author of any major changes, and can usually get a good idea of who is
>> currently doing the most work in that area of the codebase (as compared to
>> someone who authored a class 5 years ago and hasn't touched it since).
>> The one exception is when stuff gets transitioned between repositories or
>> other similar bulk import cases.
>> Conversely, the @author tag is much less maintainable, less enforcable,
>> and
>> prone to getting out-of-date.
>>
>> Torben
>>
>> On Fri, Apr 22, 2016 at 2:39 PM, Ben Caradoc-Davies 
>> wrote:
>>
>> I used to share Andrea's view but, as my confidence grew, I became more
>>> comfortable seeing @author tags as historical information not an
>>> assertion of ownership.
>>>
>>> On 23/04/16 09:24, Jody Garnett wrote:
>>>
 Andrea had a very reasoned argument for not using the @author tag and
 started discouraging its use.
 It amounted to team ownership of the codebase empowering everyone to
 work
 on a class, rather than slowing down to seek permission (or even worse

>>> wait
>>>
 for someone else) to fix a problem.

>>>
>>> --
>>> Ben Caradoc-Davies 
>>> Director
>>> Transient Software Limited 
>>> New Zealand
>>>
>>>
>>>
>>> --
>>> Find and fix application performance issues faster with Applications
>>> Manager
>>> Applications Manager provides deep performance insights into multiple
>>> tiers of
>>> your business applications. It resolves application problems quickly and
>>> reduces your MTTR. Get your free trial!
>>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>>> ___
>>> GeoTools-Devel mailing list
>>> GeoTools-Devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

Torben,

I think these are strong arguments and I am now tempted to avoid 
@author. It seems cleaner and more elegant to me to keep all metadata 
(authorship, version history, and copyright) outside the source code 
itself. The downside is that this information is not visible to 
non-revision-aware consumers (web browsers, search engines) and is lost 
on export from the revision control system, but the upside is that the 
code base becomes cleaner and easier to maintain.

Kind regards,
Ben.

On 23/04/16 11:53, Torben Barsballe wrote:
> My thoughts on the @author tag:
> I feel like the git commit log gives a clearer and more usefull picture of
> this sort of information - You can see the initial author, as well as the
> author of any major changes, and can usually get a good idea of who is
> currently doing the most work in that area of the codebase (as compared to
> someone who authored a class 5 years ago and hasn't touched it since).
> The one exception is when stuff gets transitioned between repositories or
> other similar bulk import cases.
> Conversely, the @author tag is much less maintainable, less enforcable, and
> prone to getting out-of-date.
>
> Torben
>
> On Fri, Apr 22, 2016 at 2:39 PM, Ben Caradoc-Davies 
> wrote:
>
>> I used to share Andrea's view but, as my confidence grew, I became more
>> comfortable seeing @author tags as historical information not an
>> assertion of ownership.
>>
>> On 23/04/16 09:24, Jody Garnett wrote:
>>> Andrea had a very reasoned argument for not using the @author tag and
>>> started discouraging its use.
>>> It amounted to team ownership of the codebase empowering everyone to work
>>> on a class, rather than slowing down to seek permission (or even worse
>> wait
>>> for someone else) to fix a problem.
>>
>> --
>> Ben Caradoc-Davies 
>> Director
>> Transient Software Limited 
>> New Zealand
>>
>>
>> --
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> ___
>> GeoTools-Devel mailing list
>> GeoTools-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

What is it specifically that is making you uneasy? I thought Ben made a
pretty strong argument that any dates in the copyright don’t really mean
anything when it comes to actual legal stuff.

Doing it periodically via a script does seem like a better compromise…
although from everything I have heard here I still don’t see why initial
creation date isn’t enough.

Once this thread “quiets down” I’ll summarize all of the options that folks
have put forth and throw them into the proposal and we can vote for the
options we like best. Since there are a handful of options on the table I
think perhaps having people rank options 1,2,3 might work best.

On Sat, Apr 23, 2016 at 7:22 PM Jody Garnett  wrote:

> Yeah the longer I think about this one the more I am made uncomfortable.
> We would be back to "significant" changes needing the header updated -
>
> As an alternative wow do you feel about updating the headers once each
> year (via a script) so that individual pull requests are not held up?
>
> --
> Jody Garnett
>
> On 22 April 2016 at 12:05, Justin Deoliveira  wrote:
>
>> Cool. I'll write up a quick one.
>>
>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>> wrote:
>>
>>> If you would like to make that proposal we can update the developers
>>> guide and get it done ...
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 11:38, Justin Deoliveira  wrote:
>>>
 Thanks Jody. That helps me understand.

 My thought is that the day to day overhead is not worth being able to
 rest assured that in 75 years GeoTools will still be in good standing with
 regard to copyright ;)

 My vote would be to change to a process where the copyright is set to
 the current year that the file is created or undergoes a major
 overhaul/rewrite. I

 $0.02

 On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
> wrote:
>
>> If the PMC wants to make this decision I would be -0, I understand
>> that it would assist with github pull requests, but I feel we would do so
>> by cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be automated
> (see Kevin's GeoServer script), but yeah, it's really annoying to require
> every single time a pull request comes in to update the copyright
> headers...
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be 
> confidential
> or proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, 
> reproduction,
> copying, distribution, or either dissemination, either whole or partial, 
> is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>

Re: [Geotools-devel] Copyright header policy

[Ian Turton]

Could we not come up with some sort of post-commit hook to make the change
for us, it's the remembering to do the change that is the issue for me (at
least)

Ian

On 24 April 2016 at 02:21, Jody Garnett  wrote:

> Yeah the longer I think about this one the more I am made uncomfortable.
> We would be back to "significant" changes needing the header updated -
>
> As an alternative wow do you feel about updating the headers once each
> year (via a script) so that individual pull requests are not held up?
>
> --
> Jody Garnett
>
> On 22 April 2016 at 12:05, Justin Deoliveira  wrote:
>
>> Cool. I'll write up a quick one.
>>
>> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
>> wrote:
>>
>>> If you would like to make that proposal we can update the developers
>>> guide and get it done ...
>>>
>>> --
>>> Jody Garnett
>>>
>>> On 22 April 2016 at 11:38, Justin Deoliveira  wrote:
>>>
 Thanks Jody. That helps me understand.

 My thought is that the day to day overhead is not worth being able to
 rest assured that in 75 years GeoTools will still be in good standing with
 regard to copyright ;)

 My vote would be to change to a process where the copyright is set to
 the current year that the file is created or undergoes a major
 overhaul/rewrite. I

 $0.02

 On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
 andrea.a...@geo-solutions.it> wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
> wrote:
>
>> If the PMC wants to make this decision I would be -0, I understand
>> that it would assist with github pull requests, but I feel we would do so
>> by cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be automated
> (see Kevin's GeoServer script), but yeah, it's really annoying to require
> every single time a pull request comes in to update the copyright
> headers...
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely
> for the attention and use of the named addressee(s) and may be 
> confidential
> or proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, 
> reproduction,
> copying, distribution, or either dissemination, either whole or partial, 
> is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>

>>>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> 

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

Yeah the longer I think about this one the more I am made uncomfortable.
We would be back to "significant" changes needing the header updated -

As an alternative wow do you feel about updating the headers once each year
(via a script) so that individual pull requests are not held up?

--
Jody Garnett

On 22 April 2016 at 12:05, Justin Deoliveira  wrote:

> Cool. I'll write up a quick one.
>
> On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett 
> wrote:
>
>> If you would like to make that proposal we can update the developers
>> guide and get it done ...
>>
>> --
>> Jody Garnett
>>
>> On 22 April 2016 at 11:38, Justin Deoliveira  wrote:
>>
>>> Thanks Jody. That helps me understand.
>>>
>>> My thought is that the day to day overhead is not worth being able to
>>> rest assured that in 75 years GeoTools will still be in good standing with
>>> regard to copyright ;)
>>>
>>> My vote would be to change to a process where the copyright is set to
>>> the current year that the file is created or undergoes a major
>>> overhaul/rewrite. I
>>>
>>> $0.02
>>>
>>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>>> andrea.a...@geo-solutions.it> wrote:
>>>
 On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
 wrote:

> If the PMC wants to make this decision I would be -0, I understand
> that it would assist with github pull requests, but I feel we would do so
> by cutting a corner.
>

 I don't feel strongly either way, copyright updates can be automated
 (see Kevin's GeoServer script), but yeah, it's really annoying to require
 every single time a pull request comes in to update the copyright
 headers...

 Cheers
 Andrea

 --
 ==
 GeoServer Professional Services from the experts! Visit
 http://goo.gl/it488V for more information.
 ==

 Ing. Andrea Aime
 @geowolf
 Technical Lead

 GeoSolutions S.A.S.
 Via di Montramito 3/A
 55054  Massarosa (LU)
 phone: +39 0584 962313
 fax: +39 0584 1660272
 mob: +39  339 8844549

 http://www.geo-solutions.it
 http://twitter.com/geosolutions_it

 *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

 Le informazioni contenute in questo messaggio di posta elettronica e/o
 nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
 loro utilizzo è consentito esclusivamente al destinatario del messaggio,
 per le finalità indicate nel messaggio stesso. Qualora riceviate questo
 messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
 darcene notizia via e-mail e di procedere alla distruzione del messaggio
 stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
 divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
 utilizzarlo per finalità diverse, costituisce comportamento contrario ai
 principi dettati dal D.Lgs. 196/2003.



 The information in this message and/or attachments, is intended solely
 for the attention and use of the named addressee(s) and may be confidential
 or proprietary in nature or covered by the provisions of privacy act
 (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
 Code).Any use not in accord with its purpose, any disclosure, reproduction,
 copying, distribution, or either dissemination, either whole or partial, is
 strictly forbidden except previous formal approval of the named
 addressee(s). If you are not the intended recipient, please contact
 immediately the sender by telephone, fax or e-mail and delete the
 information in this message that has been received in error. The sender
 does not give any warranty or accept liability as the content, accuracy or
 completeness of sent messages and accepts no responsibility  for changes
 made after they were sent or for other risks which arise as a result of
 e-mail transmission, viruses, etc.

 ---

>>>
>>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Torben Barsballe]

My thoughts on the @author tag:
I feel like the git commit log gives a clearer and more usefull picture of
this sort of information - You can see the initial author, as well as the
author of any major changes, and can usually get a good idea of who is
currently doing the most work in that area of the codebase (as compared to
someone who authored a class 5 years ago and hasn't touched it since).
The one exception is when stuff gets transitioned between repositories or
other similar bulk import cases.
Conversely, the @author tag is much less maintainable, less enforcable, and
prone to getting out-of-date.

Torben

On Fri, Apr 22, 2016 at 2:39 PM, Ben Caradoc-Davies 
wrote:

> I used to share Andrea's view but, as my confidence grew, I became more
> comfortable seeing @author tags as historical information not an
> assertion of ownership.
>
> On 23/04/16 09:24, Jody Garnett wrote:
> > Andrea had a very reasoned argument for not using the @author tag and
> > started discouraging its use.
> > It amounted to team ownership of the codebase empowering everyone to work
> > on a class, rather than slowing down to seek permission (or even worse
> wait
> > for someone else) to fix a problem.
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

I used to share Andrea's view but, as my confidence grew, I became more 
comfortable seeing @author tags as historical information not an 
assertion of ownership.

On 23/04/16 09:24, Jody Garnett wrote:
> Andrea had a very reasoned argument for not using the @author tag and
> started discouraging its use.
> It amounted to team ownership of the codebase empowering everyone to work
> on a class, rather than slowing down to seek permission (or even worse wait
> for someone else) to fix a problem.

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

Andrea had a very reasoned argument for not using the @author tag and
started discouraging its use.

It amounted to team ownership of the codebase empowering everyone to work
on a class, rather than slowing down to seek permission (or even worse wait
for someone else) to fix a problem.

--
Jody Garnett

On 22 April 2016 at 14:21, Ben Caradoc-Davies  wrote:

> In fact, I think we should *require* rather than just encourage the use of
> @author.
>
> Kind regards,
> Ben.
>
>
> On 23/04/16 09:14, Ben Caradoc-Davies wrote:
>
>> I like the Javadoc @author tag. We should encourage its use on all new
>> classes, and additional @author tags for any substantial contribution to
>> an existing file. @author tags are useful not only for provenance but
>> for seeking help; successive changes can make @author tags easier to use
>> than git blame. @author tags also allow us to respect the moral right of
>> attribution.
>>
>> Kind regards,
>> Ben.
>>
>> On 23/04/16 08:42, Jody Garnett wrote:
>>
>>> I like having headers that capture the initial author - since that has
>>> been
>>> very helpful in sorting out any questions during our incubation and
>>> subsequent external code audits.
>>>
>>
>>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

+1. This is a great practice, and required by some licences. Dates in 
these headers cannot be removed or changed.

On 23/04/16 09:19, Jody Garnett wrote:
> The other clarification I have gotten from external review is to leave
> headers intact when copying code into our codebase (we only have a small
> number of examples of this).

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

In fact, I think we should *require* rather than just encourage the use 
of @author.

Kind regards,
Ben.

On 23/04/16 09:14, Ben Caradoc-Davies wrote:
> I like the Javadoc @author tag. We should encourage its use on all new
> classes, and additional @author tags for any substantial contribution to
> an existing file. @author tags are useful not only for provenance but
> for seeking help; successive changes can make @author tags easier to use
> than git blame. @author tags also allow us to respect the moral right of
> attribution.
>
> Kind regards,
> Ben.
>
> On 23/04/16 08:42, Jody Garnett wrote:
>> I like having headers that capture the initial author - since that has been
>> very helpful in sorting out any questions during our incubation and
>> subsequent external code audits.
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

The other clarification I have gotten from external review is to leave
headers intact when copying code into our codebase (we only have a small
number of examples of this).

--
Jody Garnett

On 22 April 2016 at 14:14, Ben Caradoc-Davies  wrote:

> I like the Javadoc @author tag. We should encourage its use on all new
> classes, and additional @author tags for any substantial contribution to an
> existing file. @author tags are useful not only for provenance but for
> seeking help; successive changes can make @author tags easier to use than
> git blame. @author tags also allow us to respect the moral right of
> attribution.
>
> Kind regards,
> Ben.
>
> On 23/04/16 08:42, Jody Garnett wrote:
>
>> I like having headers that capture the initial author - since that has
>> been
>> very helpful in sorting out any questions during our incubation and
>> subsequent external code audits.
>>
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

I like the Javadoc @author tag. We should encourage its use on all new 
classes, and additional @author tags for any substantial contribution to 
an existing file. @author tags are useful not only for provenance but 
for seeking help; successive changes can make @author tags easier to use 
than git blame. @author tags also allow us to respect the moral right of 
attribution.

Kind regards,
Ben.

On 23/04/16 08:42, Jody Garnett wrote:
> I like having headers that capture the initial author - since that has been
> very helpful in sorting out any questions during our incubation and
> subsequent external code audits.

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

OSGeo is governed by projects such as ours setting a precedent.

I like having headers that capture the initial author - since that has been
very helpful in sorting out any questions during our incubation and
subsequent external code audits.

I really cannot see song away with headers as they are being used.
On Fri, Apr 22, 2016 at 1:39 PM Ben Caradoc-Davies  wrote:

> My understanding is that, under the Berne Convention, there is no
> requirement at all for any copyright notice, "Copyright", "(C)", "All
> Rights Reserved", or dates. The WTO requires compliance to TRIPS rules
> which thus apply these rules to practically every country in the world.
> Even the United States adopted the Berne Convention in 1989:
> https://en.wikipedia.org/wiki/Berne_Convention
>
> In my view, and I am not a lawyer, copyright headers are copyright
> theatre without any legal effect, and serve only to permit authors to
> appear serious and knowledgeable about copyright to people who know
> little about it. They are based in obsolete pre-Berne practices.
> Remember that the original GPL boilerplate was written just as Berne
> came to the US and was not widely understood.
>
> I would like to see headers that are more useful to readers and more
> maintainable. I would love to see a static header like this:
>
> /*
>   * GeoTools, The Open Source Java GIS Toolkit 
>   */
>
> All the copyright ownership and licensing information is here:
> http://geotools.org/about.html
>
> And we are done.
>
> So, what should we do? I think we are governed by OSGeo policy. Does
> OSGeo have a policy on headers? Has OSGeo obtained a legal opinion on
> this matter?
>
> Kind regards,
> Ben.
>
> On 23/04/16 01:01, Justin Deoliveira wrote:
> > Hi folks,
> >
> > Something I’ve been meaning to ask about is a clarification of why we
> have
> > to update copyright header dates to the current year for every file
> change.
> > As opposed to just having a static copyright header that signifies a
> > “copyright event” (like the change over to osgeo) and then stands for
> that
> > time forward.
> >
> > The reason I ask is because I think this policy has some negative things
> in
> > my opinion. For one it’s a pain for both contributors and reviewers to
> > enforce. I myself never remember as you probably well know and I would
> say
> > I am a pretty regular contributor. It also adds noise to patches and pull
> > requests, which also makes things harder to review than necessary.
> >
> >
> > Anyways, just curious as to the rationale behind this decision. My
> > apologies if this has been covered in previous email.
> >
> > -Justin
> >
> >
> >
> >
> --
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> >
> >
> >
> > ___
> > GeoTools-Devel mailing list
> > GeoTools-Devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
>
> --
> Ben Caradoc-Davies 
> Director
> Transient Software Limited 
> New Zealand
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
-- 
--
Jody Garnett
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Ben Caradoc-Davies]

My understanding is that, under the Berne Convention, there is no 
requirement at all for any copyright notice, "Copyright", "(C)", "All 
Rights Reserved", or dates. The WTO requires compliance to TRIPS rules 
which thus apply these rules to practically every country in the world. 
Even the United States adopted the Berne Convention in 1989:
https://en.wikipedia.org/wiki/Berne_Convention

In my view, and I am not a lawyer, copyright headers are copyright 
theatre without any legal effect, and serve only to permit authors to 
appear serious and knowledgeable about copyright to people who know 
little about it. They are based in obsolete pre-Berne practices. 
Remember that the original GPL boilerplate was written just as Berne 
came to the US and was not widely understood.

I would like to see headers that are more useful to readers and more 
maintainable. I would love to see a static header like this:

/*
  * GeoTools, The Open Source Java GIS Toolkit 
  */

All the copyright ownership and licensing information is here: 
http://geotools.org/about.html

And we are done.

So, what should we do? I think we are governed by OSGeo policy. Does 
OSGeo have a policy on headers? Has OSGeo obtained a legal opinion on 
this matter?

Kind regards,
Ben.

On 23/04/16 01:01, Justin Deoliveira wrote:
> Hi folks,
>
> Something I’ve been meaning to ask about is a clarification of why we have
> to update copyright header dates to the current year for every file change.
> As opposed to just having a static copyright header that signifies a
> “copyright event” (like the change over to osgeo) and then stands for that
> time forward.
>
> The reason I ask is because I think this policy has some negative things in
> my opinion. For one it’s a pain for both contributors and reviewers to
> enforce. I myself never remember as you probably well know and I would say
> I am a pretty regular contributor. It also adds noise to patches and pull
> requests, which also makes things harder to review than necessary.
>
>
> Anyways, just curious as to the rationale behind this decision. My
> apologies if this has been covered in previous email.
>
> -Justin
>
>
>
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
>
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>

-- 
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Cool. I'll write up a quick one.
On Fri, Apr 22, 2016 at 1:01 PM Jody Garnett  wrote:

> If you would like to make that proposal we can update the developers guide
> and get it done ...
>
> --
> Jody Garnett
>
> On 22 April 2016 at 11:38, Justin Deoliveira  wrote:
>
>> Thanks Jody. That helps me understand.
>>
>> My thought is that the day to day overhead is not worth being able to
>> rest assured that in 75 years GeoTools will still be in good standing with
>> regard to copyright ;)
>>
>> My vote would be to change to a process where the copyright is set to the
>> current year that the file is created or undergoes a major
>> overhaul/rewrite. I
>>
>> $0.02
>>
>> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
>>> wrote:
>>>
 If the PMC wants to make this decision I would be -0, I understand that
 it would assist with github pull requests, but I feel we would do so by
 cutting a corner.

>>>
>>> I don't feel strongly either way, copyright updates can be automated
>>> (see Kevin's GeoServer script), but yeah, it's really annoying to require
>>> every single time a pull request comes in to update the copyright
>>> headers...
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/it488V for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via di Montramito 3/A
>>> 55054  Massarosa (LU)
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39  339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility  for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>> ---
>>>
>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

If you would like to make that proposal we can update the developers guide
and get it done ...

--
Jody Garnett

On 22 April 2016 at 11:38, Justin Deoliveira  wrote:

> Thanks Jody. That helps me understand.
>
> My thought is that the day to day overhead is not worth being able to rest
> assured that in 75 years GeoTools will still be in good standing with
> regard to copyright ;)
>
> My vote would be to change to a process where the copyright is set to the
> current year that the file is created or undergoes a major
> overhaul/rewrite. I
>
> $0.02
>
> On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime 
> wrote:
>
>> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
>> wrote:
>>
>>> If the PMC wants to make this decision I would be -0, I understand that
>>> it would assist with github pull requests, but I feel we would do so by
>>> cutting a corner.
>>>
>>
>> I don't feel strongly either way, copyright updates can be automated (see
>> Kevin's GeoServer script), but yeah, it's really annoying to require
>> every single time a pull request comes in to update the copyright
>> headers...
>>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> GeoServer Professional Services from the experts! Visit
>> http://goo.gl/it488V for more information.
>> ==
>>
>> Ing. Andrea Aime
>> @geowolf
>> Technical Lead
>>
>> GeoSolutions S.A.S.
>> Via di Montramito 3/A
>> 55054  Massarosa (LU)
>> phone: +39 0584 962313
>> fax: +39 0584 1660272
>> mob: +39  339 8844549
>>
>> http://www.geo-solutions.it
>> http://twitter.com/geosolutions_it
>>
>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>
>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>> principi dettati dal D.Lgs. 196/2003.
>>
>>
>>
>> The information in this message and/or attachments, is intended solely
>> for the attention and use of the named addressee(s) and may be confidential
>> or proprietary in nature or covered by the provisions of privacy act
>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>> copying, distribution, or either dissemination, either whole or partial, is
>> strictly forbidden except previous formal approval of the named
>> addressee(s). If you are not the intended recipient, please contact
>> immediately the sender by telephone, fax or e-mail and delete the
>> information in this message that has been received in error. The sender
>> does not give any warranty or accept liability as the content, accuracy or
>> completeness of sent messages and accepts no responsibility  for changes
>> made after they were sent or for other risks which arise as a result of
>> e-mail transmission, viruses, etc.
>>
>> ---
>>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Justin Deoliveira]

Thanks Jody. That helps me understand.

My thought is that the day to day overhead is not worth being able to rest
assured that in 75 years GeoTools will still be in good standing with
regard to copyright ;)

My vote would be to change to a process where the copyright is set to the
current year that the file is created or undergoes a major
overhaul/rewrite. I

$0.02

On Fri, Apr 22, 2016 at 12:18 PM Andrea Aime 
wrote:

> On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
> wrote:
>
>> If the PMC wants to make this decision I would be -0, I understand that
>> it would assist with github pull requests, but I feel we would do so by
>> cutting a corner.
>>
>
> I don't feel strongly either way, copyright updates can be automated (see
> Kevin's GeoServer script), but yeah, it's really annoying to require
> every single time a pull request comes in to update the copyright
> headers...
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via di Montramito 3/A
> 55054  Massarosa (LU)
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Andrea Aime]

On Fri, Apr 22, 2016 at 8:06 PM, Jody Garnett 
wrote:

> If the PMC wants to make this decision I would be -0, I understand that it
> would assist with github pull requests, but I feel we would do so by
> cutting a corner.
>

I don't feel strongly either way, copyright updates can be automated (see
Kevin's GeoServer script), but yeah, it's really annoying to require
every single time a pull request comes in to update the copyright headers...

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Copyright header policy

[Jody Garnett]

There are two schools of thought Justin. I had this discussion in detail on
the geowebache-devel
 with Arne
Kepp (and did some research at that time which was unsatisfying to both of
us - and probably scared away a contributor). See #355
 for epic heated
discussion - during which I learned two things:
- there is a difference of between publication vs the contents of the file
changing
- when transferring ownership from OpenPlans --> OSGeo we could of done a
search and replace (removing reference to OpenPlans)

As you say some projects write down the (c) of the initial file
contribution and call it a day ... reasoning being that the length of a
copyright is now 75+ years and by that time we will have diamond lattice
grid chips running a combination of javascript wrappers around q-bit
cores

The headers are supposed to be maintained each year the content changes in
a substantial way (the actual code stuff, not javadocs and comments).
Because we change our files often we usually get away with a range - "(C)
2003-2016". For files that change less often we could have gaps "(C) 2003,
2005, 2006-2009, 2016"

I understand that we could, as a PMC, decide to just go with initial file
creation date (which is admittedly often forms the bulk of the work).
However subsequent contributions can be very important, as someone who's
work has been rewritten on occasion can attest. We can make the argument
that we should be able to recover this information from github if needed,
and I guess we would need to if it ever comes up.

If the PMC wants to make this decision I would be -0, I understand that it
would assist with github pull requests, but I feel we would do so by
cutting a corner.



--
Jody Garnett

On 22 April 2016 at 06:01, Justin Deoliveira  wrote:

> Hi folks,
>
> Something I’ve been meaning to ask about is a clarification of why we have
> to update copyright header dates to the current year for every file change.
> As opposed to just having a static copyright header that signifies a
> “copyright event” (like the change over to osgeo) and then stands for that
> time forward.
>
> The reason I ask is because I think this policy has some negative things
> in my opinion. For one it’s a pain for both contributors and reviewers to
> enforce. I myself never remember as you probably well know and I would say
> I am a pretty regular contributor. It also adds noise to patches and pull
> requests, which also makes things harder to review than necessary.
>
>
> Anyways, just curious as to the rationale behind this decision. My
> apologies if this has been covered in previous email.
>
> -Justin
>
>
>
>
>
>
> --
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> ___
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Geotools-devel] Copyright header policy

[Justin Deoliveira]

Hi folks,

Something I’ve been meaning to ask about is a clarification of why we have
to update copyright header dates to the current year for every file change.
As opposed to just having a static copyright header that signifies a
“copyright event” (like the change over to osgeo) and then stands for that
time forward.

The reason I ask is because I think this policy has some negative things in
my opinion. For one it’s a pain for both contributors and reviewers to
enforce. I myself never remember as you probably well know and I would say
I am a pretty regular contributor. It also adds noise to patches and pull
requests, which also makes things harder to review than necessary.


Anyways, just curious as to the rationale behind this decision. My
apologies if this has been covered in previous email.

-Justin
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel