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.

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.

-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.rushfo...@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.co...@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.bur...@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

Reply via email to