Talk:EULA abstract

From Fontlab Wiki

Ted H: Here are the EULA Abstract contents datapoints in their current state of discussion - mostly done by Emil Yakupov, Yuri Yarmola, and myself. There is debate as to whether "Server Installation allowed" should be an item. We really need more input from people actually writing and using Font EULAs.

Tharrson 06:32, 10 Sep 2004 (CEST): I just added two more datapoints which I think will help with understanding and maintaining licenses.

Tharrson 18:57, 28 Jul 2005 (CEST) Here's a quick summary of the TypeCon meeting for those of you who weren't there: We added a Site License option to the #1 datapoint. We discussed the embedding problem: consensus - it's still a problem. Opinion from Frank Martinez about anti-trust: it's not a problem if we don't talk about prices or anything mandatory Opinion from Frank Martinez about whether having an abstract weakens the real EULA: not if the user is warned that the abstract is not the full EULA and that they are bound by the full EULA and they are given access to the full EULA. The question arose as to whether using the EULA abstract might run afoul of the DMCA. Si Daniels will try to get an informed opinion from the MS lawyers on this. Bruno suggested internationalizing the EULA abstract interpretation by using symbols. Laurence suggested using the EULA abstract to create instant EULAs for foundries who wanted to use Frank Martinez's standard EULA form. Laurence also suggested creating an XML DTD of the EEULAA (electronic EULA abstract). I think I'll work on that. Emil volunteered to continue development of his EEULAA editor and Font Installer to reflect the new datapoints and to add the EEULAA to all the ParaType fonts. He expects to have a full system demo for ATypI.

Tharrson 21:30, 29 Aug 2005 (CEST) I have created and validated an XML DTD for the EEULAA data set and added it to the bottom of the EEULAA data points page. All are invited to comment, critique and edit.

Tharrson 16:32, 12 Aug 2006 (UTC) The data points have been stable for a year now, so I think it's time to release rev 1. Which begs the question -since there are certain to be future revisions should we included a field for rev# so that EEULAA readers can adjust their interpretations to the rev that they are reading? In any case Fontlab will include a rev1 EEULAA reader in the upcoming release of TypeTool3. We are also hoping that Emil Yakupov will update and release a version of Paragraph's EEULAA reader/editor utility, but we need to discuss the security considerations of having a freely available EEULAA editor. Perhaps we'll set up a meeting at ATypI.

Tharrson 11 April 2008 - Last weekend I attended the FDRC (www.fdrc.org) conference in Redmond hosted by Microsoft. The conference was about protecting fonts from piracy and a lot was said about using the EULA. Many people were interested in the EEULAA and now with Apple's release of Safari 3.1 that can use raw fonts in web pages there is a sense of urgency about it. John Collins gave an excellent talk on what parts of the EULA are most useful and several people talked about how they are using EULAs. Many people were interested in the EEULAA.

A couple new ideas came out about how fonts are likely to be used, so I've made a few of changes to the datapoints. I've changed one point to "eDocument" rather than "eBook_eNewsletter" in order to be more inclusive. And I've made the web embedding choices a little clearer by titling one "Intranet webpage" and the other "WWW page". Fontlab is going full out now to have Read-only and Read-write DLLs for this OpenType table ready in time for TypeCon.

Tharrson 17:56, 24 Apr 2008 (UTC) After some discussion among ourselves we've decided that perhaps there should be password protection for the editing of the EEULAA. The idea is that an original font creator would be able to add a password to the EEULAA and that in order to edit the EEULAA from that point on someone would have to enter the password. Of course this would not affect the reading of the EEULAA, that would remain open to anybody. And also we don't expect that this would stop serious hackers. But it would be a deterrent for casual typographers who might otherwise face the choice of "correcting" the EEULAA to meet their needs versus clicking the "Upgrade" button to purchase an upgraded font license.

server installation

Emil: Server installation position is not quite clear for me. Could anybody explain, is it "print (rastering) server", or just a storage for font files in a local (or may be global) network? --

Tiffany (wiki newbie): Emil, I believe "server installation" is actually for those who manage there fonts on a server instead of having the fonts reside on the computers of those who use them. For instance there is a server version of Extensis Suitcase.

