GPL is a license designed primarily for software, but it can be used for non-software. The license text has many mentions of "source code", which is ambiguous for non-software.

GNU/FSF claim that GPL can be used for non-software, "as long as it is clear what constitutes the “source code” for the work".

The GNU GPL references the “source code” of a work; this “source code” will mean different things for different kinds of information, but the definition of “source code” — provided in the GNU GPL — holds true in any case: “The source code for a work means the preferred form of the work for making modifications to it.


(bold is mine)

Unfortunately, no concrete examples are given.

Using common sense, I interpret this "preferred form" to mean for example PSD/XCF files for images, and DAW project files and/or MIDI files for audio/music. However, life experience has taught me that law and common sense seldom overlap.

Are there any notable examples of GPL being used in this fashion - to preserve access to the project files? Or any authoritative persons clarifying this issue?

Furthermore, unlike software, non-software can often be manipulated without "source code", which raises this hypothetical: what if I take a lone, GPL-licensed image file, create a derivative using Photoshop, am I required to share the PSD file under GPL, in addition to the derived exported image?

  • 5
    That's why the GPL is simply not an appropriate license for anything except software. Its writing is heavily focused on this use-case and trying to use it for media is trying to fit a square peg into a round hole.
    – Philipp
    Commented Jul 1, 2015 at 14:10

3 Answers 3


Think of 'source' as something which is created in a manual process and then fed into an automated process to produce the final artifacts.

Consider an open design for a PCB licensed under GPL.

The 'source' in this case would be the schematics, which are fed in to applications that generate the solder masks, pick-n-place instructions, drilling templates, bill-of-materials, and all the other artifacts used by a modern PCB manufacturing process.

Consider a GPL-licensed design of an object meant to be built using a 3D printer. Again, the detailed mechanical specifications act as the 'source' for the printer.

Consider an animated movie, generated using something like blender, and licensed under GPL. Again, the inputs which allow blender to render all the frames of the movie creating the final product act as the source.

Source code for software is edited using a text editor or IDE. The source for non-software items may not be human readable, and may be edited by advanced layout programs, or 3D graphics programs, but it is source 'code' nonetheless.

  • 3
    You could conceivably go so far as to define "source code" simply as a set of precise instructions for reproducing something, whether or not a "machine" is used. Cooking recipes are a common analogy. However, isn't necessarily how the GPL should be interpreted. I like your interpretation but I don't see that you've shown it to be correct.
    – Air
    Commented Jul 1, 2015 at 22:17
  • Not trying for correctness, just examples of how 'source' doesn't need to be 'code'
    – kdopen
    Commented Jul 1, 2015 at 22:27
  • @Air Your definition is very good. Some companies try to get away with making some code Free Software, but making it cumbersome to build. By your interpretation, they should distribute a build documentation (or script) as part of their source code, which should be at least as good as was they use internally. Unfortunately, this view not shared everywhere, so few people insist on that.
    – vog
    Commented Aug 6, 2015 at 16:44
  • @vog Well, to be fair, there are more and less precise recipes. In some cases it is understood that both parties have the expertise required to understand what is not explicit in the recipe. It's a matter of degree - you wouldn't include a copy of K&R with your free software, any more than I would attach Joy of Cooking to a muffin recipe. The level of precision of the recipe is influenced by other concerns than the desire to "get away with" something.
    – Air
    Commented Aug 6, 2015 at 17:02
  • @Air I disagree strongly with that view. Build processes can and should be automated away. However, if the software company gets most of their revenue with support and teaching paid by hours, there's often missing lack of incentive for automating that kind of stuff. On the other hand, I agree that you can't demand the publication of build scripts / makefiles that were never written. That's what I mean with they "get away" with it: 1) They don't fully automate that stuff, 2) they provide crappy build docs, and 3) get paid for explaining/"teching" that crap to others.
    – vog
    Commented Aug 6, 2015 at 21:48

From GPL FAQ:-

Why don't you use the GPL for manuals? (#WhyNotGPLForManuals)

It is possible to use the GPL for a manual, but the GNU Free Documentation License (GFDL) is much better for manuals.

The GPL was designed for programs; it contains lots of complex clauses that are crucial for programs, but that would be cumbersome and unnecessary for a book or manual. For instance, anyone publishing the book on paper would have to either include machine-readable “source code” of the book along with each printed copy, or provide a written offer to send the “source code” later.

Meanwhile, the GFDL has clauses that help publishers of free manuals make a profit from selling copies—cover texts, for instance. The special rules for Endorsements sections make it possible to use the GFDL for an official standard. This would permit modified versions, but they could not be labeled as “the standard”.

Using the GFDL, we permit changes in the text of a manual that covers its technical topic. It is important to be able to change the technical parts, because people who change a program ought to change the documentation to correspond. The freedom to do this is an ethical imperative.

Our manuals also include sections that state our political position about free software. We mark these as “invariant”, so that they cannot be changed or removed. The GFDL makes provisions for these “invariant sections”.

In above quote, text (For instance,...) is bolded by me.


The GPL includes the following definition:

The "source code" for a work means the preferred form of the work for making modifications to it.

What's the preferred form for making modifications? You might deduce what your project's source code is by going through the following sequence:

  1. Consider the work that is supplied to the recipient.

  2. Consider a range of possible changes that recipient might want to make: move images around, give a character different movements in an animated movie, alter text, change the order of sections in a document, bring obscured background elements to the foreground unobstructed, change a single instrumental track in an audio file, etc.

  3. What format of the work would make those editing tasks easiest?

Usually, the answer will be obvious: it's the layered Photoshop or GIMP file you used to create your finished image, or the word processing document you use to create your PDF output, or the multi-track audio-workshop file you compressed down into only a two-band stereo output. For a web page with images, the source code would be non-obfuscated HTML and the most-easily editable versions of the images.

Sometimes (I'd guess rarely) the answer is not obvious. For example, the Battle for Wesnoth community has had a non-trivial discussion about whether MIDI or OGG constitutes the preferred form for making modifications, because MIDI is closer to editable "source" but exactly how a MIDI will render to a proper sound file will vary by MIDI environment. Aside from strange edge cases like this, it should be obvious what document format is most appropriate for making modifications.

Other noteworthy cases:

  • If the work has always been in a form that is not friendly to making modifications (e.g., a complex image made in a simple Paint-style program without layer information, or a binary executable written by hand by a very clever hacker with a hex editor) then that is the best "source" that exists and is sufficient: that was, apparently, the original author's preferred format for creating and modifying the work.
  • Conversely, if the project has always been in a format most conducive to making modifications (e.g., human-readable HTML for a website), then the work is composed entirely of source code.
  • For the simple-image-in-Photoshop hypothetical, if the Photoshop file has metadata what would make it easier for a person to perform edits, that should be preserved: e.g., if you specified gradients/regions for color alterations and that information is available as separately-editable layer-like feature, then certainly that would be preferred for making modifications. If the transformation you did merely altered pixels and has no associated metadata or layer information, then the Photoshop file affords no advantage over the raw image in terms of ease of modification. However, unless I were absolutely sure that no such editing-friendly metadata existed, I would err of the side of caution and distribute the PSD file as well.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.