AI researchers looking to publicly share their AI/ML models while limiting the possibility that the models may be used inappropriately drove the creation of “Responsible AI licenses” by the RAIL group (“RAIL licenses”).1 Today these licenses are used by a number of popular models, including Stable Diffusion, the BLOOM Large Language Model, and StarCoder. RAIL licenses were inspired by open source licensing and they are very similar to the Apache 2.0 license, with the addition of an attachment outlining use restrictions for the model. The “inappropriateness” RAIL licenses are targeting is wide-ranging.

Background on RAIL Licenses

Technically, these licenses are not open source licenses per the definitions of open source promulgated by the Open Source Initiative or the Free Software Foundation. The use restrictions in these licenses’ Attachment A, such as a ban on using the models to provide medical advice or medical results or using them for law enforcement, discriminate against particular fields of endeavor in contravention of fundamental open source principles. Because the licenses allow licensees to pass on the models under their own licenses of choice, provided they flow down the use restrictions, the licenses only promise a very limited amount of “openness” or “freedom” in the traditional OSS-specific sense. Unlike open source licenses, downstream users of RAIL-licensed models are not required to receive the same rights to use, modify, or distribute the models as the original licensee. 

The use restrictions are worth reading in full if you haven’t already. Here are the ones in BigCode’s StarCoder license (they vary a bit from one RAIL license to another):

You agree not to Use the Model or Modifications of the Model:

(a) In any way that violates any applicable national, federal, state, local or international law or regulation;

(b) For the purpose of exploiting, Harming or attempting to exploit or harm minors in any way;

(c) To generate and/or disseminate malware (including – but not limited to – ransomware) or any other content to be used for the purpose of Harming electronic systems;

(d) To generate or disseminate verifiably false information and/or content with the purpose of Harming others;

(e) To generate or disseminate personal identifiable information with the purpose of Harming others;

(f) To generate or disseminate information (including – but not limited to – images, code, posts, articles), and place the information in any public context (including – but not limited to – bot generating tweets) without expressly and intelligibly disclaiming that the information and/or content is machine generated;

(g) To intentionally defame, disparage or otherwise harass others;

(h) To impersonate or attempt to impersonate human beings for purposes of deception;

(i) For fully automated decision making that adversely impacts an individual’s legal rights or otherwise creates or modifies a binding, enforceable obligation without expressly and intelligibly disclaiming that the creation or modification of the obligation is machine generated;

(j) For any Use intended to discriminate against or Harm individuals or groups based on online or offline social behavior or known or predicted personal or personality characteristics;

(k) To intentionally exploit any of the vulnerabilities of a specific group of persons based on their age, social, physical or mental characteristics, in order to materially distort the behavior of a person pertaining to that group in a manner that causes or is likely to cause that person or another person physical or psychological harm;

(l) For any Use intended to discriminate against individuals or groups based on legally protected characteristics or categories;

(m) To provide medical advice or medical results interpretation that is intended to be a substitute for professional medical advice, diagnosis, or treatment;

(n) For fully automated decision making in administration of justice, law enforcement, immigration or asylum processes.

The scope of the concerns here is remarkable. Some are rather practical (let users know they’re talking to an AI) and others are common in licensing generally (don’t use the technology to break the law). But, many of these read as attempts to prevent the technology from enabling totalitarianism and police states, generally. Licenses for general-purpose technologies have long contained restrictions related to using certain technologies in extremely dangerous, mission-critical contexts (like to manage nuclear power plants or conduct remote surgeries); those sorts of disclaimers or limitations arose because the software was simply not hardened to meet the security and performance standards those uses would require. It’s only in the last 15 years or so that such licenses have attempted to limit usage based on ethical considerations.

A spate of so-called “ethical licenses” emerged in the last 15 years, with aims that included preventing companies from using the software if they worked with ICE, if they were Chinese companies that required long, grueling working hours, and if they were harming underprivileged groups. These licenses have not enjoyed widespread use or support; very few projects have adopted them and they have been banned2 at virtually every tech company sophisticated enough to have an open source licensing policy. But the RAIL licenses are probably the most far-reaching licenses for publicly available technology that have ever gained any notoriety, pursuing not just one particular type of harm, but contractually attempting to require adherence to what amounts to an expression of a wide variety of Western, liberal principles.

