Modern day patents originated from a specific form of Letters Patent. These were decrees handed down by a monarchy granting exclusive monopoly rights to the recipient for a specific and often broad range of business activities. Patent laws have come a long way since then, but the basic premise is the same. A government provides monopolistic rights to the creator of an invention for a limited time. The justification here is to provide an incentive structure that is conducive to promoting progress and innovation.

But why, as professionals working with PHP, do we need to care about patents? Most small software development shops and startups will run their entire course without ever securing a patent. We should care because most small software development shops will infringe upon a software patent during the ordinary course of business. Patent infringement lawsuits, regardless if you win or lose, are expensive propositions. Further, we should care because they are threatening the software development industry as a whole. They are stifling innovation and creating massive barriers to entry. Major changes need to be made to fix the current system in the U.S. and across the world.

First, a little background on intellectual property laws and patents. The U.S. system will be discussed here because it has one of the broadest covering patent systems in the world, and is the basis for many of the software patent issues that are affecting the industry globally. The United States Constitution states that: “Congress Shall Have Power To […] promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries”. This one sentence contains the entire justification for the U.S. copyright and patent system. Patents are not the right to use your invention, but rather the right to exclude others from making, using, selling, or importing patented goods and services. Inventors must apply for patents which are then reviewed by government officials and awarded or denied based on their merit. In the United States, this is handled by the U.S. Patent and Trademark Office (U.S.P.T.O). They base their judgments on three main criteria. In order to be awarded a patent, the idea presented must be novel (new), useful, and nonobvious.

A patent will not be considered new if:

• The invention was publicly known before it was supposedly “invented” by the patent applicant
• The invention was explained or described in any publication more than one year prior to the date that the application is filed
• The invention was used or offered for sale in a public manner more than one year prior to the filing date.

The actual rules are more detailed than this, but are fairly clear in their application. The Useful requirement for patents is generally used only to throw out frivolous applications and is most often very easily met for software patent applications. The Nonobvious requirement is by far the most difficult to predict and judge properly. The rules state that not only must the invention be different from any prior art (novel), but it must also be a nonobvious extension or improvement on any prior art. This is judged by determining whether a person “of ordinary skill in the art” would consider something obvious. For example, as a person of excruciatingly ordinary skill in the art of computer programming, it seems obvious to me that, in an online shopping system, the less clicks required to checkout the better. Therefore, given prior art of a two-click checkout process, a one-click process seems to be an obvious extension. Unfortunately, as we will see, the judgments of the USPTO do not always follow my intuition.

A common misconception is that you have to actually copy another person’s invention in order to infringe on a patent. While this is true for copyright, it is possible to infringe on a patent while being completely unaware of its existence. Lack of knowledge is considered irrelevant in a patent infringement case. Another area of confusion is where exactly patents are enforceable. While it is true that patents are only enforceable in the country in which they were issued, international trade agreements make it very reasonable to obtain similar patents in many other countries, thereby making them internationally enforceable.

Software patents are only one specific form of patents. Surprisingly, they are available in most countries with a mature set of intellectual property laws; Even those countries that specifically do not allow them. This is achieved by working around the letter of the law and ignoring the spirit entirely. For example, in the United States software patents were not valid in the 1980s because they were regarded as “printed matter”. The federal government ruled that they were simply written instructions on how to perform a task and therefore outside the scope of the patent office. Further, the USPTO has always held that scientific truths or algorithms expressing those truths cannot be patented. No corporation can own e=mc2. In the mid-90s the “Beauregard Claim” was developed and shown to be lawful, and it changed the landscape of software development for the worse. While it was still unlawful to patent a set of written instructions, the Beauregard claim sought patent protection for a computer readable storage device (hard drive, floppy disk, CD-ROM) which contains the specific written instructions. This patent was awarded, creating a precedent that was further litigated, and now nearly all software patents contain some form of the Beauregard claim.

Armed with some general knowledge on software patents, we can now examine where the problems lie. As I said above, the purpose of patents in the United States is to promote progress. Most generally, the problem is that software patents do not achieve their purpose. In fact, the argument can be made that they actually stifle innovation, having the opposite of the intended effect. They are stifling innovation because the USPTO awards patents for very standard software development methodologies. Techniques that any PHP programmer uses in their day-to-day coding can quite often be patented. This makes creating web applications an intellectual property minefield where one misstep could lead to a patent infringement lawsuit.

The most highly publicized case that illustrates this issue is the notorious Amazon one-click patent. The invention they claimed was the concept of storing a user’s personal and payment data so that, in one click, they could complete a checkout. They considered this idea so innovative that they applied for a patent. The scary part is that it was awarded. No prior art could be found, and it was considered nonobvious by a patent reviewer. Later, Amazon sued Barnes and Noble for patent infringement for providing similar functionality on their application. The lawsuit ultimately ended in a settlement requiring Barnes and Noble to remove this feature from their website. It now takes at minimum two clicks of the mouse to checkout on barnesandnoble.com. Anyone can imagine the millions of online stores which could benefit from this feature, but the Amazon patent prevents this from happening.

As developers, an example that might hit closer to home would be the lawsuit filed by Eolas against Microsoft Corporation. The lawsuit claimed that Michael Doyle, the president of Eolas, successfully developed a manner to seamlessly embed content into a Web page. We know these as the <embed>, <object>, and <applet> tags. Because of the victorious lawsuit and Microsoft’s failure on appeal, Microsoft was forced to change the functionality in Internet Explorer 6 surrounding how they activated ActiveX controls. Microsoft released the patch in 2006, and many websites stopped functioning correctly. Microsoft’s solution was to require the user to click any ActiveX control first to activate it, and then they could interact with it. My company, Barefoot Solutions, was managing several projects at the time that were affected. Most notably, embedded video players now had to be clicked twice in order to be played – once to activate, and again to play. This was infuriating. Fortunately for developers and users, someone developed a workaround in which Javascript was used to output the embed tags, and Microsoft never plugged that hole. But as Tim Berners-Lee pointed out in a letter to the Director of the United States Patent and Trademark Office in 2003, the problem was severe considering the millions of websites with historical significance that are no longer being managed. These were affected and never updated. Regardless, we see how much damage one patent can have on the Web.

