Tag Archives: ethics

The GPL is for users

· 9 Replies

The General Public License (aka the GPL) is for users. This observation seems so obvious that it needn’t be stated. But for those who develop software licensed under the GPL (like WordPress and most related projects), it’s a fact that should be revisited every now and again, because it has all sorts of ramifications for the work we do.

Users versus developers

What do I mean when I say that the GPL is “about users”? Who are “users”? We might draw a parallel between software and books. Books have readers (hopefully!), and they have authors. Authors read too; proofing is a kind of reading, of course, and one might argue moreover that reading is an inextricable part of writing. Yet when we talk about a book’s “readers” we generally mean to discount its author. ‘Readers’ in this sense is a gloss for ‘just readers’, that is, those readers whose relationship to the book is limited to reading. The situation with software is more complex, but roughly the same distinction can be made between users and developers. ‘Developers’ refers broadly to those people involved in the conceptualization and implementation (and also often the use) of a piece of software, while ‘users’ refers to those who just use it.

My reading of the GPL is that it’s heavily focused on users. (References to the GPL throughout are to GPL 3.0. You can find older versions of the licence, such as version 2 that is shipped with WordPress, on GNU’s website.) Take the opening line from the second paragraph of the Preamble:

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.

Here as elsewhere in the text of the GPL, no real distinction is made between “you” as it refers to developers and “you” as it refers to users. Closer analysis makes it pretty clear, though. Take, for example, the freedoms that are purported to be taken away by proprietary licenses: the freedom to “share and change” software. Developers – or, to be more specific, license holders, who are generally either the developers themselves or, in the case of work for hire, the people who paid for the software to be developed – generally do not restrict their own rights to share and change the software that they create. Instead, restrictions are imposed on others, the (“just”) users.

Similar reasoning applies to the core freedoms that are outlined in the Free Software Definition, a sort of unofficial sister document of the GPL, also maintained by the Free Software Foundation. The four freedoms:

  • The freedom to run the program, for any purpose (freedom 0).
  • The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

On the face of it, freedoms 1 and possibly 3 are focused on developers, in the sense of “those who are able to write code”. But, with respect to a piece of software that they did not write and whose license they do not control, coders are just regular users (in the same way that Vonnegut may have been a “reader” of Twain). All four freedoms, indeed, are user-centric. The license holder, almost by definition, doesn’t need permission to use the code (0); the developer doesn’t need to study the code to know how it works (1); owners can redistribute at will (2); owners can modify and redistribute at will (3). It’s only in the context of users – those who did not write the software – that these freedoms need protection in the form of free software licenses like the GPL.

The GPL does make a few explicit provisions for the developer/license holder:

For the developers’ and authors’ protection, the GPL clearly explains that there is no warranty for this free software. For both users’ and authors’ sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

The second provision is a sort of legal convenience; the first intends to ease what may otherwise be a prohibitive consequence of the core freedoms guaranteed by the rest of the GPL. Both are important and valuable. But it seems fair to say that they are secondary to the user-focused parts of the document, at the very least because they are motivated by other parts of the document, while user freedom needs independent justification.

There’s no question that the people who bear the brunt of implementing and upholding the GPL are software developers. In that sense, the GPL is very much “for” them. But, in a broader sense, that’s a bit like saying that school is “for” the teachers because the teachers play a key role in education. Schools are for children; they provide the motivation and justification for the whole enterprise. Similarly, the GPL is for users; if everyone wrote their own software, and there were no “just users”, the GPL (or any free software licenses, or any licenses at all) would be unnecessary.

Sacrifice

If I buy a pizza, I trade ownership of money for ownership of pizza. Once I have the pie, I can do pretty much whatever I want with it. I can eat the whole thing myself, I can share with a friend or two, I can throw it on the sidewalk. I can save the pizza in hopes that prices rise so that I can make a quick buck in a resale, I can retail off the individual slices, or I can give the whole thing away. I can’t use the pizza to solve world hunger (not because I’m not allowed, but because it’s not possible); I can’t use the pizza as a deadly weapon (not because it’s impossible, but because I’m not allowed). In short, ownership bestows certain rights. Not all rights – I don’t have the right to murder with the pizza, or to do impossible things with it – but many, even most of them.

