Copyright update tedium
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Tue Dec 10 08:59:17 UTC 2024
On 2024-12-09 21:39, Joseph D. Darcy wrote:
> FWIW, when I've thought about the topic of copyright and licenses
> before, I think there are several aspects that can be separated.
>
> One is a syntactic-only check, as the in-flight Skara PR may provide.
> I think having a syntactic-only check is Skara is reasonable.
>
Agreed.
>
>
> A semantic check is "does file F have the proper license for its role
> in the project?" For example, GPL vs GPL w the classpath exception or
> "@test /nodynamiccopyright/" for certain langtools tests, etc.
>
> These checks are complicated enough and have enough change over time
> that I don't think they are appropriate for Skara. However, they could
> be accommodated by check/test that lived in the repository and was
> evolved with the repository.
>
Agreed. Note that this check can be done by only having access to the
source code; no git metadata is required.
But there is a third kind of check, and that is if the year should be
updated. This check can only be done with some additional metadata
present. Skara is in a unique position to enforce this, since it knows
when a commit is being added and the current year at that time. This
cannot be checked by a test that has only access to the source code. It
*can* be done locally if you have the git repo available, but that is
not the case for e.g. how we run tests in the Oracle CI.
So I believe that, if we can -- as Archie described it -- find a
"well-defined and algorithmically decidable" rule for copyright year
updates, that it should be enforced by Skara.
/Magnus
> -Joe
>
> On 12/9/2024 11:32 AM, Archie Cobbs wrote:
>> OK thanks. Apologies for getting confused, I'm not familiar with the
>> skara code so I'm not always sure what I'm looking at.
>>
>> I personally think Skara shouldn't do that, but it is a topic
>> that might be worth discussing for a future Enhancement.
>>
>>
>> I think it's a good idea, but only to the extent that "the right
>> thing to do" is well-defined and algorithmically decidable (so the
>> likelihood of false positives is virtually zero).
>>
>> There seems to be some debate about whether copyright updates are
>> required for "significant" changes or all changes; only the latter
>> case is "well-defined" so this idea would depend on confirmation of
>> an "all changes" policy - that is, unless someone can encode
>> "significant" into an algorithm.
>>
>> In other words, it seems like a sufficiently conservative
>> implementation (zero false positives) would be a net win.
>>
>> -Archie
>>
>>
>> On Mon, Dec 9, 2024 at 1:16 PM Kevin Rushforth
>> <kevin.rushforth at oracle.com> wrote:
>>
>> No, The Skara PR in question isn't proposing to do this. Rather
>> it is checking that _if_ the Copyright header is updated, it is
>> syntactically correct.
>>
>> It would be an item for further discussion to have Skara actually
>> get into the business of whether the copyright header should be
>> updated and what the copyright year(s) should be. I personally
>> think Skara shouldn't do that, but it is a topic that might be
>> worth discussing for a future Enhancement.
>>
>> -- Kevin
>>
>>
>> On 12/9/2024 10:37 AM, Archie Cobbs wrote:
>>> Bleh, ignore my comment. I didn't realize the PR#1702 you
>>> referenced is already proposing doing this!
>>>
>>> -Archie
>>>
>>> On Mon, Dec 9, 2024 at 10:45 AM Archie Cobbs
>>> <archie.cobbs at gmail.com> wrote:
>>>
>>> Thanks for working on this... something of a thankless task :)
>>>
>>> I'm sure you've considered this but I'll ask anyway. Would
>>> it make (more or less) sense to try and enforce the policy
>>> on the front-end?
>>>
>>> By that I mean adding another checkbox requirement to
>>> skara's handling of PR's: "🔲 Change must update copyright
>>> dates where applicable"
>>>
>>> The check could start out being conservative:
>>>
>>> * Only applies to files with certain extensions and/or
>>> matching some filter list
>>> * Only applies to files containing a recognizable
>>> copyright text line
>>>
>>> -Archie
>>>
>>> On Mon, Dec 9, 2024 at 7:06 AM Magnus Ihse Bursie
>>> <magnus.ihse.bursie at oracle.com> wrote:
>>>
>>> I felt responsibility for the .github files, and wanted
>>> to check if there were more build system files needed
>>> updating. So I ran a more comprehensive script, and
>>> discovered a *lot* more files that needed updating. Like
>>> a thousand or so...
>>>
>>> I have opened a series of issues starting at
>>> https://bugs.openjdk.org/browse/JDK-8345793 and going up
>>> to https://bugs.openjdk.org/browse/JDK-8345805 to update
>>> these headers.
>>>
>>> I agree, this should be automated. We're starting to
>>> slowly get there, see
>>> https://github.com/openjdk/skara/pull/1702 for a first step.
>>>
>>> /Magnus
>>>
>>> On 2024-12-03 16:45, Archie Cobbs wrote:
>>>> Dumb question...
>>>>
>>>> It seems like the thing with updating copyright years
>>>> in source files could be better automated. At least,
>>>> couldn't there be a test that fails if you forget?
>>>>
>>>> FWIW my little updater script says that these files
>>>> still need to be updated to 2024:
>>>>
>>>> .github/actions/config/action.yml
>>>> .github/actions/do-build/action.yml
>>>> .github/actions/get-bootjdk/action.yml
>>>> .github/actions/get-bundles/action.yml
>>>> .github/actions/get-msys2/action.yml
>>>> .github/scripts/gen-build-failure-report.sh
>>>> .github/scripts/gen-test-summary.sh
>>>> .github/workflows/build-cross-compile.yml
>>>> .github/workflows/test.yml
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/Attributes.java
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/InputSource.java
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/XMLReader.java
>>>> src/java.base/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java
>>>> src/java.base/share/classes/jdk/internal/platform/Metrics.java
>>>> test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java
>>>> test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java
>>>> test/hotspot/jtreg/compiler/whitebox/DeoptimizeFramesTest.java
>>>>
>>>> -Archie
>>>>
>>>> --
>>>> Archie L. Cobbs
>>>
>>>
>>>
>>> --
>>> Archie L. Cobbs
>>>
>>>
>>>
>>> --
>>> Archie L. Cobbs
>>
>>
>>
>> --
>> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241210/11ff17dd/attachment-0001.htm>
More information about the core-libs-dev
mailing list