These are only two examples of software patents with major implications in which ultimately the common internet user is the loser. Netcraft estimates that as of January 2007, 155,583,825 websites are violating at least one software patent. When these magnitudes of people are violating the law, it is natural to suspect that the law itself might be the problem.

Another major issue with software patents is that avoiding liability is impossible. Not just difficult, but literally impossible. First, there are millions of patents. The idea of reviewing all patents to ensure that your new invention does not infringe on one is just not feasible. The tools for patent research are still very ineffective. More importantly, in the United States, patent applications are not publicized. Even if it were feasible to research every patent to ensure that your invention did not infringe upon one, it would still be possible for a patent to finally be awarded – the application review can take several years – in which case your invention would then be infringing on a valid patent. This is a major flaw in the logic of the U.S. system and is unfair to any inventors, including software developers.

Finally, software patents are causing a huge drain on resources that otherwise could be used on innovation. The End Software Patents project estimates that 15% of all new patents are software patents. Their report shows that approximately $11.2 billion is spent annually on software patent litigation. This number refers only to those lawsuits which actually make it to litigation. Legal fees in the many lawsuits or licensing agreements that are reached before ever getting to litigation are not included, so the actual expense is much higher.

One significant cause for this drain on resources is the existence of so-called patent trolls. These firms buy up patents and seek out infringement cases as their primary means of revenue. Bruce Perens, a leader in the Free Software and Open Source community, dubs these firms patent parasites. Yet we cannot place the blame with these firms, but rather the system that incentivizes this behavior and makes it lawful. These parasites force patent holders to spend their resources on legal fees, as opposed to research and development, thus stifling innovation on a large scale.

Many would say however that we need software patents in order to protect inventors and provide incentives for major investments in innovation. There is evidence however that innovation will occur without the existence of software patents. Through the 1980s, software patents did not exist in the United States. Some of the most important concepts that we rely on today were created during this time, showing that we do not need a software patent system to allow for progress. These concepts include: the word processor, spreadsheet, database, email, the World Wide Web, audio-video compression/decompression, the basic elements of the graphical user interface and the fundamentals of all modern operating systems. Why then do we continue to support a system that stifles innovation and is unnecessary? As Bill Gates wrote, “If people had understood how patents would be granted when most of today’s ideas were invented, and had taken out patents, the industry would be at a complete standstill today.”

This paints a dismal picture for the future of the web development industry. So as developers, what can we do to protect our business? Unfortunately, the answer is not very promising. First, many lawyers will advise you to not read up on software patents. This seems counterintuitive, but is often the safest play. The reason is that willful infringement of a patent can involve much larger damages awarded in an infringement lawsuit. Further, U.S. law states that only patent attorneys can judge whether or not your concept infringes on a certain patent. Laymen are unable to properly determine the scope of a claim in any patent. So, if you were to read a patent and decide that your concept does not infringe, the federal court would not agree that you were able to make this judgment, and you could then be sued for willful infringement. Thus, in nearly all cases, the risks greatly outweigh any benefits, and it is best to not educate yourself on the current patents in software development.

Another recommendation is to be sure to place the liability for patent infringement in the hands of the owners of the intellectual property. In an earlier article I suggested that for a freelance PHP programmer, your development agreement should include a ‘Work for Hire’ clause that provides all intellectual property rights to the client. It is also important to include an Indemnity clause stating that the client will pay any legal fees or damages awarded due to a lawsuit for copyright or patent infringement. This will help shield you from some of the liability in the case that you unknowingly infringed upon a patent.

Another method of shielding yourself or your company is to purchase patent infringement insurance. These policies will pay for legal fees and/or any damages that are incurred as a result of an infringement lawsuit. Unfortunately, the premiums for this kind of policy are often very high, and as such this is not very feasible for freelance developers and small businesses.

In reality though, there is not much you can do to fully protect yourself from liability. In medicine, malpractice lawsuits are just part of the risk of being a doctor. In software development, patent infringement lawsuits are currently part of the risk as well. Ultimately what we must do is get involved to fix our broken system. Supporting organizations like End Software Patents (ESP) and the Free Software Foundation that fight software patents is a good start. Our very livelihood is in danger, and it is our responsibility to protect ourselves, our business, and the Web.

I was a young freelance PHP programmer studying at the University of Virginia. After many late nights coding, I had managed to save up enough money to move to San Diego upon graduation … or so I thought. About two months before graduation I received a phone call from my boss with some really bad news. He told me that the client had run out of money and refused to send payment. Then he tells me, “so I just can’t pay you”. And just like that my graduation nest egg disappeared into thin air.

I am undoubtedly not the only person reading this article that has been put in that position. I felt angry and helpless. I still had all the passwords. Should I take the site down? Hold it hostage for my measly ransom? Write a nasty message about them on the homepage? While those were tempting options, they were unethical, illegal, and ultimately just plain wrong. Instead I turned to the only thing that could protect me in that situation: my web development contract.

Before I go any further let me pronounce this disclaimer: I am not a lawyer and this should not be regarded as legal advice. I am a business owner that writes my own contracts and have successfully sued for breach of those contracts in American court. Over my years in business, my contracts have been tested and tweaked in a variety of situations, and this article represents what I have learned.

Many freelance or independent programmers do not bother with formal contracts. It is understandably a lot of trouble to try and write one, or a lot of money to pay a lawyer to draft one for you. Unfortunately though, having a rock solid contract is an absolutely crucial part of being an contract PHP programmer.

So why do you need a contract? Even though you may trust your client, it is amazing how quickly things can turn sour when money is involved. And although a verbal agreement is a legally enforceable contract, proving that it took place can be difficult. Developers need a contract because a good web development agreement provides the following benefits:

• It clarifies in writing the verbal agreement reached by the two parties.
• By law, copyright protection is automatically given to the author, but that is rarely what is desired when a client hires a web developer.
• It helps manage the expectations for the client and the developer.
• It protects both the client and the developer from unfair treatment if a project gets off track.
• Finally, contracts are the foundation of nearly every economy worldwide. Knowing that contracts are enforceable in a court of law makes it possible to do business with someone without having to trust them implicitly.

