4 ms·

You can try to explain why in a way which obviates the license, but the reality is that for the players who showed up to the game, the BSD license was a deal br

You can try to explain why in a way which obviates the license, but the reality is that for the players who showed up to the game, the BSD license was a deal breaker. "It's not the GPL!", you say. "It's that the developers preferred it!" Fine. But if your license drives off all your developers, justifiably or not, whether it's morally superior or not, your license has killed the project. Period. The fact that your missing is that the once-successful project was already dead because the primary authors no longer required it and the technology landscape had changed, not because the BSD licensed was used. Given that, I agree that the "correct" license was whatever license anyone actually willing to contribute wanted. The fact that the few new developers interested in contributing were GPL proponents is entirely happenstance and not a success story -- the project reached full maturity with years of development under the BSD license!

Scramblejams 17y ago
"The fact that your missing is that the once-successful project was already dead because the primary authors no longer required it and the technology landscape had changed, not because the BSD licensed was used." "The project reached full maturity with years of development under the BSD license!" Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs (http://news.ycombinator.com/item?id=799429 http://news.ycombinator.com/item?id=799429), but there were grave data-loss and severe locking bugs in Netatalk which persisted from as far back in its BSD heyday as I can recall. In addition, the build scripts were all kinds of broken, and enabling a basic security feature like DHX was sometimes the subject of long web HOWTOs, due to how fraught the software was. Before the project came back to life, I recommended other options to my clients not because Netatalk's function wasn't necessary, but because Netatalk wasn't trustworthy. (Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared.) And the idea that its primary users didn't need to maintain it? Hogwash! Not only were many of the major storage vendors continually shipping it in their devices, but they were shipping privately maintained forks of it with fixes for the issues I mentioned. So it _was_ being maintained, but UMich's source tree was out of luck. The BSD license is why they didn't contribute the fixes back, because they didn't have to. And so Netatalk, always kinda broken, stayed kinda broken. (Yes, Netatalk is pretty much the poster child for BSD projects which have been sorely neglected by their Fortune 500 users. IIRC, Quantum was the sole exception, but don't quote me on that.) Now, it's reasonable to propose that if Netatalk had had a GPL license from the beginning, storage vendors might not have adopted it. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. In addition, there's no need to link to Netatalk in order to build an administration interface around it, something their developers and lawyers have surely always known.
- antonovka 17y ago
  Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems. By the time Mac OS 9/Mac OS X came around, the project's necessity was already diminishing and I (like many others) had long since stopped paying attention. I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer -- we just didn't need an AFP server anymore. Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared. The BSD license is why they didn't contribute the fixes back, because they didn't have to. Vendors had absolutely no reason to use a GPL fork unless new contributors then implemented considerable useful code under the GPL. In other words, making it GPL wasn't the magic that got vendors to use the GPL'd software, providing them more value for free did the trick. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. How many of those actually significantly contribute back to the project? I count three active committers.
  - Scramblejams 17y ago
    "I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems." That's good! Unfortunately I did, and so did many others. A quick perusal of the old mailing lists will turn up plenty of this. We tried a test rollout in a division of a Fortune 50 company, and our backups saved us -- when a user noticed a file was missing, that is. "I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer." Excellent! All patches were appreciated. We could've used more of that. (And we'd have happily accepted patches from the storage vendors, they just wouldn't play ball. I don't think any of us felt the corporations were "evil," just that they were behaving like ... moochers.) "How many of those actually significantly contribute back to the project? I count three active committers." First, that's misleading. The three active committers take patches from others as they please. So to get a true picture you'd need to go through the mailing list and see where all the patches originally came from. And I haven't been involved in the project for some years, so you'll need to go research that yourself. Second, you've completely missed the point. And it's one you should really like. Netatalk entered a sick state because the people who had the desireable patches chose to hold them back. The BSD license allowed them to do so. Then other developers came in and said, we'll commit our patches, but we want a guarantee that those who ship our work will have to do the same. And that was enough to motivate them to make Netatalk fully mature -- every significant enhancement/fix implemented privately became available publicly, and more, thanks to those devs. And what was the outcome for ALL of Netatalk's users? The storage vendors were happy because they could stop maintaining their private forks and just ship from upstream. The users were happy because all these bugs were fixed and they had a responsive place to seek help. The devs were happy because they were assured that they were now on equal terms with the storage vendors. Whether the vendors continued development or not wasn't actually the issue. So everybody won, the users, the developers and the storage vendors. No, the GPL didn't write the code, but the BSD license allowed the code to remain private, and that's where everybody started losing. The GPL assured everyone that that couldn't ever happen again, which, as it turned out in this case, was a necessary precondition to success.

Scramblejams 17y ago

"The fact that your missing is that the once-successful project was already dead because the primary authors no longer required it and the technology landscape had changed, not because the BSD licensed was used." "The project reached full maturity with years of development under the BSD license!" Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs (http://news.ycombinator.com/item?id=799429 http://news.ycombinator.com/item?id=799429), but there were grave data-loss and severe locking bugs in Netatalk which persisted from as far back in its BSD heyday as I can recall. In addition, the build scripts were all kinds of broken, and enabling a basic security feature like DHX was sometimes the subject of long web HOWTOs, due to how fraught the software was. Before the project came back to life, I recommended other options to my clients not because Netatalk's function wasn't necessary, but because Netatalk wasn't trustworthy. (Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared.) And the idea that its primary users didn't need to maintain it? Hogwash! Not only were many of the major storage vendors continually shipping it in their devices, but they were shipping privately maintained forks of it with fixes for the issues I mentioned. So it _was_ being maintained, but UMich's source tree was out of luck. The BSD license is why they didn't contribute the fixes back, because they didn't have to. And so Netatalk, always kinda broken, stayed kinda broken. (Yes, Netatalk is pretty much the poster child for BSD projects which have been sorely neglected by their Fortune 500 users. IIRC, Quantum was the sole exception, but don't quote me on that.) Now, it's reasonable to propose that if Netatalk had had a GPL license from the beginning, storage vendors might not have adopted it. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. In addition, there's no need to link to Netatalk in order to build an administration interface around it, something their developers and lawyers have surely always known.

antonovka 17y ago
Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems. By the time Mac OS 9/Mac OS X came around, the project's necessity was already diminishing and I (like many others) had long since stopped paying attention. I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer -- we just didn't need an AFP server anymore. Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared. The BSD license is why they didn't contribute the fixes back, because they didn't have to. Vendors had absolutely no reason to use a GPL fork unless new contributors then implemented considerable useful code under the GPL. In other words, making it GPL wasn't the magic that got vendors to use the GPL'd software, providing them more value for free did the trick. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. How many of those actually significantly contribute back to the project? I count three active committers.
- Scramblejams 17y ago
  "I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems." That's good! Unfortunately I did, and so did many others. A quick perusal of the old mailing lists will turn up plenty of this. We tried a test rollout in a division of a Fortune 50 company, and our backups saved us -- when a user noticed a file was missing, that is. "I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer." Excellent! All patches were appreciated. We could've used more of that. (And we'd have happily accepted patches from the storage vendors, they just wouldn't play ball. I don't think any of us felt the corporations were "evil," just that they were behaving like ... moochers.) "How many of those actually significantly contribute back to the project? I count three active committers." First, that's misleading. The three active committers take patches from others as they please. So to get a true picture you'd need to go through the mailing list and see where all the patches originally came from. And I haven't been involved in the project for some years, so you'll need to go research that yourself. Second, you've completely missed the point. And it's one you should really like. Netatalk entered a sick state because the people who had the desireable patches chose to hold them back. The BSD license allowed them to do so. Then other developers came in and said, we'll commit our patches, but we want a guarantee that those who ship our work will have to do the same. And that was enough to motivate them to make Netatalk fully mature -- every significant enhancement/fix implemented privately became available publicly, and more, thanks to those devs. And what was the outcome for ALL of Netatalk's users? The storage vendors were happy because they could stop maintaining their private forks and just ship from upstream. The users were happy because all these bugs were fixed and they had a responsive place to seek help. The devs were happy because they were assured that they were now on equal terms with the storage vendors. Whether the vendors continued development or not wasn't actually the issue. So everybody won, the users, the developers and the storage vendors. No, the GPL didn't write the code, but the BSD license allowed the code to remain private, and that's where everybody started losing. The GPL assured everyone that that couldn't ever happen again, which, as it turned out in this case, was a necessary precondition to success.