Buying a painting usually means acquiring an identifiable object. In a generative work, the transaction may encompass a specific output, an edition, the high-resolution file, the source code, an executable, specific equipment, the right to run the system, or a token associated with any of those elements. These are not equivalent. If the sale does not specify what is delivered and what uses are authorised, ambiguity resurfaces when attempting to exhibit, preserve, lend, or resell the work.
The first distinction is legal. Under Spanish legislation, acquiring the medium in which a work has been incorporated does not, in itself, transfer its exploitation rights. The assignment of those rights must define the modes of use, the duration, and the territory; if the duration is not indicated, it is limited to five years, and if the territory is not specified, it is limited to the country where the assignment takes place. Ownership of the file, the equipment, or the token and the title to the rights of reproduction, distribution, public communication, or transformation are distinct planes.
The second distinction affects the very identity of the work. If only an output is bought, an image is preserved, but not necessarily the system that produced it. If only the code is delivered, it remains to be determined which versions, parameters, seeds, dependencies, and results form part of the work. It is also important to know whether each run is an authorised copy, a variation of the same work, or mere working material. There is no universal answer: it depends on the artistic and contractual configuration of each case.
Generative editions add another layer of difficulty. The output may be fixed before the sale, generated at the moment of acquisition, or selected afterwards from several results. The number of editions, the selection procedure, and the possibility that the artist may continue to produce images with the same system affect the promised scarcity, but they do not, in themselves, form an autonomous legal category. They must be described in the contract, the certificate, or the documentation of the work.
Museums that preserve software-based art do not treat these pieces as simple files. The Guggenheim recommends obtaining, depending on each work, the assets needed to run it, the source code or original project files, libraries and plug-ins, hardware and software requirements, installation instructions, external services, and reference audiovisual documentation. The Tate works with standardised documentation, disk images, emulation, metadata, and identification of components at risk. This does not mean that every acquisition always incorporates all those elements, nor that the museum automatically receives all rights: it demonstrates that preservation requires defining the system, documenting it, and agreeing on which future interventions will be admissible.
For a private collector, the documentation may be simpler, but it should resolve at least these questions:
- What constitutes the work: a specific output, an edition, the generative system, or a combination of those elements.
- Which files, code, equipment, dependencies, seeds, parameters, and instructions are delivered.
- Whether the buyer may run the system again and with what limitations.
- Which rights of exhibition, reproduction, lending, migration, emulation, or technical adaptation are authorised.
- Whether a preservation copy may be made and who may intervene when the original environment fails.
- How many authorised copies or outputs exist and whether the artist may produce others with the same system.
- What happens upon resale: what is transferred, what must be deleted, and what documentation accompanies the work.
- What access depends on: servers, accounts, hosting contracts, libraries, APIs, or third-party platforms.
A token may serve as a record of provenance, an access mechanism, or an element of the transaction, but its mere possession does not allow one to deduce which files, usage powers, or intellectual property rights have been acquired. That is determined by the documentation linked to the sale. For the same reason, announcing "includes the code" is not sufficient: the version delivered, the dependencies, the conditions for running it, and the powers granted to the buyer must be stated.
The useful question is not whether one has bought an image, a program or a token in the abstract. It is what set of objects, files, knowledge and permissions makes it possible to identify the work, display it today and preserve it when technology changes. How to record those elements and how to delimit an edition is covered in the guides on what to document in a generative artwork and how to edit a generative artwork.
About the open conversation
This text distinguishes legal and technical data from my interpretation and does not constitute legal advice. If you collect, sell, or preserve generative art and wish to clarify a detail or discuss this reading, this notebook remains open: write to me.
The author's relationship to the cases
I have digital work in my collection, the Esteban-Ruiz Collection, and these issues affect me as a collector. I have no relationship with the museums or the artists cited.
Sources
- Official State Gazette, consolidated text of the Law on Intellectual Property, arts. 17, 43 and 56.
- Guggenheim, The Conserving Computer-Based Art Initiative.
- Guggenheim, Acquisition Checklist: Computer-based Artwork with Artist-provided Computer.
- Tate, Software-based Art Preservation.
- Tate, Time-based Media Conservation.