So now that we have covered why we need a contract, next we should ask how. For many freelance programmers, especially early on in your career, hiring a lawyer to draft a contract is not financially feasible. In order to save many billable hours, it is often a better solution to draft your own contract, and then have it reviewed by a legal professional. This last part is crucial so I will repeat it. Even if you get most of it right, you do not know the city, state, and/or federal laws well enough to write a bulletproof contract. Always have it reviewed by a legal professional. But with that being said, there are certainly some topics that need to be addressed in every complete web development contract.

Relation of Parties

This describes the relationship of the two entities, the client and the developer, that are signing the contract. There are several common relationships, which include employee/employer, licensor/licensee, or client/independent contractor. In my experience the most common relationship is that of an independent contractor. If you are brought on as an employee, it is fairly common for the government to require the employer to provide you with any number of benefits like health insurance or retirement plans. The licensor/licensee relationship used to be more popular than it is now for web development. This relationship heavily favors the licensor. Many developers have taken advantage of this relationship by creating custom built software for the client, and then licensing it both to the client and his competitors. While this may be legal, if the client is unaware of your intentions then it can be considered unethical and I wouldn’t imagine you would last in this business very long.

Finally is the independent contractor relationship. For the developer, this means that you have control over your own hours and schedule. For the client, this means that you are not required to provide employee benefits. This is appropriate in many web development situations.

Duties, Term, and Compensation

For the client, this may be the most important part of the contract. I have a standard contract that I use for most clients, and it references an attachment to cover the duties, term, and compensation because I generally need to rewrite that section specifically for every contract. It answers the questions:

• What will you be doing?
• For how long?
• And for how much?

The duties section is often called Scope of Services. This section covers exactly what it is you will be doing for your client. Are you simply doing PHP/MySQL programming? Or are you overseeing the entire project from start to finish, including requirements gathering, graphic design, system documentation, etc.? Does this contract include regular updates and maintenance after the delivery? While it is important to explain what you will be doing for your client, it is often just as important to outline what you will not be doing. This will avoid any surprises down the road.

The next section covers the term and termination of the agreement. The term will begin upon execution of the agreement (when both parties sign) and may be terminated on any number of conditions. Most clients that actually read their contract will not be comfortable with a contract that they cannot terminate. I generally will allow a client to terminate a contract with 10 days notice on the condition that my company is paid, per the attached rate schedule, for all work up to and including the last ten days. Further, I am able to terminate the contract with 10 days notice on the condition that I return any payment or deposit that I may have received.

Finally, you include the payment terms. There are a few questions that you need to cover in this section. First include how much you will be paid for this contract. If you bill on an hourly basis, include your hourly rate. If you bill differently for different services (graphic design vs. programming, e.g.), then include your entire rate schedule. Or if you prefer a fixed price model, include the total price that will be charged for the project. For fixed prices, I generally will reference requirements and specifications documents, explaining that the client will receive what is outlined in those documents for this price. I will then include my hourly rate schedule for any additional features which are added on in the middle of the project – and there always are. It is also wise to determine payment due dates (Net 15, Net 30, upon receipt) and late payment penalties.

Intellectual Property

You have a few different options for the intellectual property assignments in a web development contract. Usually, developers will explain here that all tasks, duties, results, inventions, and intellectual property are considered a “work for hire”. This means that the client gets intellectual property rights to everything created. There are a couple caveats to this however. First, you cannot assign intellectual property rights to any third party materials (like the framework you used to build the site). Second, you maintain that all intellectual property assignments for work that was conceived prior to the execution of this contract are maintained by the developer, but licensed to the client for unlimited use and in infinite duration. This is important as it will allow you to continue using the libraries of code that you have built over time while allowing the client to use and modify them as needed.

Confidentiality

This section of the agreement will often be changed based on the client’s level of paranoia. It is important to allow yourself the ability to communicate with other developers, designers, or anyone else on your team as to the nature of this project so that they can build it, even if the information is highly confidential. Otherwise, the developer agrees to keep all information received from the client confidential. It is advised to speak with the client about whether or not you can tell other potential clients that you are working with them. A developer’s portfolio can be his strongest asset, but some startups in super secret stealth mode will be upset over even the tiniest of transgressions. Speak to your client, and write this section according to their and your needs.

Warranty/Disclaimer

Including a warranty on your web project is fairly standard in most web development agreements. The main purpose is to give the client a time limit within which they should complete any testing and report any bugs. The developer cannot reasonably be expected to address bugs a year after the site was initially rolled out. Any time from 30 – 90 days is reasonable, depending on the size of the project.

Limitation of Liability

In this section the developer proclaims that they cannot be held liable for any loss of profit or revenue by the client associated with the development or operation of the website. This includes indemnifying the developer for any third party claims (lawsuits) associated with the development or operation of the website, or any claims on infringement of copyright or intellectual property rights.

Non-hire Provision

This section is easily forgotten in a web development contract, but to me has proven to be one of the most important. Very frequently after completion of large web projects, clients realize that they will need a full-time employee just to manage and update the system that was developed. Who better qualified for this job than one of the people that built it? This paragraph lays out the fact that the client cannot try to convince any employee or contractor of the developer to leave their job. Further, even if this employee or contractor leaves their job, the client will not be allowed to hire this person until after a given amount of time. Anywhere from 1 – 5 years is a reasonable number.

Legal Boilerplate

While I hope that thus far web development contracts seem approachable, it is an unavoidable fact that there will be some purely legal mumbo jumbo in any contract. Some of the boilerplate that is most common:

• Entire Understanding – This document and any documents referenced by this document represent the “Entire Understanding” of the agreement. No other documents or conversations can be acknowledged if a conflict should arise.
• Arbitration – Agree to try arbitration before going to court. If it works, it will save everyone involved some money on court costs and other legal fees.
• Choice of Law – What court of law shall govern the validity of the agreement. Generally, it will be the state where the developer resides.
• Modification or Amendment – Both parties must sign and date any modification or amendment of the agreement in order for it to be valid.
• Unenforceability of Provisions – If one portion of the contract ends up being unenforceable, then the entire contract is not rendered invalid – only the unenforceable portion.

