• Show understanding of the need for and purpose of ethics as a computing professional

  • Understand the importance of joining a professional ethical body including BCS (British Computing Society), IEEE (Institute of Electrical and Electronic Engineers)

• Show understanding of the need to act ethically and the impact of acting ethically or unethically for a given situation

• Show understanding of the need for copyright legislation

• Show understanding of the different types of software licencing and justify the use of a licence for a given situation

  • Licences to include free Software Foundation, the Open Source Initiative, shareware and commercial software

• Show understanding of Artificial Intelligence (AI)

  • Understand the impact of AI including social, economic and environmental issues

  • Understand the applications of AI

What is a code of conduct?

A code of conduct is a set of rules or practices defining how a group or organisation should behave – organisations such as businesses, schools, and hospitals have codes of conduct. Many codes contain rules that seek to protect the organisation from the behaviour of individuals, as well as protecting the individuals within the organisation. For example, a school’s code of conduct may include rules about behaviour, dress codes, bullying and respect for others and their property.

Codes of conduct are also applied to computers and their use. They seek to make sure that computers are used safely and lawfully, and to protect the interests of organisations and individuals.

Computer professionals in particular have a need to follow codes of conduct. The computer systems they design, build, implement and use may have a great impact on, for example, the success of an organisation, the protection and privacy of its employees, and the protection, privacy and safety of the public. When designing and building systems, software developers (engineers) have opportunities to cause harm to their clients and to the public, such as:

• • failing to make sure their software is fit for purpose (for example, consider the implications of a safety system that has faulty software)

  • including malicious software designed to spread malware

  • including unauthorised and undeclared ways into the system (backdoor) so that they can later gain access without their client’s knowledge.

In order to prevent these types of behaviour and their consequences, computer codes of conduct are becoming increasingly important.

Introduction

The Software Engineering Code of Ethics and Professional Practice is a standard for teaching and practising software engineering. It lays down the ethical and professional obligations that should be followed by software engineers by specifying the standards they are expected to adhere to as both members of society and members of a professional team within an organisation.

Organisations exist that aim to provide standards for professionals. Two organisations that represent computing professionals are the Association for Computing Machinery (ACM), and the Institute of Electrical and Electronics Engineers (IEEE) Computer Society. Between them, these organisations developed the ACM/IEEE Software Engineering Code of Ethics. These ethics aim to provide rules, standards and protection for software developers and their clients.

There are Eight Principles in the Code of Practice: YOU DO NEED TO KNOW THESE

1. Public: Software engineers shall act consistently with the public interest.

2. Client and Employer: Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest.

3. Product: Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. Judgement: Software engineers shall maintain integrity and independence in their professional judgment.

5. Management: Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. Profession: Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. Colleagues: Software engineers shall be fair to and supportive of their colleagues.

8. Self: Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

The eight principles spell out the relationships that software engineers have with their peers, their employers, their customers and to society and informs non-software engineers what they can expect from actual software engineers. They describe how software engineers should behave and make decisions in a manner that can be called 'ethical'. These principles are not laws but provides an ethical foundation upon which a software engineer can work.

Exam Note: You are not expected to memorise all of the individual points within the 8 principles. However, it is useful to know at least one should you be asked to show your understanding of specific principles.

The relevance of the eight principles

Introduction

The eight principles of the ACM / IEEE Software Engineering Code of Practise can be applied to a Software Engineer's job in many ways. Clearly, the scenarios are endless but we listed some typical situations where the code may have an impact. The full Code is listed for claritication. You do not need to memorise it.

The following examples have been copied from this excellent website: http://www.acm.org/about/se-code

Principle 1: PUBLIC

Software engineers shall act consistently with the public interest. In particular, software engineers shall, as appropriate:

1.01. Accept full responsibility for their own work.

1.02. Moderate the interests of the software engineer, the employer, the client and the users with the public good.

1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The ultimate effect of the work should be to the public good.

1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents.

1.05. Cooperate in efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation.

1.06. Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools.

1.07. Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software.

1.08. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline.

Principle 2: CLIENT AND EMPLOYER

Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest. In particular, software engineers shall, as appropriate:

2.01. Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.

2.02. Not knowingly use software that is obtained or retained either illegally or unethically.

2.03. Use the property of a client or employer only in ways properly authorized, and with the client's or employer's knowledge and consent.

2.04. Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it.

2.05. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law.

2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic.

2.07. Identify, document, and report significant issues of social concern, of which they are aware, in software or related documents, to the employer or the client.