Ted H: Yes, that's what we had in mind. Some EULAs may restrict usage to individual computers. I.e. the font file must reside on the computer using the font. Others may allow the font file to reside on a server, but to be accessed by multiple other workstations on the network.

Emil: Well, thank you. This means that server is actually used as a storage for font files. It just the same as to keep font files on a diskette and insert it before you start computer. Actually fonts are installed, registered and processed on a certain local computer. Those who have such a restriction in EULA either don't understand this or keep in mind something else. The only reason for such restriction that I can imagine -- server is not safe place to store font files, anybody who has right to access to a server can use that fonts, but a local computer also accessible via net...

Bill D: My understanding is that the server installation was to allow users to store fonts on a server for access by a defined set of licensed users. These users would then copy the font software to their workstation either manually or via a utility such as Suitcase Server. The point is that anyone with access to the fonts on the server needed to be licensed. This kind of server use is how fonts are commonly used in large workgroups in graphic arts environments.

Note that a new kind of server use is emerging - fonts on a web server with a web-based application. For example there are web apps that allow users to select and use different fonts to interactively create business cards, etc. These kinds of server uses are beyond the typical server use definition because the end users are not licensed users.

Tharrson: per Emil's suggestion I have merged the Server Installation datapoint with Licensed Devices.

licensed devices

Emil: Many EULAs restrict both CPUs and printers. Current table does not serve these EULAs. I think it make sense to give possibility to specify number of "processing devices" and "output devices". At the same time specification a type of device is not so important for machine readable form and better be placed in human readable field. There you can better specify what do you mean under "device" and add some other important details like 'location of devices' -- single site or multiple sites; 'notebook installation'; 'server installation/storage', which is hard to formalize.

Ted H: Yes, lets try to keep this as simple as possible. If there really are lots of EULAs out there which specify number of output devices separately from number of processing devices then I think the easiest way to acommodate that is to allow multiple entries of this field in the table. So, for instance, when a EULA allows 3 users and 1 printer then this field would appear twice in the table. We wouldn't need to change any of the choices and in fact it would be much more flexible. In fact we could just use some Boolean logic between the various entries of the field in the table to come up with some rather complicated scenarios: 6 users OR 3 workstations AND 2 printers :)

Laurence: One thing we don't have, which many licenses use, many imply, and which customers might well find most useful and analogous to the way they license other software, is number of users. So how about we replace "Licensed devices" with "Licensed entities" and add "user" to the "types of entities"? (Interfaces obviously need not use the word 'entity'.)

Ted H: That sounds pretty reasonable. I'll add it.

Frank: PDF Embedding - What about checking online if the font which is embedded has the proper license that permits it to be embedded or used? Companies and individuals then could register and update their licenses online, just by adding another MAC address (unique ID of your computer). ...one more thing: We should get over the printer licensing stuff, it's 2004(!) not 1989 anymore. By the way, I don't think my printer will harvest all my fonts and start a business on its own.

Lorp Here's a tip: use three ~ characters in a row to record your username! That's how "Lorp" appears at the beginning of this paragraph. That way we can keep track nicely of who's saying what. Use four ~ characters and it'll include the time & date.

Emil 10:30, 3 Sep 2004 (CEST) Ted, if you look at the table in Tiffany's article, you'll see that more then a half of listed foundries have restrictions for number of ouput devices. But your offer seems quite reasonable, let's have 2 entries for the number of devices. I'm not quite sure that it's easy to have multiple entries, because we need to keep in mind a table of certain structure for TT/OT font file, but I'll talk to our programmer about such possibility. Laurence, yes I also 'second' your offer for adding "user".

BillDavis 16:17, 7 Sep 2004 (CEST) Yes there are a wide variety of terms used in different EULAs (workstations vs. users vs. CPUs vs. Printer). The CPU and Printer terms are a legacy from the good old days before ATM where the printer fonts were stored in the printer. I think moving forward the intent is to target the use of font software on a workstation basis. This is because you can have a workstation with multiple CPUs, thus CPU is not a good term. Similar with users - you can have a common workstation that is accessed by numerous users. The challenge is for each type designer/foundry to examine their own EULA and talk with legal counsel to determine what term best meets their needs.