While contracts can be overwhelming at first, hopefully you have seen that they can be manageable. Further, by signing a web development agreement and covering all of your bases, the risk for all parties is greatly reduced. Any savvy client or developer should always insist on a development agreement, and one which was reviewed by a legal professional.

Returning to the story from the beginning of this article – what did I do when I realized the developer was not going to pay me? I went back to my web development contract. Fortunately, a generous commerce law professor and the university student legal services had helped me draft the contract to begin with, so it and I were in pretty good shape. I filed a claim in the state of Virginia and represented myself in court. Using my web development contract and a series of paid invoices followed by a few unpaid ones, I was able to show an ongoing contractual relationship, and that he was delinquent in payment. I received the judgment for the full amount. Now actually collecting that judgment? That was not so easy, but is an article for another day.

If you’re not a real estate agent, chances are that you have never put something in escrow. But using a trusted third party to store your PHP code could be the best way to protect your investment and your intellectual property rights on either side of a licensing agreement.

I was recently asked to produce a fully-functional social networking module for a client’s web application. The catch: our company had six weeks to get it working. After weighing the options – including hiring a small army of programmers to write the software from scratch – we decided the best solution was to license some existing software and spend the six weeks customizing and integrating with the site. The code base was built for a standard LAMP stack, written in classical OO in PHP5 with one caveat: the PHP was encoded using ionCube PHP Encoder. All of the customization was to be done through the extensive web-based administration panel or the extension of very well documented classes, so our ability to customize was still pretty powerful. We were happy with the decision.

But the software was not cheap. And for the small, upstart company that was licensing it to us, we would be their biggest client to date by far. This raised several important questions. What if the company went out of business? What if something later broke that they decided not to fix? What if the company shifts priorities and they stop developing this product? We wouldn’t have any access to the source code. That could be a serious problem.

We needed a solution included in our license agreement before we were ready to sign anything. More than anything, the issue came down to trust. They couldn’t trust us with the source code in fear that we would sell it, give it away, or not protect it and have it stolen from us. But we were unable to trust that they would give us the source code if they were to go bankrupt, stop maintaining the code, or otherwise be in breach of the license agreement. Our solution to the problem was to use a service that I was largely unaware of, as I imagine most other PHP programmers are too. We decided to place the code in Source Code Escrow.

Escrow 101: Who Can You Trust?

When most people hear the word escrow, they think of placing a house in escrow while all of the inspections, credit checks, and other home buying headaches are taking place. Source code escrow is very similar in concept. At its most basic level, escrow involves a trusted third party which will hold on to some property and follow the terms of an escrow agreement. Generally the three players in a source code escrow agreement are the owner, beneficiary, and escrow agent. The owner can be any licensor, developer, or vendor that is somehow providing software to the beneficiary. The beneficiary is the licensee or customer that is the recipient of the software. And finally the escrow agent is some trusted third party, generally an escrow company, which arranges and enforces the escrow agreement. Source code escrow originally came into play to protect the licensees who were receiving the object code from a compiled language like C++ or Java. As PHP developers, object code is not a problem we face, but there are similar situations where an escrow agreement would be appropriate. First, if the code is encoded, obfuscated, or both, it is inaccessible just like object code. If a need for the source code could ever arise, then an escrow agreement might be appropriate. Another applicable situation is when a licensor hosts the software on their own machines. Even if the source code is not encoded, it is still inaccessible, and as such an escrow agreement might be appropriate. This arrangement is becoming more and more prevalent across the webscape as Software as a Service (SAAS) becomes a viable and thriving business model. This model was popularized early on by Salesforce.com, but since then has popped up in many industries from project management (Basecamp, e.g.) to personal financial services (Wesabe, e.g.).

The process of arranging an escrow agreement begins with the owner and the beneficiary deciding on the “Deposit Materials”. These are the materials that are to be deposited with the escrow agent. They would include, at the very minimum, the source code of the software. Often however, more than just the source code is deposited. The owner may also provide other inaccessible materials such as the API documentation, build instructions, and/or any other proprietary tools that may be used for development of the build process. The deposit materials will be included in the escrow agreement, and will be verified in some form by the escrow agent.

In addition to outlining the deposit materials, a complete source code escrow agreement will include a definition of the “Release Conditions”. These are the conditions which, if realized, will cause the escrow agent to initiate their release procedure, which may ultimately end up with releasing the source code to the beneficiary. Release conditions are to be negotiated between the owner and beneficiary. While every escrow agreement is different, some common release conditions include:

• The licensor goes out of business and/or files for bankruptcy and no entity will assume the licensor responsibilities for the software
• Licensor fails to meet the maintenance and update requirements outlined in the license agreement
• Licensor is acquired by another company that does not intend on continuing development

Another essential piece of any source code escrow agreement involves outlining the “Permitted Use” of the source code. If one of the release conditions is met and the deposit materials are released to the beneficiary, those materials are released with a limited license as described by the permitted use clause of the agreement. The most generous permitted use clause would allow the beneficiary to maintain, modify, enhance, or even sell the software. While most agreements generally do not permit the resale of the software, it is common practice to give beneficiaries the right to make modifications. A piece of software would, over time, become unusable if it were not being updated and modified regularly. Like the deposit materials, the permitted use terms are to be negotiated between the owner and the beneficiary, and their respective legal counsels, to fit the needs of their particular arrangement.

Technical Verification: Breathe a Little Easier

While the deposit materials, release conditions, and permitted use clauses represent the major pieces of a source code escrow agreement, there are some intricacies that are worthy of discussion in all three of these areas. For instance, as a beneficiary, how do I know that the owner has deposited what he claims to have deposited? Any escrow company will do a physical inspection of the deposit materials to make sure that everything which is claimed is present and accounted for. For instance, if 3 CDs and a binder of documentation are claimed to have been submitted, the escrow agent will physically verify that all 3 CDs and the binder are in fact deposited, and that the CDs are readable. But what would stop the owner from submitting 3 blank CDs? Or encrypted code? To account for these issues is a service offered by most IT escrow firms named “Technical Verification”. The level of technical verification, like anything else, differs from agreement to agreement, but there are some common scenarios:

