AI vs IP

Can Artificial Intelligence software claim copyright in any work that was created using their algorithms?

The short answer is “no”, since only humans can establish copyright in original creative works. Copyright can be assigned to a company or trust, or it can be created under various forms of creative commons, but there still needs to be a human author behind the copyright material. While copyright may lapse over time, it then becomes part of the public domain.

However, the extent to which a human author can claim copyright in a work that has been created with the help of AI is now being challenged. A recent case in the USA has determined that the author of a graphic novel, which included images created using Midjouney, cannot claim copyright in those images. While it was accepted that the author devised the text and other prompts that the software used as the generative inputs, the output images themselves could not be the subject of copyright protection – meaning they are either in the public domain, or they fall under some category of creative commons? This case also indicates that, in the USA at least, failing to declare the use of AI tools in a work when applying for copyright registration may result in a rejected application.

Does this decision mean that the people who write AI programmes could claim copyright in works created using their software? Probably not – as this would imply that Microsoft could establish copyright in every novel written using Word, especially its grammar and spelling tools.

On the other hand, programmers and software developers who use copyright material to train their models may need to obtain relevant permission from the copyright holders (as would anyone using the AI tools and who uses copyright content as prompts), unless they could claim exemptions under “fair dealing” or “fair use” provisions.

We’re still early in the lengthy process whereby copyright and other intellectual property laws are tested and re-calibrated in the wake of AI. Maybe the outcomes of future copyright cases will depend on whether you are Ed Sheeran or Robin Thicke….

Next week: Customer Experience vs Process Design

 

Smart Contracts… or Dumb Software

The role of smart contracts in blockchain technology is creating an emerging area of jurisprudence which largely overlaps with computer programming. However, one of the first comments I heard about smart contracts when I started working in the blockchain and crypto industry was that they are “neither smart, nor legal”. What does this paradox mean in practice?

First, smart contracts are not “smart”, because they still largely rely on human coders. While self-replicating and self-executing software programs exist, a smart contact contains human-defined parameters or conditions that will trigger the performance of the contract terms once those conditions have been met. The simplest example might be coded as a type of  “if this, then that” function. For example, I could create a smart contract so that every time the temperature drops below 15 degrees, the heating comes on in my house, provided that there is sufficient credit in the digital wallet connected to my utilities billing account.

Second, smart contracts are not “legal”, unless they comprise the necessary elements that form a legally binding agreement: intent, offer, acceptance, consideration, capacity, certainty and legality. They must be capable of being enforceable in the event that one party defaults, but they must not be contrary to public policy, and parties must not have been placed under any form of duress to enter into a contract. Furthermore, there must be an agreed governing law, especially if the parties are in different jurisdictions, and the parties must agree to be subject to a legal venue capable of enforcing or adjudicating the contract in the event of a breach or dispute.

Some legal contacts still need to be in a prescribed form, or in hard copy with a wet signature. A few may need to be under seal or attract stamp duty. Most consumer contracts (and many commercial contracts) are governed by rules relating to unfair contract terms and unconscionable conduct. But assuming a smart contract is capable of being created, notarised and executed entirely on the blockchain, what other legal principles may need to be considered when it comes to capacity and enforcement?

We are all familiar with the process of clicking “Agree” buttons every time we sign up for a social media account, download software or subscribe to digital content. Let’s assume that even with a “free” social media account, there is consideration (i.e., there’s something in it for the consumer in return for providing some personal details), and both parties have the capacity (e.g., they are old enough) and the intent to enter into a contract, the agreement is usually no more than a non-transferable and non-exclusive license granted to the consumer. The license may be revoked at any time, and may even attract penalties in the event of a breach by the end user. There is rarely a transfer of title or ownership to the consumer (if anything, social media platforms effectively acquire the rights to the users’ content), and there is nothing to say that the license will continue into perpetuity. But think how many of these on-line agreements we enter into each day, every time we log into a service or run a piece of software. Soon, those “Agree” buttons could represent individual smart contracts.

When we interact with on-line content, we are generally dealing with a recognised brand or service provider, which represents a known legal entity (a company or corporation). In turn, that entity is capable of entering into a contract, and is also capable of suing/being sued. Legal entities still need to be directed by natural persons (humans) in the form of owners, directors, officers, employees, authorised agents and appointed representatives, who act and perform tasks on behalf of the entity. Where a service provider comprises a highly centralised entity, identifying the responsible party is relatively easy, even if it may require a detailed company search in the case of complex ownership structures and subsidiaries. So what would be the outcome if you entered into a contract with what you thought was an actual person or real company, but it turned out to be an autonmous bot or an instance of disembodied AI – who or what is the counter-party to be held liable in the event something goes awry?

Until DAOs (Decentralised Autonomous Organisations) are given formal legal recognition (including the ability to be sued), it is a grey area as to who may or may not be responsible for the actions of a DAO-based project, and which may be the counter-party to a smart contract. More importantly, who will be responsible for the consequences of the DAO’s actions, once the project is in the community and functioning according to its decentralised rules of self-governance? Some jurisdictions are already drafting laws that will recognise certain DAOs as formal legal entities, which could take the form of a limited liability partnership model or perhaps a particular type of special purpose vehicle. Establishing authority, responsibility and liability will focus on the DAO governance structure: who controls the consensus mechanism, and how do they exercise that control? Is voting to amend the DAO constitution based on proof of stake?

