Re: [Geotools-devel] Copyright header policy

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 obtainin

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 as

Re: [Geotools-devel] Copyright header policy

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 i

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 ("presen

Re: [Geotools-devel] Copyright header policy

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: > >

Re: [Geotools-devel] Copyright header policy

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 m

Re: [Geotools-devel] Copyright header policy

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 (o

Re: [Geotools-devel] Copyright header policy

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) 2

Re: [Geotools-devel] Copyright header policy

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, 2

Re: [Geotools-devel] Copyright header policy

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 t

Re: [Geotools-devel] Copyright header policy

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 w

Re: [Geotools-devel] Copyright header policy

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 som

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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.

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 P

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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/lega

Re: [Geotools-devel] Copyright header policy

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 o

Re: [Geotools-devel] Copyright header policy

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 fro

Re: [Geotools-devel] Copyright header policy

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 t

Re: [Geotools-devel] Copyright header policy

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 a

Re: [Geotools-devel] Copyright header policy

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 sour

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 hear

Re: [Geotools-devel] Copyright header policy

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 b

Re: [Geotools-devel] Copyright header policy

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 Garn

Re: [Geotools-devel] Copyright header policy

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 t

Re: [Geotools-devel] Copyright header policy

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 i

Re: [Geotools-devel] Copyright header policy

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 Gar

Re: [Geotools-devel] Copyright header policy

+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 sm

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 b

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 un

Re: [Geotools-devel] Copyright header policy

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 th

Re: [Geotools-devel] Copyright header policy

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 tha

Re: [Geotools-devel] Copyright header policy

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

Re: [Geotools-devel] Copyright header policy

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 #

[Geotools-devel] Copyright header policy

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 fo