Mr. Winer has retained our firm and asked us to contact you about two related matters. If an attorney is representing you, please provide this letter to your attorney and have him or her contact me.
First, we request that you return the $5,000 deposit that Mr. Winer paid to you in October 2005 in connection with certain work that you were supposed to perform for Mr. Winer in revising and maintaining Mr. Winer's website, feeds.scripting.com. Mr. Winer had previously sent you a consulting agreement regarding this work and made it clear to you that he would not hire you to perform this work without a written agreement signed by each of you. It is our understanding that neither you nor Mr. Winer signed such an agreement, that the redesigned site was never completed and launched, and that Mr. Winer has advised you that he no longer wishes to use your services for this project.
Second, Mr. Winer has recently learned that you have used the contents of his website "feeds.scripting.com" as well a computer application authored by him and certain third-party information, to launch a public web site known as the OPML Factory, presently located at "opml.cadenhead.org." The contents of feeds.scripting.com and the computer program are Mr. Winer's property and are protected by federal copyright law as well as by state law. Mr. Winer has not authorized you to use his property to launch the OPML Factory and your use of his property for such a purpose constitutes a willful infringement of Mr. Winer's copyrights under 17 U.S.C. 101, et seq., for which you can be liable for statutory damages as high as $150,000 for each unauthorized use, pursuant to 17 U.S.C. 504(c) (2), and liable for Mr. Winer's attorneys' fees if he were to bring an action against you in the United States District Court to enforce his rights, pursuant to 17 U.S.C. 505. Accordingly, on behalf of Mr. Winer, we demand that you immediately cease using or distributing all materials that Mr. Winer provided to you in connection with the "feeds.scripting.com" project, that you return to Mr. Winer all such materials, that you cease operating the OPML Factory and any other websites or portions of websites derived from his property, that you destroy any works derived from Mr. Winer's computer program, and that you desist from these uses and from any other infringement of Mr. Winer's property in the future.
Specifically, we must insist that, by no later than next Wednesday, March 15, you:
- (1) return the $5,000 deposit to Mr. Winer;
- (2) return all materials, third-party data and applications that Mr. Winer provided to you I in connection with the "feeds.scripting.com" project;
- (3) destroy all works derived from such materials, data and applications, and provide us a sworn statement, signed under penalty of perjury of the laws of the State of California, attesting that you:
- (a) have destroyed all such derivative works and
- (b) no longer possess copies of any the materials, data and applications obtained from Mr. Winer; and
- (4) take down the OPML Factory website (presently located at "opml.cadenhead.org") and any other websites or pages that you derived from feeds.scripting.com.
If you do not take these actions by next Wednesday, March 15, we shall assume that you will not be complying with Mr. Winer's demands and we will take all appropriate actions to enforce Mr. Winer's rights.
Last spring, in a work-for-hire agreement with Winer, I ported Weblogs.Com from a Frontier application running in Windows to an Apache/MySQL/PHP application running on Linux. I'd been telling Winer for years that he should run his web services on LAMP, because it handles high-load applications better and much less expensively than Frontier. We reached a verbal deal and I wrote it in a weekend for $10,000, following up with a written contract.
The project was a personal success for me, because after years of writing books on Internet programming, I was eager to prove that I could develop a web application with such huge demand. On an average day, my program served 34.65 gigabytes of data, took 1.1 million pings and sent 11,000 downloads of changes.xml, a file larger than 1 megabyte.
It was a financial success for Winer, who sold Weblogs.Com to VeriSign in October 2005 for $2.3 million.
Right after that deal was announced, we reached a verbal agreement to do the same thing on Share Your OPML, an RSS subscription site he developed with Andrew Grumet on Frontier in early 2004. I agreed to create, host and manage a LAMP version of the web application and Winer offered $5,000 when work began, $5,000 when the application was done, and 33 1/3 percent ownership of the site.
I developed the web application over the next two months, producing a 1,602-line PHP class library, 50 PHP scripts and a MySQL database that holds 1,438 members, 68,773 RSS feeds and 174,354 subscriptions to those feeds.
Contrary to the attorney's letter, the application isn't built on proprietary data. Winer released a Share Your OPML SDK in January 2004 that offers OPML subscription data for 1,054 users who agreed to share their subscriptions, and the data continues to be offered to the public today.
The web application has been in limbo because we haven't been able to reach a written agreement to supercede the verbal one. I figured that one of us would eventually end up taking over the project and the other would recoup his original investment, and I thought it could be resolved amicably until I got Friday's letter.
Winer seems determined to go after anyone he perceives as a threat to his authority over RSS, even to the point of turning a minor business disagreement into a federal case ("17 U.S.C. 101, et seq.").
I don't have a board of directors or a venture capitalist who can talk me into quitting the RSS Advisory Board. I'm a self-employed stay-at-home dad, and my sons are not persuaded by the argument that the board threatens the RSS roadmap.
But he has succeeded in making me sorry I took his invitation back in 2004 to get involved in RSS, a syndication format that will forever be mired in childish personal animus because of his mistaken belief that allowing other people to contribute to its success will rob him of credit.
The archives of Workbench contain numerous examples of lavish praise I've given Winer over the years, including an effort I led among his admirers to pool their funds and buy him a get-well iPod after he underwent heart surgery.
I've never been more retroactively embarrassed to have paid someone a compliment in my life.
The DNS service(s) on your server are currently open to recursive queries from the world, leaving them vulnerable to DNS cache poisoning attacks and allowing them to be used to attack other sites. Your server was reported participating in an outbound DDoS attack through means of this vulnerability by an attacker. Please ensure that recursive lookups are DISABLED in yournameserver's configuration to prevent future abuse. If you need any assistance with this procedure, please let us know.
My name server was taking requests from any user for any domain, not just the ones it was configured to handle like cadenhead.org. When a request came in for a domain on another server, it was forwarded to another server, which could forward it further.
I didn't know that this open recursion let my server be used in a denial of service attack.
I closed the vulnerability by adding an acl section and a new allow-recursion setting inside the options section of the named.conf file:
acl internal {
67.19.3.218/29;
};
options {
allow-recursion {
internal;
};
};
The acl section refers to the machine hosting the name server, which allows programs on that machine to make recursive requests. All other clients should be blocked by this configuration.
While I was poking around, I took another blogger's suggestion to turn off zone transfers from my name server, except for one machine that functions as a backup name server:
allow-transfer {
67.19.86.58;
};
This is one proposal among three currently under development on RSS-Public, the public mailing list of the RSS Advisory Board.
The others are a new specification for the Really Simple Syndication format and a best practices profile, a set of recommendations for how RSS documents can work in the widest possible audience of aggregators, browsers and other software. I published the first draft of the profile this morning, which will be filled out one section at a time.
We could use more participants on the mailing list to work on the profile. A "best practices" document has a much better chance of being true to its name if a bunch of RSS publishers and developers contribute to it.
Because of that open policy, this site is hammered around the clock by comment spammers who want me to enlarge my penis and lose weight with phentermine so I look good the next time I play online Texas Holdem poker.
To give you an idea of how bad the problem is becoming on weblogs, this site has received 13,445 comments in the last 21 days, and 13,188 of them were comment spam, even though I have manually blocked 4,737 IP addresses because they were used for spam.
The interview, which I've attached as a 17-minute podcast, was to promote his new book An Army of Davids, which has the subtitle "How Markets and Technology Empower Ordinary People to Beat Big Media, Big Government, and Other Goliaths."
No knock on Reynolds, whose blog I enjoy in spite of our political differences, but the interview made the book sound like technoutopianism. Since the dot-com bubble, I have a low tolerance level for fables in which technology solves problems without creating new ones and the geek shall inherit the Earth.
ANAL INTRUDER
Anyone care to venture a guess as to what the driver was trying to convey with this sticker? I was so surprised I nearly rear-ended him.
One way to tackle confusing aspects of RSS is by defining a new namespace, XRSS, with replacements for all of the optional elements.
The XRSS spec could document the namespaced elements and also offer advice for the required RSS elements. To show how this would work in practice, I've created an XRSS namespace spec and a sample file.
The Harvard spec is the authority over all required RSS elements described in the XRSS spec, as stated in the Elements introduction:
An XRSS document consists of five required RSS elements, two required RSS elements for each item and zero or more optional XRSS elements.
The definitions of the RSS elements in this specification are provided for convenience and MUST NOT be treated as definitive. Refer to the RSS 2.0 specification for authorititive guidance on the format.
All elements of an XRSS document that are not contained in a namespace MUST be described in this specification. All recommendations offered for RSS elements in this specification SHOULD be followed in XRSS documents."
RSS documents that use the XRSS namespace would be declared in the rss element:
<rss version="2.0" xmlns:xrss="http://www.rssboard.org/xrss">
Any document with such a declaration indicates that it follows the XRSS spec, its definition for XRSS elements, and has reviewed the best-practice recommendations for RSS elements.
All namespaced elements would be under the clear authority of the XRSS spec, removing the need to mirror the behavior of the similarly named elements in RSS.
For instance, the enclosure element could be defined so that "an item may contain more than one enclosure."
Another problem the namespace can solve is whether to use an item's link or guid when the latter is a permalink:
A publisher should provide a guid with each item. When a guid represents a permalink, it should take precedence over the item's link.
The namespace also could drop elements that serve no discernible useful purpose and are rarely implemented, such as textInput.
This would indisputably follow the RSS roadmap:
Subsequent work should happen in modules, using namespaces ...