TIL: You Can Stop Updating Copyright Attribution Years (2021)
hynek.me
hynek.me
Just did that on my projects with a simple call to:
find ./ -iname "*.py" -exec perl -p -i -e 's/# All Rights Reserved.*\n//sg' "{}" \;
That also has no legal effect, but it's fun. Hail Eris!
This is true for a work that is published (or just created) and then doesn’t change after that, but there are multiple reasons why one might update the year on code:
If the code changes, it’s a new work and the new version’s term of copyright starts in the current year, not the year the file was created.
Even if the code doesn’t change, companies may still wish to try to extend their copyrights, claiming a new term every year, which pushes the expiration date out one more year every year. For code that doesn’t change, updating the year obviously might have no basis in law, but companies are free to interpret their copyright as applying to the entire repo rather than a single file, and companies aren’t necessarily being malicious with copyright terms, many clearly believe updating the year is a legal requirement, because it used to be.
Leaving the year out of the copyright notice might have the same effective goal, to make the term of copyright appear current at a glance, no matter when it is read.
Maybe this will all matter in the year 2173 when the first code copyrights start to expire. /s :P
Isn’t the expiration date counting from the death of the author rater than the time of creating?
I brought this up at a startup I worked at when the CTO insisted we change the year in every source file.
I gave multiple examples of other code bases at Microsoft and Google and other big companies that dont include the year at all in some cases and definitely dont update every year.
He said our lawyers said it had to be updated but I was always suspicious he didnt actually ask.
If something has no perceived cost, and has marginal utility, then you'll get asked to do it.
It's not a huge cost, but it's a cost nonetheless.
Also to the root's line here:
>I gave multiple examples of other code bases at Microsoft and Google and other big companies that dont include the year at all in some cases and definitely dont update every year.
This is one of those things where it seems reasonable at first blush but then completely not on second look. There are lots of cases in tech where "look these huge players do this" makes sense, but when it comes to either scaling or law things are different. Here I'd be looking for examples of small players doing that, because the big players have such powerful law teams and deep pockets that risks they'd dismiss as unimportant might be existence-threatening to a small company.
If not, then you don't need to do it.
In the US, copyright is a thing that applies the moment you have put a work into a fixed, tangible form. Actual publication is not required. If your work is copied, you can sue. But if you register it, you have some additional power and -- perhaps most importantly -- you don't have to worry about a court fight over when the copyright term began. A registered copyright began at the date in the copyright registration. There can be no argument about that.
Some of the other benefits... if you register your copyright, you can sue for statutory damages rather than having to demonstrate actual damages and you gain the ability to recover legal expenses.
Post-1976, screwing up copyright formalities means relatively little in copyright (the biggest thing is you lose the ability to sue for statutory damages if you don't register copyright). Eventually, there's going to be legal confusion over what year protections run out, but that isn't going to be relevant for software until quite late this century thanks to the current 95-year copyright regimes.
But that is not the same thing as updating the copyright year on a copyright notice, and you know it.
A film like "It's a Wonderful Life" is a finished work that never changes, unlike software or web sites. In every film, the copyright notice in the credits will remain forever the same. It can't be changed without editing the film ex post facto a la Steven Spielberg or George Lucas. Even if the copyright of "It's a Wonderful Life" had been renewed, the copyright notice in the credits would not have changed.
Except it does. It requires an engineer to maintain the dates, and the company to audit that the dates are correct. It directly interferes with source control ("updated copyright" was the bane of my existence when trying to git-bisect a few years ago).
Edit: as the article mentions open source documentation it’s possible the repo itself is what needs the year, and there’s no way around hardcoding it in the included licence.
I'll probably continue to include copyright notices and years regardless of legal necessity, but I've never lost sleep over it or put a lot of effort into it. It just seems like a "does no harm, and may clarify things" sort of deal.
This is pretty much the advice of my attorney. "It's not legally required, but I can imagine situations where it could be useful anyway. If it doesn't cost you anything, why not include it?"
Apparently CYA stands for: "cover your ass".
They can suck the air out of actual understanding of the legal situation at hand and, in the worst case, lead to an warped understanding of copyright that interacts with the world with supposed magical incantations that are legally totally meaningless or even the opposite of the truth. (I’m thinking of those YouTube videos e.g. showing some snippet of a film uploaded by someone who doesn’t have the copyright with the totally bonkers “copyright Universal 2020, no infringement intended” note. I know, that‘s mostly about someone who is not a business and who usually doesn’t have anything to do with copyright being confused about the difference between attribution and copyright and thinking giving attribution gives you copyright – which is bonkers. Fair use does require attribution, but simply copying something verbatim is certainly not fair use.)
Especially when people talk about professions like lawyers, etc. it's almost as if they conceive of it as one unified workforce of hypercompetent experts who all know The Truth and can either tell you what it is or, failing that, then at least tell you what you should do in accordance with what The Truth is. But no industry works like that.
Think of how many programmers you know or know of and the range of competencies involved, including absurd practices and just outright weird opinions/positions held by a surprisingly large proportion of folks. Half these people are B- players at best and who are only there because they figured out how to make a living following rituals—which they may not necessarily understand (and some of which may actually be counterproductive but are inoffensive in the sense that they aren't so counterproductive that it will result in being let go).
Or forget that for a moment and just think of how many cases have been tried in court with lawyers on both sides. Do the courts regularly arrive at decisions that recognize counsel for both sides as being right (and it's just, say, the facts that are responsible for their clients losing the cases)? Or can you regularly find lawyers putting forth legal theories that simply don't hold up under scrutiny?
I’m not entirely convinced about this. It constitutes a false statement about the copyright status of the work, which may be illegal in some jurisdictions. There are a few unlikely scenarios in Australia where it might technically become a crime, though by and large Australia ignores anything but authorship in matters of such notices; but mostly it would require that you try to threaten someone unjustly before it would become a crime. In the United States of America, I think it becomes a crime to even claim copyright incorrectly (meaning “this is mine and is in copyright” when it’s public domain, nothing to do with year numbers), without even needing to threaten someone. Mitigating this, both require some degree of knowledge or reasonable expectation thereof.
So, supposing a work-for-hire copyright term of fifty years (yeah, AU and US are both more than that, but I’m simplifying), if a work was actually produced and published in 2000 and you write “copyright 2010–2020” on it, this could actually be technically criminal between 2050 and 2070 in some situations, during which period the work is actually in the public domain but the claim implies it’s not, constituting copyfraud <https://en.wikipedia.org/wiki/Copyfraud>.
(Fun fact, while thinking of this stuff: Australia has mandatory legal deposit of all publications, since 2016 explicitly including things like websites. I don’t do this for my website, and I’ve never heard of anyone else doing it—in fact it was only a few years ago that I heard about this law at all, when my dad started publishing books; it’d be frightfully inconvenient to do for a website, and it’s all rather ill-specified.)
So, it might theoretically be illegal in some areas in some situations. And I think it should be illegal; it should hurt to go bumping copyright years meaninglessly.
I also just find it funny to think about this practice of bumping copyright years coming back to bite your successors 70 or 95 years down the track, when what seemed harmless silliness at the time suddenly becomes a criminal misrepresentation. ’Course, I don’t think there’s actually much value speculating about specifics of copyright law that far in advance. The last century has shown progress in some areas of copyright (doing it automatically) and massive folly in other areas (obscene and ever-growing durations).
That will generally tickle their aversion to putting data that could fail under cross examination in front of a court and they'll be more likely to let you delete all the dates entirely.
There's literally no reason for them anyway. You don't even need a copyright statement, but you probably do have a copyright file with years in it, and you've got git for supplimentary info on exactly when any given line of code went into the codebase.
Also if you're updating every file every year you're losing the information on when a piece of code when into the codebase, which is the only important thing anyway in the case of patent lawsuits, expiration of copyright really isn't an issue worth worrying about (and I think bumping the copyrights every year is wrong policy there as well).
While you're at it, remove all the Author lines as well with the people who no longer have anything to do with the project and their old e-mails which don't work.
I always thought those header comments were annoying. Do they really provide some kind of additional legal protection?
Faced with the certainty that a bunch of developers have to do something with zero perceived risk to counsel, or that there is a 0.01% chance that some negative thing would impact them someday maybe, their choice will be to avoid answering the question or status quo.
In the tech world, it's hard to imagine that software or content published today will be relevant in a century, but by not updating the year, you are risking the possibility that copyright protection will be cut off sooner (or more likely and more subtly, future infringers will have an innocent infringement defense).
Though I'm not sure if either my backups or github will survive for the next 120 years.
Small portions of FreeBSD have been untouched since the AT&T sources. That's halfway through. I don't expect anything I write to live that long, though. But I imagine there's some tidbits here and there at Microsoft.
It's not that hard to imagine it, really. There is 60 year old software right now that's still relevant and in use, and there is relevant content that is even older.
AFAIK the file itself is covered under the copyright of the whole work anyway and doesn't even need a copyright notice.
If the file itself does need a copyright notice, then how does updating the date continue to perpetuate the copyright an additional year into the future with no further updates to the text? AFAIK republication of a book with a new copyright date does not push copyright dates into the future.
Even if you update a few lines in the file, again AFAIK that doesn't update the expiration timer for all the rest of the code.
My understanding is that incrementing the data does nothing for the copyright expiration of the file, and that the act of updating the file with new lines of code is what protects those lines of code into the future, and that no copyright notice is even required.
It isn't like trademark where failure to notify and defend your trademark can eventually lead to your losing your trademark. Since 1989 copyright notices have not been required under law, but the purpose of a copyright notice is simply to reduce the possibility of an "innocent infringement" defense.
I'm always in favor of removing lawyer boilerplate though.
Fun fact[1], © gives some additional protection worldwide, but in the US simply writing "Copyright 2021" gives you full protection. Meanwhile, "(c)" doesn't actually mean anything, doesn't gain you any worldwide protection like © does, and arguably invalidates the rest of "Copyright (c) 2021".
[1] that might not even be a fact anymore, as I learned it from an excellent book on copyright in the early 90s, when DOS made "(c)" ubiquitous.
Law does not work like a compiler. It doesn't just throw "syntax error" when you use an incorrect representation.
If you put gibberish in the middle of a copyright notice, what does that do? What does "Copyright ><(((('> 2021" mean, legally speaking?
Like how I could point a gun at you and say
>Hand over the money or I'll gloobensloobenKILLfleubenYOU
and they wouldn't go "oh no there's a syntax error release this man immediately, it clearly wasn't a robbery"
Here we have the idea that you can do the secret handshake incorrectly and thereby invalidate what most countries view as an automatic right (copyright usually doesn't even require any notice) and that adjudicating judges would shrug and say "Sorry, you used parentheses: my hands are tied. They're free to copy you", based on some random book from the 90s that was likely also full of bullshit. Does that sound right to you?
You might want to ask yourself that very question.
based on some random book from the 90s that was likely also full of bullshit
Nah, it was an excellent book that I pored over.
I don't understand why you guys are so confident with zero basis for your position other than "I'm so used to seeing it that I assume it's legally valid".
As I explained already, "(c)" is gibberish. Go ask a lawyer if you should put meaningless gibberish in the middle of legal disclaimers.
If your book was actually from the 90s, then it was out of date, as the US adopted the new copyright rules in 1989.
No court will ever be confused by it, your copyright will never be invalidated by it.
And, in addition to circle-c, any of these are valid substitutes in the US for the symbol, according to [2] 2204.4(A):
• The letter c with a parenthesis over the top.
• The letter c with a parenthesis under the bottom.
• (c
• c)
• (c)
• The letter c with an unenclosed circle around it.
[1] https://www.copyright.gov/help/faq/faq-general.html#mywork
including an opposing view which suggests to include the original year and keep that:
https://liferay.dev/blogs/-/blogs/how-and-why-to-properly-wr...
mainly for this reason:
having an easy way to find the earliest date of a piece of code, might prove useful also in figuring out when an invention was first expressed to the general public. Something that might become useful for patent defense
so while updating the year does not seem very useful, knowing when a file was created is much more useful.
So, sure, not required, but helpful to show someone either a) sweats the details or b) knows how to put the year in a generated text line... but at least they took the time to care, once.
(Edited to mention range. Seeing other folks mention hassles of code history just to change year will temper my use of this signal)
Sure, no one in the US __needs__ to do this, and there is a cost to it. But the benefit of the signal could outweigh.
Having no date or an old date may send the signal that "the dev team has good legal support", but I wonder how common that perception is. We see from the comments and the parent post that at least the HN crowd has a good chunk of folks who didn't know that date isn't needed.
It's an empirical question to test: does date presence affect evaluation of the object? It would be fun to see. (I would want to try "no date", "last year", "3 years ago", "current year" to see if user perception of the object changes based on presence and time passed).
It's probably reasonable to expect a current copyright date on the home page of an active site to indicate that it's current. It probably doesn't need to be everywhere unless it can happen automagically through a template.
The difference being the brown M&M's test is an excellent one whereas when it comes to "having an up to date year on a copyright line", it's not about someone "missing" these "details", since there are good (i.e. deliberate) reasons not to update the year (and only bad reasons to actually do it).
So something rather like the reverse of what you meant is actually true: if you notice people adhere to some bizarre and misguided practice like trying to make sure the copyright year is "up to date", then what other totally unnecessary (and maybe even potentially harmful) bullshit might they be cargo culting into their work practices—and should you worry about trusting their judgement in other areas that actually matter?
If that’s the sole purpose, a “last updated on” mention somewhere would be a perfect sign they both understand the copyright thing, while satisfying your desire to be reassured.
So I registered his <first name><last name>.org and put "<first name> <last name> is an idiot." in just a single <h1> and deployed it.
He ended up deleting all his comments and blocking me but holy shit was it glorious. Best $10 I ever wasted.
Lets say for most part all goes well because most of the time people want to do the right thing and are not assholes. Well might be that other people in general are not all assholes - just that quite a lot are but not most :)
For works made after 1978, copyright begins when the work was created. Updating the date on copyright notices doesn't actually change that, and there's no such thing as a "renewal".
For work made before 1978, copyrights can be renewed, but you can't just update a copyright notice and call it "renewed". You actually have to file something with the copyright office.
If you want to start the copyright clock over again, you have to change the work enough that it is considered a new copyrightable work. How much of a change that has to be is a bit of a gray area.
I asked why we didn’t just do “Copyright <?= date('Y') ?>” and I got a spiel from the owner about how only sites paying for ongoing maintenance get their date updated.
Seemed really silly to me, more than a few sites I built may have ended up with “automated ongoing footer maintenance” for free.
But from a legal perspective (IANAL) my understanding is that dynamically updating copyright dates in and of itself is probably never a legal problem, but the issue is dates in other legal boilerplate (random disclaimers under a financial services company or health disclaimers on a pharmaceuticals ad, for example).
I think the lawyers' thought process about never wanting dynamically updated dates anywhere is that if the web workers get in the habit of dynamically updating copyright dates, they're going to apply the same logic to any of the other legal disclaimers on a corporate site, which could turn out badly. There might be a financial regulation active in one year that's not required in the next. There might a change in FDA regulations and updating the year with the old regs still on the site might be seen as a false health claim, etc. A dynamically updated date in a legal disclaimer can be a major problem.
The safest thing to do to avoid a big screwup is to tell the developers "no dynamically updated dates" ever.
It seems to me that the copyright date should be updated whenever the actual content of the site is updated (and no earlier).
They were updated: the footer was changed.
If you want the notice to protect against infringing, surely you want to state the earliest year possible. But some read the notice as “page last updated” in which case you want it as recent as possible. But why not just write “last updated…” then?
If you just have "© 2023" you might run into this scenario. In 2018 I rip off your site and include that material in my site, which is © 2018. In 2023 you become aware of this and sue me for copyright infringement.
At trial my lawyers are going to find a way to get my © 2018 notice and your © 2023 notice in front of the jury in a way that suggests mine was first and you ripped me off.
Your lawyers should be able to easily deal with that, but they might have to do things like show both sites from archive.org or something like that, and take time to explain what archive.org is, how it works, and why the jury should believe that when archive.org says that a site contained certain content on a certain date it should be trusted.
This takes time. In a civil suit court time is limited. Each side has a total time budget for their opening statement, examining witnesses, cross-examining witnesses, and closing arguments. If my lawyers can make your lawyers have to go spend time explaining archive.org to the jury, that's good for us.
And yes, your lawyers will probably have to explain how archive.org works because during jury selection mine will have worked to exclude jury members who are already likely to know that. We should be able to get at least a few people on there who are going to need it explained.
Oh, and my lawyers will also probably be able to get in a suggestion that the fact that your site said © 2023 on it means you were trying to be deceptive about the copyright maybe to illegitimately squeeze some extra years out of copyright protection. That might prejudice the jury against you on anything that is close.
If you had said © 2010-2023 all those potential ways my lawyers can make yours waste time or make you look shady go away.
But couldn't someone copy my site and change the starting year to earlier, like © 1998-2023?
Then my lawyers would still need to explain archive.org to the jury. Even then, I have a feeling that archive.org is not evidence of anything. (Well, may be enough to convince a jury.)
For that matter, the content of any website - or even anything digital - seems like flimsy evidence to support historical fact, since it can be changed at any time. Perhaps this is where someone mentions the blockchain as "immutable proof".
Without a registered copyright you can still defend yourself from an infringement suit by showing your work predates theirs, but you can't really go on the offensive. You can send cease and desist letters but that's about it. You can't collect statutory damages or attorney's fees.
In most other countries a registration will at least create the presumption of authorship, meaning the other party is obligated to prove their work came first.
But yeah, putting the year on the copyright notice does nothing.
In the bit of Big Blue that I worked in this is what we did.
You only updated the later year if you made a non-insignificant change to a file. Fixing a simple typo in a comment wasn’t enough, nor was just reformatting/moving code. Fixing a bug, changing a user visible string, refactoring, adding a new feature, etc and you’d bump the “to” year.
I think there was also some kind of magic rule that you could put the next year (e.g. 2023) from some point late in the current year, something like you could add 2023 if it was November 2022 or later.
Don’t think I ever saw these “rules” formally written down so everything was just a kind of folklore passed on from one generation of devs to the next.
Copyright years in version/help output was definitely updated as part of the build/release process.
https://copyrightalliance.org/education/copyright-law-explai...
"A copyright notice does not need to be affixed to a copyrighted work for the work to be protected under the law.
Prior to 1989 including a copyright notice on a copyrighted work was required under U.S. law, but that is no longer the case. Although copyright notice is no longer required, a copyright owner would be wise to include a copyright notice because it prevents an infringer from raising a defense of innocent infringement."
Furthermore, a copyright year may not be needed if a copyright notice with (c) mark is included.
So the copyright notice is primarily useful as a notice to others with regards to your work, but has no real use as a legal construct to establish ownership.
I was curious so I looked up the list of countries that aren't signatories to the Berne Convention, and it does include some populous countries (Iran, Ethiopia), as well as Taiwan. (Not saying this is important--just seemed interesting.)
1. To sue someone for statutory damages and to have a good chance of automatically recovering attorneys' fees (which helps make the legal effort worthwhile rather than a Pyrrhic victory), when you don't have a clear argument for actual damages, you need to have registered copyright of the work, at least in the US and probably most other countries with statutory damages.
2. If you just want to be able to issue takedowns or sue to get someone to stop redistributing something you made, and maybe if you have a clear argument for actual damages and don't need to rely on statutory damages (which are usually absurd anyway), you don't necessarily need any copyright notice, much less copyright registration, since, due to the Berne convention, everything is assumed copyrighted.
However...
I think putting a copyright notice including a year in static documents is good practice, though, for a simple reason: Copyrights expire. In order to know when the copyright expires, someone who encounters your work needs to know when it was created, i.e. when the copyright period began.
To remove any indication of the initial year of creation is essentially to admit that it doesn't matter because copyright terms are so absurdly long that you don't anticipate anyone caring about your stuff by the time copyright expires.
As a corollary, don't update the copyright year unless you make non-trivial changes to the code, text, or design. Is it really worth it, in some hypothetical distant future where your work is still economically valuable, for you, your descendants, or estate, to go after someone using a slightly modified later version of the work that isn't technically out of copyright but the original version is?
I thought the attribution line was basically a public reminder or declaration that you own the copyright the thing it's written on, but not the source of the copyright itself.
Now it's basically just a textual version of Big Brother eyes warning you that someone cares about this thing and reminding you that copyright still exists before your Ctrl-C into your own website.
I suppose then, the presence of a copyright symbol on a work makes quick work of any argument the copying was done without knowing the copyright existed. Which, if the accused could successfully make an argument for, could result in reduced penalties.
It's not that there's an explicit piece of legislation that gives © power, but rather that it's presence makes for a stronger deterrent in practice.
And remember, it doesn't let you infringe freely if it's missing, just could make seeking the highest penalty from the infringer harder, weakening the deterrent power.
For something to actually be in the public domain, the copyright term must expire.
But in neither case is your liability zero.
The law basically says that, specifically for infringing a copyright, doing so out of ignorance is less punishable.
Ignorance isn't a general defense, but some laws do account for it on a case by case basis.
It does. At least in the US, if the work contains an explicit copyright announcement then an infringer loses the ability to defend via an "innocent infringement" defense. They become a "deliberate infringer" and this can ultimately change (increase) the size of any damage awards from a lawsuit against the infringer.
Copyright Red Hat
The way I would put it: copyright notices in open source projects are typically not intended to function as formally (under US law) correct copyright notices, which do require a year. Rather, they serve different purposes for which the year is not necessary. And if you do include a year, the notice is likely to become inaccurate over time, which will make it formally invalid (under US law). That is not likely to be significant, but it makes inclusion of the year relatively pointless, in relation to the labor that would be involved in attempting to keep the year accurate.
* This simply made sense for books, since you can't update a book that's already out there, just release a new version.
* Web pages were similar, mainly because people wouldn't update them rather than couldn't update them.
* But then came blogs and other dynamic content, which did get updated. So you'd want the copyright date to match the most recent post, not the creation of the blog/site. This means updating every year for any that are still active.
* Other sites that don't update as often then copied "make sure it's the current year" without really thinking about it.
...and that third point doesn't contradict this post. You want it to match "first publication" of the most recent post, right? (assuming you include year at all)
Again this never made sense to me as I would always wonder "don't you want to show you created the content BEFORE today?" Assuming they had past content of course.
Excuse me while I draft the email to my ex-employer and management team saying Hacker News told me I was right.
© <span id="js-copyright-year">2023</span> My Product
<script>document.getElementById('js-copyright-year').innerHTML = new Date().getFullYear();</script>
If using a templating engine or some SPA framework/library like React then just dynamically substitute there instead or similar in server-side rendered code.
If it did matter then you might as well just show the default date, cause any adversary could pick to be shown it, no?
> “Literary works” are works, other than audiovisual works, expressed in words, numbers, or other verbal or numerical symbols or indicia, regardless of the nature of the material objects, such as books, periodicals, manuscripts, phonorecords, film, tapes, disks, or cards, in which they are embodied.
The reason to have this category is mostly to distinguish it from audiovisual works where there's a developed system of compulsory licensing around stuff like paying royalties for playing music on the radio or in public venues.
This point has been litigated too, e.g. in Apple v. Franklin. https://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Frankl....
For them, the copyright year was a marketing signal and they wanted it as new as possible. We had to get guidance from our lawyers on how soon we could update them or we'd have been like car models, like releasing stuff in 2023 with 2024 copyrights.
They didn't care about source code copyrights, of course, just the copyrights that could appear in marketing or product materials.
For OSS, though, the source code is part of the marketing and product materials. So there may be a marketing reason to update them.
There's one report we publish around November and we give it a title that includes the following year for the same reason. (The report body clearly spells out when the survey was in the field but we want the title to reflect when most people will actually read the report.)
It sounds ... plausible? But I've never heard of any legal case that ever covered this. Is it a myth?
"Acceptable variants include:
- The letter c with a parenthesis over the top
- The letter c with a parenthesis under the bottom
- (c
- c)
- (c)
- The letter c with an unenclosed circle around it."
That sounds like there was some kind of dispute once about a hand-written © where the writer didn't complete the circle, and the copyright office is covering all bases here!
Interesting that [c] is not acceptable.
Presumably because [c] may be a proofreading mark.
"© 2023 Company Name"
Pretty simple and gets the point across.
If I'm reading some content in the year 4023 that says (C) 2023 CM30, then I know the copyright has since expired and I'm free to do what I want with it. If it's dynamically saying (C) 4023 CM30 then it doesn't say when it was published.
If I'm publishing something in 2019 with a dynamic date, and it says (C) 2023 and by astonishing coincidence it's very similar to another piece of work by another author that has a static date and it says (C) 2021, it appears that my work post-dates their work rather than pre-dates it.
Mostly this matters much less now and there's other ways of proving publication date but in older media it mattered more.
Presumably if you know whether the author is alive or not, you'll be safe in knowing if it's under the copyright still, assuming it hasn't had a creative commons license attached or been put into the public domain.