As you can see, many of these restrictions are nebulous even at face value. You’ll notice that none of the uses of the word “discriminate” are tied to any legal understanding of what discrimination might be, leaving open the interpretation that simply sorting people by a protected or unprotected characteristic is prohibited “discrimination” under this license.3 “Harm” is defined broadly: it “includes but is not limited to physical, mental, psychological, financial and reputational damage, pain, or loss.” Note that “Harm” isn’t just harm in violation of the law or undue or unjust harm. It would include harm like sending a rightly convicted person to jail or hurting someone’s reputation by publishing true things about them.

On the face of it, (g) would prevent a reporter from using an AI to assist in writing an article on a company dumping chemicals in the water, since that would be disparaging, (e) would prohibit someone from asking an AI about the names and addresses of people on the public sex offender registry, since that would be a use of personally identifiable information likely to hurt someone’s feelings, and both (j) and (l) would prevent someone from using an AI to assist in targeting men for boxer brief advertisements, since that would be discrimination based on a predicted personal characteristic and based on a protected category. An entire essay could be written about the possible meaning of nearly any one of these provisions. The vagueness here would likely make some of these restrictions unenforceable in a court of law and leave the others open to unpredictable case-by-case determinations. 

Like open source licenses, the RAIL licenses are styled as copyright licenses. The ability to enforce them rests on the model owner’s ability to prove that they have copyright ownership in the model and that a violation of the RAIL license is therefore copyright infringement. Given that AI models are mostly just numbers representing parameter weights, there is deep skepticism in the IP world that the models are even copyrightable. If not, the license is fully unenforceable. It would need to be significantly rewritten solely as a contract in order to be enforceable, which is difficult to do because every country (and even the states therein) have very different laws that apply to contract interpretation, whereas copyright law was harmonized almost worldwide by the Berne Convention.

There is also a strong possibility that the use restrictions in RAIL licenses could constitute copyright misuse in the United States (and a few other countries). This doctrine prevents copyright enforcement where the copyright owner has conditioned a copyright license on restrictions or limitations well outside the scope of the monopoly rights granted by the Copyright Act. Examples of copyright misuse include licenses that require non-competition for 100 years and licenses that prevent the licensee from sharing any data stored in the software with others. Given the vagueness of the restrictions, I don’t think it’s hard to imagine a use case that might be read to violate those restrictions, but in which a court would be hard-pressed to enforce them (such as my example of a journalist writing about clean water, above). 

For purposes of analyzing and assessing the various enforcement mechanisms possible in RAIL licenses, I’m going to assume that RAIL licenses can surmount the potential legal challenges mentioned above and that it is possible to make better and clearer restrictions that are worth trying to enact.

RAIL Licensed Models Incorporated in Other Products and Services

RAIL licenses were drafted in the context of AI researchers sharing naked models (without the software to run them or the training data), often foundational models, in public spaces like the Hugging Face platform. Thus, it’s not entirely clear how the licenses are supposed to apply to entities or individuals incorporating a model into their own products and services. On the one hand, the RAIL licenses allow the initial licensee to re-license the model under their own license provided that they flow down the use restrictions in the RAIL license (this is “sublicensing” and the downstream users are “sublicensees”). But, on the other hand, the RAIL licenses still require the initial licensee to provide downstream licensees with a copy of the RAIL license. It’s not clear why downstream licensees need to see a license that they may not actually be subject to. 

Although the RAIL licenses require flowing down the use restrictions to downstream licensees, the license does not further require that the initial licensee enforce those restrictions4 against downstream licensees (including by terminating access rights for downstream licensees) nor does the license terminate for the initial licensee if downstream licensees violate those restrictions. As such, the owners of the model can really only enforce the RAIL license against the initial licensee and only if the licensee itself has violated the license, not if one of its downstream licensees has violated the RAIL flowdowns. Since there is no privity of contract between the model owners and the downstream licensees (i.e. there is no contract between them) when the initial licensee sublicenses to the downstream licensee, model owners have no standing to enforce any of the use restrictions against them (or their subsequent downstream licensees).5 The use restrictions are not very effective since everyone who receives the model from someone other than the licensor (the model owner), is beyond the reach of legal enforcement from the model owners. 

Even if the initial licensee wanted to sue the downstream licensee, they’d be limited to contract claims as only exclusive licensees have standing to sue for copyright infringement, and that significantly limits the appeal of enforcement since the initial licensee would need to prove that they were personally, financially damaged by the violations of the downstream licensee. That’s probably not true in most instances of violations of the RAIL use restrictions.