• Physical Verification – as described above, this is offered by any legitimate escrow agent
• File Verification – the escrow agent (or an independent contractor) can examine all media and report filenames and file sizes so that the beneficiary can confirm the presence of all necessary source files. They can go further by verifying that the code is not encrypted and/or obfuscated by randomly viewing files.
• Build Verification – many escrow agreements require the owner to submit build instructions with the source code. These instructions should be sufficient for a technically advanced person to successfully build an executable application. For a web-based PHP application, this would involve any server configuration settings, different application versions (PHP, MySQL, Apache, etc.), and any other information necessary to get a working version of the web application up and running. Then, this application can be run through a test plan agreed upon by both parties.

In addition to the verification of deposit materials, it also important that the source code be updated regularly as the production version of the software gets updated. This can get tricky. If the escrow code is not being updated regularly, eventually it will become outdated and rendered fairly useless. Ideally, the source code in escrow should always be kept up to date with the software that the licensee is using. It can be tough for a beneficiary to know when the production software has been updated however. Particularly in a SaaS environment, where updates may be made as frequently as daily, it is not practical to expect the owner to update the escrow with every update made to the production code. A compromise that can be made in the escrow agreement is a requirement of software updates on a regular interval. For instance, in software that is being updated at least weekly, requiring that the escrow be updated monthly, on a specific day each month, would ensure that the code in escrow does not become outdated for the beneficiary without creating an unreasonable amount of overhead for the owner. The owner could also be required to send notice to the beneficiary each time that the escrow is updated, so that the licensee can properly monitor the situation.

Release Conditions: Time to Share the Wealth

The particulars of the release conditions, and specifically the procedure followed when a release condition is met, is another issue that needs to be considered when drafting the source code agreement. Most escrow agents will have certain standard release procedures, but they can be fine tuned to meet the needs of the licensee. The most common release procedure is a three step process. First, the beneficiary submits a claim that a release condition has been met. For instance, suppose that the license agreement requires the licensor provide support 24/7. If the licensee were to submit a support email, and two weeks pass without response, then the licensor would be in breach of their license agreement and a release condition will have been met. The beneficiary would then submit this claim with the necessary and sufficient evidence to the escrow agent for review. If the escrow agent does confirm that a release condition has been met, then they will enact the agreed upon release procedure. Generally, the owner has a specified amount of time to respond to the claim or make repairs (like answer the support email). If they do not dispute the claim and do not repair the issue in the given time period, then the escrow agent will release all deposit materials to the beneficiary. However, if the owner does dispute the claim, then the escrow agreement should have a policy outlined for the resolution of this dispute. This can rely on the escrow agent to make the final decision, professional arbitration, or in a worst case scenario the parties can rely on the legal system to make a decision on the dispute. The deposit materials will not be released until the dispute has been resolved.

Now you can see the problem that this could create for the beneficiary. If their claim is disputed, they could be tied up in arbitration or legal struggles for a long period of time. During this time, their software could be rendered useless and they could potentially lose any number of things including money, traffic, or reputation. For this reason many escrow agents also offer an immediate release procedure. With an immediate release clause in the escrow agreement, the beneficiary will receive the deposit materials immediately upon submission of a claim that a release condition has been met. The owner will still have the ability to dispute claims and go to some form of arbitration, but the beneficiary will be in possession of the deposit materials during the dispute resolution. If the dispute is resolved in favor of the owner, then the beneficiary would be required to return all deposit materials to the escrow agent. Further, in that situation it is customary for the beneficiary to pay for any damages and legal fees incurred due to the improper claim.

Picking Up the Check

One final source of contention when drafting an escrow agreement is the age old question – who pays? Of all of the issues that can come up through this process, this issue is the toughest to solve. Because it is generally the licensee that wants the escrow, it is often assumed that they will need to foot the bill. However, it could be in the best interest of the licensor to setup a source code escrow for all licensees, in which case it is only fitting that they pay the fees. This issue should be resolved during the license agreement negotiation, and possibly before an escrow agent is first contacted.

While a source code escrow agreement is usually initiated by the licensee, it has benefits for both parties involved. For licensees, the benefits are fairly obvious. They are able to avoid the risk of relying on another company’s success for their own business to thrive. It also provides a system for monitoring and ensuring regular maintenance and updates. For licensors, a source code escrow agreement can alleviate concerns of potential customers without having to assume the risk of distributing source code and other proprietary materials. It can also provide some validation of ownership of technology assets and intellectual property and create an IP trail, which is outside the scope of this article but an interesting topic in its own right. So while they are not appropriate in all licensor/licensee relationships, they clearly have their place in software development and can be a very useful tool.

As a PHP programmer, if you have ever worked on a project that is even remotely interesting, then surely you have come into contact with a Nondisclosure Agreement (NDA). If you have ever been employed in a medium to large sized company, then quite possibly you have been presented with a Noncompete Agreement. It is vitally important to your career that before you sign these documents, you understand the implications they may have on your future endeavors.

In a field that thrives on new ideas and rapid innovation, Nondisclosure and Noncompete Agreements have become major players in the competitive landscape of high tech industries. Companies and entrepreneurs feel compelled to protect their ideas while still having the need to share them with others. To solve this conflict of interest, many will require signed NDAs and/or Noncompetes before disclosing any trade secrets. One such proponent of NDAs is Sabeer Bhatia, the founder of Hotmail. Over the course of two years he collected over 400 NDAs from his friends, family, and employees – basically anyone that knew about his startup. He believes that his secrecy resulted in a significant head start on the competition, and in 1997 he sold Hotmail to Microsoft for $400 million.

This article will not be discussing how to draft NDAs and Noncompetes. You can go your whole career without the need to draft either of these documents. If you do have the need, I suggest you hire an attorney. What it will discuss is how to react when approached with these documents. When is it appropriate to sign an NDA? A Noncompete? What should I look for in each? What are some pitfalls to avoid? At the very least it should give you the confidence to read, understand, and make a decision on whether or not to sign one of these documents. Do not forget, you do not have to be a lawyer to understand legal documents, and nearly all contracts are negotiable.

NDAs – Secrets, Secrets are no fun

