Frequenty Asked Questions
Frequently Asked Questions about Free Software Art
Do people really ask this stuff?
Yes, people really ask this stuff!
How do I make a living if my code can be copied by anyone?
The same way you make it now. If you think you can make more money by closely guarding your code so nobody can use it without permission, by all means dig your own hole of obscurity and irrelevance. It is a bloody lottery, and you may well be the next Toshio Iwai. But this is the real world, where there is only one Toshio Iwai, and most of us will never be published by Nintendo. The question boils down to what are your other choices.
This is the real world where 99,9% of software artists make a living by teaching, doing gigs at festivals, getting commissions from museums and institutions if they are lucky, working for other artists (roboticists, old-school installation artists wanting to update their craft), writing code for commercial software companies, consulting for other type of businesses and waiting tables.
In this world, getting your code to the higher number of people out there is the best way to make yourself a name and live on the ancillary benefits of public recognition. So if you want to make a living as an artist you would do well by promoting the distribution of your work by any means, including making your code Free for anyone to copy it, study it, use it in their own work.
But won’t everybody else then be able to make money off my code?
Yes. Anybody will be able to teach with it, perform with it live, curate exhibitions in which it will be shown. And they will get money for that. And you won’t get any of their money.
But it’s unfair!
Well, put it this way: what would you rather have, 100% of a paltry earning, or 1% of a take more than 100 times bigger? The diffusion afforded by Free Software allows more people’s work to achieve more relevance, and to collect a smaller share of a higher amount of returns from their work.
Let me give you an example using Processing, the Free software development tool for artists: Casey Reas and Ben Fry, the project’s originators, get the sweetest gigs teaching Processing seminars. They are the ones who go to Ars Electronica and collect a Golden Nica, and also derive other benefits from their centrality to a Free Software project that is so important to the Software Art scene. Casey is writing the Processing book, and if there were two books most people would buy his. This is as fair as I can think. If what you are saying is that they should teach all the Processing seminars in the world and write all the books about Processing for all publishers, I don’t think this would be fair for others, and it wouldn’t be fair for them either.
But then other people will retread my work by running my code, and my brilliance will become trite and clichéd!
That is as fair a question as you could have posed, and you are right. But it is also true that if you are successful people will emulate you, copy you, and reduce you to cliché anyway. Seen this way, having your code out there might even raise the standard for emulators (people who emulate other people, not code that emulates other hardware platforms).
But I don’t want anyone to tweak my code a bit and claim it’s theirs!
The 19th Century called; it wants its novelists back. If you wanted a real answer, well, most Free Software licenses do not authorise anyone to say your code is theirs, as copyright notices must normally be maintained. Also, we live a world where hex editors exist and anyone can illegally modify any binary code and say it’s theirs anyway without a Free License; bootleggers do it all the time with old school videogame ROMS. You are complaining about a problem that you might already have if you had shipped any code, and that this project doesn’t do anything to worsen. Jeez!
But people might think my work is bad because someone modified it but it still carries my name!
Free Software licenses can and do include clauses stating non-endorsement by you of what other people do. There are conflicting opinions on whether licenses with clauses requiring that the changed binary has a different name are completely free, but code under such licenses are included in Free Software distributions such as Debian. And you can always publicly ridicule anyone who makes an ass of themselves by spoiling your precious code.
Doesn’t packaging modify the original artwork?
It does and it doesn’t. A Debian package, for instance, contains your original source code in its original pristine form, and all the changes made by the packager are stored in separate files called patches. This way you, your users and art historians of the future can have the best of both worlds: integrity of the artwork and full compatibility of the binary.
But my artwork depends on a very specific and unique piece of hardware!
If your artwork is only true to itself if it runs on a unique and particular piece of hardware that cannot be reproduced, then it is an art installation, not software art according to our definition, it could never be packaged and distributed anyway, and you are reading the wrong FAQ.
And if that specific and unique piece of hardware is an old computer that most people can’t have access to, maybe we can reproduce it under emulation, and have your Software Art work run on that emulator.
Doesn’t emulation modify the original artwork?
That is a bit of a conundrum for which I have two answers; and both of them are “no”:
a) An emulator is something that stands in for hardware. The program can’t tell a good emulator from the original hardware, and neither can the audience/user/operator. We all like vintage machines, but emulation is good for those who can’t afford them, and what goes for videogames goes also for Software Art pieces.
b) Software Art pieces are like theatre plays. Consider this metaphor: software is run the way theatre plays are played. If the code is Shakespeare’s Hamlet, it can be played on any hardware: Gibson+Zefirelli+cinematography, funny_guys+IRC, paper+your_brain, Ethan_Hawke+Bill_Murray+awesomeness, TheRoyalShakespeareCompany+a_theatre.
What if a package is abandoned by a maintainer and ceases to be updated?
An abandoned package can leave the work in a much better state than the original code, and never in a worse one. It contains the original code plus metadata about its conservation history in the form of changelogs and patches. Patches amount to decisions by a conservator, and some of those patches will incorporate changes done for policy reasons, but some of them will be bugfixes in the original code or adaptations for later technology.
So even if your Software Ar work is packaged today, maintained for fifty years and then abandoned, it will be in a much better state when the 2105 arrives and your school experiences a centenary revival.
What if Debian (or Fedora/BSD/Whatever) ceases to exist?
Allow me first to say that Debian or BSD can die, yes. But I can’t envisage any scenario in which Debian or BSD can die without Free Software being made illegal and a worldwide Martial Law being established by hostile aliens from some dorky kid’s imagination.
Seriously, Debian, the *BSDs and RedHat/Fedora will exist, in some form or another, for as long as Free Software exists. They might change names, splinter into derivatives or merge into the One True Distribution, but the benefits of Free Software for Software Art and other code can be realised as long as there is still one Free Software Distribution.
What if Free Software is just a fad?
Then Google and Amazon and Yahoo! will go away and disappear forever, and so will IMDB and most of the world DNS and HTTP servers, and most of the companies rendering FX for Hollywood films and… If Free Software turns out to be a fad, the flying pigs covering the sun will give you enough food for thought that you will forget about your Software Art.
What if Software Art is just a fad?
I don’t think software art will ever go away either. The label might, but generative art, experimental videogames and self-made performing tools are here to stay, among other sub-genres of what is now called Software Art.
I might be wrong too, and Software Art could well be, as the gentleman scholar who asked me this question feared, destined to wane as quickly as it has waxed. In that case its conservation is more needed than everything, and the distro-packaged Free Software Art works will be the best maintained collection of artifacts from this particular period in the history of art and tech.
Isn’t Runme.org already doing this?
They are and they aren’t. They invited me to give a talk, and write this paper, and paid my trip, my hotel and a fee. I am grateful of that, and that is a way for them to support the project. But then they aren’t doing it themselves, because although the aims of a Free-Software-Art initiative overlap with their charter, the overlap is incomplete.
By their own commitment to the form, runme.org select and curate software art under all types of licenses, including non-distributed (just exhibited and performed) and undistributable works. Some of those are undistributable because they are not under free licenses, and some are because… they aren’t even pieces of software as such. The promotion of Free Software among software artists is not their main priority: it is ours.
Free Software Art is about Software Art licensed under Free and Open Source licenses. It is about putting works of Software Art in Free Software distributions, and that task has to be done from inside the distributions themselves. Runme.org could serve as a bridge between artists and distros, but the packaging still has to be done.
Isn’t Jaromil/$name already doing this?
Jaromil is already doing the first part of this: by releasing his own work under free licenses, he is making sure that his work is accepted into distributions such as Debian and Fedora, which will make his work last longer, will help other creators learn and work from his code, and serves also as a great example.
The second part of the process, the systematic packaging of Software Art works inside distros, is something that is just too big for one person. A distribution is not only a CD you can install on your computer, or an online-accessible repository of all their programs. It is also the process of co-ordinated communication and teamwork amongst the thousands of maintainers and original program developers, a process that can survive any given individual’s personal effort.
Aren’t institutional archives already doing this?
No, they aren’t. And they aren’t at so many levels that this answer could easily be an article in its own right.
It is true that many institutions are starting archiving efforts, but merely archiving a software artwork is not the same as conserving it. An archived Software Art piece is not running on a processor, it is merely stored in some mass storage media. It is resting, if not pining for the fjords. Geographical, technical, legal and economical hurdles preclude most people from access to those works, perfectly archived as they may be.
Even well-funded organisations face legal and economical challenges when trying to archive and make available the works they have the rights to. Access to these works for the world at large will still have to wait until they lapse into the Public Domain. We are mortals, and copyright terms nowadays are, by design, much longer than the average human’s life. Archiving is not enough!.
What will this accomplish for Art and Culture?
Culture is that which is shared. Free Software encourages the spreading of ideas, the sharing of code and know-how, and the building on the base of other people’s accomplishments.
Also remember that the practice of art is not just something artists do. Art historians and archivists also play a part, and Free Software Art allows them to keep the works alive in a usable state.
Right, Free Software is good for society as a whole, but what will it accomplish for artists?
Artists will acquire more visibility for themselves by choosing Free licenses for their work. Free Software distros will be able to package their work, and will do so either due to personal interest of individual developers, or with funding from museums and institutions.
Unless a software artists want to package their work themselves, packaging and funding is up to individual distro maintainers and curators. Artists can talk others into packaging their work into Free Software distributions as much as they can talk others into exhibiting their work: that hasn’t changed much.
Won’t this perpetuate the existing models if funded projects can get their projects packaged by paying?
Not really. Under the current model, funded artists get into museums and galleries, and their work gets out to people through their channels and the festival circuit. Unknown artists remain unknown unless they gain access to the institutional scene and circuit.
If artists release their work under Free licenses, it can get into Free Software distributions on equal footing with institutional-funded work. Free Software enhances the opportunities of experiencing all the Software Art in the world to a global audience, and the opportunities of having their work experienced by the world to all software artists.
Put it another way: although making Software Art Free won’t reverse all inequalities, a world with a Free Software Art scene is a more level playing field for new, aspiring and unaffiliated artists than one in which there is no such scene.
Won’t this get a lot of bad art/code into the archives or Free Software distro repositories?
Probably. But bad art abounds anyway. The focus is in getting all art conserved so historians and scholars of the future will be able to understand software art. The purpose of a Free-Software-Art project is not to make a canon, or to select “good” art and have that preserved. The purpose is to allow all Software Art to get produced, distributed and conserved, and let Art History sort the good from the bad.
Your examples are not the ones I would use! I know of more canonical Software Art!
Earlier drafts of this paper used the word “canonical” to refer to my examples (see Terms and Conventions). By “canonical” I never intended to mean “belonging to an artistic-historical Canon”. I meant “standing for all that share the same characteristics”. The main characteristic of the software packages listed, apart from their Software-Art-ness, is that they are under a Free license, and they do not depend on non-free code.
Many works of art could be released under a Free license but still not be freely distributable due to their dependence on non-Free code. Some of them (hacks on commercial games, works where the absence of source is part of the artistic statement) will never be distributable, and we can live with that. This does not mean we don’t like them as artworks, just that we can’t include them in our packaging effort.
But Pure Data and Processing are not Software Art, they are tools!
Agreed, but artists working with Free code need Free tools and freely-distributable runtimes too. Free Software Art is not a purely artistic project, but rather a legal-technical intervention on the Political Economy of Software Art. Thus Pure Data and Processing are included as “source code that will inevitably be part of Free Software Art works”, although they are not works of Software Art per se.
Why don’t you do this project on Windows/MacOS? I code on Windows/MacOS! Linux is scary/difficult/not my cup of tea!
The Free Software Art Project is currently at the proposal stage, and it is being proposed on Free Software distros because they are the ones that allow people to do things like distribute livecds that contain whole Software Art collections in them, or deploy inexpensive machines in schools without paying expensive per-machine licenses for the Operating System alone.
As to you and your code, you don’t have to do anything you don’t want to. This is the beauty of Free Software: if you free your code for whichever platform you work on, you will allow Linux people to do the scary/difficult/not your cup of tea thing and port it to Linux. Or MacOS, or whatever. It really is a win/win situation.