Home › Posts tagged open-source

open-source

open source legal documents

Posted on by — No Comments ↓

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.

linux kernel found to infringe patent

Posted on by — No Comments ↓

Well, this is rather disconcerting. By way of Engadget, I came across this blog entry on FOSS Patents about how a small outfit in Texas, Bedrock Computer Technologies LLC (apparently a non-practicing entity, otherwise typically described as a “patent troll”), has won a $5 million claim for patent infringement against Google.

But the part that is perhaps a bit more worrisome than either the amount or the defendant is the fact that the infringing technology in question is a portion of the Linux kernel. From the entry:

Like I said further above, the question of Google possibly having to pay $5 million (unless the judge decides otherwise or an appeal succeeds) is not really the issue. In addition to money, Bedrock also asked for an injunction, and now that Google has been found to infringe a patent deemed valid by the jury, it remains to be seen whether an injunction will be granted either by this court or on a possible appeal.

The problem is that Bedrock is now in a pretty strong position to collect royalties from other Linux users, especially those utilizing Linux for large server operations.

It’s a bit difficult to tell, based on the claims asserted in the patent, whether or not Google would be able to excise the offending part of the kernel or find some other way to avoid infringing use. I’m sure they can, but if they can’t,  an injunction might have some implications for Google’s server farms and therefore its operations.

In addition, there’s also the possibility that this will impact Android:

Concerning Android, I wouldn’t rule out that maybe some of the hundreds of thousands of Android applications out there use the teachings of the infringed patent claims in one way or another. Even if that is not the case, Google might have to modify the Linux kernel it distributes with Android in order to remove the infringing code because otherwise there’s always the risk of contributory infringement should any app make use of that portion of the Linux kernel.

Needless to say, there could be quite a few companies impacted by this, though I imagine folks in the open source community are starting to look at workarounds, hopefully. It’s difficult to tell from the claim in the patent how fundamental it is or how difficulty or easy it would be to work around.

Perhaps its just me, but sometimes get rather irritated when reading software patent claims. Often, they seem to describe things that already well known or rather mundane. Take for example the claims in this case:

1. An information storage and retrieval system, the system comprising:

  • a linked list to store and provide access to records stored in a memory of the system, at least some of the records automatically expiring,
  • a record search means utilizing a search key to access the linked list,
  • the record search means including a means for identifying and removing at least some of the expired ones of the records from the linked list when the linked list is accessed, and
  • means, utilizing the record search means, for accessing the linked list and, at the same time, removing at least some of the expired ones of the records in the linked list.

2. The information storage and retrieval system according to claim 1 further including means for dynamically determining maximum number for the record search means to remove in the accessed linked list of records.

I’m not trained as a patent agent, so cannot speak with much authority on this, but these claims, to me, seem rather mundane.

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.

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.

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 – Part II

Posted on by — No Comments ↓

Found the article that triggered my previous post – was a piece written by Suzanne Dingwall Williams in her blog. The nub:

If you want to sell your own proprietary software, make sure you have a strictly enforced policy against using open source. Here’s why: even if you agree that open source has crossed the chasm in the lifecycle that is technology adoption, your investors have not. Even the inclusion of an inconsequential open source tool can cause headaches, or stop a deal altogether.

Here are the concerns often raised about open source at the due diligence stage:
– there is no meaningful warranty or indemnity for this portion of the product
– how do we know the open source license is enforceable?
– do the terms for this piece of open source contaminate the rest of your product?
– if this was inadvertently incorporated into the product, what else was?

I should emphasize that I don’t necessarily disagree with the concerns she notes. They are concerns. Particularly in the specific instance she notes – i.e. selling proprietary software (as opposed to using an open source business model). That being said whether or not the benefits will outweigh the risks will depend on many things, including the business model of the startup (even if one chooses to go the route of developing proprietary software), the license governing the open source code and of course how its used. I don’t necessarily think that companies (including startups) should just have a flat policy not to use open source. But I’ve already rambled on about this in my previous post.

But then again, I’m not a VC. And Suzie apparently used to be one. It would be interesting to know what VCs generally think. Are you a VC? If so it would be great if you could go to the poll at the bottom of the left column. Nothing super scientific, admittedly, but I’d be interested in seeing what the general sentiment is.

Giles Bowkett: A Tale of Two Startups

Posted on by — No Comments ↓

Came across this article through reddit from Giles Bowkett, an entrepreneur type in the US. Interesting in the conclusion on VCs:

The irony is, the biggest disruptive innovation that ever came from the Internet could in fact be open source software, and the old industry it destroys will probably be venture capital.Think about it. Free software and cheap infrastructure basically eliminates the whole raison d’etre for venture capitalists. Companies are cheap to start. All the stuff you used to need millions for is now free. That means venture capitalists just don’t matter any more. It isn’t about being lucky enough to get $5 million in funding; it’s about starting something with the cash in your pocket. If you make something and it’s good enough, the guys with $5 million in funding will come to you, because those guys are basically just money in search of intelligence, and it’s a lot better to be intelligence in search of money. If you’re intelligence in search of money, you’ll choose the best way to get money. The best way to get money isn’t to find some VCs to beg, borrow, or steal from; the best way to get money is to make something people will pay for. So if you’re intelligence in search of money, you’ll make stuff people want to pay for, and you won’t even bother with the VCs, because they need you more than you need them.

My own, personal take? Fat chance. Yes yes, free software is nice and so is cheap bandwidth. But the world runs on money. People cost money. Development costs money. Money money money money. So fine, you’re a super ultratalented uber-geek that shows leadership skills, blah blah blah. Still need to create the thing that people will want to pay for. And unless you’re going to be coding everything yourself, you’ll need to hire people to help you. And you’ll need to pay the accountants to pay the bills. And the lawyers to draft the agreements. And the admin guys to, uh, do the admin. Its not as if a magic sprinkle of open source will all of a sudden obviate the need to invest to build a product – if that were the case, then absence of barriers to entry would quickly reduce what was otherwise a very profitable niche into one that looks less and less desirable – both to entrepreneurs as well as investors, be they VCs or others. And even in the case of two folks setting up shop – Company A who chooses the cheap route, builds a really neat widget (but of course doesn’t have the budget for marketing, promo, etc.) vs. Company B who gets a $10 million first round, uses to ramp up and gets to market in 1/2 the time, establishes critical mass, and basically kills off Company A. Hmmm.
I also don’t agree with the “they need you more than you need them” thing – VC money, as with most things in business, are driven by the market – more VCs chasing fewer opportunities just means the cost of their money will come down, not that they will disappear.

So, long story short, I doubt tech VCs will go away any time soon. Besides, they’re fun guys.