2.08. Accept no outside work detrimental to the work they perform for their primary employer.

2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern.

Principle 3: PRODUCT

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. In particular, software engineers shall, as appropriate:

3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public.

3.02. Ensure proper and achievable goals and objectives for any project on which they work or propose.

3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects.

3.04. Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.

3.05. Ensure an appropriate method is used for any project on which they work or propose to work.

3.06. Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified.

3.07. Strive to fully understand the specifications for software on which they work.

3.08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals.

3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.

3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work.

3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work.

3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software.

3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized.

3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.

3.15 Treat all forms of software maintenance with the same professionalism as new development.

Principle 4: JUDGMENT

Software engineers shall maintain integrity and independence in their professional judgment. In particular, software engineers shall, as appropriate:

4.01. Temper all technical judgments by the need to support and maintain human values.

4.02 Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement.

4.03. Maintain professional objectivity with respect to any software or related documents they are asked to evaluate.

4.04. Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices.

4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped.

4.06. Refuse to participate, as members or advisors, in a private, governmental or professional body concerned with software related issues, in which they, their employers or their clients have undisclosed potential conflicts of interest.

Principle 5: MANAGEMENT

Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance . In particular, those managing or leading software engineers shall, as appropriate:

5.01 Ensure good management for any project on which they work, including effective procedures for promotion of quality and reduction of risk.

5.02. Ensure that software engineers are informed of standards before being held to them.

5.03. Ensure that software engineers know the employer's policies and procedures for protecting passwords, files and information that is confidential to the employer or confidential to others.

5.04. Assign work only after taking into account appropriate contributions of education and experience tempered with a desire to further that education and experience.

5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work, and provide an uncertainty assessment of these estimates.

5.06. Attract potential software engineers only by full and accurate description of the conditions of employment.

5.07. Offer fair and just remuneration.

5.08. Not unjustly prevent someone from taking a position for which that person is suitably qualified.

5.09. Ensure that there is a fair agreement concerning ownership of any software, processes, research, writing, or other intellectual property to which a software engineer has contributed.

5.10. Provide for due process in hearing charges of violation of an employer's policy or of this Code.

5.11. Not ask a software engineer to do anything inconsistent with this Code.

5.12. Not punish anyone for expressing ethical concerns about a project.

Principle 6: PROFESSION

Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. In particular, software engineers shall, as appropriate:

6.01. Help develop an organizational environment favorable to acting ethically.

6.02. Promote public knowledge of software engineering.

6.03. Extend software engineering knowledge by appropriate participation in professional organizations, meetings and publications.

6.04. Support, as members of a profession, other software engineers striving to follow this Code.

6.05. Not promote their own interest at the expense of the profession, client or employer.

6.06. Obey all laws governing their work, unless, in exceptional circumstances, such compliance is inconsistent with the public interest.

6.07. Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive, misleading, or doubtful.

6.08. Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work.

6.09. Ensure that clients, employers, and supervisors know of the software engineer's commitment to this Code of ethics, and the subsequent ramifications of such commitment.

6.10. Avoid associations with businesses and organizations which are in conflict with this code.

6.11. Recognize that violations of this Code are inconsistent with being a professional software engineer.

6.12. Express concerns to the people involved when significant violations of this Code are detected unless this is impossible, counter-productive, or dangerous.

6.13. Report significant violations of this Code to appropriate authorities when it is clear that consultation with people involved in these significant violations is impossible, counter-productive or dangerous.

Principle 7: COLLEAGUES

Software engineers shall be fair to and supportive of their colleagues. In particular, software engineers shall, as appropriate:

7.01. Encourage colleagues to adhere to this Code.

7.02. Assist colleagues in professional development.

7.03. Credit fully the work of others and refrain from taking undue credit.

7.04. Review the work of others in an objective, candid, and properly-documented way.

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.

7.06. Assist colleagues in being fully aware of current standard work practices including policies and procedures for protecting passwords, files and other confidential information, and security measures in general.

7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.

7.08. In situations outside of their own areas of competence, call upon the opinions of other professionals who have competence in that area.

Principle 8: SELF

Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. In particular, software engineers shall continually endeavor to:

8.01. Further their knowledge of developments in the analysis, specification, design, development, maintenance and testing of software and related documents, together with the management of the development process.

8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time.

8.03. Improve their ability to produce accurate, informative, and well-written documentation.

8.04. Improve their understanding of the software and related documents on which they work and of the environment in which they will be used.

