Slashdot Mirror
What Happens to Open Source Code After Its Developer Dies? (wired.com)
An anonymous reader writes:
The late Jim Weirich "was a seminal member of the western world's Ruby community," according to Ruby developer Justin Searls, who at the age of 30 took over Weirich's tools (which are used by huge sites like Hulu, Kickstarter, and Twitter). Soon Searls made a will and a succession plan for his own open-source projects. Wired calls succession "a growing concern in the open-source software community," noting developers have another option: transferring their copyrights to an open source group (for example, the Apache Foundation).
Most package-management systems have "at least an ad-hoc process for transferring control over a library," according to Wired, but they also note that "that usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it." Evan Phoenix of the Ruby Gems project acknowledges that "We don't have an official policy mostly because it hasn't come up all that often. We do have an adviser council that is used to decide these types of things case by case." Searls suggests GitHub and package managers like Ruby Gems add a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time.
Wired also spoke to Michael Droettboom, who took over the Python library Matplotlib after John Hunter died in 2012. He points out that "Sometimes there are parts of the code that only one person understands," stressing the need for developers to also understand the code they're inheriting.
Most package-management systems have "at least an ad-hoc process for transferring control over a library," according to Wired, but they also note that "that usually depends on someone noticing that a project has been orphaned and then volunteering to adopt it." Evan Phoenix of the Ruby Gems project acknowledges that "We don't have an official policy mostly because it hasn't come up all that often. We do have an adviser council that is used to decide these types of things case by case." Searls suggests GitHub and package managers like Ruby Gems add a "dead man's switch" to their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn't log in or make changes after a set period of time.
Wired also spoke to Michael Droettboom, who took over the Python library Matplotlib after John Hunter died in 2012. He points out that "Sometimes there are parts of the code that only one person understands," stressing the need for developers to also understand the code they're inheriting.
open for anybody to continue? That is exactly the advantage of open source.
It becomes public domain
The dead guy needs an incentive for 70/75/90/95/100 years so he can keep improving that code.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
It becomes public domain
No it doesn't. When someone dies, unless their wills says otherwise, any copyrights go to their estate. It is up to their heirs what happens after that.
Yes, the code is available, it's open source, after all.
The question the article gets to is how do packagers such as Red Hat or CPAN decide which version to include by default - the old, established one that hasn't been updated, or the new one that has updates but not not the long history? That may be a case-by-case issue by it's very nature.
The other point raised is that programmers, up open source or proprietary, should make sure that two other people have commit access, or will get it.
In my most significant software I wrote by myself, I included a "dead man's switch" which I'm thinking about activating. In the license, I included a clause that said if my web page goes down, non-copyright is automatically passed to a certain person (I maintain my rights as well). If they choose not to maintain the software, two other people are named. If none of those three picks it up, it automatically goes GPL and anyone can do what they want with it, including providing updates and support as part of their business.
The person I passed it along to a few years may not be actively maintaining and supporting it, so I may post it relevant forums declaring that I'm now licensing it open source. I may also contact some of the people that make "competing" software and let them know they can freely use my old software, or parts of it, in compliance with an open-source license I'll select.
I accidentally typed
non-copyright is automatically passed to a certain person (I maintain my rights as well)
That should say:
non-exclusive copyright is automatically passed to a certain person (I maintain my rights as well)
They got full rights to do whatever they wanted with the code, expressed as a non-exclusive license. I also maintained my own rights, so I can theoretically use library routines or any patentable new ideas in my own projects, or allow other people to do so.
..is that has no gating dependencies on the original developer.
If something is opensource then either it already has other people to keep working on it, or it wasn't filling anyone else's real need anyway, so doesn't matter if it fades away.
The good, well-documented, test-covered and well-behaving code goes to heaven repository. The other codes are incorporated into Microsoft products.
The same thing that happens when a developer loses interest in a project. Either someone steps up to maintain it or it sits in stasis until then. It's certainly a better situation to be in than to be stuck with closed source stuff after the company goes under or stops supporting it.
Someone comes along, looks at it, decides it's all garbage, decides that they can do better, and rewrites it. The only real difference is that those using it in their own product have the option of locally sticking with and maintaining the old code.
Generally, they know they can use his code because he has waived his right to sue them by purporting to give them permission by placing it in the public domain.
Lawyers (IANAL) disagree over if it is possible/legit to actually place a work in the public domain, but both sides agree that if you try you're waiving your right to sue people over it.
The problem is if the people who say it isn't legit are correct, and then you die and the person who inherits the copyright sells it, and no restrictions attach to the buyer and now they can sue you over it! Hopefully, the other lawyers are right and it really would be public domain.
This is why I just use the Apache 2 license, then all the different "camps" can use it, and all their lawyers are happy.
Old programmers never die, they get redirected to /dev/null.
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain
Yes, the code is available, it's open source, after all. The question the article gets to is how do packagers such as Red Hat or CPAN decide which version to include by default - the old, established one that hasn't been updated, or the new one that has updates but not not the long history? That may be a case-by-case issue by it's very nature. The other point raised is that programmers, up open source or proprietary, should make sure that two other people have commit access, or will get it.
That's neat when you have someone to name as your heir before your untimely demise, but it's not like most projects has an over-abundance of volunteers looking to secure their rank in the line of succession. For most projects I think it would be quite unclear who, if any, is going to step up and take over in advance. Maybe they need to feel the void of your absence, maybe they're secretly hoping someone else will pick up the mantle, maybe they don't want to take on the commitment they'd feel as the named successor. This would be more like a system to enable the project members or trustees to create an interim solution, where you have to hand over control that you wouldn't give on a day-to-day basis.
For that I'd probably go with something like Shamir's Secret Sharing algorithm and a grace period to prevent hostile takeover, like if 5/8 of those I've given a vote claim that I'm no longer leading the project and I'm unresponsive for a week then they get to appoint a new project leader. That way they essentially have no power individually, but collectively they'd have the power to declare me "dead". If the project is so tiny you're the only one in it you could give the votes to people you trust in related projects. What you don't want to do is say "project abandoned, up for grabs" and have random hackers/bots take over, add malware and push it as an update. Hopefully those you hand the reins to have some sense in picking a successor.
Live today, because you never know what tomorrow brings
I get the issues involved, the desire of many in the open source community to require users of open source software to make their own software also open. Still, I find it ironic that the open source community is worried about what people might do with open source software after the author dies. If it were truly open, one would think that they would be happy that the source code now continues to be free for anyone to use or modify!
It becomes public domain
No it doesn't. When someone dies, unless their wills says otherwise, any copyrights go to their estate. It is up to their heirs what happens after that.
Irrelevant, its open source so someone forks the code and continues on. What the relatives want is irrelevant, all they have is an old project name. Well that and possibly the right to dual license it. But the existing open source recipient lose nothing even if it gets dual licensed by the new copyright owners.