After last week’s initial post about hyperlinked files as modern attachments, I’m taking a step back and starting with five assumptions about the issue.
I started this series last week by asking the question: “Should we treat hyperlinked files as modern attachments?” I also shared three case law rulings and an ESI Protocol order in the fourth case where it was agreed that they would be treated as such (the order actually used the phrase “modern attachments” in it).
I received tons of feedback on the topic, with a whopping 72 comments on my LinkedIn post about it so far (some of which were mine, of course) and received several emails as well with thoughts and opinions. Not surprisingly, there are proponents on both sides of the issue.
There were several good arguments made for and against the idea of hyperlinked files as modern attachments. I also found out that The Sedona Conference® is working on a Commentary about the issue as well and I’ll be interested to see what comes out of that.
However, some of the arguments were a bit off-point, as people put forth arguments about all types of hyperlinks, not just hyperlinked files (which was literally part of the title of my post). Others were talking about there being no requirement to produce links to public files (which I didn’t consider to be in scope either) or broken links (not possible) or the fact that discovery should be both relevant and proportional (of course).
So, I decided to take a step back for this post and state five assumptions about the issue that we can hopefully all agree on (or at least most of us), regardless of what side of the debate we’re on. I’m proposing these to help frame and focus the discussion going forward, let’s see how well it works.
Assumption #1: The issue relates only to hyperlinked files, not all hyperlinks.
We’re not talking about an email or a Slack message with a link to a Wikipedia page or to a company’s public website. The issue and discussion should be limited to hyperlinked files only.
What about links to file folders or internal websites within the control of the responding party, you say? That information may be responsive, and the parties can negotiate how that may be handled, but it hasn’t historically been treated as an attachment (because nothing is embedded). It shouldn’t be treated as one now.
Assumption #2: Those hyperlinked files must be in the “possession, custody or control” of the responding party.
This is covered in the Federal rules. FRCP Rule 34(a)(1) specifies that parties may only request the production of documents or electronically stored information (ESI) “in the responding party’s possession, custody or control.”
Public files are not required to be produced – the requesting party can retrieve them on their own. Links to files owned by a third party are also not required to be produced – the requesting party can pursue a third-party subpoena under Rule 45 to get those. Note that I said “owned” not “stored” – files stored in a repository like Google Drive or OneDrive on behalf of the responding party are still considered to be in their custody and control (at least in the case law I’ve read).
Assumption #3: A file that no longer exists can’t be produced.
One or two arguments were made about broken links or links to files that no longer exist. Of course, a responding party can’t do anything about producing those. A linked file could be older than the email or message that referenced it and could have been defensibly deleted before the duty to preserve began (or it could be on a different retention schedule than the email or message). Because these files are linked and not embedded, that’s an unavoidable truth.
I’m not including files that are still available but may have been changed since the file was sent in this assumption. The versioning issue is a big “can of worms” and requires more discussion – probably a blog post of its own later in the series. I’m only including files that don’t exist at all in this assumption, not files that still exist but may have changed (for now, at least).
Assumption #4: Hyperlinked files should still be produced if they are deemed to be responsive.
Regardless of whether they are produced as a modern attachment or not, files should be produced if they are determined to be responsive during search and review (including TAR review). Generally, the locations of hyperlinked files (e.g., Google Drive, OneDrive, etc.) should still be searched to identify potentially responsive files and they should be produced (at least as a standalone file), irrespective of their relationship to emails and messages which reference them.
The ultimate question of how they should be produced (as a modern attachment or not) is still up for debate. Of course, some hyperlinked files may only be responsive because of their relationship to the communication – those are also still up for debate. See assumption #5.
Assumption #5: Discovery of hyperlinked files must be both relevant and proportional.
Of course. The burden of producing these files as modern attachments was cited frequently by those opposed to it, given the technical challenges. The sixth proportionality factor in FRCP Rule 26(b)(1) is “whether the burden or expense of the proposed discovery outweighs its likely benefit”. Obviously, if the burden is considerable, the likely benefit must be even more considerable.
Two things regarding this assumption:
- There should be specificity in objecting to the request to treat them as modern attachments per FRCP Rule 34(b)(2) – you can’t simply object to the request as “overly broad, unduly burdensome, disproportionate to the needs of the case and not reasonably calculated to lead to the discovery of admissible evidence”. That’s a “boilerplate” objection. The objection should provide specifics as to the burden.
- As technology evolves, the burden will likely change and, in many cases, lessen as software providers automate the retrieval of hyperlinked files (and potentially the correct version of the hyperlinked files). So, what may be arguably “unduly burdensome” today may be less so in the future.
So, there you go. Five assumptions about the issue of hyperlinked files as modern attachments. I’m hoping all (or most) of us can agree that these assumptions should be true; if so, that should help to focus the debate.
Now what? Here’s where I want you to get involved. Over the next several weeks, I plan to write a series of posts that discuss the pros and cons associated with hyperlinked files and treating them as modern attachments, as well as current technological approaches for doing so (and any inherent limitations with those technologies) and, frankly, I could use all the help I can get. If you have any thoughts about the pros and cons of the modern attachments issue, or any knowledge of current technological approaches to do so, feel free to send me an email at daustin@ediscoverytoday.com. Any information that I use will be credited to the source (unless you ask me not to do so).
More to come in the next installment – stay tuned!
So, what do you think? Do you agree with my five assumptions about the issue of hyperlinked files as modern attachments? Please share any comments you might have or if you’d like to know more about a particular topic.
Image created using Microsoft Bing’s Image Creator Powered by DALL-E, using the term “email AND hyperlinks”.
Disclaimer: The views represented herein are exclusively the views of the author, and do not necessarily represent the views held by my employer, my partners or my clients. eDiscovery Today is made available solely for educational purposes to provide general information about general eDiscovery principles and not to provide specific legal advice applicable to any particular circumstance. eDiscovery Today should not be used as a substitute for competent legal advice from a lawyer you have retained and who has agreed to represent you.
You’ve laid down the ground rules brilliantly and fairly. Bravo! Now, let’s see if they hold or we return to comments pointing to the same parade of horribles you’ve just excluded.
What source data are you referring to? You mentioned what’s it’s ‘Not’ (Slack/email), but not any source examples. Are we talking about MS Teams Chat links? RDB export reports? Thanks!
Hi Joe,
Are you talking about my statement: “We’re not talking about an email or a Slack message with a link to a Wikipedia page or to a company’s public website.”?
If so, the email/Slack part is irrelevant, it was just an example. All I’m really saying is that a link that is not to a file (regardless where the link is located) is out of scope.
If that’s not what you meant, could you clarify your question a bit?
Ahh… gotcha. I thought you were talking about the source type, not the link type.
Thanks, Craig! I’m optimistic! 🙂