8.05. Improve their knowledge of relevant standards and the law governing the software and related documents on which they work.

8.06 Improve their knowledge of this Code, its interpretation, and its application to their work.

8.07 Not give unfair treatment to anyone because of any irrelevant prejudices.

8.08. Not influence others to undertake any action that involves a breach of this Code.

8.09. Recognize that personal violations of this Code are inconsistent with being a professional software engineer.

This Code was developed by the ACM/IEEE-CS joint task force on Software Engineering Ethics and Professional Practices (SEEPP):

Introduction

We have seen that computers are in a central role today and software engineers are at the heart of developing both new software and the new systems that the software will run on. We know that software engineers are in a very powerful position and can do a lot of good, as well as a lot of harm and that they are also in a position to influence others to do good or to do harm.

Because of their power, software engineers must work towards and be seen to be working towards being a force for good and working in a way that promotes their profession rather than brings it into suspicion. To ensure that everyone understands their role and responsibilities, all professional organisations draw up standards and Codes of Conduct. It then becomes very clear how everyone should behave. It also gives practising professionals a tool which they can use if ever they are put under pressure to behaviour in a less than ethical fashion. They can refer to their Code of Conduct as the guiding principle and justification behind their actions and decision-making.

There are always lots of tensions and pressures in any job and a software engineer's job is no different. At times, these pressures and conflicting interests clash. There are other times when they have an opportunity to do something because of the position of power that they are in. A Code of conduct can help to define behaviour and decision-making.

Examples where software engineers may have a conflict of interest or are in a privileged position which could be abused include:

• • Employees often have access to private and confidential data. That data should be treated with respect. It shouldn't be copied and shared or emailed out of the organisation's system unless there is a good reason related to the professional execution of the job.

  • Private and confidential data shouldn't be discussed with anyone except in a professional context.

  • Employees are in a position of trust. They should ensure that they keep that trust, for example, by not letting others who have no right to see data, get access to that data by using their login and password.

  • Employees should follow whatever legal directives exist e.g. the Data Protection Act 1998 or relevant Health and Safety legislation and if something can't be followed, to raise the issue effectively with their line manager.

  • Employees should ensure that standards of ethics are followed and that they are not put under pressure to produce substandard work that goes against professional codes of conduct.

  • Employees should be able to assess different competing conflicts when developing a product professionally, for example, the need to do proper testing against the need to get a product finished, and to be able to not compromise standards of behaviour.

  • Employees should be able to make decisions based on objective information, not any perceived or actual advantage e.g. a promotion or financial bribe!

  • Employees who have access to hardware and especially software shouldn't take advantage of their positions by e.g. copying software for home use.

  • Employees should take care of the systems they use so for example, they shouldn't bring in external pen drives and run their own programs on their employer's computers, as this could introduce a virus into the network and lead to data loss or other damage.

• Employees shouldn't take a company's intellectual property with them when they move to a different company.

There are many other examples of the impact of ethics and the code of conduct on computer professionals but the above is a sample of what you might consider as part of the ethics debate.

The Google self-driving Car

The ‘Google car’ is a concept for a self-driving car that autonomously takes the passenger where they wish to go. When designing, building and testing the software for the car, Google’s software developers had one principle placed above all others: the safety of the passenger and the public. In doing so, Google’s developers had to consider ethical questions about safety and breaking the law.

Consider this situation: a passenger in a Google car may fall ill and need urgent hospital attention. The Google car is programmed to stay within speed limits, even if the road is clear. However, keeping to the speed limit may mean that the passenger does not receive medical treatment in time. Google’s developers have to consider the ethical considerations of both the passenger and the public at large. In this situation, speeding may endanger the public, but driving legally might endanger the passenger. What should the car do?

The smartwatch

The introduction of smartwatches has raised privacy concerns that developers have had to address. Many smartwatches have health-monitoring facilities such as detection of heart rate and the amount of exercise the user has undertaken. The data from this monitoring is often sent over the internet to third-party applications, to help users monitor their fitness. Developers have an ethical duty to make sure that this data remains private: developers of the watch need to make sure that the data is transmitted securely, and developers of the third-party applications have to make sure that the data remains private.

Borland Interbase

Developers at Borland included a backdoor in their Interbase database product to make sure that a client could never be accidentally locked out of their database. This backdoor could be accessed over the internet. When knowledge of this backdoor became public, Borland were faced with the possibility that any client’s database could be accessed by an unauthorised user. From an ethical point of view, Borland originally included the backdoor with the aim of protecting their clients’ data. After the backdoor was exposed, Borland acted ethically and closed the backdoor through issuing a software patch.

