In a well designed software system, units of related functionality are organized into modules and classes, which are in turn arranged into inheritance trees, package hierarchies, components, libraries, frameworks, and services. The trade-offs between simplicity versus flexibility and power are carefully considered, and interfaces are designed that expose the key functional properties of a component while hiding much of the complexity of the implementation details. However, over time the design integrity of a well-engineered system tends to decay as new features are added, as new quality attributes are emphasized, and as old architectural knowledge is lost when experienced development personnel shift to new jobs. Consequently, as developers and as users we often find ourselves looking at a piece of functionality or other design artifact and wondering, "Why is this here?" That is, we would like to examine the provenance of an artifact to understand its history and why it is where it is within the current design of the system.In this brief paper, we sketch some of the dimensions of the broad problem of extracting and reasoning about the provenance of software development artifacts. As a motivating example, we also describe some recent related work that uses hashing to quickly and accurately identify version information of embedded Java libraries.Keywords: Software artifact provenance, software analytics, code cloning Paul, it is easy to be impressed by your body of work at a distance. There are so many important and well-cited papers over many years, and the tools and techniques you and your group have contributed have had concrete and demonstrable impact on the research community. But when I spent my sabbatical at CWI, I learned an awful lot from you about running a research group, and getting the best out of talented people. You make it seem so easy and effortless, although I know it is neither. Your management style is low key and encouraging, yet the yield is so high. Perhaps most importantly, I have seen how the young researchers you supervise -many of whom go on to careers in industry -come away with justifiable pride in their efforts, an understanding of exactly how their work fits into the grand scheme of things, and a strong belief in the value of research itself. Surely this is the right way to build an ongoing, vibrant, and collegial community of scientists, engineers, and practitioners.