3 ms·
> but the problem is that they have used a third-party library where they cannot legally release https://github.com/id-Software/DOOM https://github.com/id-Sof
by MayeulC 6y ago
> but the problem is that they have used a third-party library where they cannot legally release
https://github.com/id-Software/DOOM https://github.com/id-Software/DOOM
The DOOM source code was released without sound support due to this:
> The bad news: this code only compiles and runs on linux. We couldn't release the dos code because of a copyrighted sound library we used (wow, was that a mistake -- I write my own sound code now), and I honestly don't even know what happened to the port that microsoft did to windows.
This isn't always a true dichotomy. Any code is better than none, you don't have to release all of it to make a difference (especially if the closed-source library is provided as a shared object). The code could be provided in a non-functionning state, it would already be a lot more helpful than binary patching while relying on disassemblers. A closed-source library can be worked around (stripping functionality), replaced, re-implemented, linked against a blob, reverse-engineered, etc.
- zinekeller 6y agoI actually used Doom as an example of software that has received a great (it might be even the greatest) community help. However, this comment (https://news.ycombinator.com/item?id=25622021 https://news.ycombinator.com/item?id=25622021) has succintly described further the issues of open-sourcing a previously closed-sourced software. One of the most important point here is the fact that some software code are not organized could have a surprise third-party code which required intensive audits. Obivously, in some cases it is simply not economical to do such auditing.