Network monitoring

In the workplace, computer users might find themselves placed in a situation with conflicting ethics.For example, the management of a company might suspect that an employee is wasting work time accessing social networking sites on the company’s computers. This highlights the importance of having a computer code of conduct in place. If the code of conduct forbids access to social networking sites via the company’s computers, then the management have an ethical right to check that the code is being upheld. Without a code, checking on the employee could be considered an invasion of privacy. However, even with a code of conduct, to behave ethically the company could only check on those employees for whom they have evidence of unethical behaviour, as employees’ privacy must still be considered.

Introduction

When a person or an organisation develops and promotes a book, an album of songs, a film or a new software application, for example, it costs them a lot of time, effort and money. This can run into millions of pounds. It is only right therefore that they have legal protection for their 'intellectual property', to stop people stealing it. The legal protection that somebody has for their work is called 'copyright.

Although it may not seem like theft, when someone at home illegally downloads some music or a film or a piece of software to use that is copyrighted, it most certainly is. It is denying the people who invested their time, effort and money in the project of a means to regain some of their investment, and to make a profit so that they can continue to operate. To help protect the owners of intellectual property, the Copyright and Patents Act 1988 was introduced.

There is a side note to accompany this page which goes into much more detail on who owns the software written.

The Copyright and Patents Act 1988

People who write, paint, compose music, design web pages or invent something, for example, have 'intellectual rights' over what they have done. They own the copyright. This means that somebody who wants to use what they have done must get permission first from the copyright owner. The copyright holder can refuse to give permission, give permission freely, give permission but attach some conditions of use or could charge for permission. These rights are enshrined in law in The Copyright and Patents Act 1988. For example, If you find a web site you like, you cannot make copies of the web site. You cannot burn copies of the web site on to CD without permission nor can you use images you found there without permission. Many web sites, photographs and images now incorporate software that 'stamps' the images with the copyright owner's details.

Copyright law and the European Union

A problem with the Copyright and Patents Act 1998 is that it can only be applied if you are caught breaking copyright laws in the UK. This is clearly a problem, given that the Internet is world wide. Many (but all) countries outside the UK have similar legislation to the Copyright and Patents Act 1998 but the EU, in an attempt to ensure that all its members' laws on copyright were more or less the same, introduced a number of copyright directives. A directive is an instruction to a member state that it must ensure its own legislation meets the standards laid down in the directives. This helps a little bit, but how effective it is is anyone's guess!

Plagiarism

If you do a computing project as part of your course, you cannot include work in your project that somebody else has done without properly giving credit to the author. If you do use somebody else's work without giving it due credit then this is known as 'plagiarism' and even then, you are restricted in how much of someone else's work you can copy wholesale. It is both unethical and a breach of copyright to plagiarise someone's work. There are many web sites offering projects for sale for both school work and university work and many places you can download past pieces of work, although there is no way you can guarantee their quality. Educational institutions and exam boards have become very wise to these sites and now regularly run software through submitted coursework to look for passages that have been stolen.

The following article is taken from the Association of Software Professionals. It describes who owns software code. It predominantly relates to US Law but much applies to UK legislation.

Re-usable code is a key component of any developer's toolkit, and creating and owning re-usable code is a critical step in the process of creating a profitable software development business. Whether the code consists of web-site management scripts, "black box" modules or self-contained classes contributed to larger projects, re-usable code is the centrepiece of modern object-oriented and rapid-prototyping design principals. To fully leverage the power of re-usable code, however, you must understand the legal framework that defines who owns that code.

I assume for the purposes of this article that the code at issue is copyrightable. Some of the most basic code fragments, for example a simple "for" loop to iterate through an array of objects and perform some action on each object, may not be copyrightable at all. Most larger code segments, however, are copyrightable.

Copyright Law Creates A Framework For Software Ownership

Ownership of the copyright in software code is important because the copyright owner controls the ability to copy, distribute, sell, or modify the code, and generally controls the ability to profit from the code. Under copyright law, the author of a line of software code is the owner of the copyright in that code. That is, the person who physically puts fingers to the keyboard and types out the sequence of words and symbols that constitutes a line of software code is the "author" and owns the copyright to the code. A copy-right is created by federal law and consists of six rights the owner of a "work" has to the exclusion of any other person or business. Four of these rights are applicable to software code. Those are:

