perl5
perl5 copied to clipboard
Perl
Simplize copyright claim
I agree, it's better to specify the years as range since all are being consecutive
On 10/2/21 2:26 PM, Elvin Aslanov wrote:
I agree, it's better to specify the years as range since all are being consecutive
This pull request should be rejected. Since a copyright statement stakes a legal claim, we should not change ours unless it can be vetted by our attorney.
I strongly oppose attempts to mess around with our README.
Thank you very much. James E Keenan
When I read the first line of README. how old copyright claim style it's and waste my eye to read a lot of meaningless number. Hmm, Perl is too old.
It seem that I did trying to mess around some guys in this PR. let me talk a long story for why this PR is real a shotgun to break the old Perl to these messed around guys.
It's a fifth of a century ago, i met with Perl, which claim born with elegant semantics and clear context. yes it did! I like it and had played with it for a long time until...sorry it 's too long for me to remember when i said good by to Perl. and I finally came back again the other day to see how are Perl now. I feel a little annoyed When read the first line of README. why Perl keep some old and bad style in its face to tell people Perl keep alive 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, even 2022...
Mom always tell me that you should throw old shit out from time to time to keep your house clean and continue to be pampered by new coming friend. that's the great meaning of this PR!
When I read the first line of README. how old copyright claim style it's and wait my eye to read a lot of meaningless number.
I can see it contradicting the Easy things should be easy motto of Perl.
I can see it contradicting the
Easy things should be easymotto of Perl.
Unfortunately, lawyers tend not to subscribe to that motto.
I've made similar requests for $work code a couple of times in the past; on those occasions some lawyers have suggested the entire boilerplate is meaningless - that all qualifying original works get copyright protection automatically, and a copyright notice does nothing to strengthen that - while others have been convinced that a full copyright notice with an explicit list of years is mandatory. (None has ever supported the idea of an abbreviated list of years.) In every case, in the end, nothing changed, ensuring future work for future lawyers.
I think TPF would have to make a call on any change here, since they "carry the legal responsibility for Perl 5".
I think TPF would have to make a call on any change here, since they "carry the legal responsibility for Perl 5".
I've contacted them requesting their input. They've acknowledged the request, and will get back to me in due course.
On Sat, 5 Mar 2022 at 23:27, Hugo van der Sanden @.***> wrote:
I think TPF https://www.perlfoundation.org/about.html would have to make a call on any change here, since they "carry the legal responsibility for Perl 5".
I've contacted them requesting their input.
Thanks Hugo, this is the right way to resolve this.
Yves
perl -Mre=debug -e "/just|another|perl|hacker/"
I think TPF would have to make a call on any change here, since they "carry the legal responsibility for Perl 5".
I've contacted them requesting their input. They've acknowledged the request, and will get back to me in due course.
This is an extract from TPF conversation on this subject:
Here's the relevant quote from the GNU source:
For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage.
read as saying that it'd be fine for Perl to switch to a range but that we need to split out sub-ranges if Perl ever has a year without a release (e.g., Perl is Copyright (C) 1993 – 2025, 2027 – 2031 by Larry Wall and others if Perl didn't have a release in 2026).
In conclusion, a range is appropriate.
This is an extract from TPF conversation on this subject:
Thanks @StuartJMackintosh, that all seems very clear.
[...] and you make an explicit statement in your documentation about this usage.
This part was missing in the original proposed change, is there boilerplate handy for how to write that "explicit statement"? Not sure quite where the best place would be for it, but perhaps a paragraph under 'LICENSING' in the README file.
[...] and you make an explicit statement in your documentation about this usage.
This part was missing in the original proposed change, is there boilerplate handy for how to write that "explicit statement"? Not sure quite where the best place would be for it, but perhaps a paragraph under 'LICENSING' in the README file.
The key question is - are there any gaps in the range. Therefore this is an instruction to the management of the statement of copyright, rather than the licensee. Such an instruction is appropriate for the README therefore I propose:
Given that the GNU source guides as follows: "For software with several releases over multiple years, it's okay to use a range (“2008-2010”) instead of listing individual years (“2008, 2009, 2010”) if and only if every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and you make an explicit statement in your documentation about this usage."
then use of Copyright dates can be specified through a range (e.g., Perl is Copyright (C) 1993 – 2022 by Larry Wall and others) on the condition that there is a release in each year contained within the range.
Should there be no release within a given year, that year must be excluded from the range, for example: (e.g., Perl is Copyright (C) 1993 – 2022, 2024 – 2031 by Larry Wall and others)
(I was the person @StuartJMackintosh quoted above)
That change to the README looks good to me.
On Fri, 11 Mar 2022 at 13:11, Daniel Sockwell @.***> wrote:
(I was the person @StuartJMackintosh quoted above)
That change to the README looks good to me.
FWIW, this seems to show that we did a release every year from 1996-2022:
git for-each-ref --format="%(refname) %(taggerdate)" refs/tags | perl -lne'(/perl/ || /v5./) and /(19\d\d|20\d\d)/ and $date{$1}++; END{print join ",", sort keys %date}' 1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011,2012,2013,2014,2015,2016,2017,2018,2019,2020,2021,2022
We dont have tag data to back up the release date prior to 1996.
And perlhist says we did a release every year from 1987-2022.
perldoc perlhist | perl -lne'/(19\d\d|20\d\d)-/ and $date{$1}++; END{print join ",", sort keys %date}' 1987,1988,1989,1990,1991,1992,1993,1994,1995,1996,1997,1998,1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011,2012,2013,2014,2015,2016,2017,2018,2019,2020,2021,2022
Yves
-- perl -Mre=debug -e "/just|another|perl|hacker/"
Given that a 'copyrightable year' is considered here one where a release is made, and perlhist provides (I assume uncontested) evidence of at least one release every year since 1987, the range 1987-2022 is appropriate.
On Sat, 12 Mar 2022 at 09:20, Stuart J Mackintosh @.***> wrote:
Given that a 'copyrightable year' is considered here one where a release is made, and perlhist provides (I assume uncontested) evidence of at least one release every year since 1987, the range 1987-2022 is appropriate.
Agreed, I just wanted to post the data we had that confirmed that. I was a bit worried we might have had a gap.
Yves
@Yahasana That's usually an indication of an error: one usually wants to rebase one's branch over blead rather than merging blead into the branch.
@codesections @StuartJMackintosh - i think there is a related question that should be resolved before we change this. We have year based boiler plate in many of our files. Does that boiler plate have to reflect the history of the file itself? Can it be omitted and referenced back to the README? I don't think we should change one of our files without having a clear and common policy across all our files.
This was merged as #20771 - thank you @Yahasana for the original patch, and for prompting us to do this. Thank you @rwp0 for the updated patch. Closing as applied.