presentation on development agreements

Alas, it has been far too long since I’ve posted anything. That being said, I have amassed a nice collection of half-completed posts which have all but lost any relevance or interest. Something I’ll need to work on, I suppose.

In any event, in case it might be of interest, I gave a presentation earlier today as part of the IT.Can – LSUC Annual Sprint IT Law Form. My piece was on development agreements. It was a relatively short presentation, so I only focused on a limited set of issues. I’ve perhaps done better in terms of delivery, but the slides [PPT] aren’t bad. Feel free to download and peruse.

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.

Fair Use and the DMCA

An article in Wired News with the dramatic title of “Lawmakers Tout DMCA Killer” describes the most recent attempt to: (a) water down the protections afforded to content owners by the DMCA; (b) ensure the preservation of fair use rights on the part of users. As is usual, each side has its own rhetoric to describe what is happening, so in fairness I took the liberty of offering to readers of this blog the two alternative descriptions above. The nub:

The Boucher and Doolittle bill (.pdf), called the Fair Use Act of 2007, would free consumers to circumvent digital locks on media under six special circumstances.

Librarians would be allowed to bypass DRM technology to update or preserve their collections. Journalists, researchers and educators could do the same in pursuit of their work. Everyday consumers would get to “transmit work over a home or personal network” so long as movies, music and other personal media didn’t find their way on to the internet for distribution.

And then of course on the other side:

“The suggestion that fair use and technological innovation is endangered is ignoring reality,” said MPAA spokeswoman Gayle Osterberg. “This is addressing a problem that doesn’t exist.”

Osterberg pointed to a study the U.S. Copyright Office conducts every three years to determine whether fair use is being adversely affected. “The balance that Congress built into the DMCA is working.” The danger, Osterberg said, is in attempting to “enshrine exemptions” to copyright law.

To suggest that content owners have the right to be paid for their work is, for me, a  no-brainer. That being said, I wonder whether the DMCA and increasingly more complex and invasive DRM schemes will ultimately backfire – sure they protect the content, but they sure as heck are a pain in the ass – just my personal take on it. For example, I’d love to buy digital music, but having experienced the controls that iTunes imposes and suddenly having all my tracks disappear, I just don’t bother with it now. Not to mention the incredible hoops one needs to go through to display, say, Blu-ray on a computer – at least in its original, non-downgraded resolution – why bother with all of that at all?

I wonder whether this is, in a way, history repeating itself in a way. I am old enough to remember the early days of software protection – virtually every high-end game or application used fairly sophisticated techniques (like writing non-standard tracks on floppies in between standard tracks) in attempting to prevent piracy. Granted, these have never gone away altogether, particularly for super high end software that needs dongles and and the like, and of course recently there has been a resurgence in the levels of protection that have been layered on in Windows, but after the initial, almost universal lockdown of software long ago, there came a period where it seemed many (if not most) software developers just stopped using such measures.  At least that’s what seemed to happen. I’m not quite sure why, but I wonder if this same pattern will repeat with content rather than software. I suspect not. But hey, you never know.

In the meantime, off I go, reluctantly, in the cold, cold winter, to the nearest record shop to buy music the old fashioned way…