open source legal documents

Just got a note from the docracy folks. They’ve developed a new, US oriented, open source mobile privacy policy.

I’m quite intrigued by the whole notion of open source legal documents. As some readers of this blog may know, I am very much a fan of open source technology. That being said, I do wonder whether the application of open source models to legal documents will yield the same benefits as their application to code.

I suppose it should, but must admit I do have some doubts. For example, I don’t think that open source legal agreements will necessarily result in widespread adoption or create standards the way open source software does, for a variety of reasons – e.g. differences in each jurisdiction’s laws, variations in business models, or variations in risk tolerance for users.

Moreover, I’m not necessarily sure open source legal agreements that are freely available will supplant professional legal services, the way, for example, that Linux has (or at least has the possibility) of supplanting operating systems for which license fees are paid and no source is made available – like Windows.

Why? Because legal services are already provided in a manner similar to one open source business model – that of value added services. While I certainly wouldn’t mind trying to exploit my drafting work by licensing forms of agreements at $X dollars a pop, that’s not typically how legal services work. When someone asks me to help them create a  software license agreement, I’ll ask them various questions regarding their product, how they plan to license and distribute it, how they plan to charge for it, and so on, then take one or more existing precedents and start tailoring to their needs, charging by the hour to do that and perhaps to negotiate the terms from time to time. I don’t charge a license or usage fee for the use of the precedents, but rather only for the “value-add” services. It might be nice too, but if your competitors don’t (and I think most don’t) then it’s tough for you do so. Which is perhaps why legal services typically don’t scale quite as well as other industries.

Sorry, I digress. Anyway, my point was that this service model is quite similar to one approach to one open source business model – license the core product under an open source license, and sell value-add services, such as support, custom development, implementation services and the like – stuff that requires expertise for those that need it.

Just to be clear, I’m not suggesting that the concept of open source legal documents is bad (because it’s not), but rather that I can’t see it having the same impact on the legal services industry as open source code has had on the IT industry. But who knows.

gpl compliance guide released

The Software Freedom Law Center has just released “A Practical Guide to GPL Compliance“. For those not familiar with the SFLC, it is a group that helps to protect free and open source software (or “FOSS”), including advancement of claims against those who infringe open source licenses such as the GPL.

The guide is helpful in navigating through some of the more technical issues regarding GPL compliance, and in addition does offer some advice on best practices generally regarding software development to avoid problems later on. For example, the following is good advice generally on implementing development controls to avoid possible infringement issues:

The companies we contact about GPL violations often respond with: “We didn’t know there was GPL’d stuff in there”. This answer indicates a failure in the software acquisition and procurement process. Integration of third-party proprietary software typically requires a formal arrangement and management/legal oversight before the developers incorporate the software. By contrast, your developers often obtain and integrate FOSS without intervention. The ease of acquisition, however, does not mean the oversight is any less necessary. Just as your legal and/or management team negotiates terms for inclusion of any proprietary software, they should be involved in all decisions to bring FOSS into your product.

Simple, engineering-oriented rules help provide a stable foundation for FOSS integration. Ask your software developers to send an email to a standard place describing each new FOSS component they add to the system, and have them include a brief description of how they will incorporate it into the product. Make sure they use a revision control system, and have store the upstream versions of all software in a “vendor branch” or similar mechanism, whereby they can easily track and find the main version of the software and local changes made.

Such procedures are best instituted at your project’s launch. Once a chaotic and poorly-sourced development process has begun, the challenges of determining and cataloging the presence of GPL’d components is difficult. If you are in that situation, we recommend the Fossology system, which analyzes a source-code base and produces a list of FOSS licenses that may apply to the code. Fossology can help you build a catalog of the sources you have already used to build your product. You can then expand that into a more structured inventory and process.

Similarly, some helpful advice on dealing with other inbound vendors whose work you will be incorporating:

With ever-increasing frequency, software development (particularly for embedded devices) is outsourced to third parties. If you rely on an upstream provider for your software, note that you cannot ignore your GPL compliance requirements simply because someone else packaged the software that you distribute. If you redistribute GPL’d software (which you do, whenever you ship a device with your upstream’s software in it), you are bound by the terms of the GPL. No distribution (including redistribution) is permissible absent adherence to the license terms.

Therefore, you should introduce a due diligence process into your software acquisition plans. This is much like the software-oriented recommendations we make in § 3. Implementing practices to ensure that you are aware of what software is in your devices can only improve your general business processes. You should ask a clear list of questions of all your upstream providers and make sure the answers are complete and accurate. The following are examples of questions you should ask:

  • What are all the licenses that cover the software in this device?
  • From which upstream vendors, be they companies or individuals, did you receive your software from before distributing it to us?
  • What are your GPL compliance procedures?
  • If there is GPL’d software in your distribution, we will be redistributors of this GPL’d software. What mechanisms do you have in place to aid us with compliance?
  • If we follow your recommended compliance procedures, will you formally indemnify us in case we are nonetheless found to be in violation of the GPL?

This last point is particularly important. Many GPL enforcements are escalated because of petty finger-pointing between the distributor and its upstream. In our experience, agreements regarding GPL compliance issues and procedures are rarely negotiated up front. However, when they are, violations are resolved much more smoothly (at least from the point of view of the redistributor).

Consider the cost of potential violations in your acquisition process. Using FOSS allows software vendors to reduce costs significantly, but be wary of vendors who have done so without regard for the licenses. If your vendor’s costs seem “too good to be true,” you may ultimately bear the burden of the vendor’s inattention to GPL compliance. Ask the right questions, demand an account of your vendors’ compliance procedures, and seek indemnity from them.

Lastly, the guide helps to identify the “costs” of GPL software – there may not necessarily be a license fee, but there will be time and effort involved in complying with terms, as well as risks associated with such compliance, such as cohesion (or lack thereof) with your overall business strategy. For developers, becoming familiar with compliance requirements will allow for better decisions to be made, including more accurate comparative assessments of the overall costs associated with GPL relative to, say, proprietary alternatives. And it is definitely better to figure these sorts of things out sooner in the process, rather than learning about them say, when someone is doing a due diligence review of your organization.