Subject: DEPLOY: IPR License and Custom Software Development

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 25 Aug 2004 21:58:30 -0400

> From: Ted Hardie <hardie@xxxxxxxxxxxx>
...
> An important part of the IETF process is that we treat all of its participants
> as behaving in good faith.  If the license terms offered cause difficulties
> for you, please state how the terms impact your development and deployment.
> (Eric's description of the sublicensing issue for Sendmail is a good example
> here, and I encourage you to read it as a potential model).

I have been lurking but in response to this message, I would like to 
submit my opinion as to why this specific license might cause problems 
in deployment. My company develops software for managing small service 
businesses including management of internal company email, and 
internal/external email gateways. Our deployment concerns are outlined 
below. This message is intended as input into the Final Call process.

1. License can be revoked

Our first concern is that we do not want to sign a license with a third 
party which will affect our main product and systems, especially if such 
license is revocable. Specifically, we do not want to end up ripping 
Sender-ID code out of our software or a modified open source package 
running our systems if the licensor decides that we are in breach (as 
per section 3), and having to pay if we don't rip it out. While it is 
possible that anyone can sue us for patent infrignment, the fact that we 
have identified ourselves via a signed agreement makes this much easier. 
We are also concern about the fact that the license terms can be 
changed. We do not want to be forced to pay for the use of Sender-ID 
code a year from now or face the expensive work of ripping code out.

2. Legal Counsel is Expensive.

Being a small business we do not have the monetary resources to afford 
appropriate legal counsel to interpret the license, how it applied to 
our software, and to any open source software we may use or develop. The 
same situation applies to many open source authors who cannot afford 
legal counsel or the expense of a lawsuit. At the same time we do not 
wish to blindly sign a piece of paper which we do not know the impact of.

Recommending contacting the licensor's legal department as suggested is 
not an option either. First of all, being that they have the licensor's 
best interests in mind, their legal advice may not be reliable. Second, 
in my personal experience Microsoft's legal department is very slow to 
answer. I am still waiting for answer to a related IPR issue, which I 
first emailed the legal department in early March. Six months for answer 
when there are deadlines, is not good enough.

3. Discouragement of Open Source Software.

The whole point of open source software is ability to freely modify 
code. In this specific instance, the piece of code that implements 
Sender-ID, would require a new signed license from the licensor if it is 
changed. This discourages the use of open source software, for both our 
company and our customers.

4. Sub-licensing.

We occasionally work with customers and partners to create customized 
software. The fact that this license is not sub-licensable, creates a 
greater burden on our customers and ourselves, and discourages our 
customers from seeking our consulting services.

5. Privacy.

The license explicetely states the privacy of the licensee is not to be 
expected and that licensee's information maybe published on a website. 
We, our customers, and our partners, do not wish to have our information 
published in such matter. Additionally, we are also afraid that this 
information may be available to other parties that may seek to sue the 
licensor for infrigment, and have such list readily available to add to 
their lawsuit. Even if this list is not public, it is still obtainable 
under a subpoena.

6. Suggested Changes.

I would highly recommend taking out the requirement to sign a separate 
license for each implementor which seems to be the main problem. 
Substituting a EULA-like agreement might be better.

Otherwise, I would recommend against approving this standard with this 
license until these concerns are resolved, since all of the issues 
listed above will discourage parties from implementing and testing this 
standard.

Sincerely,
Yakov Shafranovich