Alternative Approaches to License Enforcement

The RAIL licenses could potentially be modified in two different ways to make sure that no users of a RAIL licensed model are beyond reach for those wishing to enforce the license. The first approach is to make the RAIL licenses look more like commercial licenses, with more restrictions and a clear framework for how upstream licensees take responsibility for downstream users. The second approach is to hew more closely to the open source licensing model, by prohibiting sublicensing, and forming a direct contractual relationship between the model owner and each user. 

The Commercial Approach

The companies named here are provided solely as an example and this diagram does not necessarily reflect any real-world relationships.

Commercial contracts that require that the initial licensee flow certain terms down to downstream licensees (but not the entire agreement) also reserve the right to terminate the license of the initial licensee if downstream licensees fail to comply with those flowdowns. They often require that the initial licensee report any downstream violations. They can further ask the initial licensee to indemnify the licensor against any claims or losses related to the actions of the downstream licensees. 

Companies that care a lot about downstream uses will even go so far as to require the initial licensee to make the company (the licensor) a third party beneficiary to any agreements between the initial licensee and the downstream licensees so that they can enforce those flowdowns even when the initial licensee has no interest in doing so. This can be particularly appealing to the licensor if the initial licensee is likely to be smaller than the customers (downstream licensees) it serves since that power dynamic is unlikely to yield effective enforcement of the licensor’s rights and the initial licensee doesn’t have deep enough pockets to make suing them for their customers’ actions profitable. Designating a third party beneficiary in a tech transaction is fairly unusual, but it’s worth discussing at length here because the initial licensees in this particular context are unlikely to engage in much license enforcement on their own.6

Generally, downstream licensees will chafe at the addition of a third party beneficiary because:

  • They don’t like dealing with a third party they don’t know or have any relationship with – trust and relationships are important. Some third parties are more litigious than others
  • It involves allowing a third party to have access to their contracts or potentially their confidential information, but the agreement is solely between the initial licensee and the downstream licensee and the downstream licensee therefore cannot bind the third party beneficiary to any confidentiality or data privacy obligations
  • When a third party beneficiary includes “…and their affiliates,” this could potentially mean hundreds of plaintiffs the downstream licensee has never even heard of before and which can change as companies are bought and sold. That can significantly increase litigation risk and the risk of exposing confidential information to unknown entities without restriction
  • It leads to more complex and expensive litigation

Commercial agreements also commonly include provisions that subject initial licensees to audits to make sure they’re complying with the agreement. They may also include provisions requiring the initial licensee to create and maintain certain records so that they may be available for an audit or legal discovery, and such records might need to contain information about downstream licensees.  Where the parties anticipate difficulty in bringing copyright claims or proving damages resulting from contract breach, the parties may agree to a liquidated damages provision, specifying up-front what a breach will cost the licensee.

All the additional terms discussed above could be flowed down to downstream licensees of downstream licenses, etc.

The Open Source Approach

The companies named here are provided solely as an example and this diagram does not necessarily reflect any real-world relationships.

On the other hand, open source licenses do not rely on flowdowns to downstream users. Open source licenses follow a direct licensing model, wherein every user is in a direct license with the copyright holders of the software (i.e. the project contributors). Another way of putting this is that there are no downstream licensees or sublicensees because everyone receives their license directly from the copyright holder, even if they might receive the actual software and a copy of the license language from someone else (you might see references to downstream users, though). If a company incorporates open source licensed software into their products, the open source software remains under the open source license, regardless of how the company chooses to license other elements of its products and their customer receives a bundle of licenses – one for their own software, and one for each OSS component in the product:

 Any violations of the open source license by such customers (or their own customers) can be enforced by the copyright holders. Downstream users never receive fewer rights than upstream users and the software itself thus remains “open” and “free.” 

Evaluating the Commercial Approach for the AI Space

The commercial approach is useful when the subject of the license is a proprietary piece of technology. In other words, there is no interest in the technology being widely and freely available to others and there is no interest in seeing research and development related to the technology from anyone but the licensor (the initial creator/owner of the technology) or the licensor’s chosen partners or contractors. That’s because the initial licensee of such technology must comply with the licensor’s restrictions in order to maintain the license and avoid potential legal claims. If they don’t, the licensor could get an injunction to completely prevent the initial licensee from selling their products until the licensor’s technology has been removed from those products. Missing out on several months of revenue would be detrimental to most businesses and public lawsuits would deter new customers from signing on. And, of course, the licensee would be on the hook for damages related to copyright infringement and contract breach. The licensee might even owe money to its other customers if they granted them an IP warranty or breached their contracts with them by ceasing to make their product available.

If the initial licensee is responsible for downstream use, then it’s in their best interest to limit uses of the technology to a set of pre-approved use cases and prevent users from using the technology in an unforeseen way. This has traditionally translated into initial licensees forbidding downstream licensees from modifying the technology, distributing the technology, incorporating the technology into their own products, or reverse engineering the technology (sometimes at the behest of the licensor directly, but sometimes just as a risk mitigation measure). This often goes hand in hand with not providing downstream licensees with source code to the technology and with implementing control systems like DRM, licensee keys, etc. Even if downstream licensees are allowed to redistribute the technology in certain circumstances, many of the above controls and measures will remain in play. In sum, these controls and measures mean that the technology at issue is not “open” or “free.” Additional research and development related to the technology will typically begin and end with the licensor.

In the AI space, preventing downstream licensees from violating the use restrictions in the RAIL licenses will likewise mean lockdown measures. Sensible companies will limit the ways in which their customers can interact with the AI model as well as their ability to fine-tune it or do prompt-tuning. The fear of a customer circumventing some of the controls a company may put in place to comply with the RAIL license means that in the absence of regulations requiring otherwise, the exact nature of those controls will be kept secret and so will the code implementing those controls, limiting the transparency that AI researchers and the media could otherwise provide on everything from the performance abilities of the model to the model’s safety. Since the training data itself can offer information useful for circumvention, disclosing its contents could also become risky and undesirable. 

In the B2B software context, knowledge of how downstream licensees are using a particular technology is generally rooted in either monitoring license key usage and/or logins or via physical audits of documents or computers in search of information related to payments, inventory, number of users, number of downstream licensees, and product descriptions or documentation, etc. That’s because the salient questions up until now have revolved around whether a product has been distributed when it shouldn’t have or whether too many users are using it, etc. In some cases certain uses can be identified just by seeing what a downstream licensee is doing and saying in public. Technology companies that sell to other companies (not to individuals) mostly rely on metadata and performance/utilization data to monitor customer accounts (initial licensees) for potential license violations, not the contents of customer data (which is often not their data, but data of their customers, i.e. downstream licensees – ex. AWS hosts a data analysis platform and that platform in turn ingests data from various customers who are retailers and the data provided by the retailers might actually be data of individual consumers or employees). 

Best practices in the software world include only giving a small subset of employees direct access to customer accounts, and that subset generally only has access to resolve specific security issues and support requests; their access is carefully logged and monitored, and abuse of such access quickly leads to termination. Most B2B software companies enter into data protection addendums with their customers, promising compliance with these practices. While companies often reserve the right to access customer accounts for things like enforcement of their agreement with the customer, per the above, in practice most such enforcement doesn’t require access to customer data directly. Many companies that might use AI models as part of their services also do not receive any customer data in the clear – processing that needs to happen with unencrypted data is done in customer-controlled environments before being sent to the company; they only receive encrypted data that only their downstream licensees can unencrypt. And of course, good old-fashioned on-prem software providers receive no customer data to monitor at all. 

Making sure that downstream licensees aren’t using AI models to provide medical advice, for example, would involve a level of surveillance that most B2B tech companies do not normally engage in, even if they do process customer data in the clear as part of a SaaS offering. Assessing a violation like that requires constant monitoring of the contents of that data, who a customer’s customers are, and more people viewing customer data and personally identifiable information for purposes other than providing people with the services they’re paying for. Suddenly, compliance, legal, and engineering staff are exchanging, citing, and discussing a heap of sensitive health-related information to distinguish what’s advice and what’s just a factual statement. Given the grand scope and ambiguity of the RAIL use restrictions, deciding whether or not any customer complies with all of them would require each company to form something like FaceBook’s Oversight Board, except with more expertise in a wider array of areas and without many of the legal protections that allow companies to eschew proactive surveillance and enforcement in favor of waiting for complaints of violations from third parties.7 The desire to make sure downstream licensees are using AI responsibly is in direct tension with their privacy and data protection rights, which is ironic because the RAIL licenses themselves prohibit AI models from abusing personally identifiable data. 

Most technology companies also experience instances where customers are in violation of their agreements, but they choose not to terminate those customers. That can happen when an alternative deal is struck with the customer that everyone is happy with (which may or may not get documented in a contract somewhere), when the violation is fairly minor, when the customer is also an important partner and the partnership is much more lucrative than the customer arrangement, or the customer serves as such an important signal of the company’s value (it’s a “big logo”), that it’s worthwhile to keep them on even in the face of major violations. In the B2B space, companies make money by licensing products and services and they lose money when they terminate customers or file lawsuits against them. The reality is that individuals and corporations act on the things that most deeply affect them personally and they don’t, can’t, and shouldn’t expend limitless resources to surveil and monitor their customers or cripple the privacy and security of their products in order to act as a substitute for traditional government authority. Accepting a license that comes with such a responsibility would probably be a violation of the company’s fiduciary duties to its shareholders. 

In the worst case scenario, if companies do not think they can put technical controls in place to comply with the RAIL use restrictions, they believe that enforcing these restrictions increases their data privacy-related risks (particularly if they interpret these provisions as preventing them from encrypting customer data), or they think it is too expensive and time-consuming to chase down every potential or actual violation, companies will simply ask customers to download AI models themselves and offer API integrations between their products and these models.8 That arrangement would fully absolve the companies of putting into place any controls, monitoring, or limitations that may be necessary to comply with RAIL use restrictions, putting those obligations squarely on the shoulders of their customers.

The problem with this is that the customers of Microsoft, for example, include veterinary offices and hair salons – in other words, lots of customers who do not have the capacity or interest in making AI models safer or policing their own employees’ and customers’ use. While various regulatory agencies may have the capacity to police several thousand tech companies and force them to develop a set of best practices, there is very little they can do when everyone is running their own instance of a foundational AI model to which no one’s added any compliance or safety mechanisms and very importantly, no one is incentivized to add such mechanisms because the people capable of doing the work no longer bear any potential liability and the people who bear liability will, in practice, face a low chance of enforcement. At that point, regulators can either give up on AI safety or they can ban publicly available AI models. Such a move would again run counter to the desire for transparency around how models are trained and how they work, pushing AI research and development back into the hands of a handful of corporations, and limiting AI research and development by hampering people’s ability to iterate on each other’s work. 

Changing the RAIL licenses to work more like commercial agreements may further ensure “responsible” AI use in one particular sense, but it would significantly cut against openness and the benefits related to transparency and innovation that openness brings. That “responsibility” would be of a limited nature – it would be easy to see wild license violations and corporations would likely act on such violations if committed by their downstream licensees, but it would no longer be possible for outsiders to closely study modified or fine-tuned models for bias or emergent behaviors, for example. It would be impossible for the public to know who all the users of a particular model are or what they’re using it for. Corporations would play a greater role in deciding what does and doesn’t violate the license, and other researchers, journalists, and regulators would have less opportunity to weigh in. If the cost of violating the license is high, as it is in commercial agreements, and as it would be if a company came to depend on a model under a RAIL license, then there is also a strong incentive to hide any violations that are found, rather than letting affected individuals or entities know about them. As in the data breach context, the only way to counter the incentives around hiding violations is to pass laws mandating their reporting and creating an even higher penalty for failure to disclose than for violating the license.9 But that doesn’t work in the AI context, where the entire point of the RAIL licenses is to substitute for regulations that don’t exist yet. 

Evaluating the Open Source Approach for the AI Space

The open source approach is, at first glance, unsatisfying for a model owner who wants to go after just one company and not all of its customers. In other words, for a model owner who wants to essentially delegate responsibility for license enforcement down the supply chain. But, the goals of the open source movement haven’t been hampered by the direct licensing model. On the contrary, that model is core to the movement’s success and open source software’s ubiquity.

The open source movement, as it turns out, has been wildly successful without very much need to sue anyone at all. Just a handful of enforcement actions has created legal precedent and legal awareness around the importance of open source license compliance. The software industry has dramatically improved its open source license compliance practices in the last 30 years. Partially this is because the potential for enforcement and the expense related to it has been clarified – not just to individual companies, but to their potential customers, investors and acquirers. Partially it is because the open source movement has many adherents and beneficiaries; companies that don’t comply have a harder time recruiting good engineers who care about open source and they have a harder time forming partnerships with other companies who do not want to harm their reputations. 

But perhaps the biggest reason for the movement’s success is simply that good software was shipped under open source licenses that could never be stripped from the software. That meant that not only could lots of people use the software freely, but lots of people could improve it, making many pieces of open source software the de facto gold standard in that domain. And once the software became a gold standard, no one could avoid using or avoid eventually becoming aware of open source licenses. 

If the AI movement wanted to replicate the OSS movement’s success, allowing AI models and the related software (under RAIL software-specific licenses) to be sublicensed under other licenses was a fatal flaw.10 It undercuts the ability of others to iterate on AI models and improve them, weakening the strength of openly developed AI models and in turn the ubiquity and importance of the RAIL licenses themselves. In seeking maximum “responsibility,” there’s a good chance the RAIL licenses become, for all intents and purposes, entirely irrelevant because the best models aren’t going to be released under RAIL licenses at all. 

There are also a lot of differences between the motivations of licensors in the open source space and the licensors in the AI model space. The first wave of people who licensed their work under an open source license did so because they fundamentally believed in a set of fairly succinct open source principles related to openness and freedom related to code.11 They cared not just about getting attention and accolades for their work, but specifically so that their work could be freely used and improved upon by others. This is where I believe there is schism between the open source world and the AI world: many people licensing their code under RAIL licenses don’t have a distinct and articulated (or articulable) desire for how they want their models to be used. And they don’t necessarily even agree with each other about what constitutes a good or bad use. They may want to be seen as generally “responsible,” but being responsible isn’t a movement; it’s not a set of guiding principles; it’s not a standard someone can clearly meet or fail. The general sort of responsibility imbued in RAIL licenses is the same sort of “don’t be evil” ethos that’s always been floating in the ether and not a new, better way of doing things. 

OSS licensors are also affected by license violations far more directly than AI licensors, and they have more resources available to them if they choose to enforce their license. In the open source world, someone abusing the open source license means that the copyright holder is not given back contributions to the project (by making them publicly available as licensees should), they’re not attributed, or they are robbed of revenues from alternative commercial arrangements from people who can’t or don’t want to comply with the open source license. Although lawsuits are fairly rare in the open source space, there is a culture and history of enforcement actions where copyright holders merely ask for and receive compliance in order to redress a violation. That culture is in part predicated on the fact that getting into compliance with an OSS license or getting a commercial license for the technology when it’s available is generally just one of the costs of doing business; it is rarely a matter that could make or break a company unless the company decides to literally go for broke and fight obvious violations in court. There are also foundations and open source compliance-focused organizations that help to educate the public about OSS licenses, provide resources for copyright holders trying to enforce their license, and sometimes act as counsel for a copyright holder who wants to enforce their license.

AI licensors are likely to be affected only very indirectly, if at all, by violations of RAIL licenses. Are individual PhD candidates at Berkeley really going to try to enforce against companies using their models for facial recognition technology in Indonesia? Is a Meta employee fine- tuning LLaMA in her personal time going to sue a pharmaceutical company in Norway for using her work to suggest various drugs to people? Today, there are no private organizations funded and staffed to enforce RAIL licenses. The resources or desire for people to enforce any of the RAIL restrictions are very limited. Whether it’s model developers to whom enforcement falls, as in the OSS direct licensing approach, or it’s anyone upstream of a downstream violation, as in the commercial sublicensing approach, no one individual or company has the desire and funds to enforce all of the license restrictions everywhere in the world at all times, no matter how egregious and harmful they may be. Even occasional enforcement is likely to be extremely rare in part because of resource constraints, in part because of a lack of interest, but also in part because the people who care the most about enforcement wouldn’t hand out their models to unknown entities on public platforms. 

Unlike in the OSS space, some of the potentially infringing uses of the RAIL licenses may also be impossible for certain companies to remedy. Defense contractors using AI models to help process PII in order to identify, locate, and arrest Russian soldiers in Ukraine, for example, can’t simultaneously stay in business and come into compliance with the license’s prohibition on using PII to “harm” others. That means a potential license violation could, in fact, make or break the business and the same culture of “please just come into compliance, no need for nasty lawsuits” is unlikely to take hold in the AI space. As with the commercial approach, this incentivizes people to hide the fact that they’re using RAIL-licensed models and their violations. And in particular, if you know the violations applicable to your business or your customers cannot be remedied, why look for them at all?

The success of the OSS movement is enviable and impossible to overstate. But, the many elements which have led to its success simply can’t be replicated in the AI space. The requirements of OSS licenses are much narrower and less open to interpretation than the requirements of the RAIL licenses. The people applying the licenses to their technology are much more directly affected by license violations than those in the AI space, they have far more resources available to them, and the types of violations they can allege are relatively clear cut. The scope and expense of proving that someone didn’t make a source code offer in court is orders of magnitude smaller than convincing a court in say, Myanmar, that a model has been used to discriminate against a religious minority (that the government has an active policy of discriminating against) and that the corporation running it should be prevented from selling its products until the model is removed. Not to mention the fact that enforcing many of the RAIL provisions constitutes not just an arcane commercial licensing dispute, but a provocative political statement that may lead to threats, harassment, and even torture or death for the people making them.  

What Should Be Done with RAIL Licenses?

RAIL licenses were drafted because there was (and remains) little AI-related regulation and little AI-related government or corporate expertise available. The licenses are an attempt to offer a bandaid or substitute for this lack of awareness and regulation. They are also social and political statements about the role of AI researchers in the world, chastened, perhaps, by the regrets of some of the scientists who worked on the Manhattan project or the general history of scientists driven by curiosity, excitement, and hubris who did not give a thought as to how the results of their work would actually be used in the world. 

The use restrictions in the RAIL licenses would seem to indicate that the people licensing their models this way believe that their technology is profoundly dangerous and can be used by corporations and governments alike to effect systemic bias, voter manipulation, and totalitarian control in a manner and to a degree not previously possible. I don’t know how true that is; I’m just a lawyer, but I’m willing to accept these assertions at face value from the people who know the technology best. If true, today’s RAIL licenses amount to little more than a warning sticker on canisters of purified uranium being jettisoned into the sky with t-shirt guns. They provide no real control over how any of the technologies licensed under them are used. And unfortunately, neither the commercial nor the open source approaches discussed above create a good balance between openness and safety. 

As previously stated, it’s not clear the models are copyrightable and subject to any license on that basis at all or that the licenses would survive misuse challenges. Even if the licenses are valid, like any legal instrument, they’re only useful if the entities subject to them reside in countries with operational legal systems open to foreign plaintiffs and whose own laws and politics are aligned with the goals and values espoused in the licenses. To put this another way, no license on earth is going to stop the Chinese Communist Party from using a model from Hugging Face to maintain biometric identification on its citizens, if that’s what it wants to do. If a terrorist organization wants to use the models to plan future attacks against Americans, maybe there’s no local court that cares to stop them from doing so. 

What exactly is the sort of model that’s ok for North Korea to use however it wants, but whose use will require extraordinary levels of surveillance in the Western world? Are the licensors essentially arming hostile governments and terrorist organizations and only retaining control over law-abiding people? Do the licensors think it doesn’t matter if existing totalitarian regimes entrench their power over their helpless citizens even further so long as the licenses allow them to keep such practices at bay in the Western world? Is their technology not actually dangerous enough to warrant all these use restrictions? 

This discussion is so fraught and complex because there actually is no model for how to regulate a dangerous technology that developed countries fail to recognize as dangerous. Certainly, there’s no model for further allowing people to trade this technology freely and publicly while also ensuring safety and transparency about who is using it, for what and how. Except perhaps in failed states, things that are truly dangerous, like military weapons, nuclear technologies, viruses created for scientific research, etc. simply can’t be left in the public square for anyone to come pick up and play with. No doubt all of these technologies would benefit from open and collaborative world-wide development of the sort made possible by the open source software movement, but openness and even progress don’t always trump safety and responsibility. 

Licensing of any variety can’t substitute for meaningful, international AI regulation. The ultimate answer as to how to balance openness with responsibility, probably like most of this blog post, is deeply unsatisfying and uncomfortable: if you really think your technology can be misused in such profoundly harmful ways, don’t make it publicly available on the Internet. Only provide it to people you trust who are going to be honest with you about how they’re using it, under legally enforceable agreements. All technology can be used for both good and evil, but it’s still our collective responsibility to prevent evil where we can.

Read More