Home › Posts tagged free software

free software

gpl compliance guide released

Posted on by — No Comments ↓

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.

open source and copyright

Posted on by — No Comments ↓

I was intrigued by the title of this artlce in Wired News (which was by way of AP): “Court says copyrights apply even for free software”

Sounded intriguing. Particularly the intro, where it stated that “[i]n a crucial win for the free software movement, a federal appeals court has ruled that even software developers who give away the programming code for their works can sue for copyright infringement if someone misappropriates that material. Interesting, though surprising, since I was of the understanding that it was long settled that software, whether open source or otherwise, was subject to copyright.

I then started reading the article’s analysis of the decision:

Because the code was given away for free, thorny questions emerge when a violation has been discovered and someone is found to have shoved the code into their own for-profit products without giving anything back, in the form of attribution and disclosure of the alterations they made.

Hmmm. That doesn’t sound quite right, as that implies that the fact that there wasn’t a price for the code (or rather the right to use the code) is what gave rise to dispute. In other words, it suggests that because you haven’t paid, the obligation to attribute and disclose alterations may not necessarily be enforceable.

So I decided to take a quick peek at the case. Not quite right. The developer, in this case, was trying to get an injunction (a court order that forces the other party to stop doing something, failing which they get thrown in jail). In order to get an injunction, the person seeking it must show that if the court doesn’t grant it, they will suffer “irreparable harm”. Usually, the burden will be on the person seeking it to demonstrate. However, there is US case law that basically says that in the case of copyright claims, irreparable harm is presumed (subject to certain conditions). In other words, it makes it quite a bit easier to get an injunction.

So, the applicability of copyright in this case was of primary importance as it would determine whether or not the developer would be able to get an injunction, not “because it’s easier to recover monetary damages in a copyright-infringement case” as the article states.

Anyway, it turns out what was at issue in the case really had nothing to do with whether or not the software was open source, or whether or not there was a price associated with it. Instead, it was focused on the very fine (as in detailed-oriented rather than nice) distinction between a condition in a contract and a covenant.

The way a license works is that it grants to the user, through a contract, certain rights to use, copy, etc. the software, but only those rights. So, if you don’t have a contract and use or the software, then you don’t have any rights to do so. That would be a violation of copyright law. Similarly, if you exceed the rights granted to you, that would also be a copyright infringement.

Finally, we come to conditions. Another word that is often used to describe these are provisos. These are things in a license that are tied to the grant of rights – in other words, if you don’t do them, then you don’t have the rights. Its like the “if… then” structure in programming. If you do A, B and C, then you can use the software. And of course, if you don’t, you can’t. Sometimes also worded like this: “You can use the software, provided you do A, B and C”. The effect then, is that if you don’t do A, B and C, then you don’t have a right to use the software. And if you don’t have the right and you use it anyway, then once again you will be infringing copyright.

The “heart” of the case, as the court described it, wasn’t whether or not the software license was paid for or not, but rather whether or not certain obligations to attribute the software to the developer and provide modifications were conditions or rather merely covenants. The distinction is important because a covenant is an obligation that is not tied to the license grant. In other words, if you don’t perform a covenant, you don’t lose your rights to use the software. Sure, you are in breach of the software license, and can be sued for damages, but the key difference is that you are not infringing copyright, since it is not tied to the grant of rights to use the software.

In this case, the defendant was saying that the obligations they breached were only covenants. Therefore, no copyright violation. Therefore, no presumed irreparable harm. Therefore, no injunction. The district court agreed with this.

However, the court of appeal corrected this. Perhaps not surprising, given that the license in question had language such as

The intent of this document is to state the conditions under which a Package may be copied.

The court of appeal further remarked that

The Artistic License also uses the traditional language of conditions by noting that the rights to copy, modify, and distribute are granted “provided that” the conditions are met.

In short, the decision has less to do with open source and more to do with contractual interpretation – in this case, the distinctions between conditions and covenants. The same dispute could have just as well arisen for typical commercial software.

So is this a “crucial win” for the open source community? No, probably not. However, it does serve to illustrate the importance of clear and well-drafted licenses. If you are a developer and want to make sure your software cannot used without the licensee doing certain things, your license must clearly identify those things as conditions.

Almost forgot – for those so inclined, a link to the case (PDF).

Update: I was surprised to see that Lawrence Lessig commented on this same case as being “huge and important news”. Which to me is somewhat surprising, given my comments above. In brief, he noted:

In non-technical terms, the Court has held that free licenses such as the CC licenses set conditions (rather than covenants) on the use of copyrighted work. When you violate the condition, the license disappears, meaning you’re simply a copyright infringer. This is the theory of the GPL and all CC licenses. Put precisely, whether or not they are also contracts, they are copyright licenses which expire if you fail to abide by the terms of the license.

However, the issue – at least the one that seemed to be argued on appeal – was not whether or not free or open software licenses per se could attract copyright violation if they were not adhered to, but rather the more pedestrian question of whether the obligations in the license in question actually constituted conditions as opposed to covenants. Hmmm.

Further update: I had pulled this post for a while because time and time again I kept reading how this was a big win for open source and was rethinking the above. While I certainly think the appeal decision was the right one, I don’t think this should be thought of as a big win for open source, since the findings would seem to apply to any license – i.e. its somewhat like celebrating a victory for bicycle riders because a judge has found that all wheeled vehicles are legal in a case that happens to be about a bicycle being illegal. Anyway, I do plan another post on this one, but more on the reactions and analyses that I’ve been reading rather than the decision itself.