December
2007
Dru Lavigne
Improving Application Development
by Managing Licensing Issues
Doug Levin
Ensuring Software IP Cleanliness
Mahshad Koohgoli & Richard MayerA Rallying Moment for Canadian
Open Source Software
Andy Kaplan-Myrth
An Introduction to Rights Expression
Languages
G. R. Gangadharan & Michael Weiss
Key Changes to the GNU General
Public License
Eric Smith
Protecting Information Technology
Property Rights
Russell McOrmond
Call for Proposals
Letters to the Editor
Newsbytes
December
2007
Editorial
Dru Lavigne
Improving Application Development by Managing Licensing Issues
Doug Levin describes best practices for managing intellectual property applicable to component-based development.
Ensuring Software IP Cleanliness
Mahshad Koohgoli & Richard Mayer discuss the current generation of solutions for managing software IP
cleanliness.
A Rallying Moment for Canadian Open Source Software
Andy Kaplan-Myrth argues that Canada needs copyright laws that support the open source model.
An Introduction to Rights Expression Languages
G. R. Gangadharan & Michael Weiss introduce the attributes of rights expression languages.
Key Changes to the GNU General Public License
Eric Smith highlights the changes between version 2 and version 3 of the GNU General Public License.
Protecting Information Technology Property Rights
Russell McOrmond outlines the new copyright legislation which is before the Canadian Parliament.
Call for Proposals Letters to the Editor Newsbytes
Upcoming Events Recent Reports Contribute
3
4
11
17
22
25
29
34 36 38 39 40 41 PUBLISHER:
The Open Source Business Resource is a monthly lication of the Talent First Network. Archives are available at the website: http://www.osbr.ca EDITOR:
Dru Lavigne dru@osbr.ca
ISSN: 1913-6102
ADVERTISING: Rowland Few rowland@osbr.ca
GRAPHICS: Ryan May
ADVISORY BOARD: Tony Bailetti
John Callahan Kevin Goheen Peter Hoddinott Thomas Kunz Steven Muegge Trevor Pearce Stoyan Tanev Michael Weiss
As 2007 draws to a close, three emerging trends are gaining momentum. The first is that companies are releasing formerly pro-prietary code under an open source li-cense. The second is that open source companies are being acquired or are issu-ing public offerissu-ings. The third trend is that very large number of citizens increasingly uses the Internet to oppose politicians and law makers who threaten, sometimes unwittingly, the fundamental principles of open source development.
These three trends tie into this month's editorial theme: Clean intellectual prop-erty or clean IP. In a nutshell, clean IP is about reducing license incompatibilities and non-compliance with licensing terms. Clean IP significantly affects the value of the code released as open source and the value of a company that develops and markets software.
One takeaway from this issue is that those companies with clean intellectual property (IP) stand to gain significant competitive advantages. In the first art-icle, Doug Levin, the CEO of Black Duck Software, identifies the best practices for managing IP in development environ-ments that use open source components, commercial off-the-shelf components, and proprietary components. Then, in the second article, Mahshad Koohgoli and Richard Mayer, Protecode's CEO and Vice President of Marketing respectively, exam-ine the various methods of ensuring soft-ware IP cleanliness.
In the third article, Andy Kaplan-Myrth from the University of Ottawa discusses the importance of consultation process for the upcoming legislation on Canadian copyright. He is followed by two academ-ics, G.R. Gangadharan (University of Trento) and Michael Weiss (Carleton Uni-versity), introduce rights expression lan-guages. These languages express rights, fees and conditions as machine
action-Eric Smith, a lawyer with the firm Fraser Milner Casgrain, explains the changes in-troduced in version 3 of the GPL. In the last article of this issue, Russell McOrmond, an Internet and F/LOSS con-sultant, provides a perspective on the copyright bill expected to be introduced in early 2008. Many Canadians have ex-pressed concerns about this bill.
In addition to the six articles, this OSBR issue includes a call for proposals from the Talent First Network and a letter from David Fewer inviting our readers to join the Canadian Software Innovation Associ-ation, a coalition concerned about the negative consequences of importing US-style digital copyright legislation to Canada.
2008 will see some exciting changes for the OSBR. The first will be a move to a new open source publishing system. OS-BR readers, authors and reviewers will be-nefit from the functionality of the new system.
Happy holidays.
As always, we look forward to reading and publishing reader feedback.
Dru Lavigne, Editor-in-Chief dru@osbr.ca
Improving Development
“Software assembly, whereby developers re-use already created code components, is dramatically changing how applications are built. The efficiencies are realized if de-velopment teams establish processes to manage how code is assembled, and to as-sure that the use of the code components is in compliance with the various licenses governing the code.”
Doug Levin, CEO of Black Duck Software
Over the past ten years, the Internet and open source software (OSS) have enabled developers to fundamentally change the way they produce software. Increasingly, distributed teams are collaborating to as-semble software from reusable compon-ents and their own proprietary code rather than building applications entirely from scratch.
The component-based development model is fundamentally changing the software industry. It enables organiza-tions that develop software, either for commercial sale or for in-house use, to accelerate project timelines, improve soft-ware quality, and reduce development costs. If not managed properly, the com-plexity inherent in this new world of mixed-IP (Intellectual Property) can pose business and technical risks to an organ-ization.
This paper draws on the experiences of the Black Duck Software team
(http://www.blackducksoftware.com), our customers, and other industry ex-perts to propose new approaches to man-aging IP in this new world. It describes a set of best practices that companies can use to avoid the risks and gain the bene-fits of the component-based approach to software development.
Component-based Development
Development organizations have long understood the virtues of building new applications by re-using components already built and tested. Indeed, the evol-ution and rapid adoption of component-based architectures has been driven in part by their effectiveness in promoting economically-significant re-use. It is therefore appropriate to consider com-ponents as IP assets, optimize their us-age, and protect their integrity. This applies equally to all components, wheth-er they are intwheth-ernally developed or de-veloped externally by a third party.
A development team intent on exploiting an externally developed commercial com-ponent does not typically purchase own-ership of that component. Instead, they acquire a license to use that component in a specified manner--perhaps for only a certain number of developers working on a particular project, or with a specified royalty paid for each instance of a shipped product that includes the com-ponent. Thus, business judgment is re-quired to ensure that the cost of licensing a commercial component is more than offset by the benefits.
Included in the cost analysis must be the effort required to ensure compliance with the license; for example, limiting the component’s usage to a specific project, or tracking shipments in order to accur-ately calculate royalty payments.
Open Source Opportunity
Re-use can take many forms, including bundling independent components, tegrating with or using libraries, and in-corporating source code or source code fragments. In some cases these compon-ents can be modified as required to im-prove functionality, quality, performance, or footprint. As with commercial com-ponents, the ownership of externally de-veloped OSS components and fragments remains with their authors. While most of these authors allow the commercial use of their software without initial payments or royalties, many have chosen to impose other constraints, such as:
• Attribution
• Usage reporting
• Publication of modifications and improvements
• License replication
• Resulting software must be open source
Such constraints are imposed by means of licenses. Examples of open source licenses include the:
• Apache Software License (ASL)
• Common Public License (CPL)
• GNU General Public License (GPL)
• Mozilla Public License (MPL)
• New BSD License
A more complete listing of open source li-censes is provided at
http://www.opensource.org/licenses.
Open Source License Compliance
Development teams that incorporate OSS components or fragments of OSS components in their projects must com-ply with the terms of the licenses associ-ated with those components. This can be challenging for several reasons including the following:
• There is wide variation in the tions imposed by open source licenses, ranging from the BSD license (which has few obligations) to the GPL license (which has many)
• Some open source licenses are legally complex, introducing constraints whose business implications may not be us to a developer choosing to re-use a component
• The licenses of some commercial and open source components are mutually incompatible
• The origin of a particular source code fragment may be difficult to determine, effectively obscuring its license tions
• Discovering the need to comply with a license late in a project’s lifecycle can produce disagreeable tradeoffs, such as publishing all of the project’s source code v.s. increasing time-to-market by months while a component is replaced
Improving Development
Management Alternatives
Organizations can react to the challenges of OSS licenses in one of three ways. Some organizations turn a blind eye, ig-noring the issue until a catalyzing event or crisis occurs. But the resulting misfor-tunes--major code rewrites, embarrass-ing negative publicity, delayed sales, failed acquisitions--make this an increas-ingly untenable approach. This is espe-cially true in the new environment of increased business transparency, execut-ive responsibility, and potential share-holder lawsuits.
Other organizations take the Draconian approach of banning all OSS re-use. This strategy is flawed because it:
• Is difficult to enforce
• Decreases productivity and agility pared to organizations that successfully re-use externally developed ents
• De-motivates development teams by requiring them to apply scarce resources to develop components from scratch and test them rather than moving ward
The first two approaches fail to recognize the reality that open source and compon-ent reuse are here to stay. The third and recommended alternative is to encour-age the re-use of both internally de-veloped and externally developed (commercial and open source) compon-ents, while establishing controls at critic-al points in the project lifecycle, for example:
• When components are first added to a project
• When internally developed components are created or modified
• At every build
• At each phase transition in the ment process
• When considering the contribution of a component to an open source project or the transfer of its ownership to another party
• Before acquiring a significant ownership interest in a software component
It is important to note that identifying problematic licensing issues early in the development cycle is tantamount to de-tecting serious software defects. The earli-er a problem is detected, the less expensive it is to fix. While IP controls late in the development cycle, during testing or release assembly, are better than none, the earlier they happen in the lifecycle, the better.
Preparing for IP Management
To adopt best practices, several tasks should be considered by the individual or teams responsible for development and li-censing. An organization intent on man-aging its software IP should identify the responsible business, legal, and technical individuals who will be involved in the process. The organization also should designate them as authorizers for each active project, and commission them as a group to oversee and manage the plan-ning, implementation, and ongoing man-agement of the process.
Best Practices for IP Management
Whenever a development team considers adding new features or refining existing functionality in a project, it should expli-citly seek internally developed and ex-ternally developed components that could accelerate delivery. The team should establish criteria for selecting and procuring these components. As would be expected, any component under con-sideration that fails to meet functionality, performance, reliability, maturity, or risk requirements should be eliminated.
The team should also eliminate any ex-ternally developed component whose li-cense is on the prohibited lili-cense list, whose license obligations are financially or legally incompatible with the project’s business objectives, or which uses other external components or fragments whose licenses are similarly unacceptable. For example, an organization developing a product that will be delivered under a proprietary license needs to be certain that any open source or proprietary li-censed code that is incorporated can be safely included without causing an irre-concilable conflict between licenses. Any components that pass this initial test should be subjected to a make-buy ana-lysis to determine whether or not its ac-quisition makes sense from a business perspective.
To protect the organization’s critical IP, the creation and modification of all in-ternally developed components should be tracked by recording a timestamp, the names of each author, and the applicable objectives and constraints. If a newly-cre-ated or modified component is suspected to be sensitive, the project’s legal, busi-ness, and technical reviewers should be convened. If these reviewers deem the component to be sensitive, they should add it to the organization’s list of sensit-ive internal components.
Another organization might extend its view of internal software to include li-censed proprietary software and software developed by its contractor and out-source partners. On the other hand, a de-partment of a large corporation may want to consider its department internal and consider everyone else, including other departments in the same company to be external. Business judgment must be used to determine where the bound-ary should lie.
Another key preparation task is for the team to identify the development process phase transitions at which component re-use reviews will be conducted. The team should define criteria for designating an internally developed component as sens-itive, for example due to trade secrets or patents, and develop and maintain a list of these sensitive items. The organization also should consider establishing and maintaining lists of:
• Licenses that are prohibited by the organization
• Externally developed components that, based on previous reviews, are approved for use in projects, and the situations in which use is approved
• Internally developed components that, based on previous reviews, are approved for contribution to open source projects or disposition to third parties
Improving Development
By assessing sensitivity and license oblig-ations at the point where a component is first being considered for re-use, de-cisions can be based on verifiable facts, eliminating last-minute surprises, guess-work, compromises, and risk-taking. This dramatically reduces the risk of schedule slippage, cost overruns, and damage to the organization’s reputation. It also helps prevent the inappropriate re-use of critical IP.
For each component that a project’s de-velopment team proposes to use within a project, the team should understand:
• The intended use and rationale for inclusion
• The component’s sensitivity
• How the code will be incorporated
How the team deals with the component will depend, in part, on whether plans call for that component to be used tem-porarily or permanently. For example, the intent may be to use that component for a limited amount of time only to speed up prototyping or to advance the early phases of the development cycle, but not be intended to be made a permanent part of the code base.
Another determination the team should make is whether a component will be used only as is, or if modifications will be allowed, and if so, under which ap-provals. Development teams should de-scribe the method of joining that will be used to incorporate the component into the project. This is an effective step be-cause different types of joining can create different licensing obligations.
To achieve greater control over compon-ent re-use, teams should also take the fol-lowing actions:
• Determine whether the component has been previously approved for the posed form of use
• Declare the component’s version and understand its license obligations as well as those of any externally oped components or fragments it con- tains or depends on
• Understand all potential ies between the component’s license obligations and the license obligations of other externally developed ents included in this project
• Present the above information to the project’s legal, technical, and business authorizers and request approval to use the component as described
• If the component is internal and ive, the list that covers these items should be updated to note that ent’s inclusion in this project
• If the component is externally oped, its metadata and approval details should be recorded in the list of proved external components
Inspecting the code base on a regular basis decreases the likelihood that unex-pected components will be introduced without being noticed. Therefore, at the creation of each project build or at re-lease assembly, the development team should verify that:
• No unapproved sensitive internally or externally developed components or fragments have been added to the ject
• No changes have been made to ally developed components whose form of use precludes changes, or requires that all changes be approved
Any inappropriate additions or changes discovered during verification should be immediately addressed, either by obtain-ing approval from the project’s legal, tech-nical, and business reviewers, or by backing out the offending modification. The root cause of any component misuse should be identified and corrected to en-sure no subsequent regression. By promptly and diligently assessing every build and release, the development team will be able to detect errors when they are least expensive to correct.
At the completion of each build or re-lease, the key metadata for all externally developed components should be recor-ded in the associated bill-of-materials. This enables demonstrable compliance with license obligations, and eliminates any uncertainty caused by changes between project releases by providing a clear audit trail. As a project completes a major development process phase, its leg-al, technicleg-al, and business reviewers should do the following:
• Verify that no unapproved sensitive ternal or external components or ments are used in the project
• Verify that no unapproved changes were made to sensitive internal components, and that no unapproved or precluded changes were made to external ents
• Review the license obligations of all ternal components used in the project, and ensure compliance with these ations
These phase reviews backstop the devel-opment team, and keep the legal, tech-nical, and business reviewers engaged in the management of software re-use. They also verify that changes in the project’s objectives have not created legal, technic-al, or financial inconsistencies with the li-censes of components used in the project.
The rationale for contributing compon-ents to an open source project is beyond the scope of this report, as are the consid-erations involved in transferring owner-ship to a third party or creating a new open source project. However, if a contri-bution or transfer of a candidate compon-ent or fragmcompon-ent is deemed appropriate, the project’s legal and business reviewers should:
• Determine whether the candidate ponent’s sensitivity is an impediment to contribution or transfer
• Verify the right to contribute or transfer every externally developed component or fragment contained within the idate
This helps to ensure that the organization does not inadvertently contribute code that shouldn’t be added because of its sensitivity or because the organization is not entitled to supply it. If an organiza-tion is considering an acquisiorganiza-tion that would include a significant interest in one or more software components, the designated set of legal, technical, and business reviewers should be charged with the following:
• Identifying all included components not owned by the supplier or target
Improving Development
• Assessing the impact of any required rework or change on cost, revenue, and quality
Note that this best practice applies to a variety of situations in which financial in-vestments are involved. Such situations include: company mergers and acquisi-tions, product acquisiacquisi-tions, joint venture formations, and venture capital invest-ments.
Conclusion
By integrating these practices in to devel-opment processes, organizations will have far greater assurances of compli-ance with all relevant license obligations and far more effective protection of soft-ware IP. Adopting these practices will en-able companies to be more aggressive in their use of the software assembly ap-proach. That, in turn, will enable those companies to more quickly gain the bene-fits and competitive advantage this new development approach promises includ-ing accelerated project timelines, im-proved software quality, and reduced development costs.
Doug Levin is president and CEO of Black Duck Software. Prior to founding Black Duck in 2002, Levin served as CEO of MessageMachines (acquired by NMS Com-munications in 2002) and X-Collabora-tion Software CorporaX-Collabora-tion (acquired by Progress Software in 2000). From 1995 to 1999, he worked as an interim executive or consultant to a range of software com-panies, including CMGI Direct, IBM/Lotus Development Corporation, Oracle Soft-ware Corporation, Solbright SoftSoft-ware, Mosaic Telecommunications, Bright Tiger Technologies and Best!Software. From 1987 to 1995, Levin held various senior management positions with Microsoft Corporation, including heading up world-wide licensing for corporate purchases of non-OEM Microsoft software products. He is a graduate of the University of North Carolina at Chapel Hill and holds a certi-ficate in international economics from the College d’Europe in Bruges, Belgium.
Recommended Resource Best Practices for Managing Software Intellectual Property
"By June 2006, the project has hit the ma-gic "100 cases finished" mark, at an excit-ing equal "100% legal success" mark. Every GPL infringement that we started to enforce was resolved in a legal success, either in-court or out of court."
http://www.gpl-violations.org At many points in the life of a software enterprise, determination of intellectual property (IP) cleanliness becomes critic-al. The value of an enterprise that devel-ops and sells software may depend on how clean the software is from the IP per-spective. This article examines various methods of ensuring software IP cleanli-ness and discusses some of the benefits and shortcomings of current solutions.
Source of the Problem
In any software-producing organization, software projects conceptually comprise iteratively decomposing a project into smaller and more manageable sub-pro-jects until that point where individual sub-projects can be assigned to individu-als or groups. In such a scenario, an indi-vidual software developer assigned to a software sub-project has a combination of options for sourcing the necessary soft-ware, including: (i) obtaining software from their organization’s code repository, (ii) obtaining software from one or more open source repositories, (iii) obtaining software through purchase, and (iv) ob-taining software through the creative pro-cess of writing it.
Depending upon the size and complexity of a software project, this scenario may be repeated many times. Also, when a sub-project is outsourced or otherwise as-signed to a separate organization such as in a collaborative project, the out-sourcing team goes through a similar scenario.
In sum, the software employed by any typical software-producing organization may be derived from such sources as: (i) the organization’s code-base; (ii) open source repositories; (iii) commercial vendors; and (iv) in-house development.
With this scenario in mind, IP integrity of the final product is very much a function of: i) individual pieces and ii) the IP prac-tices that were defined, monitored and enforced during the development pro-cess.
We observe that the IP integrity of the software produced can be compromised in ways that include:
• The organization’s code repository may have impure artifacts that are duced into the product
• If used, the outsourcer’s repository or the collaborative organization’s ory may have impure artifacts that are submitted
• Open source components do not satisfy the open source policy of the tion, assuming that the organization has an open source policy, and it has been appropriately communicated
• Open source components introduced by outsourcers or collaborators may not satisfy the open source policy or may be improperly checked and verified against existing policies
• The license governing the use of certain commercial code may be improperly censed for the application, geographic market, or the mode of deployment
Ip Cleanliness
For example, a recent survey indicates that about 70% of developers carry code from one company to another
(http://www.itfacts.biz/index.php?id= P1134). Anecdotal experience suggests that the real percentage may be higher.
The situation gets more complex if we consider that code repositories can be-come contaminated because of “genera-tional tainting” properties of licenses such as the GPL, or more generally, the pedigree of open source code may be un-known or difficult to categorically estab-lish.
In this article, we do not address inten-tional code contamination and instead focus on unintentional contamination as we believe that most code contamina-tions are unintentional. For any software project of sufficient size it is generally dif-ficult to understand exactly what is in the software by the time the software is col-lected, integrated, tested and released. It may be very costly and time consuming to perform the necessary due diligence to identify what problems may exist.
An immediate conclusion we can draw from the preceding is the importance of employing safe software development practices. That is, we advocate a prevent-ive approach aided by policies, education and tools.
Who is Affected
Understanding the IP pedigree of soft-ware is important and is becoming an in-creasingly common requirement in many enterprises that create and/or use soft-ware. In what follows, we first describe the software food chain, and then exam-ine how it can impact the players.
The software industry chain may be de-scribed in simple terms.
The chain consists of increasingly larger and more complex organizations that “consume” software by bringing in soft-ware from other (typically smaller) firm(s), combining the software with their own “value-added” functionality, and passing the result on to the next (typ-ically larger) firm in the chain.
To show the scope of the firms that can be affected by contamination, let’s use an example. The software chain in the cellu-lar phone industry consists of:
• Small developers and independent ware vendors that contribute hardware drivers or protocol stacks to the chip makers
• Chip makers that add their own content and pass it on to the cell phone vendor
• The cell phone vendor adds tions and graphical user interfaces, again obtained from other players and internal development teams, and passes these on to the operator
• The operator may add its own ized content such as splash screens or operator-specific applications and pass these on to the end user
In this example, there could be twenty or more players involved. An IP contamina-tion anywhere in the food chain would af-fect many players.
Attention on IP purity is heightened gen-erally when there is a transaction in-volved. The nature of the transaction could be:
• Investment in an organization that ates or consumes software
• Public Offering by a player in the chain
• A software transfer from one player to the next in the chain, such as a ing or software licensing event
Such transactions contribute to the cre-ation of a whole industry centered on verifying software cleanliness through due diligence. Another contributor is the clauses on representations and war-ranties or IP indemnity in legal docu-ments supporting such transactions. It is increasingly common to encounter IP lawyers and Venture Capitalists (VCs) and be regaled by stories of transactions that have been delayed or lost (i) due to the time that it takes to verify cleanliness, or (ii) due to ambiguities around IP owner-ship. All of which advocates the need for adopting and deploying safe software de-velopment practices.
IP Contamination is Prevalent
The scope of IP contamination is expand-ing, and is better understood when we ex-amine its contributing factors and the momentum behind them.
The use of open source software (OSS) is increasing dramatically, shifting the models and metrics behind software de-velopment. Software re-use, code visibil-ity, efficient development intervals, costs, and enhanced functionalities are some of the positive attributes driving the increas-ing use of open source. However, very specific licenses regulate the use of OSS and the terms of many of these licenses differ and not uncommonly require ex-pert interpretation.
Aside from OSS, other growth areas for contamination include:
• Designer previous-life contamination, which we described earlier, is common
• Outsourcing, on-shore or off-shore, is expanding, with the additional danger of cross-project contamination
• E-bidding for software as in
http://www.elance.com is growing • Collaborative development is becoming common with universities, governments and industries as players
In sum, we reiterate our belief that most contamination is unintentional, and hap-pens when safe development standards and practices are absent in the software organizations of the food chain.
Current Prevention Methods
We have grouped the general methods of managing IP contamination into two groups: i) corrective methods, which try to detect contamination or IP policy in-fractions in a piece of software, and ii) preventive methods, that strive to stop unintentional penetration of undesirable code in a project.
We will further divide these methods into manual and automated techniques, and will comment on their suitability and per-ceived short comings.
Corrective Solutions
Ip Cleanliness
The general objectives behind corrective solutions are: (i) to detect possible IP con-tamination; (ii) to identify the external source from which the IP contamination was derived; (iii) to determine the validity of suspected IP contamination; and (iv) to appropriately respond to the possible IP contamination. IP contamination can take one of two forms: (i) a complete module or file, or (ii) a snippet such as a subroutine or method within a module or file. It is noteworthy, reflecting that IP contamination is seldom malicious, that it is not uncommon for an IP contamina-tion object to have associated comments that clearly identifies the source or copy-right owner of the object.
Corrective solutions can be quite sophist-icated and there can be value to just per-forming one or more of the above objectives. For example, it is not always necessary to identify the source from which an IP contamination object was de-rived. Lexical and grammatical analysis of a file can be employed to detect and flag explanation changes in coding style. Also, detection and identification may be one and the same. A precautionary sweep of all the files used in a load build may be performed to ensure there are no inad-vertent and unaccounted for dependen-cies on commercial or open source licensed software modules.
Corrective solutions typically involve a combination of both manual and auto-mated processes. A comprehensive and formal review may be performed by an in-ternal team of code reviewers and legal council as part of the general develop-ment process. This may be an extension to the typical code review that is com-monly employed during the development process to find bugs and improve the soft-ware.
Alternatively, an external commercial due diligence service may be employed to provide an independent assessment in or-der, for example, to validate that the soft-ware asset being sold rightfully belongs to the seller. In either case, the process involves examining various artifacts such as the software bill-of-materials, software files, and documentation files, determin-ing the sources of various artifacts, and interviewing developers. In short, looking for indicators of external artifacts and upon finding suspects, investigating the IP attributes of these suspects.
The more common commercially avail-able automated tools typically address the identification of external software modules/files together with external source code within modules/files. To ac-complish this function, these tools have associated repositories containing soft-ware modules/files, actual source code, and the equivalent of code fingerprints known as codeprints. These tools accom-plish their objectives by comparing a giv-en artifact against the contgiv-ents in the repository. Such repositories are com-monly assembled by mining the vast col-lection of generally available OSS as well as contributed commercial software source code, object files, library files, and executables. The contribution of such commercial software creates a win-win for everyone involved as:
• The owners of the commercial software are increasingly confident that their code is being properly used
• The developers of software are ingly confident that their market offer is not exposed to the risks associated with inadvertently incorporating commercial software
A few examples of the automated mech-anisms used to detect and identify extern-al code snippets include:
• Comparison and correlation of the pet with various snippets of code ing in a repository
• Computing a codeprint for the snippet and comparing this codeprint against a repository of pre-computed codeprints
• Scanning the snippet for keywords such as "license", identification marks such as "written by", and copyright notices
As mentioned, generally a combination of manual and automated methods are employed. Two noteworthy academic projects in this field are: (i) MOSS (Meas-ure Of Software Similarity) in Stanford University (http://theory.stanford.edu/ ~aiken/moss/), and (ii) JPLAG
(https://www.ipd.uni-karlsruhe.de/ jplag/) in Karlsruhe University. Limitations of Corrective Solutions Although the steps for corrective solu-tions are relatively straight forward, prac-tically they are very labor intensive, time consuming and expensive. Increasing automation makes this endeavor more feasible, which is contributing to an in-creasing use of such tools for software de-velopment. Which, in turn, is resulting in an increase in the innovation and availab-ility of market offers addressing this area.
However, there are limitations to correct-ive solutions. Even with automation and aggregation, corrective solutions can not detect external content unless they can identify it. In other words, if an external content is not available in the tools’s re-pository or is not otherwise detectable by being clearly marked or stylistically differ-ent, it cannot be detected.
And in particular, it is extremely difficult, if not impossible, to detect proprietary ex-ternal content since generally it is not available for comparison purposes.
Even if the external content does exist in the database, the comparison process is not always 100% accurate. Moreover, the comparison process is computationally intensive, requiring a tight linkage between the comparison algorithms and the repository. This typically requires co-locating the repository and the code to be examined.
Corrective solutions address the relat-ively well defined issue of spotting IP con-tamination. There are, however, a myriad of related and overlapping issues. Not-able among these issues is software pedi-gree, or “who wrote this stuff?”. Software pedigree is concerned with determining whether or not the copyright license at-tached to a file/module or code snippet is properly attached and that the license really does apply. Another issue sur-rounds determining what constitutes a software derivative as some OSS licenses require all derivatives of a given work to be licensed under the same license as the original.
Possibly the most significant limitation associated with corrective solutions is that they are corrective, occurring after the fact. Resolution of any corrections can impact the project’s completion date, transaction closing and sales cycle, and add unanticipated costs to the overall project.
Preventive Solutions
Ip Cleanliness
Among the more widespread manual pre-ventive solutions is education. Education includes organizations setting policies and rules for acceptable and safe coding practices, as well as the associated com-munications and training. These include the introduction of guidelines that are well documented, generally available for developer reference, and are integrated into the company’s practices.
The success of education in addressing IP contamination is dependent upon a num-ber of factors, including the education program employed and the ethical beha-vior of the programmers. While recog-nized as clearly important, education will generally be insufficient in and of itself to prevent IP contamination, both mali-cious and non-malimali-cious.
Another preventive solution is setting the requirement that only specific code may be used. Again, rules must be defined, documented and communicated on the acceptable practices and sources of code. A common criticism of this solution is that it may not generally apply. For ex-ample, programmers may find that it lim-its their choices and needs, and that acceptable alternatives become hindered by approval processes. Pressures of dead-lines and deliverables create an atmo-sphere of tension between following the process and adhering to the rules. It is noteworthy that we have recently seen the emergence of successful commercial ventures that offer a database of IP-in-demnified, pedigreed OSS.
Automated preventive solutions rely upon the detection and identification of external content immediately upon it be-ing introduced into a project. Integration of the preventive solution within the de-velopment environment enables detec-tion of external content, although it may not necessarily automatically identify the source of that content.
Detection can flag the introduction and optionally require the developer import-ing the code to annotate the source for fu-ture reference. Timely detection of the company’s IP policy violations and pos-sible immediate correction is included among the advantages of automated pre-ventive solutions. Like corrective solu-tions however, preventive solusolu-tions do not address the related issues associated with determining software derivatives.
Summary
The software development industry is wit-nessing a transition, brought about by the explosive growth of OSS, code-search en-gines and outsourcing practices. The new order brought about by this transition car-ries certain IP challenges that must be ef-fectively handled, otherwise the results could be catastrophic for a software com-pany. IP policies must be set, monitored and enforced.
"A balanced approach to intellectual prop-erty rights is vital to economic growth."
Committee for Economic Development
In the Canadian copyright reform arena, the events of early December, 2007, changed everything.
In late November, it was widely anticip-ated that new copyright legislation would be introduced in the model of the contro-versial American Digital Millennium Copyright Act (DMCA). The bill was rumored to include harsh “anti-circum-vention laws”, which grant software dis-tributors the right to seek legal remedies for circumvention of technological locks on content. In response, veteran Cana-dian copyright advocates issued an ap-peal to Canadians to take an interest in the bill and to call for fair and balanced copyright.
Canadian citizens answered that call in unexpected numbers, both online and offline. A Facebook group, called Fair Copyright for Canadians, grew to over 25,000 members within two weeks, and provided grassroots advocacy tools to cit-izens. A new website, called Copyrightfor-Canadians.ca, established itself as a centre for news on the bill and consumer advocacy. Using these tools, Canadians wrote letters, met with politicians, and demanded balance. With their words and their actions, not only did Canadians delay the introduction of the bill until next year, but they put copyright in the spotlight and showed legislators that fair and balanced copyright can capture the public imagination.
Industry Minister Jim Prentice now has the opportunity to hear from groups rep-resenting Canadian perspectives on copy-right, hopefully resulting in a better and more balanced bill.
Open source developers have a unique re-lationship with copyright, with licences and practices enabling them to flourish in the copyright ecosystem. Open source software businesses are uniquely situated to comment on the copyright balance, since open source developers rely on copyright both for protection of their ware, and for freedom to access the soft-ware of others. In the consultation process to come, the Canadian Software Innovation Association (CSIA) is in a posi-tion to be the voice of the Canadian open source industry.
The CSIA is a growing coalition of busi-nesses, nonprofit organizations, individu-als and user groups working in the business of free and open source soft-ware. The CSIA is an organization that ad-vocates copyright laws in Canada that continue to support creativity and en-courage innovation in the Canadian soft-ware industry while offering users necessary freedoms. The CSIA is being formed around a white paper, available at the CSIA's website
(http://softwareinnovation.ca/
whitepaper/). The white paper builds a case for Canada's need for copyright laws that support the open source model. The white paper offers three points to sup-port this case: i) an account of Canada's open source business community and the economic contribution of open source to the marketplace; ii) an account of open source and its relationship to copyright law; and iii) an account of how anti-circumvention laws undermine open source software.
The CSIA offers guidance to the govern-ment on how to do so.
This short article offers a summary of the CSIA white paper, and issues a call to arms for open source developers: good laws don't just happen; law-makers need to understand the interest is in the bal-ance. The CSIA offers a way to make your voice heard in copyright policy debates.
Economic Contribution of Open Source Open source software (OSS) offers many practical and economic benefits to both open source businesses and users. Open source offers the public sector and small, medium, and large businesses alike, pro-ductivity and efficiency gains and other practical benefits such as specialization and scaling to meet a user’s specific needs. Viewed more broadly, the open source model is a hotbed of innovation that contributes to Canada’s economic well-being.
A 2005 Statistics Canada report discloses that open source software occupies a sig-nificant fraction of software operated by both private and public sector organiza-tions. Over half (52.7%) of all public sec-tor organizations reported using open source software. Among private sector firms, over two thirds (37.3%) of large firms reported using open source soft-ware, with less being reported by medi-um (16.5%) and small (9%) businesses (although these figures likely under-re-port open source usage through out-sourced web services).
More work needs to be done to educate smaller businesses about the benefits and capabilities of open source software. Smaller businesses would benefit the most from the cost savings and flexibility that open source software delivers.
rallying moment
Open source consumer applications, such as the Firefox browser, Ubuntu Linux-based operating system, Apache web-server, MySQL database program, and OpenOffice productivity suite, are also increasing market share.
There are many economic advantages to using open source over proprietary soft-ware:
• Reduced Cost: considering the total cost of ownership of software, including the maintenance and support, in most cases OSS is less expensive than equivalent proprietary software
• Security: open source code is ent to users, making software vendors more accountable, giving users and developers access to the source code and allowing them to identify vulnerabilities and provide or push for fixes in a timely manner
• Efficiency, scalability, and innovation: software upgrades can be controlled and determined by users and not the ware vendor and the software may be easily customized to meet the specific needs of its users
Finally, open source encourages choices between vendors and programs and pro-motes interoperability for all users.
This includes creating a business climate that is free of hurdles for open source im-plementation. Canada has a small but strong history of open source contribu-tion. Nonetheless, Canada lags behind both the United States and the European Union in terms of open source develop-ment.
Open Source Software and Copyright Copyright law is central to the philo-sophy and practices of open source de-velopers. The public policy underlying Canada’s copyright law seeks to balance the public’s interest in rewarding authors for their creative efforts with the public’s interest in access to those works. Open source developers similarly have interests on both sides of that balance.
Copyright law grants OSS developers ex-clusive rights in the computer programs they create, including the exclusive right to reproduce, distribute, and adapt and modify the software. Open source de-velopers rely upon these exclusive rights to dictate the terms under which their software may be distributed and used. Open source developers collect these terms into standard licence agreements, simple legal documents that predictably and economically communicate the con-ditions under which the software may be used, adapted and distributed. The busi-nesses and users that do not abide by the licence terms infringe copyright. The OSS copyright owner may seek remedies for infringement; the same way that the own-er of copyright in a proprietary program might.
In return for the grant of copyright pro-tection, the creator of a work is required to let the public engage in certain activit-ies with the work created. This is often de-scribed as the “copyright bargain” in the sense that allowing access is the price the author pays for the benefit of copyright
The development of open source soft-ware requires access to computer pro-grams for many reasons, including the need to develop innovative extensions or extend the functionality of existing soft-ware, to undertake security research and to make code interoperable. Access to code is also required to research function-ality, which includes reverse engineering code to identify non-patented inven-tions. Copyright law recognizes the value of these activities, and the need to place them beyond the absolute control of the copyright owner.
Technological Measures
Technical measures are ubiquitous, con-sumer-level digital technologies that al-low copyright owners control over the distribution and use of software and digit-al content. Technicdigit-al measures add a second layer of content protection that is independent of and in addition to copy-right protection. The WIPO Internet Treat-ies oblige states to give legal protection to Technical measures. These legal protec-tions, collectively known as “anti-circum-vention laws”, offer content distributors a third layer of protection.
Technical measures, like all technology, are fallible. Accordingly, anti-circumven-tion laws ineffectively prevent infringe-ment but effectively deter legitimate uses of copyrighted works by law-abiding cit-izens, including open source developers.
The best anti-circumvention legislation is no anti-circumvention legislation. Canada should not enact anti-circumven-tion laws. Canada is also under no inter-national or domestic obligation to introduce such provisions. Anti-circum-vention laws chill innovation and offer no further benefit that copyright law does not already offer.
If Canada does enact anti-circumvention laws, it should do so in a manner that avoids the mistakes that other nations have made in respect of such laws, and minimizes the potential for such laws to chill innovation. We suggest that:
• Canada must restrict the application of anti-circumvention laws to instances where a circumventor intends to fringe copyright; common sense tates that legal activity must not be rendered illegal merely because of the presence of technical measures.
• Technical measures are seldom directed primarily towards content protection and, more often, they have itive objects. Anti-circumvention laws s should recognize this reality by cing such protection with legal ures designed to protect the consumer.
• Proprietary software distributors often seek to lock in customers by minimizing interoperability while still satisfying the minimum needs of users. Open source developers, in contrast, seek ability among open source projects and their proprietary counterparts. right's exceptions and limitations tect these efforts. Anti-circumvention laws should not frustrate them.
• Reverse engineering is a crucial tool for achieving interoperability and other legitimate ends. Canada must legislate the right of users to circumvent logical measures for non-infringing poses.
rallying moment
• Secrecy does not protect systems ively. Electronic security is improved through testing by the security munity including academic security searchers and hobbyist programmers. Anti-circumvention laws chill security research since successfully breaching any form of technological measure tecting the underlying software raises the spectre of liability. The United States currently suffers from precisely this search chill. Canada has no such search chill and should not introduce one: bona fide security researchers must not operate under a cloud of liability.
• Even the most restrictive vention laws permit circumvention for certain purposes. Tools to engage in such circumvention must be available in the marketplace to those who need them for legal use.
• Effective laws do not mandate the use of particular technologies. Technology mandates run the risk of losing ance as technologies evolve and impose burdens on creator, user and tion communities.
• Canada's general defense to ment, fair dealing, suffers from cies that undermines its utility, and so undermines the effectiveness of right law as a whole. Canada should expand fair dealing to address its rent structural and technical cies, and to clearly encompass reverse engineering and security research and access for purposes intended to allow interoperability.
Conclusion: A Call to Action
If it chooses to do so, it must do so in a manner that does not undermine innova-tion policy in Canada.
There are many ways that concerned cit-izens and businesses can be active in the copyright reform process, especially now that a window is open for Canadian voices to be heard. The CSIA is a group representing stakeholders in the Cana-dian software industry. The CSIA is work-ing to ensure that copyright legislation in Canada continues to support creativity and encourage innovation in the Cana-dian software industry. Since CSIA mem-bers use new modes of peer production, their position in this area differs from oth-er software industry groups, and will provide a crucial voice in the consulta-tion process. There is power in numbers. By joining the CSIA, you help to ensure that the voice of open source is heard.
Other good ways to get involved include joining 25,000 other Canadians in the Fair Copyright Facebook group
(http://facebook.com/group.php?gid= 6315846683) and adding your name to one of two petitions at Online Rights Canada (http://www.onlinerights.ca/ get_active/copyright_pledge_petition/) and Digital Copyright Canada
(http://digital-copyright.ca/petition/). It is also very effective to write to your MP, the Minister of Heritage, the Minister of Industry, and the Prime Minister. Copy-rightforCanadians.ca offers a number of tools for helping you do just that.
Since much of the motivation for copy-right reform in Canada comes from gov-ernments, organizations and businesses located outside our borders, it is particu-larly important in this context that Parlia-ment carefully evaluate proposed changes in light of their impact on Canada’s interests.
Where the interests of Canada’s creative and innovative industries differ from those of foreign governments and lob-bies, Parliament must act in the interests of Canadians, even where this may be viewed with disapproval by outside forces.
Finally, copyright law is designed to foster innovation and productivity. In or-der to do this, as in other areas affected by copyright, the law must maintain the balance between the interests of copy-right owners and users of copycopy-righted works. In the software innovation con-text, this means granting copyright own-ers appropriate protections while ensuring access for innovative open source developers.
The events of December, 2007 provided evidence of Canadians' interest in the is-sue of fair and balanced copyright laws. As individuals, they have affected the le-gislative process and injected the public interest into the conversation. Now is the time for software innovators to state their position as well, while the window is open for their view to be heard.
Andy Kaplan-Myrth is the Manager of the Law & Technology group at the Faculty of Law at the University of Ottawa and an Associate of the Canadian Internet Policy and Public Interest Clinic. As a joint Pro-ject Lead with Creative Commons Canada, Andy speaks on open source, free culture and the sharing economy and pro-motes the use of OSS whenever the oppor-tunity presents itself.
Contacts
David Fewer, Staff Counsel, CIPPIC dfewer@uottawa.ca
"Language is a process of free creation; its laws and principles are fixed, but the manner in which the principles of genera-tion are used is free and infinitely varied."
Noam Chomsky
The objective of this article is to:(i) ex-tend the discussion of licensing to non-software assets and (ii) provide an intro-duction to rights expression languages (RELs). Licensing is not limited to soft-ware. We can associate a license with any kind of asset that holds intellectual value, and can thus be turned into a source of revenue. Here, our interest is on informa-tion assets, which include software and software components, but also services, processes, and content. For instance, a song that a user downloads from iTunes is an information asset. So is a web ser-vice such as the Google Maps API (applic-ation programming interface).
Licensing and DRM
We begin the discussion by defining two key terms, licensing and digital rights management (DRM). Licensing is a fun-damental way of controlling the distribu-tion of informadistribu-tion assets, and underlies the design of business relationships and strategies. Licensing principles reflect the overall business value of assets to their producers and consumers. Also, licensing is often used to protect the intellectual property rights (IPR) of the producers of an asset. Licensing is both a source of rev-enue and a strategic tool.
In their book Digital Rights Management: Business and Technology, Rosenblatt, Trippe, and Mooney define DRM as an umbrella term referring to the collection of technologies (hardware, software, and services) that govern the access to in-formation assets through associated rights, and controls their distribution (http://tinyurl.com/39kav4).
The foundation of DRM technology relies on our ability to represent the rights over digital assets. RELs represent the rights over assets in a machine-understandable way (http://www.loc.gov/standards/ relreport.pdf). RELs describe different as-pects of usage control, payment, and ac-cess, for a digital access environment.
According to Parrott, a REL consists of four components (http://xml.coverpages. org/RLTC-Reuters-Reqs.pdf):
• Subjects, the actors who perform some operation or action
• Objects, the content against which a subject wants to perform an operation
• Operations or what the subjects wants to do to the object
• A set of constraints or conditions under which an operation can be formed
These components and their relations support a range of models, each describ-ing a way of applydescrib-ing digital rights. In general, a REL expresses the rights of an information asset either in some form of logic or in an XML-based language.
To illustrate these concepts, let us as-sume that a user wants to download a song from the iTunes store and play it on his iPod. The subject is the user, the ob-ject the song, the operation to play the song, and the constraints are that the user has to pay 99 cents for the download and cannot share the song with his friends.
Rights Expression Languages
What follows is a brief history of RELs.
A pioneering formal language called DigitalRights describes a mathematical model of simple licenses that consists of payment and rendering events and a formal representation of licenses
(http://www.ldl.jaist.ac.jp/drcp/doc/ dr-models.pdf). LicenseScript is a logic-based REL (http://www.ub.utwente.nl/ webdocs/ctit/1/000000a1.pdf).
Logic-based RELs express general prepos-itions of a permissive or obligatory (re-strictive) statement. However, these languages cannot express a finer level of granularity of the assets, actors, or ac-tions involved. Logic-based RELs cannot interoperate with other types of RELs.
XML-based RELs support interoperable ways of expressing the rights of an in-formation asset. An XML-based REL al-lows asset producers to specify flexible expressions. The Extended Rights Markup Language (XrML,
http://www.xrml.org) and the Open Digit-al Rights Language (ODRL,
http://odrl.net) are two XML-based RELs which have gained international recogni-tion and are widely used in industry.
XrML is the basis for the REL of the MPEG-21 multimedia framework. It fo-cuses on the license through which a rights holder confers usage rights to a consumer. A license can be digitally signed by the rights holder, now also re-ferred to as the issuer, to confirm that the holder grants the rights contained in the license. An XrML license contains one or multiple grants and the license issuer. A grant is the element within the license that authorizes a subject to exercise a right on some object under some con-straints. Note that the actual terminology used by XrML is slightly different from this.
ODRL is an open standard language for the expression of terms and conditions over assets in open and trusted environ-ments. ODRL consists of an expression language and a data dictionary. The ex-pression language defines basic terms of rights expressions and their organization using a set of abstract concepts. The data dictionary defines the semantics of the concrete terms used to express an in-stance of a rights specification.
ODRL is based upon an extensible model for rights expression, and defines the fol-lowing three core entities and their rela-tionships:
• Assets, the objects being licensed
• Rights, the rules concerning permitted activities, the constraints or limits to these permissions, the requirements or obligations needed to exercise the permission, and the conditions or specifications of exceptions that, if true, terminate the permissions and may require re-negotiation of the rights
• Parties, the information regarding the service provider, consumer, or broker
With these entities, ODRL can express of-fers (proposals from rights holders for specific rights over their assets) and agreements (contracts or deals between the parties with specific offers). ODRL supports the declaration of a wide range of expressions. It can also be extended to different types of domains. For example, we can use ODRL to specify that a con-sumer of a geocoding web service can only use this service in a non-commercial context, as well as the number of times the service can be accessed each day. ODRL has been published by the World Wide Web Consortium (W3C,
ODRL is supported by several industry consortia such as the Dublin Core Metadata Initiative (DCMI,
http://dublincore.org/) and the Open Mobile Alliance (OMA,
http://www.openmobilealliance.org/). Two applications of ODRL are an ODRL profile of the semantics of Creative Com-mons (CC) licenses and the ODRL profile for services (ODRL-S). The core se-mantics of CC licenses have been ex-pressed in ODRL. This profile supports extensions to these semantics, and defines an XML Schema
(http://odrl.net/Profiles/CC/SPEC.html). ODRL-S (http://tinyurl.com/ypn5pu) is an extended version of ODRL to express clauses for service licensing, creating a machine-understandable service license.
Conclusion
Information assets are usually accompan-ied by a license that describes the terms and conditions on the use of this asset imposed by its producer. A license re-flects the overall business value of the as-set to its producers and consumers. The kind of rights vary based on the nature and context of the assets involved. For ex-ample, one of the rights for a multimedia asset is that consumers can play it. The concept of playing can not be directly ap-plied to a web service asset.
Similarly, the rights governing the use of the interface and implementation of a web service are distinct. However, for multimedia or software assets we cannot make such a distinction. In this article we introduced the concept of licensing and RELs, and briefly described XrML and ODRL as the two most prominent RELs.
We thank Dr. Renato Iannella, NICTA, Aus-tralia, and Prof. Vincenzo D’Andrea, Uni-versity of Trento, Italy, for their suggestions and comments.
G.R. Gangadharan is a doctorate student in University of Trento, Trento, Italy. His re-search interests include Free/Open Source Software Systems, Service Oriented Com-puting, Internet Software Engineering and Web 2.0, and Business Models of Software and Services.
Michael Weiss holds a faculty appoint-ment in the Departappoint-ment of Systems and Computer Engineering at Carleton Uni-versity, Ottawa, Canada, and is a member of the Technology Innovation Manage-ment program. His research interests in-clude open source ecosystems, service-oriented architectures and Web 2.0, business process modeling, social net-work analysis, and product architecture and design. Michael has published on the evolution of open source communities and licensing of open services.
