2•4
Data sources, capture systems and lawyers As if it is not already difficult enough to preserve a given piece of software art, some works that are not stand-alone require external sources of data to process. Typical examples are works that use, abuse or mock the content and data generated by web applications and other Internet-based social networks.14 Depending on the data used, it is highly likely that the source is ephemeral. In such a case a capture system is needed that samples this data, so that the artwork can still be shown even when its source of information no longer exists. This seems like a simple solution, and is without doubt facilitated by open standards, but it is hindered by the prevailing licensing and copyright jungle. Thanks to a general effort to raise awareness about proprietary technology and copyright issues, there is a growing number of FLOSS and open standards that are simplifying the way network software communicates, distributes and stores its data, creating greater freedom for its users. Unfortunately a consequence of this effort is a rather ugly bureaucratic monster that is now very hard to avoid: the licensing of this data, with at least a dozen different licenses to choose from.15 At this moment, if someone’s network data is not already owned by corporate groups, users can choose a certain license under which their data can be published, and in some cases this choice is already made for them, without them having the possibility to change it. In this increasingly complex legal construct, using corporate or privately owned data as part of a work of art and capturing this data for archival purposes can be a rather painful process. This flood of licenses introduces the risk of creating an unworkable situation in which archiving can only be done by lawyers and becomes almost impossible. When creating an artwork that uses external data, a certain amount of selection and research is needed prior to its production and release to avoid being limited to the use of artificial, locally generated data when exhibiting the work in the future, unless, of course, the work is meant to be as ephemeral as its data sources. dpkg --install art.deb: refactoring and porting At some point maintaining a work in its original environment becomes impossible because the technology has changed so much that there is no common ground with current software practices. We already see the rapid evolution of computing pushed by ‘cloud’ and mobile technology, and we could also very well argue that the Internet, as we know it, will eventually evolve into something else or simply disappear. A current solution to this issue is to start a migration process in order to port and re-factor the code so it can run on another, more recent platform. In this case the custodian or archivist of