The situation is more complex with intangible goods; especially those, like software, which can be reproduced without cost or loss. Copyright law in the United States (so far as I understand it; IANAL etc), in accordance with the Berne Convention, grants rights over intellectual and creative works to the authors automatically, at the time of creation. Thus, if I write a piece of software (from scratch – set aside issues of derivative work for a moment), I am granted extensive rights over the use and reuse of that piece of software, automatically, in virtue of being the author. That includes copyright – literally, the rights related to the copying and distribution of the software. In short, the default situation, for better or for worse, is for the developer – and only the developer – to possess the rights and freedoms enumerated by the Free Software Definition. By default, nothing is protected for the users.

Free software licenses exist in order to counteract this default scenario. But keep in mind what that means: When a developer releases a work under a license like the GPL, certain freedoms and rights are granted to users, which necessarily restricts the freedoms of the developer. The GPL admits as much:

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

“Responsibilities” is a nice way of putting what is essentially the stripping of certain rights (in the same way that, once you become a parent and thus responsible for your child’s well-being, you no longer have the right to go on a week-long bender). Once the software is released under a GPL, the original author has lost the right of exclusive distribution of the original software. Subsequent developers, those who modify and redistribute the software, are similarly restricted.

It’s a trade-off. Users get certain rights (viewing source code, copying, modifying, redistributing) because the developers have given up the default right of exclusivity. Examined in itself (without reference to subsidiary benefits for the moment), the trade-off is clearly made for the benefit of the users, and involves sacrifice on behalf of the developer, sacrifice which is usually quantified in monetary terms (Bill Gates didn’t get rich by writing open source software), but could also be associated with pride in being the sole author, etc. There are, in addition to this, secondary sacrifices involved in free software development (loss of identification with the software because of modifications or forking, less guaranteed income than in a proprietary development shop, increased support requests that come from wider use of a free-as-in-beer product [though the GPL explictly says that you can charge what you want, and that no warranty is implied]). To some extent, these secondary sacrifices can be mitigated by the realities of the market, and are anyway subject to the particulars of the scenario in which you find yourself. But the core sacrifice – giving up exclusivity over distribution – cannot be separated from free software licenses.

Software licenses are political documents

Developers have all sorts of reasons for releasing software under free software licenses like the GPL. A few, off the top of my head:

  • You want to modify and redistribute existing software that is GPLed
  • You want to distribute somewhere that requires GPL-compatibility, like the wordpress.org plugin repository
  • You believe that forkability and other GPLy goodness makes for a better product
  • You want to develop for a platform, or contribute to a project, that requires GPL compatibility

I classify these reasons as prudential, in the sense that they are focused on the material benefits (money, fame, better software) that you believe will come from developing under the GPL. All of these reasons are great and important, and many of them have motivated my own work with GPL-licensed software. Taken together or even individually, it’s easy to imagine that these (and other) benefits would outweigh the sacrifice involved in giving up exclusive distribution rights over your work.

There’s another kind of justification for releasing under the GPL: you endorse, and want to advance, the political and moral ends that motived the creation of the GPL. The GPL assumes that it’s a good thing for users to have maximal freedom over their software:

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

The assumption here is that “greatest possible use to the public”, and by the extension the good of the public, is something to be actively pursued – a moral claim par excellence.

And, among free software licenses, the GPL is perhaps the most explicit about the ways in which user freedoms (and thus the greatest good of the public) should be guaranteed and propagated. The “viral” nature of the GPL constitutes a kind of normative statement about the value of user rights over developer rights, which goes beyond other free software licenses that do not share its viral nature. The difference might be summed up like this. Alice and Bob are coders, and Carol is a potential user of the software. If Alice writes a piece of software and licenses it under a free software license like those in the BSD tradition, Bob can fork the software, make a few changes, and sell it to Carol under any terms he’d like – he can compile a binary executable for distribution, without making the source code available, converting his fork into closed-source, proprietary software. If Alice licenses the software under the GPL, on the other hand, Bob can still modify and sell to Carol, but he may not change the terms of the original license – in particular, the source code must be made available for further modification and distribution.

