Meme transcription [Kid drowning in pool]

In the background a person plays with a kid in the pool. The person is labeled “Companies updating their website”. The kid is labeled “The company logo”.

In the foreground a kid seems to be drowning. It is labeled “Useful information”.

In a second panel a skeleton sits at the bottom of the pool. It is labeled “The copyright year”

  • konalt@lemmy.world
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    4 months ago

    document.querySelector('span#copyright_year').innerText = new Date().getFullYear()

    • bleistift2@sopuli.xyzOP
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      4 months ago

      No need to specify the tag name in the selector if you’re going to use an ID anyway.

      • FooBarrington@lemmy.world
        link
        fedilink
        arrow-up
        3
        arrow-down
        1
        ·
        4 months ago

        Right - it should have been:

        document.querySelectorAll('span#copyright_year').forEach((el) => { el.innerText = new Date().getFullYear() })

        so that we update all spans with that ID!

  • ramirezmike@programming.dev
    link
    fedilink
    arrow-up
    15
    ·
    4 months ago

    My understanding is you don’t actually need to update the copyright year… if anything it’s kinda misleading if you only have the current year

    • jecxjo@midwest.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      Not that a date in a file really is valid evidence, but the point is to define when the copyright occurs. If i come back and say “well i did that same thing before you did” them it would make your copyright invalid.

      If you update then you add an additional date.

  • litchralee@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    8
    ·
    edit-2
    4 months ago

    I’m not any type of lawyer, especially not a copyright lawyer, though I’ve been informed that the point of having the copyright date is to mark when the work (book, website, photo, etc) was produced and when last edited. Both aspects are important, since the original date is when the copyright clock starts counting, and having it further in the past is useful to prove infringement that occurs later.

    Likewise, each update to the work imbues a new copyright on just the updated parts, which starts its own clock, and is again useful to prosecute infringement.

    As a result, updating the copyright date is not an exercise of writing today’s year. But rather, it’s adding years to a list, compressing as needed, but never removing any years. For example, if a work was created in 2012 and updated in 2013, 2015, 2016, 2017, and 2022, the copyright date could look like:

    © 2012, 2013, 2015-2017, 2022

    To be clear, I’m not terribly concerned with whether large, institutional copyright holders are able to effectively litigate their IP holdings. Rather, this is advice for small producers of works, like freelancers or folks hosting their own blog. In the age of AI, copyright abuse against small players is now rampant, and a copyright date that is always the current year is ammunition for an AI company’s lawyer to argue that they didn’t plagiarize your work, because your work has a date that came after when they trained their models.

    Not that the copyright date is wholly dispositive, but it makes clear from the get-go when a work came unto copyright protection.

    • DeaDvey@lemmy.ml
      link
      fedilink
      arrow-up
      3
      ·
      4 months ago

      If a work is updated every year between 2020 and 2024 (2020,2021,2022,2023,2024) would it be valid to write 2020-2024?

  • devfuuu@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    edit-2
    4 months ago

    There’s some good info out there from the good people that know how things should work that created the reuse tool - https://reuse.software/ - and basically the conclusion is that nobody should be updating the years on the copyright line just because it’s a new year. The only useful info and what should be done is put the year when the file is created and that’s it.

    Edit: took me a while to find the proper thing I wanted to link - https://matija.suklje.name/how-and-why-to-properly-write-copyright-statements-in-your-code

    Had to go first to the recent curl blog where the author wants to go the weird way of not having useful info at all on the files.

    • stetech@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      Thank you for those two links!! I don’t necessarily have the time right now, but from first glance, those seem super interesting!

  • collapse_already@lemmy.ml
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    4 months ago

    The one thing that consistently gets caught in code reviews in my shop is a failure to update a copyright date. I have been tempted to submit clearly crap code just to see if anyone actually is paying attention.

    • zebbedi@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      4 months ago

      Unless you’re renewing your copywrite every year, changing the date every year is wrong. You list the date it was copywrited, not the current year.

      • collapse_already@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        4 months ago

        We add the current year to the copyright dates, the current updates are protected from the time of authorship. So if the copyright says, 2012, 2014, 2022; I would add a 2024. The commit records can be used to determine what was changed each instance, but the update provides notice of when changes were made.

        Discerning what is protectable creative expression versus functional and therfore unprotected is an issue for the courts.