Despite these emerging uncertainties, and the limitations inherent in smart contracts, it’s clear that these programs, where code is increasingly the law, will govern more and more areas of our lives. I see huge potential for smart contracts to be deployed in long-dated agreements such as life insurance policies, home mortgages, pension plans, trusts, wills and estates. These types of legal documents should be capable of evolving dynamically (and programmatically) as our personal circumstances, financial needs and living arrangements also change over time. Hopefully, these smart contracts will also bring greater certainty, clarity and efficiency in the drafting, performance, execution and modification of their terms and conditions.

Next week: Free speech up for sale

 

No-code product development

Anyone familiar with product development should recognise the image below. It’s a schematic for a start-up idea I was working on several years ago – for an employee engagement, reward and recognition app. It was the result of a number of workshops with a digital agency covering problem statements, user scenarios, workflow solutions, personas, UX/UI design and back-end architecture frameworks.

At the time, the cost quoted to build the MVP was easily 5-6 figures – and even to get to that point still required a load of work on story boards, wire frames and clickable prototypes….

Now, I would expect the developers to use something like a combination of open-source and low-cost software applications to manage the middle-ware functions, dial-up a basic cloud server to host the database and connect to external APIs, and commission a web designer to build a dedicated front-end. (I’m not a developer, programmer or coder, so apologies for any glaring errors in my assumptions…)

The growth in self-serve SaaS platforms, public APIs and low-cost hosting solutions (plus the plethora of design marketplaces) should mean that a developer can build an MVP for a tenth of the cost we were quoted.

Hence the interest in “low-code/no-code” product development, and the use of modular components or stack to build a range of repetitive, automated and small scale applications. (For a dev’s perspective check out Martin Slaney’s article, and for a list of useful resources see Ellen Merryweather’s post from earlier this year.)

There are obvious limitations to this approach: anything too complex, too custom, or which needs to scale quickly may break the model. Equally, stringing together a set of black boxes/off-the-shelf solutions might not work, if there are unforeseen incompatibilities or programming conflicts – especially if one component is upgraded, and there are unknown inter-dependencies that impact the other links in the chain. Which means the product development process will need to ensure a layer of code audits and test environments before deploying into production.

I was reflecting on the benefits and challenges of hermetically sealed operating systems and software programs over the weekend. In trying to downgrade my operating system (so that I could run some legacy third-party applications that no longer work thanks to some recent systems and software “upgrades”), I encountered various challenges, and it took several attempts and a couple of workarounds. The biggest problem was the lack of anything to guide me in advance – that by making certain changes to the system settings, or configuring the software a certain way, either this app or that function wouldn’t work. Also, because each component (the operating system, the software program and the third party applications) wants to defend its own turf within my device, they don’t always play nicely together in a way that the end user wants to deploy them in a single environment.

App interoperability is something that continues to frustrate when it comes to so-called systems or software upgrades. It feels like there needs to be a specialist area of product development that can better identify, mitigate and resolve potential tech debt, as well as navigate the product development maintenance schedule in anticipation of future upgrades and their likely impact, or understand the opportunities for retrofitting and keeping legacy apps current. I see too many app developers abandoning their projects because it’s just too hard to reconfigure for the latest system changes.

Next week: Telstar!

 

 

 

Monash University Virtual Demo Day

Last week I was invited to participate in a Virtual Demo Day for students enrolled in the Monash University Boot Camp, for the FinTech, Coding and UX/UI streams. The Demo Day was an opportunity for the students to present the results of their project course work and to get feedback from industry experts.

While not exactly the same as a start up pitch night, each project presented a defined problem scenario, as well as the proposed technical and design solution – and in some cases, a possible commercial model, but this was not the primary focus. Although the format of the Demo Day did not enable external observers to see all of the dozen-plus projects, overall it was very encouraging to see a university offer this type of practical learning experience.

Skills-based and aimed at providing a pathway to a career in ICT, the Boot Camp programme results in a Certificate of Completion – but I hope that undergraduates have similar opportunities as part of their bachelor degree courses. The emphasis on ICT (Cybersecurity and Data Analytics form other streams) is partly in response to government support for relevant skills training, and partly to help meet industry requirements for qualified job candidates.

Industry demand for ICT roles is revealing a shortage of appropriate skills among job applicants, no doubt exacerbated by our closed international borders, and a downturn in overseas students and skilled migration. This shortage is having a direct impact on recruitment and hiring costs, as this recent Tweet by one of my friends starkly reveals: “As someone who is hiring about 130 people right now, I will say this: Salaries in tech in Australia are going up right now at a rate I’ve never seen.” So nice work if you can get it!

As for the Demo Day projects themselves, these embraced technology and topics across Blockchain, two-sided marketplaces, health, sustainability, music, facilities management, career development and social connectivity.

The Monash Boot Camp courses are presented in conjunction with Trilogy Education Services, a US-based training and education provider. From what I can see online, this provider divides opinion as to the quality and/or value for money that their programmes offer – there seems to be a fair number of advocates and detractors. I can’t comment on the course content or delivery, but in terms of engagement, my observation is that the students get good exposure to key tech stacks, learn some very practical skills, and they are encouraged to follow up with the industry participants. I hope all of the students manage to land the type of opportunities they are seeking as a result of completing their course.

Next week: Here We Go Again…