Juan A. Esteban

Contemporary artist and independent researcher.

Illustration of Juan Esteban’s runic monogram rendered in a three-dimensional architectural style within a frame, set against a light background.

Software licences and artistic works: what each licence covers

An artwork made with code may combine a computer program, libraries, typefaces, images, data, documentation and outputs. A single LICENSE file does not merge these layers into a single artwork or settle all of their permissions.

This guide explains how to separate these components before sharing, selling or delivering the project. It does not determine the compatibility of a specific combination: one must review versions, architecture, distribution methods and full texts. If you also wish to prepare the technical package, consult How to prepare creative code so that it can run again.

What the law protects as software

Articles 95 to 104 of the Intellectual Property Law form the specific regime for computer programs. Article 96 defines a program as any sequence of instructions or indications intended for use in a computer system and includes its preparatory documentation; it requires originality, protects any form of expression, successive versions and derivative programs, and excludes from copyright protection the ideas and principles upon which its elements are based, including those of its interfaces.

Article 97 addresses ownership: when an employee creates a program in the exercise of their duties or following the company's instructions, the exploitation rights correspond to the latter, unless otherwise agreed. Article 99 regulates the rights of reproduction, transformation and distribution, and presumes that the licence to use a computer program is non-exclusive and non-transferable. Article 100 sets limits for the lawful user, such as backup copies, observation and testing of functionality, and interoperability. Do not simply apply the rules for an image or text to software.

Six distinct layers

  1. The artist’s own code. Clarify authorship and ownership, particularly regarding collaborators, commissions or employment relationships.
  2. Dependencies. These retain their licence even when contained within your repository.
  3. Assets. Typefaces, images, audio, video, models and data may be subject to different permissions.
  4. Interface. The specific expression, such as icons, text and design, may be protected separately; the underlying ideas and principles, however, are not.
  5. Documentation. Manuals and fact sheets may be subject to a content licence.
  6. Artistic output. It is not automatically covered by the licence of the computer program that generates it.

MIT

The MIT licence grants permission, free of charge, to use, copy, modify, merge, publish, distribute, sublicense and sell copies of the software. It requires the inclusion of the copyright notice and the permission notice in all copies or substantial portions of the software, and excludes all warranties.

It is permissive, yet it does not override dependency licences nor does it grant rights over trademarks, data or materials not covered.

Apache 2.0

Apache 2.0 distinguishes between source form and object form, defines derivative works and requires, upon redistribution, the provision of a copy of the licence, clear indication of modified files, the preservation of copyright, patent, trademark and attribution notices and, if a NOTICE file exists, the inclusion of its notices. It includes an express grant of patent rights within its terms and provides for termination if the recipient initiates patent litigation. Do not summarise it as "MIT with patents". Compatibility with other licences depends on specific versions.

GPL: selling is permitted

The GPL is a copyleft licence. The GNU FAQ indicates that the GPL permits the sale of copies at any price. When distributing object code or an executable, the conditions of the applicable version must be met to provide the corresponding source code; a written offer is one of the methods provided for in certain circumstances, not a universal rule for all distribution.

Not every use of a library produces the same result. The GNU FAQ, which expresses the organisation's own interpretation of its licences rather than a court ruling or a universal legal rule for every architecture, maintains that static or dynamic linking with GPL code may result in a combination subject to the GPL, with an exception for certain system libraries. According to those same responses, the LGPL and AGPL have different rules: the LGPL is more flexible regarding dynamic linking and the AGPL adds obligations when software is offered over a network. Do not confuse these with the GPL.

Regarding outputs, GNU maintains that, as a general rule, the output of a program is not covered by the program's copyright, and that the situation may change if the output incorporates protected parts of the program itself, such as full text screens, graphics or audio. Selling an image generated with a GPL program does not, therefore, necessarily render the image GPL software, but it is advisable to verify which materials from the program are incorporated into the output. Delivering the program, an executable or a combination may indeed trigger obligations.

Creative Commons is not the recommended licence for code

Creative Commons advises against using its licences for software. According to its FAQ, they do not contain specific terms regarding source code distribution, do not address the patent rights that many software licences cover and are not compatible with major software licences.

Creative Commons licences may be applied to documentation, separate artistic assets such as images or music, and other content. Specify which files each licence covers:

  • code folder: Apache-2.0;
  • artistic assets folder: CC BY 4.0;
  • documentation folder: CC BY 4.0;
  • typefaces: refer to a THIRD_PARTY_LICENSES file;
  • outputs: specific conditions.

This is an example of separation, not a combination recommended for all projects.

Creative Commons notes that CC0 may be applied to software, although it recommends studying its implementation and the issues of patents, warranties and rights that cannot be waived in each jurisdiction. Its specific FAQ, last edited in 2016, clarifies that CC0 does not grant a licence for patents and that it had not been approved by the Open Source Initiative. CC0 is not a software licence equivalent to MIT, Apache or GPL: it is a tool for dedication to the public domain and waiver of rights, to the extent permitted by law.

Open source does not mean without conditions

According to the Open Source Initiative FAQ, all open source software may be used for commercial purposes, and open licences may not discriminate by field of endeavour or restrict the use of the program. They may, however, impose conditions such as acknowledging the authors or, in the case of copyleft licences, providing the source code and maintaining the same licence for any distributed modified versions. "Commercial" is not synonymous with "proprietary".

Compatibility

Record the following for each component:

  • exact licence and version;
  • SPDX identifier;
  • holder and notice;
  • form of combination;
  • modifications;
  • intended distribution;
  • source that must be provided;
  • restrictions, patents and trademarks.

Do not infer compatibility simply because two licences permit commercial use. "GPL" and "open licence" are insufficient descriptions.

Selling a work that uses open source code

You may sell a work created with open software. The decisive factor is what you deliver:

  • an image may not distribute the program;
  • an executable may require notices or source code;
  • the code carries its own licences and those of its dependencies;
  • a work served over a network may trigger specific conditions, such as those of the AGPL;
  • third-party assets require redistribution permission.

In the contract, separate the work, medium, exhibition copy, program and licence.

Licensing of outputs

If you wish to permit the exhibition, reproduction or transformation of outputs, identify them in a specific licence or clause. Consult how to authorise the reproduction of a work.

Do not grant an open licence for materials whose rights you do not control. A licence only conveys the permissions available.

Credits and records

Maintain LICENSE, THIRD_PARTY_LICENSES, NOTICE, AUTHORS, changes, asset licences and output conditions. MIT requires the inclusion of the copyright and permission notice in copies, and Apache 2.0 requires the provision of a copy of the licence: a link that may change does not, in itself, satisfy these obligations (interpretation).

The licence grants permissions; it does not replace proof of authorship or the registration of a work. If you publish the repository, also review the reservation of rights against text and data mining.

Checklist

  • Code, dependencies, assets, documentation and outputs are separated.
  • The exact licence and version of each element are recorded.
  • Ownership of the artist’s own code has been verified.
  • The intended distribution complies with the dependencies.
  • Notices, licence, changes and NOTICE are preserved.
  • The combination was reviewed, not merely each isolated package.
  • The sale is not confused with an assignment of rights.
  • Source, executable and output are distinguished.
  • Artistic assets have their own permissions.
  • Secrets, credentials and personal data are not published.
  • Critical compatibility has received specialist review.

Further reading

Sources

Status: Verified. Review: 11 October 2026. General information, not a legal analysis of a specific combination. If you find an error, write to me.

Discover more from Juan A. Esteban

Subscribe to receive the latest posts by email.

Español English (UK)