1 / 12

CSE350 Software Design and Engineering

This lecture from CSE350 at the University of Pennsylvania discusses the history and principles of the Free Software Foundation (FSF) and the GNU Manifesto. It delves into the contributions of Richard Stallman (RMS) and the impact of copyleft licenses like the GPL on software development. The course emphasizes the successes of GNU projects such as Emacs and GCC, as well as the challenges faced by the FSF, including the failure of the HURD kernel. Key lessons about distributed programming and community-driven software development are highlighted.

micheal
Télécharger la présentation

CSE350 Software Design and Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Administrative • Homework #2 due today • How did people do with it? • Homework #3 assigned Thursday (I am still testing a few details, so not today) • Have people been doing the readings? • Topic today: Free Software Foundation

  3. History • RMS - hacker at MIT AI Lab • Really liked atmosphere • Contributed software such as “emacs” – editor macros (for early editor, “teco”) • Several events: Symbolics, AT&T “commercialization of UNIX” • Result-> GNU Manifesto

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

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

  6. Software engineering • Distributed. Work over network • Some programmers at FSF • Others: meet as needed. • Take advantage of UNIX modularity: except for kernel, largely tools / componentware • RMS projectmeister; periodic releases (I wonder if this is an artifact of physical distributions?)

  7. Intellectual property • A major distinction of FSF software is the so-called “copyleft” – the GNU public license (GPL) • Everybody is permitted to redistribute or modify software, but • No distributor allowed to restrict its redistribution • Use GPLed software, must GPL it too. • Very interesting consequences…

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

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

  10. Failures of project • Never got a kernel working (this was called the “HURD”). Linux can be viewed as filling this hole, but not engineered by RMS/FSF • I 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. • Distributed programmers can be successful • Voluntary projects can produce software at least as good as paid programmers • As Raymond notes in C&B, debugging is distributed – “many eyes” hypothesis • Volunteers often extremely dedicated

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

More Related