The normative aspect of the difference is in the value that each license scheme ascribes to the rights and freedoms of various individuals involved. BSD is more permissive with respect to Bob; GPL limits his ability to license the derivitive work as he pleases. GPL is more focused on Carol, and protecting her – and other “just users” like her – at the cost of some of Bob’s freedoms. (The GPL is for users.) One might express the difference in political terms thus: the GPL is more liberal, and less libertarian, than the BSD. Users, who are on the weak end of the power spectrum when it comes to software, are protected under the GPL, in the same way that society’s underprivileged and weak are often the focus of political liberalism. On this picture, licenses, like laws more generally, are designed in part to create the restrictions necessary to protect the positive freedoms of a vulnerable population.

For developers who agree independently with the normative principles underlying the GPL, its moral benefits can outweigh the sacrifices it entails. Such a justification is the starting point for Stallman and the Free Software Foundation (see, for example, the FSF’s about page). You may, of course, foreground other aspects of free/open-source software when justifying your licensing. I’ve listed some justifications above, and entire movements have sprouted to focus on prudential, rather than moral, justifications for open source development.

But – and here’s the rub – licensing your work under the GPL constitutes an endorsement of its moral justifications, even if it’s not (from a cognitive point of view) what motivated you personally to apply the license. If you choose a free software license for prudential reasons, you are not justified in complaining when your project is forked. If you choose the GPL for prudential reasons, you can’t altogether disavow the inherently altruistic underpinnings reflected in the license’s preamble. Put another way: Among other things, software licenses are political documents, and it’s incumbent upon developers to understand them before adopting them.

It’s important for developers to think carefully about this before diving into a license. My own take is that the original motivation for free software – that user control over the software they use is fundamental to their autonomy – becomes truer every day, as more and more of our agency is mediated through software. For that reason, licenses like the GPL are ethically important, at least if your worldview depends (as mine does) on respecting the agency of other human beings.

This post was prompted by a recent post by Ipstenu. Much of my thinking on the matter is clarified and inspired by the first few chapters of Decoding Liberation: The Promise of Free and Open Source Software, a book about free software written by philosophers/computer scientists Samir Chopra and Scott Dexter. You can (and should) buy the book here.

Hub-and-spoke blogging with lots of students

· 16 Replies

Inspired by some of the blog posts that have recently come through my reader on the topic of classroom blogging, I thought I’d throw my hat in the ring. In particular, I wanted to respond to some of the concerns raised in the comments to Mark Sample’s post regarding the “hub and spoke” method, where students maintain individual blogs that are linked through the teacher’s hub blog. Can this model work with a large number of students?


Not quite drowning | cc licensed flickr photo shared by Jaako