A Nondisclosure Agreement – also known as a Confidentiality or Secrecy Agreement – is a contract between at least two parties in which they agree to protect confidential information that is disclosed during the course of business. The two necessary parties are the Discloser and the Recipient. The Discloser is the party who originally possesses the confidential information. They disclose this information to the Recipient, who agrees to protect it in accordance with the terms of the agreement. In the programming world, confidential information can be any number of things including: general business ideas, code, database schemas, documentation, development tools and techniques, business processes and much more.

There are many different circumstances which could involve you being presented with an NDA. I am the owner of a Web development firm that focuses a good portion of our resources on startups. Often I am approached by entrepreneurs who would like me to provide a quote to build a Web application based on what they consider to be an innovative or bleeding edge idea. Understandably, they are uneasy with just disclosing their idea to me and my company. With our resources, we could surely be first and best to market if we were to try and poach their idea. So before they disclose any confidential information, they will send over an NDA for me to sign. This is a perfectly normal part of doing business, and I have signed several dozen NDAs over the last few years. As a programmer doing contract work, some business owners will require a signed NDA before giving you access to their code, schemas, or other technical information. Also, it is very common to sign an employment agreement which includes a nondisclosure clause. In these and other situations, it is quite often appropriate to sign an NDA. What is important is that you carefully examine the document, and make any changes that you need before you sign anything. Remember, with a little knowledge, contracts are both understandable and negotiable.

So what should you look for when examining a Nondisclosure Agreement? The clauses with major implications include the definition of confidential information, the exclusions of confidential information and the disclosure obligations and terms.

Any NDA should carefully define the nature of the confidential information that is being disclosed. This must be done without actually disclosing the information however, so it is generally described categorically. For instance, an agreement may include: PHP code, database schemas, and unique development processes. As the recipient, it is important that the definitions are not too broad, and are limited to what you actually may be receiving. Something like all business related information is too broad and should be avoided.

More important than the definition of confidential information are the exclusions of confidential information. Sometimes the best way to describe something is by describing what it is not. This is a list of situations in which information cannot be considered confidential. Usually the list will include situations where:

• The recipient had prior knowledge of the information
• The recipient gained the information independently or from other resources
• The information is available to the public

This ensures that you do not sign away your right to share your own knowledge to others.

The final important clause of an NDA is the disclosure obligations and terms. This section outlines the obligations a Recipient has to protect the confidential information and permissible reasons for disclosure. In my situation, I often need to consult my programmers and graphic designers in order to provide an accurate quote. So if I sign an NDA it is important that I be allowed to communicate. Some common ways of structuring these terms include:

• Requiring that the Recipient use all ‘best efforts’ to maintain the confidentiality
• Defining a purpose, such as providing a web development quote, and allowing disclosure only to fulfill that purpose
• Requiring that the Recipient disclose only on a ‘need to know’ basis
• Requiring that the Recipient protect this information similar to the way they protect their own confidential information
• And always, allowing disclosure if the information is requested by a government agency or court of law.

These terms are important to allow disclosure when it is truly necessary, whether for business or protection from legal sanctions.

Finally, a few minor points to make note of in an NDA include the term of the agreement and the right to receive an injunction. Be sure that the term is of a reasonable length; one to five years is common. Also, it is standard that the Discloser has the right to receive an injunction if the terms of the agreement are breached. However, be wary of any other relief options like attorney’s fees. The last thing you need is to pay for someone to sue you.

Noncompete Agreements – The NDA’s Ugly Stepsister

hile an NDA is fairly common and can be approached with little trepidation, Noncompete clauses are less common and must be approached much more carefully. A Noncompete Agreement – also known as a Covenant not to Compete – is a contract, generally between an employer and employee, that restricts the employee from working in any related business for a certain length of time after termination of employment. The purpose is to protect the employer from training an employee in all of the trade secrets and practices of a business just to have the employee turn around and work for a direct competitor, or start their own competing business. For instance, suppose an existing search engine hired you as a programmer and gave you access to all of their code and procedures. After a year, you were unhappy with your job and felt you could create a better search engine on your own. Your employer would not want you to be able to start your own competing search engine, using all of the tricks of the trade learned during the course of your employment. As such, they would have required that you sign a Noncompete Agreement before you began your employment.

Unlike the NDA, there are only a few situations where it would be appropriate for a PHP programmer to sign a Noncompete Agreement. The most common circumstances would involve a Noncompete clause in an employment agreement. Even in that situation, the job should be in a specialized industry, not just general programming. Be wary of others sneaking Noncompete clauses into agreements like NDAs, Independent Contractor Agreements, or Employment Contracts. As always, be sure to fully read any document before you sign it. On more than one occasion, I have had an entrepreneur try to include a Noncompete clause into a document titled, “Nondisclosure Agreement” or “Independent Contractor Agreement”. In those specific instances, I do not think there was malicious intent. Instead, I just think the entrepreneurs included the clause out of ignorance. Regardless, I did not and would never sign a Noncompete in that situation.

These clauses are generally fairly straight forward, and as such there is not too much to look out for in the language itself. Most importantly, be sure that the duration of the agreement is reasonable. These vary from area to area and industry to industry, but somewhere between two and five years is a reasonable amount of time. Ten years ago, geography was an important factor in a Noncompete Agreement. Most limited employees from working in a competing business within a certain distance from the employer. For instance, if I sold dolls in Virginia, I would not want my former employee to sell dolls in Virginia. But if he wanted to sell dolls in California, I doubt he would be serious competition, so that would be allowed in my Noncompete clause. Given the current technology however, geography is often not included in Noncompete clauses. If I sell dolls in Virginia, and I have a website, then I sell dolls in California too.

While there is not too much in the language to look out for, there are certainly a lot of other extenuating factors to consider before signing a Noncompete Agreement. First, it is important to note that enforcement of Noncompetes differs greatly from area to area. In the U.S., each state has its own policy and precedents concerning the enforcement of a Noncompete. For instance, Michigan has a history of enforcing Noncompete agreements, while they are generally thrown out in California. Some have argued that the unenforceability of Noncompetes in California is what helped lead to the success of Silicon Valley as a technology startup haven, while other areas remain much less successful. The ability of bright young employees to jump from company to company and share knowledge allowed Silicon Valley to thrive at a much faster pace than would be possible if these employees were mired by Noncompete Agreements.

