it took a lot longer than we planned (last atypi I said "a few months") but we're finally live with the new eula.
The documents were actually written last December but we waited to post them till we could make some changes to the site. We're also publicly displaying three addenda documents and the corresponding pricing (though purchases of addenda still need to go through our office.)
Link :
http://dardenstudio.com/license/eula
Comments
How does "If you want to send your client a file that permits the client to edit, alter, enhance or modify the Font Software, your client will need to purchase its own license to use the Font Software" jibe with "You are prohibited from decompiling or disassembling the Font Software for the purpose of converting, porting, adapting or modifying it in any manner"? I worry that a client will be made to buy its own license with the intent of modifying the font, only to then realize it's not allowed.
Actually, I think this should be
"If you want to send your client a file that permits the client to edit, alter, enhance or modify the file using the Font Software, ..."
I stand corrected. I think Hrant has caught a drafting error. I will make sure to do something about it quickly.
@JoyceKetterer I'm not expecting to change your mind about the untenability of the no-mod clause, and I honestly don't want to use your post to drive my agenda; it's that I feel that wording in 1.c does really give false hope to those not rigorously paying attention. But I guess you meant to say a file made with the font, not the font itself.
Also, section 1D refers to the font software being used on clothing which seems wrong. You don't use font software on clothing...at least not for another decade.
Say I'm an agency and I'm using this typeface for a brand. From reading this, I'd feel like I'm restricted from creating a slogan t-shirt. It would be as if Mazda weren't allowed to make a Zoom Zoom or Summer Sale shirt. That's how it reads to me. And it's fine if that type of use is restricted but there seems to be no addendum to deal with it. It seems to be telling me it can't be done.
Also section A3 talks about CORS - if you are serious about licensees implementing this help needs to be provided; I dare say even your average web dev will scratch their heads at first, let alone designers or clients.
Also, at the beginning of this month we went live with a massive rewrite of the web addendum (and a parallel but more minor rewrite to the app addendum). The intent remains the same but we are now better capturing the technology of web design.
Additionally, we made some minor changes to the primary EULA - most notably 1.i. - where we clarify our existing policy that addenda can only be issued to the owner of the brand which is embarking on the use. Previously, the EULA had stated that an addendum was needed for "this license" which would not be true if "this" was a license held by the web developer. Since we do make that clear when we do sales of addenda, as a practical matter, this clarification is for infridgers reading the license after the fact so that it is clear who is responsible to us. Anyone who has ever done a license enforcement action will know that this is a major sticking point because the client and contractor can each claim that the other is responsible and force you to to court.
I'm always interested in your feedback though I admit we're getting a bit tired of working on the EULA and sincerely hope nothing you say triggers more rewrites.
@Adam Twardoch - I'm looking forward to your thoughts as well
The reason to have this even if most people don't follow it and - even if we aren't going to treat lack of following it harshly - is because it IS best practice. Furthermore, we want self hosting to feel like a big deal when people contemplate it. We want the vast majority of customers to think twice before self hosting. It is higher risk. Also, both for that reason and because pricing to labor on our end doesn't scale down well, we would prefer that the consumer grade people not do it. That also means that the business grade companies that do it are the sort who need to be more security conscious generally.
For now most people don't use CORS but we are not above being aspirational in our business practices and you can look at this that way.
Thanks for elaborating in such detail, always good to know not just the what but the why and how you arrived at certain terms.
I’m asking because my thoughts have always been that people can download fonts in easier ways than going through source code, anyway, so there’s very little reason to require htaccess setups and other things.
It is a fundamental truth that we can not stop bad actors from stealing our fonts. It is equally a fundamental truth that it is worth our effort to help well meaning people who start of from the position of trying to license fonts properly to be more aware.
Therefore, we don't require licensees to take security measures to protect their licensed fonts as a means to limit piracy. We do so as a means to increase awareness among those associated with the licensee (staff, contractors, etc) that fonts are valuable commodities that should be treated carefully. Remember that a lot of people only understand they need to get a license and don't understand that continued maintenance that might be required.
We see a direct correlation (I don't have enough data to prove causation) between licensees with bad font license management culture and license infringement. The inverse also seems to be true based on the high percentage of licensees who go through a license enforcement with us and then make additional large license purchases.
Therefore, if we use the opportunity presented by the interactions we have with licensees to make them more thoughtful and respectful of fonts then it seems likely to be useful to us over time.
What I'm thinking of is types of use which are not strictly wrong or violating but which don't treat fonts with care. What we've been discussing is a good example. Two other good ones are companies with large licensees that don't have a font server, or that don't have a style guide. There's nothing strictly wrong with either of these but they are opening themselves up to more human error that way. I talk about this a lot in the lecture I did for extenis that @Katy Mawhood posted in another thread.
The foundational problem in licensing fonts is that most customers don't understand that they don't function like other software. When I talked about this in my lecture someone actually interrupted me to say "why don't you push consent of the EULA on installation?" You can't hear him in the recording but you can hear my answer "we literally aren't able to." This is how basic the lack of understanding is among our client base - that a person who knows to go to a day of lectures on font license management doesn't know the limitation of installation.
Most software has strong DRM and fonts do not. This allows licensees of most software to ignore the EULA and trust they can't violate it without purposely cracking the software. WIth fonts that's so completely not true that we can't even control the number of copies they make. And the problem here is that people either don't know that or don't think about it when they are using the fonts.
Add to that the fact that a great number of people think fonts are not a big deal and have no idea how much money their employer could be on the hook for if they make a mistake with the fonts.
So, as licensors of fonts we are constantly having to navigate a cultural problem. Therefore, whenever we can reinforce the idea that fonts are valuable and need to be treated with care then we do.