Re: [HACKERS] Copyright in partition.h and partition.c

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Copyright in partition.h and partition.c
Дата
Msg-id 19831.1504613649@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Copyright in partition.h and partition.c  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] Copyright in partition.h and partition.c  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2017/09/05 15:48, Etsuro Fujita wrote:
>> Here is the copyright in partition.h:
>> 
>>  * Copyright (c) 2007-2017, PostgreSQL Global Development Group
>> 
>> I think it's reasonable that that matches the copyright in partition.c,
>> but partition.c has:
>> 
>>  * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
>>  * Portions Copyright (c) 1994, Regents of the University of California
>> 
>> Is that intentional?

> No, it's unintentional.  The difference may have resulted from copying
> different files to become partition.h and partition.c, respectively.

> Maybe, we should change both to say 2016-2017?

> I don't know the exact rule for how we determine those years.  Is there
> some rule in place about that?  When I look at execParallel.c, which
> supposedly got introduced into the tree recently, I see 1996-2017.  OTOH,
> the files in contrib/bloom all have 2016-2017.

Our usual practice is to write the copyright like it is in partition.c
even in new files.  This avoids any question about whether any of the
code was copied-and-pasted from somewhere else in PG.  Even if not one
word in the file can be traced to code that was somewhere else before,
it seems to me that this is an appropriate thing to do, to give due
credit to those who came before us.

In short: we should make partition.h's copyright look like partition.c's
not vice versa.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER nameHANDLER ...