Another important facet to consider before signing a Noncompete Agreement is how this factors into your overall employment situation. As a potential employee, it is important that you include this in your decision just as you would the salary and benefits. It also could give you leverage during your contract negotiation. Not being able to work elsewhere in the industry could be a major detractor, so perhaps the employer can provide something to help account for this. Further, some employees are approached with a Noncompete after they have signed their initial employment agreement. This is common in the case of startups that bring on their first employees before hiring an attorney. If you are in this situation, it is important to realize that many states require that the employee benefit from signing a Noncompete. For instance, signing the agreement could be coupled with a raise in salary, a bonus, or better benefits. Because you are forfeiting some of your rights, most courts agree that it is only fair to receive something in return. In Wisconsin however, precedent has shown that not being fired is considered a benefit. So, an employer in Wisconsin could tell you to sign a Noncompete or you will lose your job, and be within the law. Once again, this is different from area to area, and it is important to consult a local attorney to review your agreements.

Finally, let us suppose that you sign a Noncompete and eventually choose to leave that job. When applying for a new job, it is important that you disclose to the potential employer that you have previously signed a Noncompete. The employer could be vulnerable to a lawsuit by hiring an employee that is in violation of a Noncompete Agreement. Not disclosing this information would certainly be grounds for firing if the new employer were to find out, or even worse, get sued by your former employer.

The Last Word

Unfortunately, NDAs and Noncompetes are a part of the business we have chosen. We are forced to navigate carefully and sign only when necessary. Armed with a little knowledge, these legal documents are understandable and negotiable. If you have any doubts however, particularly with Noncompete Agreements, be sure to consult an attorney before signing anything.

Pagerank is analagous to the Twitter of the SEO world. Everyone wants a piece of the action, but very few get how to leverage it. In the following post, we discuss what it is, how to use it, and what tactics to avoid.

Pagerank Defined:

For all its mystery and sinister reputation, it can be explained in one line: how likely is someone to end up on your webpage? Back in the day, Google wanted a way to show how likely it was for a “random surfer” to end up on your webpage. Later on, they realized that no one browses the internet by clicking links randomly, its all driven by intent, and fixed their model. Modern pagerank is the result of that.

The more BIG websites linking to your brainchild, the better your pagerank and the better you tend to fare–and I say this with the utmost emphasis on ‘tend’.There are plenty of webpages out there with garbage Pagerank that still place within the top 3 search results in their respective fields. Most of the time, however, a link from a popular page will drive significant traffic to your door, thereby increasing the likelihood that your page is visited, and thus increasing Pagerank.

Synopsis: You care because Pagerank affects how well your search rank fares and the amount of traffic you receive by proxy.(Granted this is an extremely rough cut explanation: if you want technical details check out this excellent article from hubpages.)

The Care and Feeding of Your Pagerank:

Building Pagerank is just as much about social networking as it is about avoiding pitfalls. Like all things worth having, Pagerank is something you must accumulate gradually over the course of years through your persistent, attentive pruning.

Here are the top 3 ways to grow your page rank:

1. Be social. It’s a popularity contest. All the content in the world won’t help you if you’ve got zero web presence. Comment on other sites, send out emails, talk to people for the sake of talking. The links will follow.

2. Name dropping. Whenever you’re given the opportunity to refer your readership to a valuable resource or alternative perspective, or even a reference, USE IT. Most web savvy individuals check their analytics compulsively. They’ll know when you link to them. The nice ones will link back.

3. Link to yourself. Pagerank flows from page to page, as it does from site to site. You can distribute and grow your Pagerank, tailoring it to the pages you want to get the most exposure by tweaking your internal linking (You can test out any potential effects of link Pagerank sculpting here). Additionally, the more pages that Google indexes from your site, the higher your maximum Pagerank. The fastest way to ensure your entire site gets index is by sending your xml sitemap to Google.

Synopsis: Communicate to your web community: if your site sells leather goods, its time to start posting in biker forums. Go to town on the linking process: link to as many outside sources as you can—preferably your newfound biker friends. Submit your sitemap to all the major search engines so they can index your ENTIRE site. Finally, channel your pagerank to the desired pages through creative linking.

This is Why We Can’t Have Nice Things:

Here are a few obstacles that you’ll want to avoid when growing your Pagerank.

1. Buying links. Not gonna lie. It’s possible to buy links from big sites to increase your PR. Google usually catches on pretty quickly, however and removes any potential benefits. You’re better off saving your money.

2. Linking to shady sites. A good indicator is the lack of pagerank despite being online for awhile. These pages will drag you down with them. Do your homework before you accept those link exchange requests. If the site seems less than legit, just move on.

3. Traffic farming. Creating viral content is one of the fastest ways to generate fresh traffic. However if you rely on it soley, Google will take notice and penalize your efforts. Keep running those campaigns, but do so in moderation.

…And that about wraps up today’s lesson.
Till next time: stay classy.

Twitter’s new integration scheme has made it easier than ever manage your social media marketing campaigns. Following setup (instructions below), with one simple click you will be able to communicate your micro-message across multiple platforms simultaneously. In a generation where speed is everything, Twitter is quickly becoming an indispensable tool. Now compatible with Facebook, LinkedIN, and Evernote (to name a few), integration will allow your message to populate across platforms every time you post a new tweet.

Here’s how to set it up:

TWITTER FOR YOUR PERSONAL PROFILE:

1. Create a Twitter account, here.
2. Follow this link. You should see a prompt similar to the following:



3. Click allow.
4. Login to your Twitter account and tweet away!

TWITTER FOR YOUR FAN PAGE:

Follow this link. You should see a prompt similar to the following:


1. DO NOT CLICK INSTALL.
2. Go to http://facebook.com/pages/manage
3. Click ‘Edit Page’ beneath the name of your Fan Page
4. Find ‘Twitter for Pages’ in your Applications list and click the pencil icon
5. Click ‘Edit’
6. Allow Involver to install.

Though this isn’t highly advisable as the social media applications of Twitter and LinkedIn don’t really overlap, we’ve included a tutorial just in case you decide to do it anyway. We know how stubborn you are.



