Seminars

May 27, 2008

Week 10 (week commencing 19th May)

IP: copyright, patents, licensing, etc

Most people will have a view on these things as they can’t be avoided.

I suggest that seminars commence by discussing individual attitudes to IP:

• do you believe in IP, that is, ownership of intellectual property?
• how do you justify your position?
• it is easy to arrive at a realisation that there are good arguments either way, that is you have one of these ethical dilemmas.

At that point, it will be worth looking at

• http://danny.oz.au/free-software/, a free software advocacy site, and in particular
• Against Intellectual Property, the “free software” view of IP as expressed by Prof. Brian Martin from the University of Wollongong. The paper is also available in PDF.

  This paper is chapter 3 of the Brian Martin’s book “Information Liberation” by Brian Martin. The complete book can be found at http://www.uow.edu.au/arts/sts/bmartin/pubs/98il/.

  A review of the book can be found at http://dannyreviews.com/h/Information_Liberation.html.

This discussion drifts easily into open source development and the free software movement.

A few comments are added here on copyright and patent, as some students are unclear about the distinction.

Copyright:

is concerned with the form of expression of something. Notice that any ideas are not protected only the way it is expressed. This might be an essay, a book, a piece of music, a performance of music, a piece of software. Notice that it is “form of expression” that is protected, so translation into another language, or into machine code does not avoid the copyright, indeed it infringes the copyright. Copyright in Australia does not require any registration, nor does it require a copyright notice, although that is recommended. Copyright around the world is recognised by the Berne agreement.

Patent:

is concerned with the means of production or implementation. You cannot patent an idea, you can patent something to be produced, and you must show that it can be produced. You can’t patent “blue sky”. Notice that patenting involves publication: all patents are “world readable”. Patents do not automatically transfer to other countries: you must pay for extending to other countries and the exercise can get very expensive. DNA patents are “interesting”.

Trade secret:

is an alternative to patent. You don’t publish and there is no expiry date. You simply swear everyone to secrecy. Clearly doesn’t work for computer software.

You might like to have a look at

http://progfree.org/Patents/industry-at-risk.html

and decide whether somehow software is different to other manufacturing industry to which patents have applied for 200 years.

Consider:

• IBM holds patent #4,965,765 which covers the use of different colours to distinguish the nesting level of nested expressions.
• Patent #5,249,290 covers assignment of client requests to the server process having the least load.
• Patent #4,941,125 covers using a digital camera in conjunction with character recognition software to store and index documents on a CD ROM.

I’ll leave it to classes to work out issues to be discussed, but you might like to tackle the following.

On the one hand much software looks like mathematics, so should we patent mathematics? Patents were never intended to cover ideas.

But on the other hand, if we take the concept of Software Engineering seriously then surely an engineering process should allow for some patent capability?

This gets to perhaps the nub of the issue: how do we --or if you like, do we-- provide for some form of ownership of invention within software engineering? Of course, you can take Brian Martin’s approach and broaden this question to all areas.

Some other possible questions:

1. Describe situations where IP produces unfair outcomes.
2. How much should somebody profit from their ideas?
3. Do we have free speech in Australia?
4. Do you believe in IP?
5. How common/rare are good ideas?
6. Is there such a thing as an original idea?

Week 1 (week commencing 10 March)

For the first seminar, please print the Engineering and Software Engineering .

Read the document before the seminar and bring it to the seminar. There are other linked documents and you may wish to print some of those also. In particular, the “Are Software Engineers Engineers” document should be read and perhaps printed.

This is a very wide ranging seminar. Please form your own list of topics that you would like to discuss. That way you can affect the agenda for your seminar.

We will organise the seminar discussion using the Six Thinking Hats, so please read the short summary document on that.

Please remember one thing: you are not coming to the seminar to be supplied information from you facilitator. You are coming to take part in a discussion and that should include initiating discussion.

Also, in general, there are no “right answers”. But this course is very much about your future, so there may be “right questions” for you.

Week 2 (Week commencing 17th March)

