I'm a tech, not an academic, but I see it as part of the broader problem of science reproducibility. Software plays a huge huge part in modern science publishin

I'm a tech, not an academic, but I see it as part of the broader problem of science reproducibility. Software plays a huge huge part in modern science publishing and, in the case of data derived using proprietary software, it's expected we just trust the results - that the software is infallible. The comment "We have opted not to make the code public." really gets my goat, but is probably less because they sampled community opinion and found it wanting but more because it's just plain inconvenient or unknown how to publish software. Authors are not actively discouraged from publishing details about the software used (in journals in general) or including copies in the supplementing files, but the process typically has the editors (who guide the authors through the submission process) paring back the submission to just bog standard and familiar media types: image, audio, video, pdf, etc that are known quantities and can be nicely formatted in the final pdf. My small contribution to combating this has been encouraging our editors at eLife to be alert to authors using bespoke or modified software and capturing that software at a specific revision at the time of publication (https://github.com/elifesciences-publications https://github.com/elifesciences-publications) and making sure it meets some basic criteria, like being openly licensed. I'm hoping this effort will help resist general entropy and bit-rot, software moving on or getting lost, licence changes and the overall mandate of eLife to improve science publishing, which means reproducible results and software amenable to audit.