I would argue that a legal license is not the place to talk about citations, in the same way that copyright considerations are not the right tools to handle plagiarism of text in more normal settings. There are two sets of standards that academic publications need to follow, the legal ones and the academic ones, and we're better served by keeping them separate.
As such, the approach I would argue for is to choose a standard legal-considerations license (Apache / GPL / MIT / whatever works for you) and then make it clear that there are additional obligations (not just your wishes) from the academic arena. Thus, a sample readme section might read
This code is © C. Knight, 2017, and it is made available under the GPL license enclosed with the software.
Over and above the legal restrictions imposed by this license, if you use this software for an academic publication then you are obliged to provide proper attribution. This can be to this code directly,
or to the paper that describes it
- C. Knight. How the ACDS software solves every problem. J. Awes. Softw. 12, 37654 (2017).
or (ideally) both.
This separates the two arenas and it makes it easier (hopefully) to deal with problems if and when they do come around. Think about it: if someone comes in and uses your code without attribution (and you somehow find out), what are you going to do?
Are you going to sue? Is it going to work? Or can you at least present such a credible threat of legal action that e.g. their institution caves in? (Unless the answer to any of those questions is "yes", then there's not that much point to trying to come up with fancy legal language to attempt to enforce citations.)
Or, more realistically: are you going to contact their journal editors, show how the paper is plagiarizing your code, and demand a retraction?
The second option is much more likely to work, and it works entirely on non-legal mechanisms, because academia does have additional standards and additional ways to enforce them. The plagiarism might not have broken the license, but you didn't need to sue them to get what you wanted.
And, while we're at this, notice one important feature of the sample readme I just gave: it makes your code easy to cite! By putting this in up-front and making it unambiguous that it needs to be cited and how it needs to be cited, you're setting clear expectations and making it easier for authors to cite you. Some features of note:
- Provide a 'proper' publication to direct the citations. You need them, because of the economies of academia, and plenty of people are happy to ping a paper so long as you tell them which one.
- Ideally, write a software paper that describes the software itself, in journals like the Journal of Open Research Software (or, say, if you can stomach the elsevierness, Computer Physics Communications) or whatever works in your field. If your code is user-ready then a software paper is both useful for those users, and useful for you in capitalizing the work you've done on the software into forms that the ever-slow-moving academic economy of citations can recognize more easily.
- Put your code somewhere easy to find, and make sure it's going to stay there.
- Give every version of your code a DOI. They're easy enough nowadays, at least via github but also directly on Zenodo or Figshare, that there's no excuse not to. And, moreover, they make it easy to locate and download exactly what version of the software was used for any given calculation, making your software more accountable.
Think of this as a stick-and-carrot routine: set up some stern language to set expectations but then prime your users to follow your wishes and make the process as seamless as possible.