The seminars will be concerned with at discussion of codes of ethics and codes of conduct. The ACM Code of Ethics and Professional Conduct will be investigated largely through the Self Assessment XXII by Eric Weiss. This paper can be found on the Papers page in the class website and you should obtain a copy and read it before the seminar. The ACM Code can be found on the class website.

In addition to the scenarios found in the above paper, please also add the following two scenarios suggested by Achim:

1. Andrew is a senior software engineer who leads a project team on a new hospital information system. Andrew thinks that after completing the first version next week it takes at least another 4-6 weeks to properly test the software and to fix possible bugs.

   The CEO of the smallish company SmallSoft says that the software needs to be shipped within two weeks - otherwise a competitor is likely to come out first with a comparable product and is likely to grab the bulk of the market. As a consequence, the SmallSoft may go bankrupt.

   What could Andrew do? Consider the ethical/professional implications and consequences of different actions.

2. Peter is a member of a software engineering team and is testing the human-computer interface of the software under development. He reports in a project meeting that the software is cumbersome to use and that it will probably take about twice as much time to learn to operate the software successfully as with an alternative interface design.

   A colleague replies: ”I think we should stick with the current interface design. Given the current market, the users will not have too many choices. More importantly, once a user made the effort to learn our interface they are likely to expect that competitor products will require a similar amount of work and, hence, will be less inclined to try any competitor products. So it is actually desirable for our company to make the customers spent some effort and time on our products.”

   Given that the software is a mass-market software it is likely that this decision will cost the users a total of several millions of hours of time and productivity.

   Peter’s actions

   Consider the ethical implications and possible consequences of actions that might be taken by Peter.

   Team leader’s actions

   Consider the ethical implications and possible consequences of the team leader’s actions.

The Self Assessment document consists of:

Part I

of that document is an introduction to ethics.

Part II

presents an overview of the ACM Code of Ethics and Professional Conduct.

Part III

a set of scenarios that present various ethical conflicts.

Part IV

is a scenario analysis form (see later) Part V presents panel responses to the scenarios.

A scenario analysis form consists of:

Scenario No:
Party (actor):
Ethical conclusion:	one of
	1) Unethical
	2) Not unethical
	3) Not an ethical issue
General principles:
Canons, professional ideals or mandatory rules influencing decision:
Comments:

A form based on the above should be completed for each scenario studied in the seminar and a summary of all class results should be built during the seminar.

You should analyse each scenario and identify the ethical conflicts. You should then identify ethical principles or rules of conduct that are appropriate to each actor in a scenario. Also, be prepared to determine whether the ACM Code is adequate for the job.

Notice that the self assessment exercises are intended to be exercises and are not intended to provide definitive answers to ethical dilemmas.

In the lectures on Professionalism and Ethics, Stephen contrasts a code of ethics and a code of conduct as follows:

Code of Ethics	Code of Conduct
General	Specific
Value/Principles	Prescriptions/Directives
Judgement	Uniformity
Empowering	Enforceable statement of something specific

So a code of ethics encourages individual responsibility and accountability for ethical decisions. A code of conduct, on the other hand, tries to provide (enforceable) rules for responding to an ethical issue.

Question How do you see the ACM Code of Ethics?

Professionalism requires a professional to act in the best interests of the client and the general public. A consequence of this, as Stephen Cohen pointed out, is that it is not possible for many occupations to become a profession: a sales person, a financial advisor. What does this mean for a Software Engineer?

Week 3 (week commencing 31st March)

This week’s seminars will begin discussion of the Killer Robot story. This story consists of 9 articles that can be found here and also on the Other Sites page of the class web page . This story forms about half of the Killer Robot book, by Richard Epstein. The book contains extra material that is not online, and contains much interesting ethical discussion and references.

The seminar discussion will be based on the first 6 articles. Please read the articles and bring copies of all 9 articles to the seminar. Please come prepared.

There are some differences between the book and public version of the Killer Robot story.

If you only look at the public version, please also look at the extra prelude articles to the above .

Discuss the case as though it is real. It’s not hard to do.

