It Matters Who Owns Your Copylefted Copyrights
byon June 30, 2021
Throughout the history of Free and Open Source software (FOSS), copyright assignment has simultaneously been controversial and accepted as the norm in our FOSS communities. This paradox, I believe, stems entirely from some key misunderstandings that perpetuate. This issue requires urgent discussion, as two of the most important FOSS projects in history (GCC and glibc) are right now considering substantial and swift changes to long-standing copyright policies that date back to the 1980s. This event, and other recent events over the last few years in the area of GPL compliance and corporate FOSS adoption, point to long-term problems for projects. This essay works through these nuances, and will hopefully assist FOSS contributors as they make difficult decisions about copyright ownership for their projects. At the end, I provide a summary list of issues to consider when creating copyright ownership policies for FOSS.
The Default Is: You Give It Away To Your Boss
I was at one time bemused, but now am mostly aghast, at the true paradox of common wisdom about copyright assignment for FOSS projects. I don't believe anyone has done a statistically valid study, but anecdotally it's rare to find a FOSS contributor who enjoys assigning copyright to another entity. FOSS contributors who do assign copyright to a non-profit charity that collects copyrights (such as the FSF or Conservancy) often complain about the complexity and annoyance of the paperwork to get started as a contributor. Even more commonly, contributors express disgust or annoyance at the pressure from the project to give away something that should be rightfully theirs.
I am sympathetic on both points, and have worked over my career to design, implement, and improve copyright assignment processes for projects — in hopes to address that first complaint. However, the second concern — the preference of FOSS contributors to keep their own copyrights, is an ironic complaint. Here's why:
Almost no contributors to larger FOSS projects hold their own copyrights. If they have not gone through a process to assign them to a charity, the most likely scenario is that their employers own those copyrights. My colleagues at Conservancy have been working on the Contract Patch project — which seeks to educate FOSS contributors about their inherent right to employment agreement negotiation, and seek more favorable terms in those employment contracts. However, over the years of our Contract Patch work, we still find that only dozens (among the thousands of FOSS contributors) have insisted that their company allow them to keep their own copyrights. If you work for a company, check your employment agreement. I'll bet that your employer owns your copyrights for everything you do at work — including your contributions to FOSS — unless there's a separate agreement that gives those copyrights to a charity like Conservancy or FSF.
As a result, in debates about copyright ownership, discussions of what policy contributors want regarding the fruits of their labor is sadly moot. Without a clear, organized mitigation strategy to assure that FOSS contributors keep their own copyrights, a project (such as GCC or glibc) that switches from a standing “(nearly) all copyrights assigned to a charity” model to a plain Developer Certificate of Origin (DCO) or naked inbound=outbound contributor arrangement will, after a period of years, mostly likely have copyrights that are primarily held by the employers of the most prolific contributors, rather than by the contributors themselves.
The Faustian bargain that causes this default is the “work-for-hire” doctrine in the USA (and similar arrangements that exist around the world). When you take a job, in most places in the world, by default, your employer owns and/or effectively controls all your copyrights. They argue that they're paying you handsomely for this and as such they have every right to own it all. Perhaps that argument has merit with regard to software that will ultimately be proprietarized, but for copylefted software, the value proposition is different and history shows that the arrangement leads to surprising results.
Copyleft Is Weakened When Most Copyright Holders Oppose Enforcement
Copyleft licenses are not magic pixie dust. Copyleft is not a legislatively-mandated regulation (e.g., pollution regulations) — which are enforced by government staff. Ultimately, an entity — most commonly the copyright holders themselves — must proactively enforce GPL. This entity can be an organization, an individual, a group of individuals, a group of organizations, or a mix of all of those. Someone must enforce the rules; so-called “spontaneous compliance” is a myth promulgated by those who oppose copyleft.
Yet that myth's apparent unexamined truthiness has taken hold; many FOSS contributors reasonably think that it does not matter who owns the copyright of their copylefted works. If it's GPL'd, they surmise, surely someone out there will enforce the GPL when it's violated. Or, perhaps the contributors think that GPL violations on their particular codebase are rare. Either way, most contributors avoid the effort required to figure out who owns their copyrights and ponder whether that entity will uphold copyleft in a reasonable way. Nevertheless, I really urge FOSS contributors to think through this issue with care and healthy skepticism, as they may be surprised at the outcome. What lurks in the backchannels may well surprise you:
Once upon a time, copyleft enforcement was not considered controversial by many otherwise-pro-FOSS companies. In recent years, companies that prefer non-copylefted FOSS have succeeded in making even the most mundane GPL enforcement appear as controversial and industry-destabilizing. Many developers who contribute to GCC and glibc — even ones that work for historically FOSS-friendly companies — will be surprised to learn that their employers (or at least their legal departments) are opposed to any GPL enforcement. Conservancy, as the main organization actively doing GPL enforcement, hears this kind of pressure regularly. Our colleagues at FSF historically told us that they hear the same. It's rarely done publicly — but, when public, criticisms are delivered by proxies in a subtle, “you don't really need copyleft to be enforced anyway, do you?” manner. The public arguments are usually couched in a careful “dog whistle” style. While the message comes through loud and clear to executives, lawyers, companies and their trade associations, it's easily missed by contributors — who understandably have a much more important task to do: writing great FOSS code!
We expect that you may be surprised by this, but we can tell you that: in private, companies that contribute to key copylefted projects are not so subtle. They have communicated to those of us in the GPL enforcement community on several occasions — a message delivered by many executives over a period of many years — that they would prefer both Conservancy and FSF to curtail, or outright end, GPL enforcement. Their view, as communicated to us, is that GPL enforcement causes customers to think copyleft is problematic. As one executive once said to me: “We consider it a failure if any customer ever even asks us if they have to worry about GPL compliance”. These companies usually say: “well, we will always comply with the license, but we'd prefer if anyone who is our customer (or potential customer) simply is just left alone if they violate”. Once, an executive actually claimed to me that his company, a huge multinational software company, would: “cease to build any products on Linux and other GPL'd software at all if Conservancy and FSF don't cease their enforcement”. That statement was fortunately bluster and bluff; the company in question is still heavily invested in copylefted software, including Linux, GCC, and glibc, but the sentiment is a common one that we hear privately often. And, that company has since funded work to discredit GPL enforcement. Conservancy faces constant pressure and threats regarding its GPL enforcement efforts, and we're aware that FSF has faced to similar pressure.
In parallel, these companies have also steadily worked to hold more of the copyrights in key copylefted works — primarily by hiring the key developers that contribute to key copylefted projects. While I oppose this outcome, it's undeniably a rational approach: if companies hold the copyrights, they can decide when, how, where and most important if copyleft licenses are ever enforced. This process is well underway for copylefted works that don't have any policies about copyright ownership. For example, the “Who Contributes to Linux?” reports by LWN show starkly over recent years: fewer contributions coming copyrighted by individuals, and more contributions copyrighted by companies. While corporate involvement is always welcome in FOSS projects, we (as a FOSS community) have not responded with the necessary care to question why the companies, rather than the individual contributors, should own our FOSS. Only very few developers have even questioned this issue; we thank them for their efforts, but such questions are simply not raised enough.
As such, the most important consideration in ending copyright assignment to a charity is to consider what the employers of most of the developers will do with those copyrights, and whether they will enforce the copyleft in the best interest of the community. Even worse, might they eventually sell those copyrights to someone who will use enforcement in a manner that a charity never would — for their own avarice rather than the good of the community?
While the remainder of this essay addresses at length other secondary considerations and nuances regarding copyright ownership in copyleft projects, this point is the absolutely most important one:
Most for-profit copyright holders prefer copyleft to function much like non-copylefted FOSS. Namely, “it's certainly nice when folks voluntarily release their changes, improvements and ‘scripts used to control compilation and installation’, but if they don't, their failure to do so should be begrudgingly tolerated, and compliance should never be compelled for those who refuse”.
Violations Are More Common Than You Think
During this recent upheaval in the GCC community, I spoke at length with a GCC developer who has contributed to the codebase regularly for decades. After I'd explained some of issues above, the developer stated: “Well, is any of this really an issue for GCC? When was the last time there was a GPL violation on GCC?”. I glibly answered: “Well, I haven't heard about one for about a week, but I'll surely hear about another one soon.” The developer was flummoxed to learn that part-and-parcel to nearly every embedded Linux GPL violation (which have been, for years, innumerable) is a companion violation on GCC. Specifically, most system-on-chip (SoC) vendors not only have a stock Linux build given to the OEMs, but also include a toolchain. More often than not, a GPL violator who has what we call an “incomplete Complete, Corresponding Source (CCS)” violation on Linux will also have a “no-source-or-offer” or “incomplete CCS” violation on GCC. The usual reason is that part of the SDK given to OEMs must include an appropriate binary toolchain (sometimes with vendor-specific patches, and almost always with a complex configuration that's difficult to reverse engineer) so that the SoC integrators can compile other software for the system. This scenario is so common that we in the GPL enforcement community coined the shorthand term “toolchain violation” to refer to the scenario where the GCC violation “tags along” with a Linux violation. While glibc violations of this nature are admittedly less common than GCC, glibc violations do occur relatively often in the same manner.
Upstream developers are mostly unaware of how bad the compliance problem is regarding their code for one simple reason: the folks impacted most by GPL violations are downstream users, not upstream developers. Furthermore, correction of compliance problems usually produces code releases that “work” for the given device on which the original violation occurred, but rarely is that CCS released resulting from a GPL enforcement action trivially upstreamable. After all, this is code written, modified, and/or integrated by developers whose plan was to “get away” with a GPL violation, so why would they have invested the time to provide the improvements in a manner that it was immediately digestible for upstream? My view is that users matter, and FOSS contributors should care about their experience with the downstream consequences of their code. I urge FOSS contributors to implement copyright ownership schemes that have the most likely chance of enabling enforcement actions principled parties.
The Power of Collective Action
Regarding my views on FOSS copyright assignment, I often quote the famous gaffe of (former USA presidential candidate and senator) John Kerry, “I voted for it before I was against it” when I'm talking about copyright assignment. But I don't quote it purely for self-deprecation; I never felt the press was all that fair to Kerry, because I think policy makers should be willing to change their positions over time as new information comes to light, or when policies that we thought were beneficial in theory prove problematic in practice. I once thought universal copyright assignment for a copylefted work to a single charity was an absolutely necessity. Then, Conservancy's successful and continuing work with various BusyBox copyright holders, and our collaboration with Christoph Hellwig, showed me that there was huge value in individuals having copyrights and making their own choices about enforcing copyleft. Still later, I realized that individuals like Erik Andresen and Christoph Hellwig are quite rare, as most FOSS contributors — even if they've kept their own copyrights — ultimately have to take on such political and career risk to enforce copyleft that they must often chose not to because they could easily get blacklisted from major employers for doing so.
The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects. Ultimately, copyleft functions best when leaders of a project have the agency, wherewithal, commitment, and collective consensus to either ensure copyleft functions to protect their users' rights, or enable another entity to do that job for them in a principled way that serves the public good (usually in contrast to the interests of for-profit industry). (Note that even if that interest is “vendor-neutral”, as that means the interests served are the common business interests of the vendors, but not their customers.)
These issues are complex. Every policy change, or lack of policy change, will have many unintended consequences. An apparent “simple move” away from mandated assignment to a centralized organization could well be a decision to ultimately move copyright holding to for-profit corporations and their trade associations — all of whom are unlikely to stand up for the GPL and user rights. Beyond all else, I urge caution and slow deliberation before any policy changes about copyright control. I ask FOSS contributors to do the substantial and necessary homework of not only reading and considering the points of this essay, but those points raised by all parties. As you do, keep in mind that every party, including me, has a policy goal in mind for copyleft. I and Conservancy are very transparent that our policy goal is to see copyleft licenses enforced regularly on behalf of end users who buy products on the open market that contain copylefted code. We believe, as a policy matter, that copylefted copyrights are best held by entities that have a bona-fide track record of serving the public good, act in a principled and ethical manner in doing so — the most important principles being to never prioritize financial gain over users' rights — and who won't back down and give up when faced with the inevitable anti-copyleft backlash. Others, probably including your employer and the trade associations to which they pay membership dues, probably disagree with this position, but you should ask questions and listen carefully to see if you're getting a straight answer. After you've heard everyone's position, decide for yourself who deserves to have your copyrights: your employer, a charity, or yourself. Once you've decided, you'll have hard work ahead to change the default (which will likely be your employer once projects drop their copyright assignment mandate).
A Word on FSF's GPL Enforcement
The elephant in the room that I've not yet mentioned is the current status of the FSF as an organization. There is no question, given the recent mass resignation of their management, and other rapid leadership change surprises, that the FSF faces serious challenges in the next few years. I personally was previously affiliated with the FSF. That affiliation ended in 2019, so I have no real information about the internal status of the FSF since then. What I do know is that FSF currently lacks sufficient capacity to follow up on any GPL violations on GCC and glibc that we've reported for years. That said, if I have to chose between the strict dichotomy of: (a) copyrights held by the FSF (which has the possibility of recovery in the future and restoration to an organization that actively enforces the GPL) vs. (b) copyrights held by companies — many of whom are known to oppose enforcement of the GPL, I would still pick the FSF. Remember that copyright does not expire for a very, very long time. GCC and glibc are both codebases that prove the half-life of well-written software is very long, and that software stays relevant and useful for much longer than any of us usually admit. We have to think long term about the copyright ownership of copylefted works. While there are serious short-term and medium-term problems at the FSF, we have to consider carefully who is the best long-term steward of copyrights: companies or charities. Most importantly, changing 30 years of careful planning about the copyright inventory of important codebases is certainly not a decision to be finalized in a matter of just a few weeks or even months. Thus, most of all, I ask FOSS contributors to take care and ample time in their deliberations on such matters.
A Summary of Recommendations and Considerations
As promised at the start of this essay, here is a laundry list of recommendations and considerations that any copylefted project should consider regarding how to structure its copyright ownership rules. This list is provided as a quick reference only, and readers should keep in mind the complexity of the topic before jumping to a conclusion about the right policies. Not every issue below was addressed in detail in the essay above, but if there is interest from the community, I will publish further essays on other topics.
- Without your active work to avoid it (such as by modifying your contract or demanding assignment to another entity), for-profit employers will control your copyrights. You typically have no say into how or whether the license of your project is enforced if your employer holds your copyrights.
- Modern copyright assignments to charities such as the FSF or Conservancy usually take two forms: either your employer has a blanket copyright assignment, or you must individually assign copyright. In the latter case, there are typically two components: a disclaimer from copyright from your employer, and an assignment from you. In either case, you should speak at length with your employer's legal department to figure out what form, if any, is in place, and what will happen to those systems if your project changes its copyright aggregation policies.
- FOSS contributors have safety in numbers. A strong consensus that your project wants to see copyleft enforced for your users can create leverage that mitigates risk of “blacklisting” of those who chose to enforce copyleft licenses. When policies like copyright assignment to a charity or copyright ownership only by individuals are set project-wide, companies historically have simply accepted it. (The Samba project is an excellent example of a project where the developers have control.) By contrast, each contributor faces a steep climb in negotiating their ownership of the copyrights in the absence of such policies.
- While assignment to a charity can be annoying and feel problematic, this is often the most expedient way to assure that the copyleft license of your project is upheld. Conservancy, for example, will accept one-off assignment from FOSS contributors to strategically important FOSS projects. Even if you (collectively) chose to not mandate assignment for your project, it's valuable to assist and encourage your contributors to either develop together a collective individual copyright ownership plan, or assign to different charities, or recommend a mixture of the two.
- As an upstream developer, you're likely going to be unaware of most copyleft violations on your code. If possible, work with an entity that has the time and resources to investigate violations for you, and empower that entity to act on your behalf if possible.
- Pay attention to the details of Contributor Licensing Agreements (CLAs). Often, these require that you give up almost as many rights as a copyright assignment would require you to give up anyway. Avoid asking your contributors to agree to a CLA.
- Developer Certificate of Origins (DCOs) and other inbound=outbound contribution regimes are very good, useful and recommended. However ultimately such systems are entirely orthogonal to who holds the copyright. DCOs and contribution terms are general statements that attest to your right and permission to make contributions under the project's license, but are, by design, silent on the details. A DCO is absolutely compatible with a project that separately requires copyright assignment, or with a project that has other recommendations about how developers should handle copyright ownership.
- Seek and consider advice from all sources. Everyone with an opinion on these topics has a policy agenda. Ask what their policy agenda is when they advise you. Ask them their view on copyleft enforcement. Ask them if they've ever investigated copyleft violations on your software, and if so what they found and what their opinion is. If you're considering assigning your copyrights to someone, most notably your employer (who, again, is likely to by default receive your copyrights) be sure you've fully understood their policy and views on these matters. Insist that they put their policy and views in writing for you for future reference. Ask for strong commitments, and be skeptical if you cannot receive them.
Come chat with us at firstname.lastname@example.org 🎉
byon June 21, 2021
Last Thursday we launched our new chat platform chat.sfconservancy.org! Conservancy's main chat room, which used to be on Freenode, is now available at the following locations:
- The primary room, on XMPP at email@example.com (also via the web)
- A bridged IRC room, at #conservancy on irc.libera.chat
- The bridged room that Matrix provides, at #xmpp_general_chat.sfconservancy.org:matrix.org
We've taken the opportunity of leaving Freenode to change technologies to something we think reflects our ideals. XMPP is a decentralized, open standard and widely used chat platform that supports many of the common features we've come to expect in the new era of chat. Given that we've been using IRC, almost anything would be a strict upgrade when it comes to features. We also wanted to make it as easy as possible for newcomers to start chatting.
We evaluated and tested a multitude of options: XMPP, Matrix, RocketChat, Mattermost, Zulip, ircv3, etc and permutations of bridging support. Given the near parity of features that we care about (we even support reactions now 👍), some reasons we chose XMPP over the others are the longevity and fundamental independence of the XMPP protocol, that we found the matrix-bifrost bridge to work better with Matrix users coming in to XMPP than XMPP users joining Matrix channels (but hope in the future to see this support get better!) and staff familiarity with XMPP. There is also a really healthy and growing ecosystem of XMPP clients and you'll find some recommendations below.
Note: similarly to IRC, your connection to the XMPP server is encrypted, but due to the nature of chat rooms, we cannot provide E2E encryption of the channel itself. Nevertheless here are a list of clients that support OMEMO (which is the standard for E2E encryption for XMPP).
Clients 💻 📱
- Web: Movim, jsxc (for use with NextCloud)
- Linux: Dino IM, Gajim
- OS X: Beagle
- Windows: Miranda
- Android: Conversations
- iOS: Monal
- Linux: Snikket
And here are some other tools which I think are interesting:
- Biboumi allows you to connect to IRC channels from your XMPP client. We are using this instance.
- matrix-bifrost allows you to bridge from Matrix to XMPP. It's a bit hard to run yourself but Matrix runs one for you!
- matterbridge is what we're using to bridge from XMPP to IRC. It has a plethora of options and is a great tool if you want to bridge yourself into walled garden platforms but use your own FOSS client.
We're excited about the possibilities of what XMPP will bring our community. Specifically helping our projects use more free software where possible. Communication is one area that we particularly think is important to remain free and in our (collective) hands. The proliferation of chat software over the years is a well noted problem, and this is one area that free software both outperforms proprietary options and promotes interoperating standards and giving back the freedom of users to use the software that works for them.
So which ever client and connection you choose, we're excited to hear from you 💻🌉💻
I'm Pono Your New Community Organizer
byHi there, my name is Daniel Pono Takamori and I'm the new Community Organizer and Nonprofit Problem Solver here at Conservancy! My background is in running free software as infrastructure so you might've filed a ticket with me somewhere in the past :) I'm looking forward to this new non-technical role as community support. Being able to bring my skills to help further software freedom here at Conservancy is a very exciting new chapter to me. With projects ranging from programming languages to make programming languages, to community building and mentorship programs, the breadth and spread of projects is incredible. Conservancy projects really help keep you grounded in the varied relationships all people have with software. I'm so grateful for the opportunity to learn from people with different backgrounds, approaches and lived experiences. on May 18, 2021
I recently gave a keynote at SeaGL 2020 and found the experience of being able to share my non-technical thoughts about technical subjects very invigorating. Speaking more to the human experience of computing technology and the effects computers can have on us. It's with this lens that I hope to bring a more nuanced and compassionate view to the world of software freedom. It's easy to get lost in the billion dollar industries that rely on our labor, but at the end of the day we are people working together with people.
Going forward in this new remote friendlier world, I'm hopeful for more accessible communication. Both with remote friendly conferences, more free software being used to communicate and a more universal understanding that we are people first. While my day to day will probably be lots of email and meetings, I'm excited to find ways to help augment communities with tools like Apache STeVe and freeing projects from proprietary communication tools. Please help me help you by letting us know how Conservancy can be better. Whether it's a more active social media presence, IRC office hours, or if there's an event or project you think we should know about.
I can't believe that after volunteering with Conservancy and contributing to member projects, I now have the honor of championing the great work that WE do.
So you want to apologize... Now what?
byon April 20, 2021
We are all human. We all make mistakes. This is true of everyone, including leaders in free software communities.
We often end up needing to apologize after we hurt another person. Harming someone with your words or actions is mortifying and embarrassing.
Your first reaction may be to explain your reasoning — why you did what you did. You understandably want to explain that you didn’t intend to cause harm.
This is a natural human desire, but can often be counter-productive. Trying to explain your actions can sometimes cause others to feel even more hurt.
This blog post was written to help people in free software avoid some of these unintuitive but common pitfalls in crafting an apology.
The TLDR; apology template
⚠️ Please read the rest of the blog post before using the sample template below. The other sections of this blog post will help you avoid common mistakes that may cause people to misunderstand your apology. ⚠️
A written or verbal apology should meet two goals:
- Communicate that you understand what behavior needs to be changed
- Commit to not doing similar harmful behavior in the future
An effective apology should contain:
- an explanation of the specific behavior that caused harm
- an apology directly to the people or group of people harmed
- a commitment to stop the behavior that is causing the harm
- a plan to avoid similar harmful behavior
- a plan to repair any harm your behavior caused
- the name of a person who will hold you accountable for changing your behavior
Discussing Your Behavior
The first thing you need to discuss in an apology is what you are apologizing for. Be specific and mention the precise behavior that you want to apologize for.
Most of the time, people don’t intend their behavior to hurt another person. You might have been unaware that your words or behavior would have a negative impact on others. You may have been trying to help, but end up hurting someone instead.
Even with good intentions, actions (or lack of action) sometimes do still cause harm. The most important thing is to ensure the harm stops and you work to prevent future harm.
When we make mistakes, we want to fix them. An apology should make it clear you want to fix any harm you caused. In order to do that, any apology you say or write should meet two important goals:
- Communicate that you understand what behavior caused the harm
- Commit to not doing similar harmful behavior in the future
As you are apologizing or discussing a mistake you’ve made, focus on these two goals. Keeping these goals in mind will help mitigate misunderstanding, and assure that you communicate your remorse well.
Understanding the Harm
When you apologize, invest substantial time and consideration to determine what part of your behavior caused harm, and what similar behavior might also cause harm. Ask peers or colleagues not involved in the situation to frankly tell you their assessment of the behavior and its problems.
For example, say you told a joke that negatively impacts a person’s ability to do their job. It’s not enough to say, “Sorry, I won’t tell that joke again.” This fails to communicate to those you’ve harmed that you truly recognize why that kind of joke can be harmful.
People may worry that you might tell a similar joke in the future. They may also be afraid that you might make statements in future that aren’t jokes. They may be concerned about whether the joke is a sign you will behave in biased, discriminatory, or even ways that make them feel unsafe.
The joke alone may not have a huge impact in the moment. The person may have laughed or politely disengaged from the conversation. However, on further reflection, they may feel the joke created a sense that it may not be safe or comfortable for them to collaborate with you.
A good apology will communicate true regret for creating an unsafe environment, not just apologize for one instance of your behavior.
Acknowledging Harm Done
After describing what behavior harmed others, apologize clearly and directly to the people who were harmed.
Ideally an apology would happen in a private space, so that the other person has space to process your apology before responding. Apologizing in a one-on-one conversation or through a private email is best.
However, mistakes that were widely seen by the public often require a public apology. Public apologies are often necessary when it’s impossible to apologize privately to everyone.
In an online public apology, you should carefully consider whether to name the specific person you harmed with your behavior. That may direct online harassment to them, causing further harm. Instead, you should anonymize the details to protect the person’s privacy, and only identify them with their permission.
Online public apologies are tricky. People may question your motivations when posting a public apology. They will legitimately worry that you are apologizing merely due to public pressure, rather than because you acknowledge your behavior caused harm.
Therefore, take extra care and effort in public apologies. Consider sharing drafts of apology with others who pointed out your harmful behavior to have them frankly evaluate whether your apology reads as sincere.
There are three common things that people use to judge whether an apology is sincere:
- How you talk about your behavior
- How you talk about your reaction to being asked to change
- How you talk about others’ reactions to your behavior
The next three sections talk about pitfalls to avoid when acknowledging the harm you caused.
Don’t Talk About Intent
One mistake people fall into is trying to explain their intent. They want to communicate that they didn’t intend their behavior to harm others.
Explaining the intent behind your behavior usually requires describing your thoughts, feelings, or background. You may want to say things like, “I wasn’t raised to understand that behavior was inappropriate,” and talk about your journey towards learning and changing.
Unfortunately, talking about your past intent can come across as making excuses for your behavior. An apology is not an excuse; it’s a statement of remorse and regret! Doing a deep dive into your background and feelings can make the person you’re apologizing to feel like you’re ignoring their hurt feelings.
In your apology, you need to center the feelings of the other person or the group of people you hurt. Make sure that you talk more or write more about the other person than you. If possible, avoid talking about your intent, your feelings, or your background entirely. If the recipient wants this information, they can ask you for it later.
Don’t Focus on Your Emotions
Being told your behavior is causing harm can be hard. You may be upset. You may spiral into over-analyzing your past behavior. Being told you are causing harm in a public manner can have an impact on your other relationships or work.
An apology is not the place to talk about the harm done to you. You may want to talk about your emotional response to being told your behavior is inappropriate. However, doing so redirects attention away from the harm your behavior caused to others. Your feelings about the situation, and the pain it has caused you, belongs in private discussions with your closest friends, companions, and therapists — not with the public or those you’ve harmed.
Don’t Critique Others’ Emotions
Sometimes you may be unclear exactly why your behavior caused harm. You may see the other person’s emotions — anger, disgust, fear — but not understand why the other person feels that way.
That’s normal. A lot of people find it hard to understand another person’s lived experiences. Focusing on the emotions you can see is easier than understanding why your behavior had a negative impact.
However, talking about the emotional response that you observed can backfire. Focusing on the other person’s emotions can be seen as criticizing those emotions. Talking about how the other person got angry or offended can be seen as criticizing their tone or actions. This can cause other people to think you are deflecting attention away from your harmful behavior. An apology is not an argument, or a difference of opinion to be explained; an apology acknowledges your mistake and speaks to the changes you’re making in your own behavior to prevent future mistakes and harm to others.
Instead of focusing on emotions you see but don’t understand, focus on the fact that you do understand you harmed another person and you commit to not doing harm in the future.
Avoiding Future Harm
An important aspect of changing your behavior is understanding what types of behavior to avoid in the future.
If you don’t understand why your behavior caused harm, you can ask the person, at the end of your apology, “How can I avoid similar mistakes in the future?” The advice they give might take the form of the following suggestions:
- Read these resources before you talk about a topic
- Avoid talking about a topic altogether
- Use a specific phrase instead of another phrase
- Don’t do a specific type of behavior
- Modify policies or processes
Sometimes the other person isn’t willing to provide feedback. They may not want to spend the time to educate you. They may be upset and unwilling to discuss the matter further. In this case, allow the person space and respect any communication boundaries they set. Otherwise you risk further harm and damaging your relationship with them.
If someone sets a boundary and doesn’t want to provide education, there are other ways you can learn what patterns of behavior to avoid.
There are often books and resources for understanding why specific behaviors are harmful. There may be workshops or other training you can attend. You may also want to pay professional coaches, counselors, therapists, workshops, or other consultants.
You can also follow people on social media who talk about how to change that type of behavior. While social media posts are public, it’s important to acknowledge that providing this kind of education is emotionally taxing and time consuming. Many people who share education on social media have ways you can become a patron or provide the person a small tip for good information. Please contribute financially if you can.
Committing to change
So far in your apology, you’ve acknowledged what behavior was harmful, and apologized to the people you’ve harmed. The next part of the apology is to commit to changing your behavior.
It’s important that you be specific about what behavior you are committing to change. The commitment should take the form of “I will no longer do X” and “I will do Y”. It’s important to describe what behavior you will change as concretely as possible.
It can be tempting to put a disclaimer in your apology that it will take time for you to change. However, that can again be seen as making excuses.
Instead of talking about how hard it will be for you to change, it’s important to talk about the effort you will put into changing. This focuses your apology on a growth mentality. It takes time and effort to change, and you are committing to putting in the work it takes to change.
Repairing the Harm Caused
In some cases, an apology may be enough to to repair the harm your behavior caused. In other cases, additional actions may need to be taken.
If you are in a leadership or authority role, you may need to commit to changing policies or processes. It’s important that you don’t do this alone. If your organizational leadership didn’t realize it was causing harm, you need experienced people to help that are outside of your organization.
Once you’ve committed to changing your behavior or repairing the harm that was caused, find one person who can hold you accountable for changing your actions. This could be a business coach or mediator (for a free software organization), or a counselor or therapist (for an individual). You need to find someone who is not involved with your organization and not a friend. This is the only way to get an unbiased perspective.
Some people want to make it clear that anyone can approach them with further concerns. They may want to say, “If I mess up again, please tell me!” This is natural, but it usually backfires if you don’t have a specific person to hold you accountable.
When you ask a group of people to hold you accountable, the bystander effect can kick in. Everyone will assume the other people will talk to you about your harmful behavior. The end result is that no one will talk to you about behavior that needs to change.
If you are a leader, it can be very intimidating for another person to ask you to change. That person may hesitate to share how your behavior impacted them. Sharing why they felt hurt requires them to become vulnerable in front of a highly respected person. This can be hard for a lot of people.
If you are a leader who is trying to change their behavior, it can be good to designate one particular person to meet with people who have grievances. The person can then mediate the conversation with you.
Make sure that your apology designates one person outside of your organization to hold you accountable to change.
Template for an apology
Phew, that was a lot! Now the long explanation of why you need each part of an apology is out of the way. Let’s take a look at a template you can use to craft an effective apology:
“Over the past TIME RANGE, I did the following behavior:
- BEHAVIORS and DATES OF BEHAVIORS
I recognize that my behavior CAUSED TYPE OF HARM. (Examples of harm: caused someone to quit working in a community, caused someone to avoid community events, caused GROUP OF PEOPLE to avoid a community, etc.)
I recognize my behavior caused harm because…
I acknowledge my behavior was inappropriate because…
I apologize to everyone who was harmed by my actions, especially GROUP OF PEOPLE.
I commit to not doing BEHAVIOR again. I will work to avoid similar harmful behaviors. I have committed to learning how to change by ATTENDING XYZ CLASSES, READING XYZ RESOURCES, OR OTHER LEARNING METHODS over the next DATE RANGE.
Additionally, PERSON will be holding me accountable by PROVIDING ACCOUNTABILITY TYPE. PERSON has XYZ CREDENTIALS. I will be working with PERSON over the next DATE RANGE.
I am committed to repairing the harm I caused by ACTIONS.
I will post about my progress towards changing my behavior again on DATE.”
This template seems simple, but without reading the discussion of the common pitfalls above, it can be easy for people to misunderstand your apology.
Corrections to This Article
Did you catch an error in this article? Tell me about it! I welcome feedback from people on how to improve this article. You can send feedback via the info email below.