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.
It becomes public domain
No. Unless the author expressly wanted it to become public domain.
:)).
SIDE CLARIFICATION: all my open-source code and public activity is public domain since over 2 years ago. So, me being alive/dead doesn't change anything on this front (the updates might get a bit delayed though
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Sometimes I wonder if Webalizer (web server log analyzer) has been orphaned in a manner similar to this thread's topic. Last I checked, the website (webalizer.org) is still up, but no one seems to be home.
Zero support. Zero updates. Zero documentation.
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.
What is "usable and understandable to others", though?
I always use brackets for my ifs, my ifs/else, switch/case, etc. You can't NOT see the blocks of code.
And I never understood why something as obscure as "if x:?z" exists, its purpose only makes for unreadable code.
#DeleteFacebook
The good, well-documented, test-covered and well-behaving code goes to heaven repository. The other codes are incorporated into Microsoft products.
From this page /dev/null it's still GPL.
https://en.wikibooks.org/wiki/...
"One of the main motivations for the usage of the GPL in FOSS is assurance that once something is released as FOSS, it will remain so permanently."
My understanding is that means in perpetuity.
After you go to
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.
So if the owner of GPL'd software is a single person and s/he passes away, does the right to make proprietary extensions to the code vanish for eternity?
No, it passes to the person's estate. The only thing that really changes (aside from the name of the person you need to talk to) is that the clock on the copyright finally starts ticking.
So you have no license on your code at all? How does anyone know they can use 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
Things don't happen that way, but most "open source" projects don't end up with ownership problems so much as maintainer problems. It's quite rare that the legal inheritor of the copyright has either the desire or the ability to maintain it. With most open source licenses, certainly with GPL, the next maintainer retains the right to alter and release new versions of the code even without legal ownership of the copyright to the existing code. But capability is an entirely separate matter. There can also be problems with the right to use the name, but, again, that doesn't usually arise with death.
Actually I believe that for FOSS projects the two main problems in this area are the right to continue using the name and the capability to maintain the code (and interest in doing so). And that doesn't always wait for somebody to die to become a problem. I know Debian is frequently asking for someone to adopt a package that has lost its maintainer...and often the reason is loss of interest rather than death.
All that said, I know that in the Python community awhile ago (over a decade now?) there was significant concern about "What do we do if Guido is hit by a bus?", and the result was the current Python Software Foundation. Smaller projects, however, would probably find that solution expensive overkill.
I think we've pushed this "anyone can grow up to be president" thing too far.
If nobody can understand it, it *will* rot. This may be a disaster as far as the project is concerned. But if nobody really understands what it is doing, replacing it can be...problematic.
I think we've pushed this "anyone can grow up to be president" thing too far.
Assuming that the developer did not explicitly designate succession plans, and that the developer's heirs don't have an interest in the project, the code becomes abandoned property. The law in most countries recognizes abandoned property as available to anyone who wants it, whether that is physical property or virtual. For example, if you take a refrigerator out to the curb for trash pickup, anyone who wants it is free to take it and use it however they want to. If software is abandoned, it would legally fall under the same principle.
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!
My experience is that on projects with few contributors, those contributors care about the project - they are using it in their business or their own larger project, so one will be willing to take over even if only for their own self-interest. I've taken over a few projects for that reason. I became the maintainer not because I'm altruistic, but because I needed the software to work.
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.
Generally this is true, although there are some other ways they can be transferred (e.g. they may be transferring the copyright via a community property agreement, living trust, buy-sell agreement, marital property agreement, or other instrument upon their death). The important thing is to make sure your estate planning attorney knows that you have contributed to open source projects and knows what you want to happen to your copyrights when they draw up your documents. Part of that should also be leaving good instructions for your executor in terms of how they should reach out to project co-maintainers.
Making plans in advance means someone down the road may have the ability to issue your software under a more permissive license or to enforce the GPL, for example. This applies also if you become disabled--ideally you should have some kind of instruction regarding open source projects with your power of attorney. (If you want help in Seattle or want me to find someone in your neck of the woods who does this, let me know and I can either help out or ask around, as appropriate.)
Real lawyers write in C++
To be fair, copyright law does make sure I have no incentive to murder you to save on licensing costs.
On the other hand, a fixed time like "20 years from the work's creation" would have the same effect; this is just an argument against setting the copyright expiry date to the death of the author.
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.
If a project is useful it will be forked and maintained by a new maintainer. Linux will survive perfectly well without Linus Torvalds. Do the original developers of gcc even still contribute?
If people need new features, they can add them. They will do so because it's easier than finding software that does what we want.
So you have no license on your code at all? How does anyone know they can use it?
No. I have licenses (and quite a few other references) clearly saying that my code can be considered public domain. Didn't you know that, within the most common lists of copyright licenses, you can find public domain ones? In some cases, you have the express option of public domain or cc0 or unlicense, all of them are basically the same. What this means is that my code/any other public output can be used according to whatever rules are applicable to public domain in the given jurisdiction. The basic idea is that you can use it without any limitation and without referring me at all (it would be nice though), but you cannot claim its authorship. The whole point of my public codes is giving an idea about my coding skills to potential clients; I don't care about people using it more or less and, in case of doubt, I usually choose the generous alternative :)
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
but both sides agree that if you try you're waiving your right to sue people over it.
Honestly, I cannot imagine me suing anyone about stealing my code (mainly when there are many other much quicker and efficient "counter-measurements". LOL); but I am not renouncing to that right anyway. Although public domain protection is certainly much more imprecise than other more restricted alternatives, it is still protected at least for what matters to me: the original authorship. You can take any famous public domain work from Mozart or Shakespeare to immediately understand that nobody will ever go away with claiming authorship of that. I am only renouncing to modern restrictions/revenue-generations which I don't fully support and which, in any case, are quite useless under my specific conditions, where my public code is used as mere advertisement of my actual income source (= being hired to actually perform whatever development).
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
There are two reasons to avoid the public domain, though they're largely been relaxed over time. The first is that most software licenses include an explicit disclaimer of liability. If you put something in the public domain then you are not providing that, so though you waive the right to sue over copyright infringement no one else waives the right to sue you. That said, I don't believe that there's been a single lawsuit over merchantability of public domain code, and I'd be surprised if one didn't get laughed out of court.
The other is that some jurisdictions either don't recognise that public domain exists, or recognise it only as the state into which works fall after the copyright expires. In particular, there's a lot of jurisdictional difference over moral rights, which either don't exist at all (much of the US - yes the US has bits of copyright law that vary from state to state), aren't transferrable / waivable, or are simply the same as other rights, so depending on the jurisdiction public domain work may still have strong attribution requirements.
The CC0 license avoids all of these issues and so is generally a better choice if you want to ensure that the rights that the recipient of your code has are the same that they'd have in a common interpretation of what public domain means.
I am TheRaven on Soylent News
Although I am not particularly concerned about anyone taking an unfair advantage of my public-domain-licensed activity, you are certainly making good points and providing some useful information. Thanks.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.