My post about responsibility for bug reports on old software versions the other day stirred up quite some discussion, and I wanted to drill a bit more into what I think is the crux of the dispute: the difference between legal obligations and the social contract.When you package and distribute free open source software (FOSS), you legally have to comply with the terms of the license: “make the source code available,” “don’t change the license,” and so on.You might also notice the absence of a warranty, or silence about responsibility for bug reports.So let’s return to the question:Who’s responsible for bug reports on old software versions?An accurate legal reading is “Nobody, unless you’ve signed a work contract with a developer or purchased a commercially-sold OS.” But it’s also not the whole picture, because there’s another potential non-obvious legal obligation:TrademarkTrademark law varies across the world, but at least where I live in the USA, “unregistered trademarks” are a thing, and in a professional context, you’ve got a legal obligation not to violate a product’s trademark — registered or unregistered — by referring to it as something that it isn’t, or changing it and saying it’s still what it originally was.Ah, but how much to you have to change it before that kicks in? That’s definitely not something that I — a non-lawyer — am qualified to assess. And my understanding is that this varies a lot across the world’s legal regimes, too.But my layman non-lawyer perception is that applying bug fixes (especially backports of the developer’s own bug fixes) probably doesn’t count, while making visual or functional changes not from the developer probably does press closer to that fuzzy line.Which brings me to what I think is the most important part:Doing only the legal minimum“Follow the terms of the license agreement.” “Don’t mis-represent trademarks you don’t control.” “Don’t steal.” “Don’t murder.”These are good places to start. But what if that’s all anyone ever did — the bare legal minimum?I think the world would be a pretty miserable place. There’s no law requiring anyone to love you or soothe your feelings when you’re upset. There’s no law requiring you to find a source of joy or direction in life, or help others unbidden.What makes life worth living is everything beyond the legal minimum: politeness, kindness, friends, love, pleasure, purpose, art, music, entertainment, faithfulness, professionalism, and so on.Everything desirable but not required by law comprises the social contract: a set of unwritten rules that, the more people follow them, the better their society is to live in. It helps personally, too: follow the social contract, and you’ll end up calmer and happier, be perceived more positively, and things will just kind of start going your way, as if by magic. Break it, and the opposite starts to happen.Applying the social contract to this situationLet’s say that I write an app, and someone distributes it with a feature patched in that I didn’t write, or a visual change that I didn’t make. How mad at them am I going to be?If we have a bad relationship due to previous perceived violations of the FOSS social contract, I might be very mad. I might complain publicly, or even threaten to enforce my trademark and demand they change the branding to reflect the fact that they’ve created what I believe to be a derivative work that reflects poorly on the original.No matter what, we can be sure it will escalate into a fight with a winner and a loser. And that loser might be me.But if we have a good relationship and view each other as pro-social upholders of the FOSS social contract? I might be really happy about this, or at least tolerate it. Maybe I’ll even reach out and ask them to submit their change upstream and help maintain it. There’s a 0% chance I’m going to threaten to invoke trademark law or give them a hard time about it.That’s the power of respecting the social contract that exists between us.But what is the FOSS social contract?Like the definition of “derivative work”, it’s unsatisfyingly fuzzy and nebulous. But like a cloud, even if we can’t contain 100% of it in a jar, we can probably identify many of its features. So here are some pro-social behaviors that I hope we can all agree are squarely within the “FOSS social contract”:Using FOSSIf you didn’t pay any money, appreciate what you’ve gotten for free. It’s a modern miracle.Understand the basic software lifecycle of the OS you’re using, and choose the one that suits your needs the best.Accept the “no warranty” clause. Understand that support may be slow, and that if you need it fast, you’ll need to pay for it.If you don’t like the software you’re using, use something else.Bug reportingEndeavor to report bugs in the right place, to the best of your ability.Phrase your bug reports gently, and articulate a real problem to be solved, rather than making demands or suggesting solutions.Be understanding of the fact that your request might be a big ask that might not get done soon, or might be better done in a different place or in a different way.Treat people kindly with the benefit of the doubt, even if they don’t respond to your bug report in a timely manner, or at all.If your needs are urgent, pay a person or company to address them; don’t make demands of people working for free.Software developmentDo your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.If you aren’t distributing your own software in a way that’s suitable for 100% of your users, appreciate the free efforts of distributors who are doing it for you, even if they aren’t doing it in exactly the way you would prefer.Work with your distributors to help them showcase your software in the best light. They don’t know it as well as you do.Don’t piss off too many of your users. You’re doing this for them, not just for yourself.Only make your software publicly available via a FOSS license if you’re willing to accept people using it or distributing it in ways you might not have expected or preferred.Software distributionDo your best to respond to polite and helpful bug reports in a timely manner. Read your email. Don’t ghost people.Respect the reasonable wishes of the developers whose software you distribute. Keep up good relationships with them as much as possible.Clearly communicate your OS’s software lifecycle and release schedule. Curate your users so everyone using your OS is within its intended audience.If you meaningfully change the software you distribute (outside of backporting the developers’ own bug fixes or similar), accept that you’ve created a derivative work that needs to be presented accordingly: At the minimum, change the name, icon, and metadata (like the bug report URL).If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own, or remove it entirely if you don’t have the resources to offer support for old software.Only create an OS in the first place if you’re willing to take responsibility for the support needs of the people who will use and depend on it.Hopefully we can all agree that if everyone considered the above ideas to be part of the social contract they follow, our world would be a very friendly and pleasant place! We’d end up with way fewer arguments and disputes, and could more and more get on with doing the fun part of what we do. And it’s my hope that we can all aspire towards these ideal with our actions and words.