Home › Posts tagged GPL

GPL

it.can presentation on open source

Posted on by — No Comments ↓

I gave a speech, along with Thomas Prowse (Genband) and Fred Dixon (Blindside Networks) at the IT.Can Annual Conference (PDF) in Montreal last week. The following is the paper that went along with the presentation, for whatever it’s worth. Not particularly earth-shattering but an approach that is a little different than user/purchaser centric approach I usually see about the topic in other papers and presentations, at least within the realm of those addressed to lawyers. Also in Word format: IT.Can 2010 open source (paper) v2.

Many other great presentations as well, by some of the leading IT practitioners in Canada. Not a member? Consider joining. Well worth it.

OPEN SOURCE BUSINESS MODELS

by David Ma[1]

1.                  INTRODUCTION

This paper will: (a) review some of the more common business models used to exploit intellectual property; (b) describe, in brief, what open source is; and (c) identify characteristics of open source licenses as they pertain to those business models.

It is oriented primarily to owners or developers of intellectual property that are contemplating the alternatives available to them in the commercial exploitation of that IP. The general context on which this paper focuses is the development and exploitation of software. However, some or all of the principles described below may be applied in other contexts, and we describe some of these briefly toward the end of the paper.

The intent of this paper is not to advocate open source business models as the definitive way to undertake such a venture. Rather, it is to familiarize the reader with the underpinnings of what is becoming an increasingly prevalent approach to exploiting IP which warrants serious consideration as an alternative to more traditional methods – namely, a proprietary licensing model which emphasizes the treatment of underlying source code as a trade secret. It may well be that the particular circumstances of a business undertaking do not lend themselves to such models. However, it would be, in the author’s opinion, inadvisable not to give them due consideration.

Read more it.can presentation on open source ›

foss tool to… detect foss

Posted on by — No Comments ↓

Saw the announcement for this and thought it would be of interest. It’s a new tool called Binary Analysis. You can go to the site for more info but in short it scans through object code (including firmware) to detect specified source code. Apparently it includes automated checking for Linux kernel code.

Might come in handy for compliance checking, though, as the site itself indicates, it’s no substitute for a compliance engineer and the development of appropriate development policies. Also might come in handy if you’re doing due diligence on a potential acquisition if you suspect there might be some open source in what you’ve been told is proprietary. Usually the vendor recommended for that sort of work is Black Duck but I imagine Binary Analysis may be good for a quick and dirty check.

Created with the participation of Armijn Hemel, the same fellow that runs gpl-violations.org – an organization that tracks, publicizes and occasionally takes legal action against those infringing GPL licensed software.

google open sourcing vp8 codec

Posted on by — No Comments ↓

Interesting but perhaps not surprising news that Google will make the VP8 video codec open source. You can read in more detail by following the link but here’s a quick rundown: Many companies have decided to support H.264 for video streaming, including Google, Apple and Microsoft. Others, like Mozilla (the creator of Firefox), have not, as they are concerned about adopting, as a standard, proprietary technology that may one day require payment of royalties. Instead, they have chosen to support Ogg Theora, an open source codec based on a much earlier version of VP8. Making VP8 open source will remove this divide and will likely encourage the adoption of VP8 as a standard in place of either, as VP8 appears to be technically superior to both H.264 and Ogg Theora (which was developed from a much earlier iteration of VP8) and presumably would be free of potential licensing issues (and fees) associated with proprietary solutions such as H.264.

Perhaps not surprising given Google’s approach in mobile (i.e. the Android open source platform). Though it is worth noting that Google isn’t enchanted with all things open source, as evidenced by the hubbub about it and the Affero GPL a few years ago…

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.

after one gpl body blow, skype yells uncle

Posted on by — No Comments ↓

As most of you probably know, there has been a case that just went to court earlier today in Germany on the GPL. It had been described by Harald Welte as one of the more time consuming cases he has worked on. For those of you not familiar with him, Mr. Welte founded gpl-violations.org, an organization that helps to enforce the provisions of the GPL.

Skype had apparently used certain elements of the Linux kernel in its WiFi phones without complying with the GPL, and was set to challenge the validity of the GPL based on its alleged contraventions of German legislation – in particular anti-trust legislation. It would be interesting to see the analysis in that regard, particularly on the anti-trust front, but so far I’ve not been able to get my hands on a translated copy of the pleadings – if anyone knows where to locate, do let me know.

Anyway, apparently, they didn’t get too far. According to the entry in Harald Welte’s blog, apart from the validity of such claims, the somewhat ironic result to which the court alluded at the hearing is that if Skype were able to successfully assert the invalidity of the license, then it would also be difficult for them to claim any right to use the impugned code. Makes sense. Invalid license = no use rights.

After the court suggested that Skype’s likelihood of success would be low, Skype apparently threw in the towel in such a manner that they would not be able to revisit it further, effectively giving the victory to Welte.

I find the case and Skype’s litigation strategy somewhat puzzling, both given the decision in the 2006 D-Link case, also in Germany and the relative costs of litigation in comparison to compliance. That being said, I haven’t been able to obtain much in the way of original documentation regarding the particular GPL violations that Skype allegedly committed. Presumably, Skype went down a path in its use of GPL code that would result in it incurring significant expenses (or facing significant risk, of some sort – perhaps exposure of their own proprietary IP?) if they were required to comply after the fact. Presumably, they would not have found themselves in this situation if they had turned their mind toward structuring their use of GPL code appropriately, by either ensuring they could comply in a cost-effective manner, or not using the GPL code.

first us gpl lawsuit filed

Posted on by — No Comments ↓

