1. CSE350 Software Design and Engineering University of Pennsylvania http://www.cis.upenn.edu/~jms Office: 254 Moore GRW, Phone: 8-9509 March 5 th, 2002

2. Administrative lHomework #2 due today lHow did people do with it? lHomework #3 assigned Thursday (I am still testing a few details, so not today) lHave people been doing the readings? lTopic today: Free Software Foundation

3. History lRMS - hacker at MIT AI Lab lReally liked atmosphere lContributed software such as “emacs” – editor macros (for early editor, “teco”) lSeveral events: Symbolics, AT&T “commercialization of UNIX” lResult-> GNU Manifesto

4. What is the GNU Manifesto? lMid-80s. Circulated on pre-Web USENET and also available via Internet FTP. lPrincipled argument for software community versus commercial software lA “call to arms” for those similarly inclined lCrystallize Love vs. Money distinction…

5. Structure lFoundation (FSF) – a charity to which people donate machines, money, software, time lSome people work for FSF, depending of course on donation level l$$ also from sales of distribution, manuals, etc. lIncentive for machines: early ports

6. Software engineering lDistributed. Work over network lSome programmers at FSF lOthers: meet as needed. lTake advantage of UNIX modularity: except for kernel, largely tools / componentware lRMS projectmeister; periodic releases (I wonder if this is an artifact of physical distributions?)

7. Intellectual property lA major distinction of FSF software is the so-called “copyleft” – the GNU public license (GPL) lEverybody is permitted to redistribute or modify software, but lNo distributor allowed to restrict its redistribution lUse GPLed software, must GPL it too. lVery interesting consequences…

8. Effects of GPL lUsing “emacs” doesn’t GPL result lUsing “emacs” code base does lSince early GPLed software was system software (emacs, gcc, gdb), no big deal lHowever, many companies which create software for $$ do not want GPLed software used at it “contaminates” their software – restricting their right to sell it lIntellectual property value (e.g., of startup)?

9. Successes of project lGNU emacs (I’ve used for ~20 years…) lgcc – manufacturers support it – “good enough” lGdb, flex, bison lText tools: groff, gpic, geqn, grefer lCommunity: these tools continue evolving lLinux can be thought of as emerging from project GNU (Linux thinks not, tho…..! )

10. Failures of project lNever got a kernel working (this was called the “HURD”). Linux can be viewed as filling this hole, but not engineered by RMS/FSF lI view GPL as a failure. In its own way, it enforces someone’s perspective over how you use the software. BSD license makes no moralistic judgements.

11. Lessons for S.E. lDistributed programmers can be successful lVoluntary projects can produce software at least as good as paid programmers lAs Raymond notes in C&B, debugging is distributed – “many eyes” hypothesis lVolunteers often extremely dedicated

12. Summary lMajor advance in understanding how to build software: UNIX + hackers + net lOngoing – it’s not over lWeird political overtones lVolunteers only work on what they’re iinterested in; tend to be “systems” things rather than applications – hence “ease of use” whinge