From: Ted Hardie <hardie(_at_)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