Remember that this story if being revealed through newspaper reports, and therefore possess all the attributes of a real life incident and its investigation. You are not necessarily getting the truth, or at least not the whole truth.

You might pursue the following points of discussion, but facilitators can proceed however they wish:

1. Looking at the first article, why did Bart Matthews say, ”I trust this robot”? What did he mean? It’s a strange thing to say. Perhaps he was saying this to raise his own confidence? There’s nothing definitive here; just get discussion going.
2. Since the third and fourth articles raise the issue of charging a software developer with manslaughter, we discussed this next. Is it plausible that a software developer could be charged with manslaughter? I don’t know, but I don’t see why not. Understand that murder is killing someone with intent; manslaughter is killing without intent. In manslaughter a person has been killed in an accident. So it’s acknowledged that it is an accident, but has there been negligence, criminal negligence?

   Instruction to facilitator: This can be developed into a quite serious discussion. Any person in the class could be charged with manslaughter. Put it to them. You’ve been charged with manslaughter. How do you defend yourself? What would you need to have done to defend yourself against such a charge?

3. Then discuss what actually happened? Collect as many details as possible.
4. What were the potential causes that led to the software malfunction that caused Bart Matthews death?

   Each student in the class should be able to provide a potential cause. All answers can be written on the board, as for the answers to the above questions.

Try to ensure that the answers are coming from all the articles and not being concentrated on just a few articles. If the latter is happening, look for new reasons.

As well as noting the issues, carry out some discussion of the points.

Which are consequences rather than causes? Try to identify significant causes. If the consequences are undesirable, what would you do to prevent them?

Week 4 (week commencing 6th April)

The seminars in Weeks 4 & 5 will be concerned with the Therac 25 case study.

Objectives

to get a clear picture of

the Therac-25 machine:

what is was; what it consisted of; and what it was used for.

the accidents:

what accidents occurred; details of each accident.

causes of the problems:

details of all causes.

context of accidents:

understand the situations of the accidents.

how the accidents were handled:

what action was taken.

In week 5, with all the above understood, the objective is to do a more thorough ethical analysis of the case.

Material for discussion

Full report of the Therac-25 case

For a full report of the Therac-25 case you should consult ”An Investigation of the Therac-25 Accidents” (see Papers/Leverson et alon this web site).

Teaching material on Therac-25

You should also look at the computingcases.orgfor a breakdown of the case. You will probably find this much more digestible than the Leverson report.

Wikipedia

You could also consult the Wikipedia http://en.wikipedia.org/wiki/Therac_25 .

Other material

There is also a book appendix, Medical Devices: The Therac-25.

You should bring a copies of the Leverson investigation paper to the seminar. This report has very full pages. To print, use acroread or gv and print at 90%.

You should also consult the teaching material at computingcases.org.

Therac 25 case

This is a famous case in which a number of patients were seriously injured, and some died.

The Therac is a dual mode electron beam/X-ray photon machine used to treat tumours. There were predecessors of the Therac 25 that had a clean safety record. The Therac 25 came into use around 1985 and the case covers a two year period in which the casualties occurred and investigations were carried out. The case is of interest to this group because it combines:

• ethics
• software design and implementation; there were software errors
• professional practice: what lessons are to be learnt from the case.

Historical note

The Therac-25 was built in the early 1980’s. For most students that was before you were born. The computing environment then was dramatically different to the one you know:

• this was the age of the mini computer, not really so mini, probably about 2m x 2m x .5m in size.
• processor speeds were about to break 1MHz, ie at least 1000 times slower than current processors, and they were generally shared machines.
• RAM and disc capacity was MB.

A very different environment, and the writing of software was different. We don’t know, but the software that controlled Therac-25 was possibly written by an electrical engineer. There were no graduate software engineers, or even computer engineers. But there were computer science graduates!

A possible agenda

1. What was Therac-25?
2. What were the relations to its predecessors?
3. What accidents occurred in the use of the machine?
4. What was the role of the turntable in the operation of the machine?
5. What was a common scenario that occurred in the cases that led to overdoses being administrated?
6. What software errors were occurring in this interface software?
7. What professional errors are revealed in the case?
8. Are there any ethical issues revealed in the case? What are they?
9. What lessons can be extrapolated from the case?