• 1. The right to reproduce the code

  2. The right to create "derivative works" based on the code, such as the screen display that the code generates, future versions of the software, or other software programs into which the code is integrated

  3. The right to distribute copies of the code

  4. The right to "display" the code, for example by posting to a web site.

Applying the basic law of copyright to software development, if you personally write a class or a module, you own the copyright to that class or module. If you write a website in html, or a website display script in a scripting language like PHP or ASP.NET, you own the copyright to those lines of code you wrote. You are free to re-use that code in any way you like, and no other person or entity can legally use that code without your permission.

The basic rule is subject to several exceptions. In the software world, there are three exceptions so common they swallow the rule. A more nuanced and practical understanding of the role of copyright in re-usable code requires as much understanding of the exceptions as the basic rules. The three exceptions to the basic rule of copyright ownership most prevalent in the context of software development are the "work-made-for-hire" rule, the "License or Assignment" clause in a development contract, and the unique situation encountered when developing on an "Open Source" platform.

The "work-made-for-hire" doctrine generally defines the relationship between a software developer and his or her client.

A segment of software code is a "work-made-for-hire" if it is either:

a) A work prepared by an employee in the scope of his or her employment; or

b) a work specially ordered or commissioned for use as [1] a contribution to a collective work, [2] as a part of a motion picture or [3] other audiovisual work, [4] as a translation, [5] as a supplementary work, [6] as a compilation, [7] as an instructional text, [8] as a test, [9] as answer material for a test, or [10] as an atlas, if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire.

In either situation, the author of the code does not own the copyright in the code, as would be expected under the basic copyright framework. Rather, the person or business that employs the author or that commissioned the software owns the copyright in the code.

When a developer creates software as an employee, determining ownership of that software under the "work-made-for-hire" rule is relatively straightforward. Any work a developer creates within the scope of his or her employment is owned by the employer. Analysis of whether work is "within the scope of employment" can be extremely complex. However, at its most basic, if a developer writes a particular piece of software for work, his or her employer owns the copyright to that software.

When a developer creates software as a contractor, analyzing who owns the copyright in code created as a result of that relationship becomes both more complex and more important. Courts and legal analysts use a three-part test to determine whether the developer or the client owns a particular segment or module of code. First, the work must have been specially ordered or commissioned. Second, the work must specifically fall within one of the ten categories enumerated in part (b) of the "work-made-for-hire" rule. If the work at issue does not fall within one of the enumerated categories, it cannot ever be a "work-made-for-hire." Almost all software code is consumer-facing code and will fall under category three, audio-visual work, although some software without a human-readable interface may not fall under any of the ten enumerated categories. Third, and most significant, a commissioned and copyrightable work will only be considered "work-made-for-hire" owned by the client if the parties have a written agreement signed by the developer that explicitly states that the work is "work-made-for-hire."

If a particular piece of software is a "work-made-for-hire," the employer or client that commissioned the code owns the copyright in it. In order for the developer to have any right to use the software later or in different projects, the developer must negotiate a license to the software in the same way any third-party would.

Outside of "work-made-for-hire," almost every development engagement includes some arrangement for the ownership, assignment, or licensing of the software.

The original author or any other owner can also transfer or share copyright rights to or with others through an assignment of the copyright or a license of the copyright. These two concepts should not be confused. An assignment is a grant of all of the rights of the author in the copyright to another party. If the developer assigns his rights to code he or she has written, the developer no longer has any right to the code, and must license the code from the new owner to have the right to re-use it. Additionally, for an assignment to be binding, it must be made in writing, and must be signed by the developer. Any alleged verbal assignment of copyright rights will be considered a license of those rights and not an assignment.

A license, in contrast, is a grant of permission to use the code without giving up ownership of the code. If assigning copyright in software is like selling your house, licensing copyrighted software is like renting your house. A license can range from a mere right to use the software, module, script, or class in the completed software, to granting rights to re-write the software or create derivative software from it, all the way up to all of the rights to the code that the original creator has. A license can be exclusive in the sense that the author agrees not to license the code to anyone else in a particular geographic region, industry, for a period of time, or at all, or it can be non-exclusive in the sense that the licensee is only one of several concurrent licensees, each with the same or overlapping rights. Importantly, the terms of licenses are interpreted according to the contract rules of your local jurisdiction. Therefore it is extremely important that the parties understand exactly what they are agreeing to before coming to an agreement.