Over the course of several semesters using such a model in Intro to Philosophy and Intro to Ethics classes, I’ve hit on a couple of techniques that have made it easier to deal with somewhere between 60 and 70 students (from two sections of the same course) blogging roughly twice per week. Here are some thoughts, in no particular order.

  • Groups – On the right hand side of http://boonebgorges.wordpress.com, you’ll find a link to the blog of each student in the class. The links are organized into groups of five or six students each. The students’ first assignment at the beginning of the semester is to register for a wordpress.com blog and to email me its URL. As these URLs land in my inbox, I number them 1-7 (in sections of 35 or so students, seven seemed like the right number of groups). The blogroll is then split into groups, using Wordpress’s link categories.

    In practice, the groups serve several purposes. First, membership in a group give individual students a more focused and manageable reading load. That’s because the syllabus requires students to read only the blog entries of their group members. As the semester progresses and students get to know each other, their blog reading (as evidenced by, among other things, the scope of their commenting) increases dramatically, but this is self-motivated rather than required. Second, focused groups mean that each student has a guaranteed audience. If all students were assigned to read all blogs, then only the most popular blogs (or those appearing first in an alphabetical list!) would get regular readers and commenters. Groups make sure things are more spread out. Third, dividing the class into blog groups provides ready-made groups for in-class work as well. I’ve found that the camaraderie that forms in a blog group (see these comments for an example of what I mean) translates very nicely into in-class work, and vice versa.

  • “In the blogs” and classroom integration – When my students first started blogging a few years ago, I would make a habit of finding a few posts that caught my eye before most class sessions to discuss with the class. Bringing the blogs to the center of the classroom experience does a couple of things: it highlights good student work (I try to talk about everyone’s blog at least once per term), it creates the impression that the blogs really are a crucial part of the class, it’s a good way to revisit issues that went either unexplained or underexplained in the previous session, and it makes future blog posts better when blog authors believe that their work might be discussed in class.

    Since I was going through the process of picking out and making notes about interesting posts anyway, I figured I might as well make my notes available to students before class. So I started writing “In the blogs” posts, digests of what caught my eye that day, and a brief description of why. I’d generally try to post this at least twelve hours before the class session where the posts would be discussed. After a few weeks of doing this, I noticed that many students had actually read the posts that I blogged about (though I didn’t require it). Comment counts on those posts also tended to be a bit higher.

    Near the beginning of the term, I deliberately overdid it with In the blogs, in order to give students the sense that the blogs were really significant intellectual spaces and important to the class. See, for example, digests from the beginning, the middle, and the end of the semester.

  • RSS and grading – The purpose of the blogs in these classes is to give the students a space for reflection that they take seriously (publicness does this) but that is low-stakes enough to allow for risk-taking and experimentation. Thus my pass-fail grading: if the blog post is on time, and demonstrates even a modicum of thought, you get full credit. The happy byproduct of this arrangement is that a close reading of every blog entry and comment is not necessary. Early in the semester I try to read every post relatively carefully and comment on most of them – largely so that I can model the kind of thoughtful but not-too-formal commenting that I’d like the students to adopt – but as the term progresses the community generally takes care of itself pretty well. By the end of the semester, I hunt and peck my way through the blogs at my leisure, much like the students do.

    I used Google Reader to keep track of the students’ blogs, so that at the end of each blog grading period (every two or three weeks, I think), I could scan back through the feeds to see that they were on time. Comments work in a similar way: I subscribed to the comment feed of each blog, and at the end of every grading period would scroll through the comment feeds, keeping a tally of comment authors (this makes comment counting a bit more time-consuming than post counting).

Requiring such prolific blogging with so many students is not for the faint of heart (or, perhaps, for those with a 5-4 load), but I’ve found that some of these techniques – and especially the general rule that doing a lot of work early in the semester means that a self-sustaining community will develop – make the job much more manageable.

Doctorow on ethics and copyright

· Leave a reply

I’m posting this passage from Cory Doctorow’s generally awesome discussion of copyright to Microsoft because it’s too long to tweet:

Copyright isn’t an ethical proposition, it’s a utlititarian one. There’s nothing *moral* about paying a composer tuppence for the piano-roll rights, there’s nothing *immoral* about not paying Hollywood for the right to videotape a movie off your TV. They’re just the best way of balancing out so that people’s physical property rights in their VCRs and phonographs are respected and so that creators get enough of a dangling carrot to go on making shows and music and books and paintings.

Now, I think this is perhaps overly simplistic, since utilitarian considerations might ipso facto be ethical ones. More explicitly, if it’s true that violating copyright reduces the efficacy of Doctorow’s “carrot”, and if the ensuing decreased productivity of content producers has negative overall “utilitarian” impact, then that initial act of piracy might rightly have negative ethical import.

But the core of what Doctorow is saying strikes me as absolutely correct: to act like the copying of a CD is a violation of someone’s rights is to make a lot of very questionable assumptions about the concept of intellectual property.

The piece is worth reading in its entirety. Do it!