Week 5 (week commencing 13th April)

In week 5 we will continue with Therac-25.

The assumption is that each seminar class has already got a reasonable overview of the Therac 25 case, and what we want to do in this seminar is to build some analyses and conclusions on what we find in this case.

Each class should produce written summaries of their discussion and these should be put on the class forum on the class website under each seminar class.

The following organisation is suggested:

1. each seminar class is split into subgroups
2. subgroups decide which items they are going to cover; each subgroup should cover at least 5 items; the class as a whole should cover at least 20 items; subgroups will have more to do in a small class
3. the class as a whole discuss each item, but the subgroup responsible for that item should document the discussion
4. the subgroups consolidate their summaries
5. possibly a final discussion of the conclusions for the class
6. each subgroup adds their summaries to the class forum.

The following is a list of topics. Feel free to add your own items.

1. Was there a single cause of the Therac-25 accidents?
2. What is safety critical software?
3. How can it kill people?
4. How can you make safety critical software safe?
5. How can professionalism, education, regulation or a code of ethics make software safer?
6. Was the solution to the Therac-25 problem, simply to put back the hardware interlock?
7. Could the Therac-25 be made safe purely through the software?
8. Name some components of the system. What do you notice about the jargon?
9. Discuss the UI. Could you operate this system? Should you be able to?
10. Discuss some general ways for improving UIs. How could these have been applied to the Therac-25 UI?
11. How do you go about quantifying usability?
12. What is ”faulty software”?
13. Who investigates software errors?
14. Do you understand the problem from reading this report?
15. Do you the report hard to read?
16. Would your boss understand it?
17. Would you sign off on it, if asked by your boss?
18. How much can you expect others to understand about software problems? Nurses? Physicists? Other Engineers?
19. How common is software in medicine?
20. What are ”intermittent errors”? How do you deal with them?
21. How was the software produced?
22. Would you have made the same mistakes? How would you avoid them?
23. Are there structural impediments to accurate fault reporting?
24. Whose fault was it?
25. Does it matter? Aren’t the patients going to die of cancer anyway?
26. What is a ”race condition”? What do you know about non-determinism?
27. Who is responsible for certifying a system ”safe”?
28. Other issues.

Weeks 6 (week commencing April 21)

This seminar will be used for debates.

Week 7 (week commencing 28th April)

The seminar is based on the How Good is Good Enough paper of Collins, et al.

This paper is available from the Papers page of the course web site. Please study this paper before attending your seminar.

See also Rawl’s Theory of Justice .

In the seminar you should consider the following issues:

1. Discuss Rawls’ ethical principles.
2. Discuss the application of these principles in the case studies given.
   • What happened?]
   • Who was involved?]
   • What went wrong?]
   • What should have happened?]

3. Discuss the impact of this form of analysis on SE.
4. Is this form of analysis well suited to anaysing ethical situations in computing?
5. Revisit the Therac 25 papers to see if this theory would help analyse that case.
6. Do Rawls’ principles correspond with Stephen Cohen’s outline of the foundations of ethics?

Week 8 (week commencing 5th May)

Mon11b only: as for week 7.

Week 9 (week commencing 12th May)

Roger Clarke (ANU) coined the name “dataveillance” in the late 1980 and he has a large website at http://www.anu.edu.au/people/Roger.Clarke/DV/ on dataveillance.

Get a copy of

• Introduction to Dataveillance and Information Privacy, and Definitions of Terms
• What’s Privacy? , and
• Dataveillance -- 15 Years On

More information can be found at http://www.anu.edu.au/people/Roger.Clarke/DV/.

1. What is dataveillance?
2. Is it immoral to collect data about other people?
3. What personal data is currently being collected?
4. What new opportunities are there to collect even more personal data?
5. How can dataveillance be regulated?
6. What advice would you give to non-specialists about safeguarding personal information?

Discuss the contents of Dataveillance -- 15 Years On.