"It's presumptuous to take a product that was entirely and successfully developed for years under the BSD license and then claim it as a GPL success story because the new maintainers had a moral imperative to relicense."
Something to remember is that the key pain point at this stage of Netatalk's development was that its CNID scheme -- the method by which the server gives a unique identifier to each file/directory and refers to it when communicating with the client -- was broken and frequently led to silent data loss when the server would mistakenly reuse IDs.
This problem was well-known and well-understood. And nobody -- certainly not the big companies who'd fixed the problem in their private forks -- would step up to fix it.
In this context, it's very hard to truthfully characterize Netatalk as "successfully developed for years under the BSD license."
A file server in widespread production use with a well-known data integrity problem? That no one will fix? Call it what you like, but that ain't a healthy project.
You can trump this up however you want to, but how do you weigh your anecdote of a small, abandoned project that now has three active contributors, compared with another University Michigan open source project that underwent a similar transformation -- UMich-LDAP.
UMich LDAP was developed under a BSD-like license. The project stagnated with serious issues that were not fixed. Maintainership was then acquired, the project became OpenLDAP, and it remains highly successful to this day under a liberal BSD-like license, and is even incorporated into commercial products like Apple's Open Directory?
Same original maintainer (umich), same open source maintenance abandonment, better outcome (incredibly widespread use and active development), different license (liberal).
Not trolling. The point here is that given two projects in the exact same circumstance (abandoned), with the exact same absentee maintainers (umich), and equivalent levels of contributions and code quality (low), both went with two different licenses -- BSD and GPL.
The BSD project saw significantly higher contributions. However, that doesn't imply to me that the BSD license usage was a "success story" any more than the GPL usage was. It merely implies that the specific individuals interested in maintaing the projects had entirely different licensing predilections, and there were different levels of community interest in the projects.
Happenstance in the case of OpenLDAP I could accept, though again I'm totally unfamiliar with the project. For all I know they were big Waldo fans and were promised signed first editions of the latest book.
It definitely wasn't happenstance with Netatalk though. Why? Because the community (not just devs) felt some of Netatalk's corporate users had taken advantage of them, and avoiding a repeat wasn't considered a wishlist feature, but a must-have. In that light, simply sticking with the BSD license wasn't an option for them. Switching to the GPL broke the logjam.
You can't just decouple the developer's contributions from the community's determination to address the behavior of the storage vendors. A fork and a license change was a foregone conclusion at that point, the only question was whether it would have bothered the BSD-ites enough for them to keep the UMich tree alive. And the answer was a resounding "no."
The fact is that the developers had to write the code themselves anyway. The switch to the GPL didn't cause vendors to contribute CNID fixes, it merely let those specific developers feel better by sophomorically raising the proverbial middle finger to "thieving" commercial interests while they did free work anyway.
Clearly the developers were interested enough to write the code themselves, in which case the fact that they preferred to fork under the GPL license is just as much happenstance as the interested OpenLDAP developers being happy with the existing BSD license.
It's not as if Netatalk changed the license to the GPL and then attracted a large following of GPL-only developers.
"it merely let those specific developers feel better by sophomorically raising the proverbial middle finger to 'thieving' commercial interests"
Oh man. Fine, you don't like the GPL. We get that. But to say the license change should have been irrelevant is to say that developers should be code-crapping robots with nary an expectation of a social contract. Some devs dig BSD. That's great. But some of us actually like Stallman's four freedoms and in certain situations need to see them guaranteed. Deal with it.
It's not a GPL "success story". You preferred the GPL, you were going to write the code anyway, and you did. At no point in this process was the GPL somehow conveying an advantage beyond satiating your desire to lock out external users/contributors who were potential 'thieves'.
The analogy I gave earlier still fits -- you could have just as easily called new code style conventions a "success story", despite the fact that they aren't the primary driver behind getting something done.
The most audacious aspect of the story is that by locking up future work via the GPL, you've done what you accuse external entities of doing: locking out previous BSD-licensed contributors from your future improvements to the project.
Haha! "Thieves." "Locking out." You're just an anti-GPL zealot. If using the GPL makes me audacious, then call me audacious. Now go troll somewhere else.
"It's presumptuous to take a product that was entirely and successfully developed for years under the BSD license and then claim it as a GPL success story because the new maintainers had a moral imperative to relicense."
Something to remember is that the key pain point at this stage of Netatalk's development was that its CNID scheme -- the method by which the server gives a unique identifier to each file/directory and refers to it when communicating with the client -- was broken and frequently led to silent data loss when the server would mistakenly reuse IDs.
This problem was well-known and well-understood. And nobody -- certainly not the big companies who'd fixed the problem in their private forks -- would step up to fix it.
In this context, it's very hard to truthfully characterize Netatalk as "successfully developed for years under the BSD license."
A file server in widespread production use with a well-known data integrity problem? That no one will fix? Call it what you like, but that ain't a healthy project.