Surprising. I’ve read about cases going to court in Europe and naturally assumed, given the litigious environment of the US, that something had happened long ago stateside. So, I was a bit surprised to hear about the first GPL lawsuit down there.

For the first time in the U.S., a company and software vendor, Monsoon Multimedia, is being taken to court for a GPL violation. Previously, alleged GPL violations have all been settled by letters from the FSF (Free Software Foundation) or other open-source organizations, pointing out the violation. (Linux Watch)

Hmmm. Maybe not – recent news is that they’re now in settlement discussions. In any event, this gives me yet another excuse to rant, once again, about open source software, or for that matter, any third party code that companies out there may wish to use or build into their products.

As some of you may know, I personally quite like open source stuff. In fact, this blog is written using a giant truckload of the stuff, which works remarkably well for something developed by folks who aren’t paid (for the most part) to develop any of it. Open source can also be a great asset to many companies out there, whether in use or in development.

BUT (and surely you must be expecting a but by now), to the extent you are going to develop with open source code, public domain code or for that matter ANY third party code, you absolutely, positively, MUST keep track of it and make sure you use it both in compliance with the terms under which it is licensed and: (a) make sure the license terms are appropriate for the intended purpose; and (b) make sure you comply with the license terms.

Why is (a) important? To give a very simply illustration, if you plan on building a company whose primary asset and value is based on closed and (ostensibly) proprietary code, you should not be putting GPL code into your product, since one of the requirements of doing so would be an obligation to make your code publicly available on the same terms. This is probably a vast oversimplification of the terms of the GPL but I hope it illustrates the point. And if you don’t think this is likely to have an impact on your company, well, think again. Regardless of what you may think about (b) (which we’ll be getting to in a second), a potential acquiror of your company may feel quite differently about the risks of unintended use of open source code if, for example, it has been told your product is proprietary. And they definitely will find out about it. In fact, there are very, very effective tools to do so, like the one provided by Black Duck. And it is becoming a rather normal practice in acquisition due diligence to run code through Black Duck or something similar if there is the possibility of undisclosed open source.

Why is (b) important? Well, in addition to what’s described above, there is a real risk associated with contravening the GPL, the LPGL or other open source licenses. Just because its free does not mean that someone will not invest the time and effort to find out about contraventions of such licenses and make sure their terms are complied with, including the Software Freedom Law Center. In addition to institutions like those, there are also many, many folks out there keeping an eye out for possible breaches of GPL and reporting them to bodies like the SFLC.

All that being said, I should make it clear that I do think that open source software does have a place in profit-driven companies, as do open source development models. JBoss, MySQL, and Sleepycat are just a few in the latter category that have been quite successful. The key of course, is to make sure that how you use those tools works consistently both with your intended business model and with the terms under which apply to their use. Which will be a good topic for another day.

The Virtues and Evils of Open Source

Posted on by — No Comments ↓

Yes, I know, I’ve been behind lately. A ton of very interesting things to catch up on. But I’d like to put in one quick note about open source code. I recently came across an article, written last year by a lawyer, generally advising development companies not to use open source. I don’t quite recall where it was (if I did I’d link to it) but I do remember it being quite clear in stating that using open source is A Bad Thing and to avoid it altogether – not just to be careful, but rather to treat it as one would radioactive waste.

With respect, I don’t quite agree. I certainly advise my clients to take a great deal of caution in using open source code, particularly the GPL variety, and very particularly if they have a desire to keep some or all of their own secret, proprietary code secret and proprietary. That being said, I do have many, many clients who have used open source code to great advantage in various ways. Some have simply used existing open source code to avoid reinventing the wheel (and saving on costs), while taking care to keep viral elements out of their proprietary code. Others have been more aggressive with the open source model and have intentionally decided to use open source as the basis for their business model and making their very own code, or parts of it, either open source or subject to a dual-licensing model. As the Red Hats, JBosses, Sleepycats, MySQLs etc. etc. of the world have demonstrated, you can go open source and still have a pretty viable business. And, of course, there are the “old world” companies like IBM who have decided to go open source (in some limited ways – e.g. IBM’s DB2 Express-C thing).

Of course, this is not to suggest that anyone through caution to the wind and just start pulling down stuff from Sourceforge and whacking it into your product. Use of open source definitely requires some planning ahead and consideration of what the business model and value proposition of your business will be. Optimally, enlist the help of a lawyer who’s familiar with open source licenses to discuss what you plan to do and the packages you plan to use. Or, if that’s not feasible, try at least to read the applicable licenses yourself and ensure you comply with them, because if you don’t think that anyone will notice, or that no one will actually sue you, you may want to pay a visit to the GPL Violations Site and reconsider, in addition to the questions that will be asked of you when the due diligence starts on your next round of financing or, even worse, your (aborted) exit event. Can badly managed open source usage (and I emphasize badly managed, not simply open source usage) kill a deal? Definitely.

In short – I don’t think open source is necessarily a bad thing. In fact, it can be a pretty good thing, not just in the social good sense and all that, but also as a business. But it need to be used taking into account its terms of use and ensuring that its consistent with the strategy you plan to take.

If perhaps there’s one thing I’d recommend it would be for shops to make absolutely sure they have a disciplined approach in tracking where code comes from and the terms under which its being used and why its being used. That applies not only to open source stuff, but also, for example, your programmers taking neat snippets of code from Dr. Dobbs or something else, or coming across a nice little script somewhere on the Web and saying “Gee, that’s neat, let’s use it in our product”.

Anyway, if I remember where the article was I’ll update this to include a link.