The ASCL is participating in the American Astronomical Society (AAS) meeting that started yesterday in Honolulu, Hawai’i. We have two events, both on Sunday, January 5:
Best ways to let others know how to cite your research software
January 5; Poster 109.12
Software citation is good for research transparency and reproducibility, and maybe, if you work it right, for your CV, too. You can get credit and recognition through citations for your code! This presentation highlights several powerful methods for increasing the probability that use of your research software will be cited, and cited correctly. The presentation covers how to create codemeta.json and CITATION.cff automagically from Astrophysics Source Code Library (ASCL ascl.net) entries, edit, and use these files, the value of including such files on your code site(s), and efforts underway in astronomy and other fields to improve software citation and credit.
The Future and Future Governance of the Astrophysics Source Code Library
January 5, 2:00 PM – 3:30 PM; HCC – Room 301B
Over the past ten years, the Astrophysics Source Code Library (ASCL, ascl.net) has grown from a small repository holding about 40 codes with hand-coded HTML pages maintained by one person to a resource with citable entries on over 2000 codes with a modern database structure that is user- and editor-friendly maintained by a small group of volunteers. With its 20th anniversary now behind it, it’s time to look at the resource and its governance and management. Does its current structure best serve the astro community? What changes would you like to see to its governance? We don’t know the answers to these and other questions! Please join us for an open discussion on the resource and what a new governance model for the ASCL might be.
At lunch yesterday, I was asked in what year the earliest code ASCL has was written (or was first created). I didn’t know off the top of my head, but thought probably in late 70s. (The earliest I ever pursued was from the 60s, IIRC, & though I found an working email address for the woman who wrote it, which was amazing in itself, she no longer had the code, alas.)
But the question got me to wondering, so in a quick look, here’s what I found: three codes that were initially created in 1978:
All of these have undergone further development and are still in use, as indicated by citations to them in papers published this year.
Are these the most long-lived codes we have? Are there codes that were started even before 1978 that are still in use? Probably. Maybe part of the Starlink (ascl:1110.012) code base? Something else?
If you know of one or can find one in the ASCL with a history that goes back further than 1978, please let us know in the replies.
UPDATE, August 21, 2019
Yes! There is one code that goes back even further, to 1972. Warrick Ball (@warrickball), a postdoc at the University of Birmingham (U.K.), replied on Twitter that the stellar evolution code STARS (ascl:1107.008) got its start in 1971, and the 1972 article which describes the code is listed in the ASCL entry for it. The code is still in use and was cited earlier this year. There’ll be dark chocolate heading Dr. Ball’s way as soon as the weather cools off; kudos to him for finding the answer to this question!
ASCL Editor Alice Allen (that’d be me) was interviewed by Nature Toolbox on the last day of the January AAS meeting. The Q&A appears here.
“Each developer holds copyright in his or her code the moment it is written, and because all the world’s major copyright systems—including the US after 1976—do not require notices, publishing code without a copyright notice doesn’t change this.”1
In the recent code sharing session at the AAS 223 meeting, both Alberto Accomazzi and David Hogg mentioned the difficulty of dealing with code that did not carry any license, copyright notice, nor sometimes even author information with it. Such code is difficult to share for transparency, reuse, or expansion. Letting people know whether and how they can use your code and/or share it is a kindness not just to them, but to the community and even yourself, whether you want to retain copyright on the code, choose one of the copyleft licenses, or make your code public domain.
Just beginning to think about licensing and trying to wrap your head around it? TechSoup offers a good introduction on licensing in Making Sense of Software Licensing, and I’ve previously mentioned A Quick Guide to Software Licensing for the Scientist-Programmer from PLoS in our list of general articles that may be of interest to astronomical software users.
If you already know you want an open source license for your open source software (OSS) but don’t know which to choose, the Choose a license site describes different popular open source licenses; it is a good resource for getting an overview of each of them. The Open Source Initiative also offers information on licenses and has a FAQ that is useful for clarifying such terms as copyleft, public domain, open source, and free software in addition to others one runs across when considering licensing.
Interested in retaining copyright within a collaborative free software project? This white paper from the Software Freedom Law Center identifies best practices for doing so. And if you’re thinking about changing a code’s license, you may want to read Bruce Berriman’s informative post, with plenty of resources in it, on his Astronomy Computing Today blog.
What resources have you found helpful for licensing? I am very interested in knowing, and hope you will please share them; thank you!
Peter Teuben moderated today’s BoF, which asked participants to brainstorm ideas for dealing with three categories of concerns: factors which inhibit code sharing, factors which encourage sharing, and overall community issues. The questions were in yesterday’s blog post, along with a link to the introductory slides for the session. One of the questions posed was not selected for discussion; another was proposed by participant William O’Mullane (what tools are available for sharing code?).
Each discussion group discussed one of eight questions; people were given the opportunity to move to another group for a second discussion. Scribes captured the ideas and comments of participants; the resulting documents can be found by following the links below.
My thanks to Jessica Mink, Kimberly DuPrie, Omar Laurino, Mark Taylor, Bruce Berriman, Bob Hanisch, Kai Polsterer, and William O’Mullane for scribing, to Nuria Lorente for tweeting about the session, and to Peter Teuben for his leadership!
Please feel free to add your own comments directly in the documents!
I’m currently working on a report for the Preserving.exe: Toward a National Strategy for Preserving Software summit held at the Library of Congress in May. My head is filled with the reasons and ways (and lack of ways) to save software discussed at the meeting, and by software, I don’t mean necessarily astrophysics codes, oh no! All kinds of software: mainframe HR software and VisiCalc and Doom and old browsers and dBASE and … well, everything.
This has dovetailed nicely, or perhaps alarmingly, with recent readings, including a blog post by Kristin Briney titled How Long Should You Keep Data? and the Retraction Watch post which inspired it, JCI paper retracted for duplicated panels after authors can’t provide original data, about a 2007 paper which recently had one figure retracted because the authors could not provide the data from which it was generated.
Jon Ippolito of the University of Maine was at the summit and wrote about it in his blog post The Ex-files: how long will our software last?
How long indeed? And if you wanted to retrieve data from 2007, would you be able to even if you had the data files? Would you still have the tools available to get into them? In astronomy, probably so; with FITS, astronomy is better off than many sciences. Elsewhere, maybe not.
How long will astronomy software last? That might be unknowable; perhaps a better question, then, is how long should it last?