As part of the technological arms race in the financial services sector, banks and other financial institutions are increasingly embracing hackathons as a way to innovate consumer products and banking tools. These types of events can help spur innovation, engage potential employees, and produce valuable digital assets for the hosting firm. However, at the same time, companies should be cautious about the intellectual property issues at stake.
A "hackathon" is a software coding competition that happens over a short period – usually a day or two – where participants compete to come up with innovative new programs or applications. Sometimes employers, traditionally technology companies, hold internal hackathons to encourage employees to develop new tech for the firm's business lines. Hackathons can also be open to anyone.
Earlier this month, Scotiabank held its first-ever hackathon: "Scotiabank Hack IT," joining a global trend of financial institutions sponsoring and hosting tournament-style development challenges to innovate and recruit tech talent. It was open to 100 participants and the challenge was to "find innovative solutions for managing debt."
Other recent hackathons presented by financial institutions in the past year include RBC's Digital Challenge (which focused on the future of mobile banking) First National Banks' Code One, and ING's 24H-CodeIT. MasterCard has put on regional "Masters of Code" competitions all over the world whose winners were flown to Silicon Valley for a grand finale round.
Cash prizes are usually awarded to the developers of the top creations. As an added incentive, the company sponsoring the hackathon may offer to buy or license the developments created by the winners of the hackathon (the "Hackathon Developments"). One recent tech blog suggests that very skilled developers can live off their hackathon earnings as "pro hackers."
In addition to cash prizes for the top three teams, Scotiabank offered the top developers job interviews at its Scotiabank Digital Factory, the bank's innovation hub set to open this year.
Hosting hackathons can provide opportunities for organizations to source new technology, recruit talent and promote their brands. Companies considering a hackathon should determine up-front what their goals are, including in particular how they wish to structure ownership and licensing rights for the Hackathon Developments (especially if they are seeking to use or monetize them) and communicate them to the participants.
Moreover, companies who support hackathons need to be cognizant of the intellectual property landmines that they may encounter if they do not conduct adequate due diligence before adopting or using the Hackathon Developments or do not have appropriate agreements in place with participants who developed the Hackathon Developments.
Generally hackathon organizers require participants to agree to the official participant rules. At a minimum, firms organizing hackathons should think through the structure of ownership of rights in the Hackathon Developments. In addition, firms need to protect themselves from participants that misuse or misappropriate third-party code into their Hackathon Developments (even inadvertently) and third parties who may have rights that could affect the company's freedom to commercialize the Hackathon Developments.
Ownership of Hackathon Developments
It is important to set out who will be the owner of any work product created during a hackathon. Copyright law is the primary source of protection for software programs.1 Copyright protection exists as soon as a work becomes fixed in a permanent form and registration is not necessary to obtain such protection. Under Canadian copyright law, the author of a work is generally the owner. However, if the work is created "in the course of employment" (i.e. by an employee), absent an agreement to the contrary, the employer will be the owner of the copyright in such work.2
However, if the competition is held outside of normal work hours or the participant's development of software is outside the role for which he or she was hired, the work might not be considered to be made "in the course of employment." Thus, the author would be the owner of the copyright in the work, rather than the employer. For open hackathons not reserved to employee participants, unless the participants have agreed upon otherwise, the individual or team that creates any work would be the owner of the copyright.
Accordingly, before commercializing any Hackathon Developments, the hosting company should consider purchasing the Hackathon Development or licensing it exclusively for a specified period of time following the competition. If the Hackathon Development is to be purchased from the developer, the assignment of rights should be in writing between the company and the developer.
However, even when copyright to software is sold, the original author may retain certain fair dealing rights3. Furthermore, the author will retain moral rights in the work. Moral rights constitute an author's right to integrity in his or her work and to be associated with the work. Moral rights can be waived by authors, but not assigned.4 Therefore, a company commercializing Hackathon Developments should obtain moral rights waivers in writing from the applicable developer.
Due Diligence of Hackathon Developments
To minimize risks associated with participants misappropriating code or third-party intellectual property rights, hackathon hosts should consider including appropriate representations and related indemnifications in the participant rules agreement. For example, contestants may be required to only use content or code for which they have the appropriate rights (e.g., open source code) and agree not to use any content or code that violates any law or third party's rights.
A company looking to commercialize Hackathon Developments may consider obtaining an indemnification from the applicable developer to cover any damages and claims relating to the developer's failure to comply with the hackathon rules and for infringement of third-party rights.
However, since most hackathon developers are individuals, they may lack the financial means to cover the indemnification. Therefore, it is important for a company to conduct its own due diligence of the Hackathon Development it is looking to commercialize. For instance, the company should conduct a source code audit to determine whether third-party code (including open source software code) has been incorporated into Hackathon Development. It should also consider conducting appropriate intellectual property searches, which could include patent and copyright searches, to determine whether there are infringement risks associated with commercializing the Hackathon Development.
To the extent any third-party software code or content is incorporated into a Hackathon Development, the commercializing company should review the applicable licence terms, such as an attribution requirement to identify the source of the data, to determine whether the use of the code and content is permitted and whether new licences would need to be obtained by the commercializing company.
Since most hackathons permit developers to incorporate open-source software code into their products, a source code audit is key to identify the applicable licences for such code. Because there are risks associated with certain types of open-source code, including code licensed under viral open source licences, such as the general public licence (GPL) and lesser general public licence (LGPL), the results of the source code audit will allow a commercializing company to determine whether specific software code should be replaced with proprietary software code or code licensed under non-viral open source licences.
Companies hosting hackathons should consider the associated intellectual property risks, when the company hopes to commercialize or otherwise make use of any of the superior software submission. Properly crafted agreements with participants and appropriate due diligence relating to Hackathon Developments are needed to obtain the benefits of cutting edge innovation while mitigating the risk of having inadequate rights to actually use the innovation.
1. See generally, Barry Sookman, Sookman: Computer, Internet and Electronic Commerce Law, Chapter 3.1.
2. Copyright Act, R.S.C., 1985, c. C-42, ss. 13(1) and (3).
3. Canavest House Ltd. v. Lett,  2 C.P.R. (3d) 386 at para. 27, where the court found that the original author of a software program was permitted to use his research materials so long as he did not reproduce the work itself or otherwise infringe on the copyright interest that belonged to his employer.
4. Copyright Act, R.S.C., 1985, c. C-42, s. 14.
To view the original article please click here.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.