1. Create a Twitter account here.
2. On LinkedIn: Scroll to the bottom right-hand corner of the page and look for the [ + Add an Application ] box.
3. Hover over the box, scroll down the resulting menu and click “Tweet” (left thumbnail)
4. Click the “Add application” button (right thumbnail)
5. Login to your Twitter account via LinkedIn.
6. Choose the settings that best suit your needs.

1. Create and login to your Twitter account.
2. Go to this URL: http://twitter.com/badges



3. Pick where you want to place your Twitter Widget.
4. Select the look and options that best suit you.
5. Copy and paste the code provided into the body of your site.

Once you’ve completed any of the above operations, you’ll be able to update your Twitter and synchronized account simultaneously through Twitter.com.

So you just started this whole blogging business on the side, and now streams of visitors show up at your virtual doorstep every day, demanding flash media and video content. You’re feeling ready to embrace a larger audience and maybe redesign your homepage, but aren’t really sure what direction to go.

We’ve got what you need. Barefoot Solutions has picked through dozens of articles to deliver the cream of the crop for your consumption.

BY FAR the MOST IMPORTANT component of a high caliber blog. You can’t become a rockstar without fans. Make friends with other bloggers and win over some of their traffic:
•    Link to other blogs
•    Comment on their posts
•    Feature guest writers

Most serious bloggers check Google Analytics religiously, so they’ll know, with startling immediacy, when you interact with them in the slightest way. The nice ones will pay you a visit or ideally even link you back.

From there, your glowing prose and dazzling personality will hook new traffic and grant you the worshipful readership you’ve always dreamed of.

Want the nitty gritty of link building? Vandelay Design offers 9 ways to make sure you’re linking where it counts.

This is how it’s done: VentureBeat.com - Think your page already has enough links? VentureBeat has 944,506 incoming links from other webpages. Well, 944,507 now. The staff’s amazing networking ability has no doubt played a major role in launching this page into the top 100 Technorati Blogs.

The simplest explanations are usually best. Keep it a quick and fresh. If you can’t say it in a few paragraphs, save it for another article or trim the fat.

Keep in mind: bullets, top 10 lists, and short blocks of text are your friends.

I’m confused. Examples? DaringFireball.net - Extreme minimalist design. This page only has 2 images…and one of them is a search button. The result is amazingly clean, professional, and easy on the eyes.

The more time you take to manufacturing an appealing (read: glowing, abstract, and AHDH-friendly) interface, the more likely you are to be well received.

TIP I: If you use a lot of colors it will tend to make your site look cluttered. Take a little time, pick a 2-3 color theme with good contrast, and stick to it.

TIP II: The best looking websites will take an idea and apply it to every last detail and aspect of their design. Always think about how adding or subtracting from your blog will impact your theme.

A study conducted by Dr. Gitte Lindgaard found that it takes users 0.05 seconds to decide if they enjoy looking at your site. Not sure where your page falls on the spectrum of attractiveness? Check out WebSiteOptimization.com for examples.

Emulate me: OurWorld – Winner of the Best Blog Design Weblog Award 2008. This page tactfully combines beautiful high resolution banner images with an understated low color saturation theme, sleek fonts, and hot javascript action for an amazing webpage that just sucks you in, eyes first.

According to Giancarlo Gallegos from BlogCatalog, we click because we believe we have something to gain from it—whether it is knowledge, pleasure, or LOLCATS, clicking requires a clear motive.

Give people a reason to click through to your blog by creating a unique spin on overblogged topics. To quote Dawn Foster:

“You can talk about a news story that other people are blogging about, but spend some time writing about your experiences and ideas that offer a different perspective than the rest of the crowd. Use research in new ways, interview interesting people, and talk about your experiences. By offering something new, people are much more likely to read your blog post and link to it, which is where the real SEO magic is found.”

Brush off that storyteller’s cap. Y’all got some yarn spinnin’ to do.

Now this is writing: RoughType - While the layout isn’t much to look at, Nicholas Carr’s blog is the perfect example of a content driven blog. The homepage has a mindblowing PageRank of 7.0 – this one man has accumulated the same net authority as the COMMUNITIES of Yelp and Metacafe. Be amazed.

Google Analytics and Google Webmaster are amazing for visitor tracking, sculpting page rank, and otherwise refining your blog in ways you would have never thought possible.

Once you’ve mastered the skills, you’ll be able to pinpoint the “who”, “what”, “where”, “when”, and probable “why” of every last click and page-view on your blog. Did we mention you can run customized analytics and test multiple versions of your blog simultaneously? No? It’s awesome.

If you’re looking for a nice springboard into the world of analytics, Google has graciously provided a quick tutorial to get you started. Hop to it!

Serious Skills: SethGodin’s Blog – So what’s so special about Seth Godin? His blog ranks #12 on google’s search for “blog”. While normally ranking on page 2 is sort of unimpressive, this page trumps roughly 2.3 BILLION other search results: including the official Whitehouse and Facebook blogs as well as BLOGS.COM. HE OUTRANKED A PAGE WITH BLOG in the URL. SEO. Learn to love it.

1. First off, be sure to visit all major review engines and iyp portals – like Google Maps, Yahoo! Local, Yelp, Yellowpages, Bing Local Search, Insiderpages, and Superpages – to see if your business is already listed there.  If it is, be sure to claim the listing.  If it is not, request to add your listing to each of these sites individually.  Claiming or adding your business listing on these websites allows you to add information about your company including products and services offered, contact information, url links to your company’s website, and other details a potential client may want to know.

2. During this process, be sure to select the right categories for your business.  Each website will request that you select the category/categories that best represents the products or services your company provides.  Fewer clients will find your company if you fill out all details about your doggie daycare company and categorize it under “Professional Services” instead of “Pets” on Yelp’s site.

3. Once you have claimed your business listing and categorized it appropriately, your rankings can also improve based on the number of reviews from clients and the positive ratings from them.  Potential clients are far more likely to pick up the phone and call or buy from a company that has a number of favorable reviews.

4. It also helps if your company’s address is listed in the city or area code where most of your customers come from.  Review engines and iyp portals have become very city specific, and so you will reach a larger audience if your physical address is listed as a doggie daycare company in San Diego rather than Fallbrook.  Having San Diego and the products/services you offer listed in your company’s website title tags can also help boost your local search rankings during the web development process.

– Stephanie