From kfogel Thu Dec 22 01:46:23 -0600 2005 Date: Thu, 22 Dec 2005 01:46:23 -0600 Message-Id: <8764phbmls.fsf@floss.red-bean.com> From: Karl Fogel To: Nathan Torkington Subject: proposal for OSCON talk (was: Re: How did you get into computers?) References: <48d4ecb00511021043h42334f0elb42b281274a0c884@mail.gmail.com> <87mzk0kmuo.fsf@floss.red-bean.com> Reply-To: kfogel@red-bean.com X-Windows: more than enough rope. I wrote, far too long ago: > Lastly, I haven't forgotten that I promised you a proposal for a > future OSCON talk, which will be in your mailbox very soon! Hi, Nat. Sorry for not sending this to you sooner; I got laid up by a microbe of indeterminate origin but tremendous potency. Thanks to the miracle of antibiotics, I am functioning again, and the microbe is not. The session I had in mind is is non-technical: it's about the surprising (and little known) history of copyright, and why that history matters for open source. The inspiration for it is Robert Lefkowitz's brilliant presentation at EuroOSCON on innovation and patents, and the unexpected Renaissance origins of the patent system. Tentative title: The (Surprising) History of Copyright and What It Means For Open Source Very briefly, with some details compressed: It turns out that copyright grew out of a censorship law in England in the 1550s. In the early 1700's, the government decided to lift this censorship statute, and the publishers' guild (whose monopoly up till then had depended on being part of the crown's censorship system) realized they were about to lose their main source of revenue. So they proposed a new statutory right, the copyright, originating with the author but transferable by contract to other parties. Since authors couldn't distribute their works without a printing press, the publishers reasoned, authors would naturally transfer their new right to publishers -- and that's exactly what happened. Copyright became the means by which publishers subsidized the high up-front investment needed to do a print run. So what does all this have to do with open source? A lot of today's increasingly heated copyright debate is predicated on the (false) notion that copyright was invented to subsidize the act of creation, that is, to provide an sustainable economic basis for creativity. But copyright was actually invented to subsidize the act of *distribution*. It's not that this was necessarily a bad idea: having healthy distribution mechanisms is in society's interests, and there are good reasons (which I'll go into in the talk) why publishing was ripe for some special monopoly protection. It's just that this purpose -- subsidy of distribution -- is very different from the one usually assumed, and viewing copyright in this new light changes a lot of one's usual conclusions. It transforms the question from "Does copying hurt artists?" (no, and anyway copyright wasn't about the artists) to "What kind of support does distribution need today?" Instead of being on the defensive when Microsoft talks about how open source hurts innovation, it becomes possible to turn the tables and point out that copyright was never about supporting innovation in the first place. When the RIAA rants against file-sharing software and lobbies for DRM, we needn't respond on their terms. Instead, knowing that copyright was not invented by or for creators, we can turn the accusations around, and ask the RIAA to justify their distribution subsidy in an age when distribution costs are fast approaching zero. In general, I think, the open source movement is a predictor of where all our culture is going, and a historically informed understanding of copyright will help us argue more effectively for open source values in the wider world. (See http://www.copyrightmyths.org/node/4 for another example, one I intend to bring up in the talk). Hmm, I could enter this all into http://conferences.oreillynet.com/cs/os2006/create/e_sess/#form if that would be easier. I just sent it directly to you run because I had said I would. There were enough overtly political (and non-technical) talks at EuroOSCON, and they were well enough received, that I'm hoping this will fit right in. Let me know what you think. -Karl Notes later: Some things that go away: - a "rare" book or record - the "director's cut" - "out of print" -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- -*- 10 [Collaboration] Tools Developers Need Today (Original title: "Technologies of Cooperation".) The goal of this talk is to get the audience thinking about collaboration itself as first-order activity, and one that is extremely responsive to good tools. The talk will start off with a discussion of collaboration tools that have made a big difference (e.g., Wikis, the CIA commit watching system). Then it will explore some new ideas for tools and techniques that are not widespread yet, but that could really help open source projects a lot: 1. Today's IRC bots are dumb, but we know how to make them smarter. 2. Extended patch format for trading traceable changes between different projects that have a common ancestry or that share some code. 3. How to improve mailing list usage by better integration with the list archiver. 4. Mailing list traffic summaries are too hard to write; the right tools can make them easier. 5. Spam filtering techniques that could really reduce the moderation burden on OSS projects. 6. Inter-project attribution conventions would make it *much* easier to trace where a given programmer has been active. The Subversion project has started with a rudimentary form of this, but it needs a standardization drive. 7. "urljump": Deep-referencing into HTML pages is possible, but there is currently no standard for it. If we had a standard and enough browsers (or web servers implemented it), certain kinds of references would be much easier to make. These next ones in the "law as technology" group: 8. Copyright assignment law is currently designed for a world in which people are physically present to sign forms. It's a problem for open source projects, and needs to be solved. 9. General group governance question: the law is designed around physical meetings. Yet decision procedures in mailing-list-based groups are unambiguous and just as decidable. If the law would recognize this, developer groups would have a much easier time formalizing their associations. (Depending on how much time the above fills when fully prepared, I may add or take away some items.)