Lorp 18:12, 7 Sep 2004 (CEST) : Bill, I agree that "users" is probably not right for corporate environments. Despite their being informally known as "multi-user licenses", corporations would probably much prefer to manage each workstation's licensed software rather than each employee's. However this doesn't address Tiffany's concerns at all: she wants to be able to take work home on her laptop, to use the font on the PC with Photoshop installed one day, and on the InDesign Mac the next. And she wants to be given the trust that she - that single end user - will be the only person using the font. All this in the standard, default license. In corporate environments the "end user" never sees or agrees to any kind of font license - his IT or marketing manager licenses the font on his behalf - so even the term EULA can be misleading here.

Miss Tiffany I don't think there should be separate specs differentiating "processing" from "output" devices. But, I think we live in an age that the number of "output" devices should be unlimited as long as they are within the same buiding/address as the person who licensed the type. I think it is not user-friendly to put some crazy limitation on that. However, that said, I am speaking as a designer in a small agency and so don't really speak for everyone. Emigre (off the top of my head) does the best and is the most user-friendly. While they use the term "device" and do not differentiate between "processing" and "output" devices, at least the number of "devices" is reasonable. ¶ Laurence is correct in his assumptions. I think that those foundries that allow for use by the licensee at home and work on the laptop would be more user-friendly. Large corporations don't allow (most likely) their team to work at home anyway, and so it would only really benefit the small freelancer and so I don't see any harm in loosening that up a bit.

embedding

Lorp 17:54, 9 Sep 2004 (CEST) : I don't think Font Embedding/Type is well defined. For example, a foundry may want to allow PDF embedding for output at service bureaux, and set the appropriate embedding bits, but declare that these documents must not be posted on the web. Like so many specs, we seem to be confusing the technology (e.g. PDF embedding) with the IP control (e.g. where those PDFs are going). I wonder if we should be discouraging foundries from making technology-specific restrictions, and encouraging them to decide where their data's allowed to go, and who beyond the licensee is allowed to edit documents. Thus a "web-embedding" license would typically allow PDF, WEFT and Flash embedded fonts; an "output bureau embedding" license would allow all of those too, if they were the method chosen to get a document to a service bureau, but disallow use on websites. Here's an attempt at a list of types of embedding:

• user only (such fonts might still technically allow embedding for user convenience)
• output bureau
• intranet (documents may be downloaded by anyone within a company)
• editable embedding (other users may edit the document)
• eBook and eNewsletter (free and paid-for, one-off and subscription)
• OEM software (game, multimedia encyclopedia)
• web (freely downloadable)

A licensor may want to distinguish between free and paid-for documents and software. Agfa-Monotype go into even more detail: read their page (http://www.fonts.com/fontservices/services_home.asp?nCo=AFMT&con=embedding).

Tharrson 06:43, 10 Sep 2004 (CEST): Yes, I think this is a crucial part of the EULA and we need to allow maximum flexibility here. But I would revise your list to exclude "editable embedding" since that is a permission (or maybe we should call those "levels" rather than "permissions"?), not a type. Perhaps what we need is a two-tier system here where each Embedding type gets its own embedding level? I've rearranged the Abstract data points to show what I mean.

This would be significantly more difficult to parse and interpret. What do the programmers think? Emil? Yuri?

Lorp 15:52, 10 Sep 2004 (CEST) : Ted, I imagined those things in my list as multiple checkboxes rather than radio buttons (i.e. multiple selections possible), but you're right to separate the two strands clearly. Let's avoid using the vague word 'type' and use 'distribution' and 're-use' to label these two independent axes. Such a 'matrix' recalls Clive's embedding matrix.

Tharrson 20:40, 12 Sep 2004 (CEST): Absolutely there should be multiple selections possible. This puts us in the same position with this field as we are in #1, where we need to allow multiple entries of the same field but with different data. I think Emil said that was feasible. It's just a matter of writing the interpreter so that it parses it correctly.