Licenses and assignments are the two building blocks of software development agreements, and should be a part of every software development contract. If software is not a work-made-for-hire, or the software copyright is not either expressly assigned to the client or licensed to the client at the end of the development project, then the client will infringe the developer's copyrights in the code every time the client uses that code. Therefore, every well written software development contract will contain a clause designating the code a work-made-for-hire, assigning the code to the client on completion, or granting the client a license to use the code on completion.

Putting it Together, A Sample Contract Clause

It is not uncommon for contracts to have a clause or series of clauses addressing all three of the above ideas, work-made-for-hire, license, and assignment. Below is an example of a typical section addressing copyright partitioning:

The copyright in all works of authorship created pursuant to this agreement are owned by Client. All such works or portions of works created by Developer are "works made for hire" as defined in 17 U.S.C. § 201. Developer assigns to Clients all right, title, and interest in:

(a) The copyright to all works of authorship ("Work") and contribution to any such Work ("Contribution") created pursuant to this agreement;

(b) Any registrations and copyright applications, along with any renewals and extensions thereof, relating to the Contribution or the Work;

(c) All works based upon, derived from, or incorporating the Contribution or the Work;

(d) All income, royalties, damages, claims and payments now or hereafter due or payable with respect to the Contribution or the Work;

(e) All causes of action, either in law or in equity, for past, present, or future infringement of copyright related to the Contribution or the Work, and all rights corresponding to any of the foregoing, throughout the world.

Developer may use the Work only until Developer delivers a final product to Client, and may use the Work only insomuch as such use is necessary to the creation of the final product. Client grants no license to developer for any use of the Work other than as expressly described herein. Developer must request a separate license from Clients for any use of the Work other than as expressly described herein. Such license must be explicitly granted in writing, signed by Client, or it is void. Should a court of law with jurisdiction over the parties and the subject matter of this contract deem the Work not a "work for hire," and should a court of law with jurisdiction over the parties and the subject matter judge the above assignment of copyright void, Developer grants Client an exclusive, royalty-free, irrevocable worldwide license to use the Work without limitation in any manner Client deems appropriate.

This clause attempts to cover each of the bases for the client to control the work, first by asserting that the work is a work-made-for-hire, then, by assigning the work to the client, and licensing back only the rights to the code necessary for the Developer to work on the project at issue, and finally, by granting the client an unlimited license for use of the work, in the event a court deems the code neither a work-made-for-hire, nor lawfully assigned. This particular example gives all of the rights to the code to the client. Of course, each of the component parts of this clause can and should be negotiated beforehand. Under a contract containing the clause above, the developer would not be allowed to re-use the code developed for the project. In negotiations, the savvy developer must understand each of the components to the above clause, and understand the ownership interest in the code each clause represents.

Open-source software platforms complicate the ownership of code

Open-source software is ubiquitous today, and it is impossible to develop software without encountering some form of open-source code, either as a platform on which to develop your software or as a component of your software. The key to understanding the implications of open source software on development is the understanding that open-source software, while free, is not in the "public domain." Open-source software is copyrighted software, the proper use of which is mandated according to the particular terms of the license. Importantly for developers, derivative software that is based on open-source software must generally conform to the terms of the original open source license, while software written to perform on an open-source platform need not. For example, if you write a flavor of Linux for use with a particular hardware suite, you must grant access to your source code in the same way you have been granted access to the Linux source code. Conversely, if you write a program to run on the Linux operating system, you need not conform to the GPL 2 open source license under which Linux is released, because in that case, Linux, while necessary for your software to function, is not a component of your software. In copyright terminology, your software is not a "derivative work" of Linux.

On the distribution side, if you choose to release your software under an open-source license, be aware that there are different flavours of open-source licenses. (See, for example, the Wikipedia entry on "Open Source Licenses" describing, comparing and contrasting many of the licenses.

Each flavour allows users of the software to do slightly different things, places slightly different restrictions on the user's use of your software, and grants slightly different remedies in the event a user breaches the open source agreement.

What It All Means

There are a number of things you can do while negotiating a development agreement to ensure that you can fully leverage the power of re-usable code, and that your interests in the code you write are protected. The following are a sample of the most important things you should consider before you write a single line of code:

Get agreement in writing on ownership of the code before you write a line of code: In almost every aspect, copyright law defers to the agreement between the parties. Before you start writing code for a project, make sure that both you and the client completely understand each other's expectations for who will own the copyright in the code and what rights the respective parties will have to use the code when the project is over.