Skip to content

Conversation

petk
Copy link
Member

@petk petk commented Feb 3, 2019

Hello, this patch follows previous license year ranges updates (#3730). With the new approach source code files now have simplified headers with license information without year ranges.

Things to clear out:

  • What to do with license year range for the output of php -v (Zend Technologies line already has the year range removed for PHP-7.4+)
  • What to do with man pages that need to have the last change written in bottom header (TH command)? (out of the scope for this part for now, only bumped to "2019" for now)
  • What should man php include under the COPYRIGHT section regarding the year ranges?
  • Do we update the LICENSE and ext/oci8/LICENSE year ranges also?

TODO:

  • sapi/phpdbg/phpdbg.c
  • sapi/litespeed/lsapi_main.c
  • sapi/fpm/fpm/fpm_main.c
  • sapi/cli/php_cli.c
  • sapi/cgi/cgi_main.c
  • ext/opcache/ZendAccelerator.c (L 4060)
  • sapi/cgi/tests/001.phpt
  • sapi/cli/tests/001.phpt
  • sapi/fpm/tests/main-version.phpt
  • ext/reflection/tests/ReflectionZendExtension.phpt
  • win32/php7dllts.rc2
  • win32/php7ts_cli.rc2
  • win32/php7ts.rc2

@KalleZ
Copy link
Member

KalleZ commented Feb 3, 2019

I can't speak for Oracle, but I would keep it as the policy for that is a little different from that ours, ... for corporate reasons I guess. Tagging @cjbj for confirmation on that matter.

Would a simple "Copyright (C) The PHP Group" be enough on the CLI output?

Also (I'm not certain if included), I believe somewhere in the win32/ folder we got maybe a build resource file or similar that sets a copyright year. I didn't look over the commit in its entirety so apologies if its missed as I believe we write the copyright years when compiling the binaries.

@cjbj
Copy link
Contributor

cjbj commented Feb 3, 2019

@KalleZ

  • IANAL !
  • I don't recall ext/oci8/LICENSE needing to be different. The file was added because it became a pre-requirement for PECL Windows builds
  • FWIW, I have been taught (no prizes for guessing by who's lawyers) that files need the year of file creation and the year the file was last updated. I.e. one or two years should be listed in each file.

@petk petk added the Quickfix label Feb 4, 2019
@petk
Copy link
Member Author

petk commented Feb 5, 2019

Alright, thank you for the feedback. It helps to understand this issue. Then year range removed for the php -v and man php also... I didn't get any other answers to these questions and it doesn't look problematic to remove these from these places also. Plus major thing is that it makes managing the source code files simpler. Last change is also very forgetful thing to do and bump years properly, nevertheless when changes does happen.

About the template.rc file, the year was always bumped manually (via separate commit). If it will, cause issues with some setting somewhere that might generate this file (which I don't think its the case), we'll change it to a format of a year range.

So, now the only place to bump the year are the two LICENSE files (one in php-src root and other in ext/oci8 extension) which both include the year range of 1999-2019 together with the license text file in the web-php repository.

@KalleZ
Copy link
Member

KalleZ commented Feb 5, 2019

Thank you @petk, this is a very welcoming thing from my side. If there is no direct objections from any others, then go ahead with merging this sometime this week.

@petk
Copy link
Member Author

petk commented Feb 5, 2019

I'll merge this one to PHP-7.4 and master this weekend then... I'll also bump notification on the internals mailing list in appropriate topic, so it doesn't cause the end of the world maybe if something terrible has been missed here. Thank you all.

This patch follows previous license year ranges updates. With new
approach source code files now have simplified headers with license
information without year ranges.
@petk
Copy link
Member Author

petk commented Feb 8, 2019

Applied via c245898

@petk petk closed this Feb 8, 2019
@petk petk deleted the patch-years branch February 8, 2019 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants