Should a Desktop License include Use in Online Design Tools?

Stuart Sandler

There has been a lot of discussion around what grants of right a Desktop Use license should include and I'd like to put it to the group to provide their thoughts. By default, as font creators, we accept that a Desktop Use license allows all paid licensed End Users the ability to download and install a font file locally on computers they use to surface in Desktop applications.

Do we also assume that licensed End Users of a Desktop Use license can add these fonts to a variety of online based design tools or services that they use for design via a web browser?

Does this use constitute the need for a new type of license all together? Should it have its own fee structure? Should it be part of the default Desktop Use license at the time of purchase? Should it require an additional licensing fee?

Everybody has their own case whether they are a font buyer or a font seller and their perspective will inform their answer but sincerely I'd like to approach this discussion without bias to understand what is best for all parties. Thank you in advance for sharing your insights with the community.

Jess Latham

Stuart, you probably already know what I think. Yes, absolutely, a regular desktop license should include use in cloud apps. Is there a reseller that expressly doesn't allow it?

Thierry Blancpain

It should include the use of tools like Figma. It does not necessarily need to include the use of tools like Canva, which might be better served with a license that focuses on the numerical output (how many documents created / year) than the number of users — sometimes that’s 5000 users who create 3 documents per year each, and that’s what made us move to a document creation license for that kind of tool that’s more focused on templated design usage.

There’s arguments to be made for either case here but that’s where we landed.

Thomas Phinney

If you are licensing a font to a user, my personal opinion is that your standard license should include allowing that user to use the font to author with any online tool they use. With the limitation that authoring a document with that tool should not give use of the font available to other unlicensed people accessing said document.

Nadine Chahine

Excellent question and I agree with Thomas. My recommendation would be to explicitly prohibit the use of the fonts in apps with multi-user access. So if you're one person using Figma fine, but if there's an entire team working on a Figma project and only one user has a license, then not a good idea.

Please keep in mind that one only needs a local copy of the font for text editing and resizing in Figma. So a whole team can work off just one license and that seems at odds with how users in the desktop license are counted.

Further, collaborative online work is the way forward, that is pretty clear by now. So our licenses would need to adapt to that reality. 

Stuart Sandler

I definitely agree the total number of End Users should never exceed what was purchased but it would be quite difficult too clearly express usage limits to users of these services (document limit, eBook, websites, etc) and hope they're respected.

For clarity, please explain why does Figma get different treatment than Canva or other online design tools?

John Hudson

I need to review our license to see if it makes sense to add explicit about online design tools, but in general we approach this as akin to installation on a local server, i.e. it is an implementation of the device use license in which the number of users having access to the fonts on the server/tool must not exceed the number of users in the license purchase limitations.

I’m not keen on the document quantiity model, because it makes a weird distinction between creating a document in a page layout app running on a local computer and creating a document in an equivalent app running on the Web. Unless the online app itself is going to somehow manage the document count and apply the restriction, it seems unenforceable. Also, does such a license restriction make a distinction between draft documents and final documents? How?

Thierry Blancpain

This is because most users of Canva are in a corporate environment where templates are set up once, and then exported with some adjustments. These exports are usually not edited by a designer but by a general user, i.e. more of a text field editor logic.

We apply the same licensing to server-created documents. This could be for business card ordering processes, that is a web interface for employees to order their own business cards by entering name, role, phone, etc. in a web form interface. Or for the creation of hundreds of thousands of invoices for customers of a utility company every month, to give you another example. A desktop licensing logic doesn’t make any sense here (often there’s no font installation happening at all), and instead it’s about automated document creation.

Canva sits in between the two worlds of desktop use and automated document creation. But in speaking with our users, we found that they’re more likely to be closer to that second world of automated document creation in that they just export thousands of documents per year based on a few actually designed templates.

In Figma, they need to have the fonts installed locally for such a use case. In Canva, they don’t. As such, we decided to treat these two services / apps differently.

jeremy tribby

Thierry Blancpain said:

In Figma, they need to have the fonts installed locally for such a use case. In Canva, they don’t. As such, we decided to treat these two services / apps differently.

I think that depends on the plan - enterprise plans and organization plans make it possible to upload a font file to figma for teams to use and doesn’t require local installation

Stuart Sandler

Thank you for the insight Thierry! Given that, how do you communicate to the customer not to share templates in Canva? What mechanism have you implemented to preserve what your EULA allows? Do you sell a Canva specific license?

Thierry Blancpain

Stuart Sandler said:

Thank you for the insight Thierry! Given that, how do you communicate to the customer not to share templates in Canva? What mechanism have you implemented to preserve what your EULA allows? Do you sell a Canva specific license?

Generally speaking, this licensing is always purchased in addition to other licensing types. It’s not really an issue from our point of view, we’re not here to police our licensees super hardcore as long as they are overall trying to cover their uses. I know some foundries employ (and easily pay for) lawyers on their staff just to go after licensing infringement. I’d rather not run that kind of foundry, personally.

It’s called our Server license add-on and can cover Canva but also the above-mentioned other uses that fall under the umbrella term of automated document creation.

Stuart Sandler

https://typedrawers.com/discussion/5244/canva-adobe-express-uploaded-fonts-with-unrestricted-use

JoyceKetterer

My license is agnostic about the means by which the fonts are used on a computer.  We specifically allow cloud platforms so long as all CPUs are licensed.  

Stuart Sandler

@JoyceKetterer Section 1(b) of your EULA expressly forbids the use of the font as part of a website's CSS code which is precisely what Adobe Express allows if your fonts are uploaded to that platform, what am I missing?

JoyceKetterer

@Stuart Sandler. you're the first person to read that clause as relating to cloud computing, including both me and my lawyer. I don't know the exact mechanism for Adobe sync but it's sequestered and not a website.  Also, all our fonts are already with Adobe so we were thinking more about Canva when we wrote this.  

Here's the relevant clause below.  I included the whole paragraph and  bolded the relevant bit because I couldn't figure out how to highlight.  

Paragraph 1. e:

CPUs up to the licensed maximum may access and operate the Font Software, so long as the CPUs are owned or leased by you and are being used by you and your employees. If you host the Font Software on a server, non-licensed CPUs must not be given server access to the Font Software, and the number of licensed CPUs must equal at least the server CPU(s) plus all CPUs which you want to have access. If you intend to install the Font Software on virtual machines for use by your employees, the number of licensed CPUs must equal at least the server CPU(s) that host the virtual machines plus all virtual machines to which you want to have access. If you upload the Font Software to a cloud platform which accepts uploaded fonts, the number of CPUs which access those fonts via the platform cannot exceed the number permitted by this License, regardless of the number of user accounts registered with the cloud platform.

Stuart Sandler

@JoyceKetterer your clause makes sense for using fonts solely within an online design application however I'm specifically referring to your fonts being published as part of a website that was designed within an online design application. As you noted, if every Darden font is already there, it's a non-issue but in cases where an Adobe Express user can't access Darden fonts but finds a copy of Omnes floating around the internet, uploads it and then publishes a website via Adobe using the font, does this not violate Section 1(b) of your EULA?

JoyceKetterer

no. that would be web embedded, which is not permitted sorry, i miss understood the question 

Stuart Sandler

My effort to raise the flag on this concern I think is valid and I wonder why there isn't more foundry concern.

In both Canva and Adobe's cases, they're publishing user created websites directly via their host platforms, so it's an end to end issue and should be addressed by how they allow fonts to be treated that are onboarded manually as I noted to both not a single EULA grants a web font use right by default (save for one or two indie foundries)

Christopher Slye

Stuart, in the other thread I pointed out that I could not reproduce any scenario where Adobe Express was using user fonts in published websites. Is this something you’ve seen for yourself?

Stuart Sandler

100% Yes @Christopher Slye - You can upload a font by creating a Brand then you can hit the + Icon in the upper left to create a Webpage and then while there are precreated templates you can use, you can also click the Create from Scratch button in the lower right, you can click the magic wand icon in the upper right, Create a New Theme, Click any title you wish to stylize and select the Title Text which includes any fonts uploaded into a Brand.

Christopher Slye

Thanks Stuart. I hadn’t tried the “Brand” route. I was able to create a web page and see it using the fonts I had uploaded.

The so-called “brand” — initially called a “brand kit” in earlier products like Adobe Spark (and I think something before that too) — originated as a tool for enterprises and agencies to control brand assets across an Adobe workflow. In that sense, it was not really an end-user feature, and arguably it made sense to allow these more license-aware and responsible users to upload fonts for that.

The thing is, it has now leaked out to be more end-user-facing, which creates more opportunities for inadvertent misuse. The workflow still includes the standard checkbox acknowledgement when fonts are uploaded, and then when adding “brand” fonts to a webpage, there’s an additional warning (which I’d never seen before) that says:

By publishing this webpage, you acknowledge that you have all necessary rights and licenses to allow storage and serving of these fonts to a public website.

That language is explicit about “a public website” which helps a little. The thing that bothers me the most is that both checkbox warnings include a “Learn more” link to a help page that explains more about “Font usage and rights” and EULAs, etc. (largely written by me many years ago!) that is very specific to desktop publishing. It doesn’t address web fonts and web publishing at all – and IMO it should.

Stuart Sandler

@Christopher Slye I appreciate your taking the time to validate my concerns about this. Not sure if you're still in touch with the former teammates but anything you can do to make sure the concern gets in front of the right eyeballs at Adobe is deeply appreciated. I do sincerely feel there needs to be some additional blacklisting that foundries can participate in that prohibits these sorts of infringing uses.

Christopher Slye

Stuart, I do keep in touch with my old team there and will be happy to bring it up. I think the documentation could be improved for sure.

Back when this was all getting off the ground I probably annoyed some people in my caution about licensing guardrails, but in the end I thought the implementation was a good balance between foundry and user (and I guess Adobe’s) interests. Still, this webfont usage is new and while I’m not as troubled as you, I still think it’s lacking in the user education department. While I think you’d disagree, I still think any “infringing uses” would be primarily on the end user.

Stuart Sandler

Of course you're not as troubled as I am @Christopher Slye because you don't make or sell your own fonts. This is sincerely an erosion of potential licensing income from the loss of web font sales and it's a violation of desktop End User Licensing terms across all foundries.

Consider the fact that the organizations who are enabling the ability to upload fonts and generate webfonts from them within websites they host on their own platforms aren't actually policing this use and aren't providing foundries a means to police these uses either.

That means they are legally required to prohibit these uses via some internal mechanisms to assure they don't accidentally run afoul of being complicit of the violation of these EULA terms.

To call it a failure of customer education is an absurd observation. People pay monthly fees to these companies and believe anything they're able to do with these tools is allowed as it is encouraged and as any paying customer would assume. Unless they're expressly notified in-app that uploaded fonts cannot be used in generated websites or prohibited from using uploaded fonts in generated websites, we have a problem that requires a remedy.

Shrugging and saying it's a user issue is not a meaningful solution, it simply passes the buck on responsibility which lies solely at the feet of these organizations.

Christopher Slye

Stuart, I disagree. I think there’s always room for improvement, but these assertions that Adobe is “legally required to prohibit these uses” are unconvincing to me. It’s not like Adobe doesn’t have their own legal counsel weighing in on the matter. There are two click-throughs warning users that they need a license that permits web use. I don’t pretend that a typical user knows or cares much about that, but they should, and I think it passes legal muster. If you disagree, I think you’re welcome to challenge Adobe in court. (Spoiler: You would lose.)

And every day, font end-users are absent-mindedly posting fonts to the web in other ways, not to mention the age-old problem of sending fonts off to colleagues, contractors and print shops when their EULA prohibits it. I’m skeptical that this relatively obscure Adobe option is a unique, grave threat to foundries.

You laugh at the idea that it’s a failure of customer education, and you also dismiss the suggestion that it’s a user issue. Do end users have any agency at all in this?

I don’t necessarily disagree that “we have a problem that requires a remedy,” but for font creators (of which I am one, actually) it’s one of about five hundred problems that could use a remedy. I guess we disagree on how to prioritize them.

Stuart Sandler

When the organization that allows the font to be uploaded also converts the font and publishes it to a platform hosted by the organization, they've effectively become legally entangled and inherit the liability of violating the EULA terms even if the customer 'I acknowledge I have the right' checkbox is in place it's not a compelling argument.

To your notion that I laugh at anything, is an editorialization of my position which is based in fact, not opinion. Organizations who allow fonts to be uploaded bear a responsibility to assure those fonts are only used in the legal manner which they were licensed by the creator of the font.

If those fonts are then used in a manner that is wholly outside of the scope of 95% of all foundry and distributor EULA terms for a web font license purchase requirement, that's a meaningful breach of trust that requires the solution happen at the organizational level since it is the host of all the website generated by this feature.

It doesn't dismiss the End Users agency whatsoever but in fact is a covenant between the organization and the foundry that shouldn't be ignored. And if it is, do we simply shrug and let the behavior continue as if it's OK? It's not and doing nothing will assure the trend continues as these organizations start to expand the mediums that design tools can export into which may also violate EULA terms.

As an example, most foundries and distributors have a Digital Ads license upgrade requirement and once it's possible to generate banner ads directly from these platforms right into Google or Meta's ads platform (which is very likely for the benefit of its customers) this is also a meaningful loss of income for foundries. When should foundries intervene? Never?

John Hudson

Stuart, while I sympathise with your position, I think Chris is correct to say that this is something that, in legal terms, could only be decided in court. You are asserting that there is ‘a covenant between the organization and the foundry that shouldn’t be ignored’, but what is the substance of that covenant? There is no contract between the parties. I’m not a lawyer, so I don’t know what remedies exist in such a situation, but it seems to me that as a legal question it might drift into something like criminal liability rather than civil tort law.

You ask, ‘When should foundries intervene?’, but what does intervention look like? I would be wary of any court action around fonts in the USA.

Miles Newlyn

I'm concerned about the possible change of file format that uploaded font files might undergo. I uploaded an otf but was not able to find out if the webpage I created using the font was calling that otf file or if the backend had changed it to woff.

John Hudson

@Miles Newlyn The backend almost certainly converts to WOFF2 (and WOFF if also targeting older browsers).

Stuart Sandler

@John Hudson it would be important to look at if there is precedent to make such a determination. Github is one example where users may have uploaded files that are publicly available and some discourse was had although I don't know if this ever ended up with a legal ruling. The main difference here is that Github isn't performing a software format conversion and then hosting the converted software in a new medium.

If indeed the End User becomes the mechanism for the infringement who becomes the responsible party? Organizations like Canva and Adobe create these offerings knowing they add value to a customer's subscription but knowing a vast majority of font licenses prohibit this use and taking no action to meaningfully assure uploaded fonts aren't used in this manner is at minimum displays reckless behavior on their part and at maximum makes them a willing accomplice to the infringement.

There is only so much liability that can fall on the End User if the platforms they are uploading fonts to only use a checkbox to confirm rights of use knowing full well almost every EULA forbids conversion. I don't think the burden of proving complicit behavior in these types of infringements is that high given what is generally known by organizations that produce design applications.

Do I intend to mount a legal challenge? Who could? But I can make sure my fellow font creators are aware this issue exists and that nobody is taking action to remedy it.

John Hudson

There is only so much liability that can fall on the End User...

And yet the end user is the only party that has entered into a legal agreement with the font foundry.

This is why it looks to me like any third party service liability is difficult to establish, especially if such a service takes even minimal steps to require the end user to confirm rights to use the fonts in this way, e.g. by clicking a checkbox. That measure may seem inadequate to us in terms of limiting infringement, but it may indeed be adequate to dodge legal liability.