3 Things You Need in Your Open Source Policy!

If you operate a software based business you are likely using some open source code in your software. There really is nothing wrong with that, as it is really common now (and probably a best practice). But what is your process to review and track this code, and the associated license terms? Well, here are 3 thoughts from a software licensing lawyer that may help.

1) Written Policy. Think through (a) what situations makes sense for your company to use open source code (maybe with functionality that is not core to your offering), and (b) what type of licenses you will allow and won't (maybe try to avoid GPL licenses if you distribute your code to your customers). For example, you may allow licenses which only require notice (i.e. attribution) that the code is distributed with yours. Oh yea, don't forget to write this down in a policy and let all your developers know about it.

See below for an example of attribution.

2) Tracking Process. Tracking where you use the open source code and the associated license terms is critical, and I suggest very easy to do (along the way at least). Your process could be as simple as a spreadsheet with the name of the open source code, listing of which of your products (and versions) it is included with, any requirements of that license, and a copy of the license agreement. This tracking process is super simple if you implement it along the way, and really hard to re-create if you have to do it years later when someone (an acquiror or the CEO) needs to know what open source code is embedded in your product.

3) Annual Review. While many people overlook this, whoever is in charge of your open source process/policy (and I suggest you have one person in charge who owns this policy), should annually review that your developers (including any developers that are actually contract developers) are aware of and follow your policy.

Look I could make this a lot more complicated, but I find that most small software companies need at least these three basics requirements and not the 25 page open source policy.

Great More Detailed Article on Developing an Open Source Policy.

Some Thoughts from a Microsoft Attorney on Creating an Open Source Policy

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice. Contact your attorney for legal advice, which should be provided after review of the facts and applicable law.

4 GREAT Reasons to Register Your Software for Copyright Protection!

Most people may not realize that there are 4 GREAT reasons to register your software for copyright protection with the US Copyright Office.  As a software copyright attorney or lawyer, I recommend this for every software based company, whether you are licensing your software or providing it as a service.  So here goes.

1) EASY. It can be done by yourself or with the help of a software copyright attorney. Your call, but any good lawyer will tell you to consult with a software copyright attorney before you file.  In general though, it is not hard to file for copyright protection, so this is not an issue.

2) INEXPENSIVE. The filing fee is low (less than $100) so that is not a barrier either.

3) REIMBURSEMENT OF ATTORNEY'S FEES.  If you file a claim for infringement based on a registered copyright that existed before the infringement, federal copyright law provides that you could be reimbursed for your attorney's fees. If you think about it, this is really a big deal, as it is extremely rare that plaintiffs in a case are reimbursed for their attorneys fees. This can be a double edged sword though, as if you lose you may be paying for the defendant's attorney's fees (i.e. something to definitely discuss with your lawyer before you file the case). To have a shot at being reimbursed for your attorney's fees though, you need to file within 3 months of the work being published (if it is a published work). Talk to a software copyright attorney about it.

4) AWARD OF STATUTORY DAMAGES. What statutory damages provide is a fixed amount of damages awarded to you, without having to go through the difficult (and expensive) task of having to prove your actual damages. This is a big deal too, as proving your business harm of someone infringing your copyrights can be tricky and often difficult, so you have an alternate way of being compensated for the infringement. These damages can be as high as $30,000 per work, and up to $150,000 per work for willful infringement; these are set by a judge, who has some discretion here. To make a claim for statutory damages, you also need to file early (within 3 months for published works), so again talk to a software copyright attorney about the timing issues.

Any software based company should consider filing for copyright protection of their software early, as it can make a real difference to their overall protection of their IP.

Here are some resources:

US Copyright Office: FAQ

Can you Obtain Copyright Protection for your Software's Graphical User Interface (GUI)?

4 Things to Remember About Copyright Law

Contracts vs Copyrights

Legal Disclaimer: This is for informational and educational purposes only, and does not constitute legal advice.

Hiring an Offshore Software Developer? 5 Things to Remember in Your Software Development Agreement.

As a software attorney, I think there are a few practical things to think about when using an offshore software developer/outsourcing software development, and negotiating the software development agreement. As you know, this has become commonplace, even for smaller Software, SAAS and IT services companies. Here are a few thoughts, from a software attorney.

1. Ownership Rights. While I am sure you saw this issue coming, make sure you document it very clearly, and address 'work for hire' copyright, pre-existing code, open source licensing, patent issues, etc. There is a lot to think about so dig in and get it right.
2. Termination Rights. Think about it, you know that this relationship will not go on forever, so the termination rights in the contract will be exercised (relatively soon). I would spend a fair amount of time with your software lawyer detailing what happens upon termination and how your property is returned to you (hardware, software, etc). Also, I suggest you should be able to terminate (without cause) on much shorter notice than the service provider, so think about that practical issue too.
3. Gap between Expectations and the Contract/SOW. While this is not purely a legal issue, in a way it is the most important issue.  One of the main purposes of a contract is to communicate and outline which party is responsible for what and when. Take ownership of these important details, and don't delegate this to your attorney. I think the contract should be 100% consistent with reality and what the parties expect to happen along the way; while this may not be easy, it is worth striving for.
4. Where is my Source Code? I always recommend that you keep control of your source code and know were it is at all times (your server, their server, in the cloud, etc). You don't want to rely on a contract to get your code back. The thought should be that if there is a dispute you can get control of all your intangible assets, without the service provider having to do anything (think about that!).
5. Which Law Governs? This is a complex issue, but the importance of it should not be overlooked. Think through which law will govern the transaction and where disputes will be resolved (arbitration may a good option too). Also, if you are contracting with a developer offshore, get an in-country attorney to look at the IP and local law issues, as irrespective of the contract, local law will be important in figuring out who owns what (if there is a dispute). There are lots of reasonably priced in-country attorneys you can find on the web. I recently found and used one in Europe for a client, and it worked out well.

Any company outsourcing part of its software development should consider these issues when offshoring, and drafting the software development agreement.

Disclaimer: This is for educational and information purposes only, and does not constitute legal advice. Contact an attorney before taking any action based on this.