Wifcon.Forum Archives

To Contents	COTS Software - Procurement vs License - Which Controls?
By Anonymous on Thursday, May 08, 2003 - 03:13 pm: What do you think? Does a software license swallow up the software procurement instrument? COTS software licenses commonly state: “This Agreement is the entire and complete understanding between [vendor-licensor] and [licensee] in regard to the subject matter covered herein. It replaces, supersedes, and renders void any and all predecessor Agreements, if any, made between the parties, whether written or oral, which pertain to the covered subject matter.” This language in the license, which is typically executed after the procurement instrument, could be read to totally eviscerate the terms of the government procurement contract under which the software is purchased. And yet, the software license agreement containing the language is most often executed by the licensee who is someone other than the contracting officer. Does the licensee, lacking a warrant, have authority and power to eviscerate a warranted contracting officer's software purchase agreement? Does the licensee have authority or power to waive application of the Contract Disputes Act (which may or may not be invoked by the particular procurement contract) in favor of trial in the state court convenient to the software vendor, as is typically provided in the license? It would seem that the license and the underlying procurement contract should operate and be construed together and the contract terms should control where there is a conflict between them. That is how a rationale software procurement world would operate. Unfortunately, DFARS 227.7202-3 Rights in commercial computer software or commercial computer software documentation, can be read to support the opposite result. In pertinent part, DFARS 227.7202-3(a) says that "the government shall have only the rights specified in the license under which the commercial computer software was obtained." This language, if read literally, displays ignorance of the fact that the government does not "obtain" commercial software "under" a license - rather it obtains software (that is subject to a license) under a procurement contract. The license can dictate what uses the government makes of the data comprising the software - i.e. its software “data" rights but it can't dictate the terms of the procurement of the software - those terms being set by the procurement instrument and federal laws and regulations concerning the procurement. And yet that is exactly what standard COTS license terms appear to attempt to do. By Stan M on Thursday, May 08, 2003 - 03:55 pm: One of your statements is troublesome, you say "This language in the license, which is typically executed after the procurement instrument.." This could be the root of the problem, at my Agency we send any such argeement to Legal and it would not be executed prior to their concurrence. By formerfed on Friday, May 09, 2003 - 07:15 am: I agree with Stan's approach. Actually the license should be part of the procurement instrument. Legal needs to review the license thoroughly. Then the T&C's of the license or the license itself are part of the resulting PO/contract. By Anonymous on Friday, May 09, 2003 - 09:11 am: The anonymous original poster of the item in this thread agrees that Stan is correct that agency sloppyness may have compounded the problem. Former Fed is correct that the license should be "part of the procurement instrument." But how best to accomplish this integration in unmistakable terms? Perhaps a procurement instrument clause that specifically references the license and sets it in its proper context. It could say something to the effect: THE SOFTWARE PROCURED UNDER THIS CONTRACT IS SUBJECT TO LICENSE. THE TERMS OF SAID LICENSE ESTABLISH, AND RESTRICT, THE PURCHASER'S USE RIGHTS IN THE DATA AND TRADESECRETS EMBODIED IN THE SOFTWARE, AND ARE HEREBY INCOPORATED HEREIN BY REFERENCE FOR THIS PURPOSE. THE OTHER TERMS OF THIS CONTRACT, AND APPLICABLE FAR, CONTROL IN THE EVENT THEY CONFLICT WITH THE TERMS OF THE LICENSE. My concern is that, absent something like this, all that a stranger to the software procurement[ e.g. a judge] has available to resolve differences between the license and the contract/FAR [over such things as choice of law, choice of forum, breach by vendor-licensor or by licensee-purchaser] is the statement in the license that it is the exclusive agreement between the parties. That said, the real world problem is that the agency most often goes to a schedule contract and simply places an order thereunder. In this situation it is hard for the agency to dictate new terms, such as those suggested above. Has anyone else had this problem? Has anyone found himself or herself litigating, in the state forum chosen by the licensor, a matter which more correctly should have been handled under the CDA as a breach of contract? Are claimed violations of a COTS software license by or against a Government purchaser of the software, always correctly handled as matters arising under or related to a contract and thus cognizable only in a Contract Disputes Act forum, i.e., Boards of Contract Appeals or the Court of Federal Claims? If not, why not? Alternatively, was anyone else as "blissfully ignorant" of these issues as we were in this agency. By sysdev on Saturday, May 10, 2003 - 02:31 pm: I do not believe one has much choice in the matter. Further, I believe the original Anonymous is misunderstanding and misstating the issue. First, the data rights issue for software developed under contract (differences in civilian and DoD rules) can be excluded. That is not "COTS" by definition. One is left with what COTS means: Commercial Off The Shelf. Congress blurred the line a bit with the definition to include items that have not quite been on the shelf yet, but we are not talking about developmental software here. Next, I have problems with the statement that the rules display "ignorance of the fact that the government does not 'obtain' commercial software 'under' a license - rather it obtains software (that is subject to a license) under a procurement contract" as I believe it is shading semantics. COTS software is most certainly obtained under license as that is how it is offered. The government does not procure any ownership rights. The license to use is obtained under a procurement contract, not the software. Any idea to the contrary is simply false. It is up to the procuring agency to make sure its procurement documents align with legal reality. It seems to me that probability is slightly stretched to believe the use license for COTS software would ripple up into procurement contracts under which licenses are obtained. I would say the problem is in the procurement requirements documents and then as a result of the writer's ignorance of the commercial world and Congressional mandate if the probability is much beyond remote. I too missed the old way when this change took effect, but after considerable analysis found it not to be an insurmountable problem. It just takes more care. As one example look at a system integration contract requiring an integrator to integrate COTS software into a system. Licenses become an issue. Some are so restrictive they really cannot be integrated into a system without system impacts. An example of that is where software in a critical system that on a failed platform requires extensive time lag or payment to move it to an operational platform. You cannot legally disregard such a license or put faith in your procurement document requiring portability will likely overcome the license's legal requirement. You solve the problem by placing upon the integrator the responsibility to obtain only software that meets your requirement. Maybe your preferred package is too restrictive. Tough. You may have to obtain two alternate packages that you like less and integrate them. If you have no integrator, that problem rests entirely upon your shoulders. Let's be clear. Government violation of software license is serious and exposes agencies to legal action and penalties. Some vendors have become aggressive in seeking such misuse as they became aware of a cavalier attitude of "we are the government" in usage. Some have offered bounties for information on such use. You may not like the law, but that makes no difference at all. Government procurement people must instead learn to do the analysis to avoid license requirements becoming a system problem or they must choose a professional integrator and place the requirements upon them. By Anonymous on Tuesday, May 13, 2003 - 11:00 am: To the original Anonymous who posted the question: Here's a link to a document that might be helpful to you: http://www.contracts.ogc.doc.gov/cld/lv/SWLic0799.pdf By sysdev on Tuesday, May 13, 2003 - 01:28 pm: Anonymous of May 13, that reference is an interesting view with application to an agency in the position of working with the vendor on license language. I am not entirely sure it has global application. It probably applies well to a large purchase of major system software. One will also find that the vendors of such software already recognize the government's peculiar situation and already have provisions. I do not think the problem will arise so much when buying "industrial strength" software for large systems. An example would be a major database engine. For those packages large companies and government are the target customer, the vendor has sales people ready to work with those customers and licenses may well be negotiable. It will likely not apply at all to the software most individuals are familiar with, usually marketed for the personal or small business to be used on PC or PC networks. I think that is where the problem will arise. The new factor here is that fairly large government systems are now composed of "personal" hardware and software components. Major vendors are likely to still have a government sales representative who can work with an agency on licenses. Expecting a smaller software house to negotiate a shrink wrapped package license is entirely different. It may even be somewhat difficult to even find someone in the company to work with. Some, like some businesses, will simply take an attitude that they will not compromise their business objective by involving themselves with government red tape and requirements. Their refusal does not simply nullify their legal rights under their license. Do not expect to find a neat little package to use on a government PC system from a small software house and negotiate anything much, even if you are planning to fill your shopping cart with several hundred copies. Do so without adequate review of license details and you may find yourself subject to lawsuit on the license provisions, not your requirement. This may be particularly true when employees with credit cards fan out to retail computer store racks to find software. Be aware of the differences in advance and avoid these problems. It will be interesting to see how Federal Courts decide cases where procurement of "shrink wrapped" licenses from vendors with no real intention to support a Federal market are decided. By Anonymous on Thursday, May 15, 2003 - 01:01 am: From Anonymous of May 13 to sysdev: I disagree with you on the following points: 1. I have negotiated many shrink-wrapped license agreements with software houses, small and large. Commercial companies do it all the time; why shouldn't the Government? (Visit www.dobetterdeals.com and click on the link to their Articles - you'll be surprised at the wealth of information there.) And it's not hard to find the right person to negotiate with. In fact, it's easier to find that person if the software house is small. 2. You just have to tell the software house that you want to negotiate; that there are terms in their shrink-wrapped license agreement that conflict with federal laws. That approach always gets me to the negotiating table. I'm a customer and they want my business. I've never been turned down flat when I've asked to negotiate. (But, home-buyers don't have the opportunity to negotiate shrink-wrapped licenses since they usually buy from retailers, not software houses.) Keep in mind that FAR 12.212(a) states, "Commercial computer software or commercial computer software documentation shall be acquired under licenses customarily provided to the public to the extent such licenses are consistent with Federal law and otherwise satisfy the Government's needs." Let me emphasize the phrase "to the extent such licenses are consistent with Federal law." You do the software house a disservice by blindly accepting shrink-wrapped software by, for example, not pointing out that Federal law trumps State law when a federal contract is involved. 3. Many PC software products can be found on a reseller's GSA Schedule. The GSA Schedules contain the data rights clause, FAR 52.227-19. (Although sometimes - ok, many times - the GSA schedule price list allows the inclusion of terms and conditions from shrink-wrapped licenses that conflict with the FAR, which tells me that the GSA price list wasn't scrutinized (if at all) before it was published.) 4. Recently in FCW, (see http://www.fcw.com/fcw/articles/2003/0505/news-omb-05-05-03.asp) there was an article about OMB crafting a plan to implement government-wide license agreements to take advantage of our collective buying power. That's good news. But I anticipate that this plan will take care of the problems in trying to negotiate a shrink-wrapped license agreement for a $20 software product. I also anticipate that this plan will alleviate the problem that arises when we do accept shrink-wrapped licenses when the software is acquired via a purchase card. Once a government-wide license agreement is in place, all we'll need to do is issue an order. (Uh-oh...I wonder which agency will be responsible for negotiating these license agreements?) By sysdev on Thursday, May 15, 2003 - 11:37 am: I agree it can be done. I do not agree that every software house will do so. You may have had success. Others have not. Some companies simply are not going to get involved in tracking their licenses to that level and their target customer is not the government. The highest risk is in the lower level, PC type, software buys made using credit cards. A secondary risk is in larger buys made by unaware purchasing departments. The cover that was lost when the change was made has most effect at those levels. Perhaps OMB and others are beginning to realize the difficulty in dealing with a hodgepodge of license terms, individual agency rules and an army of buyers not really up on licensing matters. Personally I'd like to see something like the old system back in force. I think this is one experiment that did not work well. By sysdev on Thursday, May 15, 2003 - 11:46 am: The license problem is, as far as I know, less acute in what might be termed popular software. Most office software is probably not a real issue. The issues seem to be most acute in niche products most agencies might never use. Many are highly specialized with a small target audience and some still follow practices that have been rejected by the mass market. Do not expect them to make exceptions for an agency.

COTS Software - Procurement vs License - Which Controls?

By Anonymous on Thursday, May 08, 2003 - 03:13 pm:

What do you think? Does a software license swallow up the software procurement instrument?

COTS software licenses commonly state: “This Agreement is the entire and complete understanding between [vendor-licensor] and [licensee] in regard to the subject matter covered herein. It replaces, supersedes, and renders void any and all predecessor Agreements, if any, made between the parties, whether written or oral, which pertain to the covered subject matter.”

This language in the license, which is typically executed after the procurement instrument, could be read to totally eviscerate the terms of the government procurement contract under which the software is purchased.

And yet, the software license agreement containing the language is most often executed by the licensee who is someone other than the contracting officer. Does the licensee, lacking a warrant, have authority and power to eviscerate a warranted contracting officer's software purchase agreement? Does the licensee have authority or power to waive application of the Contract Disputes Act (which may or may not be invoked by the particular procurement contract) in favor of trial in the state court convenient to the software vendor, as is typically provided in the license?

It would seem that the license and the underlying procurement contract should operate and be construed together and the contract terms should control where there is a conflict between them. That is how a rationale software procurement world would operate.

Unfortunately, DFARS 227.7202-3 Rights in commercial computer software or commercial computer software documentation, can be read to support the opposite result.

In pertinent part, DFARS 227.7202-3(a) says that "the government shall have only the rights specified in the license under which the commercial computer software was obtained." This language, if read literally, displays ignorance of the fact that the government does not "obtain" commercial software "under" a license - rather it obtains software (that is subject to a license) under a procurement contract. The license can dictate what uses the government makes of the data comprising the software - i.e. its software “data" rights but it can't dictate the terms of the procurement of the software - those terms being set by the procurement instrument and federal laws and regulations concerning the procurement.

And yet that is exactly what standard COTS license terms appear to attempt to do.

By Stan M on Thursday, May 08, 2003 - 03:55 pm:

One of your statements is troublesome, you say
"This language in the license, which is typically executed after the procurement instrument.." This could be the root of the problem, at my Agency we send any such argeement to Legal and it would not be executed prior to their concurrence.

By formerfed on Friday, May 09, 2003 - 07:15 am:

I agree with Stan's approach. Actually the license should be part of the procurement instrument. Legal needs to review the license thoroughly. Then the T&C's of the license or the license itself are part of the resulting PO/contract.

By Anonymous on Friday, May 09, 2003 - 09:11 am:

The anonymous original poster of the item in this thread agrees that Stan is correct that agency sloppyness may have compounded the problem.

Former Fed is correct that the license should be "part of the procurement instrument." But how best to accomplish this integration in unmistakable terms?

Perhaps a procurement instrument clause that specifically references the license and sets it in its proper context. It could say something to the effect: THE SOFTWARE PROCURED UNDER THIS CONTRACT IS SUBJECT TO LICENSE. THE TERMS OF SAID LICENSE ESTABLISH, AND RESTRICT, THE PURCHASER'S USE RIGHTS IN THE DATA AND TRADESECRETS EMBODIED IN THE SOFTWARE, AND ARE HEREBY INCOPORATED HEREIN BY REFERENCE FOR THIS PURPOSE. THE OTHER TERMS OF THIS CONTRACT, AND APPLICABLE FAR, CONTROL IN THE EVENT THEY CONFLICT WITH THE TERMS OF THE LICENSE.

My concern is that, absent something like this, all that a stranger to the software procurement[ e.g. a judge] has available to resolve differences between the license and the contract/FAR [over such things as choice of law, choice of forum, breach by vendor-licensor or by licensee-purchaser] is the statement in the license that it is the exclusive agreement between the parties.

That said, the real world problem is that the agency most often goes to a schedule contract and simply places an order thereunder. In this situation it is hard for the agency to dictate new terms, such as those suggested above.

Has anyone else had this problem? Has anyone found himself or herself litigating, in the state forum chosen by the licensor, a matter which more correctly should have been handled under the CDA as a breach of contract?

Are claimed violations of a COTS software license by or against a Government purchaser of the software, always correctly handled as matters arising under or related to a contract and thus cognizable only in a Contract Disputes Act forum, i.e., Boards of Contract Appeals or the Court of Federal Claims? If not, why not?

Alternatively, was anyone else as "blissfully ignorant" of these issues as we were in this agency.

By sysdev on Saturday, May 10, 2003 - 02:31 pm:

I do not believe one has much choice in the matter. Further, I believe the original Anonymous is misunderstanding and misstating the issue.

First, the data rights issue for software developed under contract (differences in civilian and DoD rules) can be excluded. That is not "COTS" by definition. One is left with what COTS means: Commercial Off The Shelf. Congress blurred the line a bit with the definition to include items that have not quite been on the shelf yet, but we are not talking about developmental software here.

Next, I have problems with the statement that the rules display "ignorance of the fact that the government does not 'obtain' commercial software 'under' a license - rather it obtains software (that is subject to a license) under a procurement contract" as I believe it is shading semantics. COTS software is most certainly obtained under license as that is how it is offered. The government does not procure any ownership rights. The license to use is obtained under a procurement contract, not the software. Any idea to the contrary is simply false. It is up to the procuring agency to make sure its procurement documents align with legal reality.

It seems to me that probability is slightly stretched to believe the use license for COTS software would ripple up into procurement contracts under which licenses are obtained. I would say the problem is in the procurement requirements documents and then as a result of the writer's ignorance of the commercial world and Congressional mandate if the probability is much beyond remote. I too missed the old way when this change took effect, but after considerable analysis found it not to be an insurmountable problem. It just takes more care.

As one example look at a system integration contract requiring an integrator to integrate COTS software into a system. Licenses become an issue. Some are so restrictive they really cannot be integrated into a system without system impacts. An example of that is where software in a critical system that on a failed platform requires extensive time lag or payment to move it to an operational platform. You cannot legally disregard such a license or put faith in your procurement document requiring portability will likely overcome the license's legal requirement.

You solve the problem by placing upon the integrator the responsibility to obtain only software that meets your requirement. Maybe your preferred package is too restrictive. Tough. You may have to obtain two alternate packages that you like less and integrate them. If you have no integrator, that problem rests entirely upon your shoulders.

Let's be clear. Government violation of software license is serious and exposes agencies to legal action and penalties. Some vendors have become aggressive in seeking such misuse as they became aware of a cavalier attitude of "we are the government" in usage. Some have offered bounties for information on such use.

You may not like the law, but that makes no difference at all. Government procurement people must instead learn to do the analysis to avoid license requirements becoming a system problem or they must choose a professional integrator and place the requirements upon them.

By Anonymous on Tuesday, May 13, 2003 - 11:00 am:

To the original Anonymous who posted the question:

Here's a link to a document that might be helpful to you: http://www.contracts.ogc.doc.gov/cld/lv/SWLic0799.pdf

By sysdev on Tuesday, May 13, 2003 - 01:28 pm:

Anonymous of May 13, that reference is an interesting view with application to an agency in the position of working with the vendor on license language. I am not entirely sure it has global application.

It probably applies well to a large purchase of major system software. One will also find that the vendors of such software already recognize the government's peculiar situation and already have provisions. I do not think the problem will arise so much when buying "industrial strength" software for large systems. An example would be a major database engine. For those packages large companies and government are the target customer, the vendor has sales people ready to work with those customers and licenses may well be negotiable.

It will likely not apply at all to the software most individuals are familiar with, usually marketed for the personal or small business to be used on PC or PC networks. I think that is where the problem will arise. The new factor here is that fairly large government systems are now composed of "personal" hardware and software components. Major vendors are likely to still have a government sales representative who can work with an agency on licenses.

Expecting a smaller software house to negotiate a shrink wrapped package license is entirely different. It may even be somewhat difficult to even find someone in the company to work with. Some, like some businesses, will simply take an attitude that they will not compromise their business objective by involving themselves with government red tape and requirements. Their refusal does not simply nullify their legal rights under their license.

Do not expect to find a neat little package to use on a government PC system from a small software house and negotiate anything much, even if you are planning to fill your shopping cart with several hundred copies. Do so without adequate review of license details and you may find yourself subject to lawsuit on the license provisions, not your requirement. This may be particularly true when employees with credit cards fan out to retail computer store racks to find software.

Be aware of the differences in advance and avoid these problems. It will be interesting to see how Federal Courts decide cases where procurement of "shrink wrapped" licenses from vendors with no real intention to support a Federal market are decided.

By Anonymous on Thursday, May 15, 2003 - 01:01 am:

From Anonymous of May 13 to sysdev:

I disagree with you on the following points:
1. I have negotiated many shrink-wrapped license agreements with software houses, small and large. Commercial companies do it all the time; why shouldn't the Government? (Visit www.dobetterdeals.com and click on the link to their Articles - you'll be surprised at the wealth of information there.) And it's not hard to find the right person to negotiate with. In fact, it's easier to find that person if the software house is small.

2. You just have to tell the software house that you want to negotiate; that there are terms in their shrink-wrapped license agreement that conflict with federal laws. That approach always gets me to the negotiating table. I'm a customer and they want my business. I've never been turned down flat when I've asked to negotiate. (But, home-buyers don't have the opportunity to negotiate shrink-wrapped licenses since they usually buy from retailers, not software houses.)

Keep in mind that FAR 12.212(a) states, "Commercial computer software or commercial computer software documentation shall be acquired under licenses customarily provided to the public to the extent such licenses are consistent with Federal law and otherwise satisfy the Government's needs." Let me emphasize the phrase "to the extent such licenses are consistent with Federal law." You do the software house a disservice by blindly accepting shrink-wrapped software by, for example, not pointing out that Federal law trumps State law when a federal contract is involved.

3. Many PC software products can be found on a reseller's GSA Schedule. The GSA Schedules contain the data rights clause, FAR 52.227-19. (Although sometimes - ok, many times - the GSA schedule price list allows the inclusion of terms and conditions from shrink-wrapped licenses that conflict with the FAR, which tells me that the GSA price list wasn't scrutinized (if at all) before it was published.)

4. Recently in FCW, (see http://www.fcw.com/fcw/articles/2003/0505/news-omb-05-05-03.asp) there was an article about OMB crafting a plan to implement government-wide license agreements to take advantage of our collective buying power. That's good news. But I anticipate that this plan will take care of the problems in trying to negotiate a shrink-wrapped license agreement for a $20 software product. I also anticipate that this plan will alleviate the problem that arises when we do accept shrink-wrapped licenses when the software is acquired via a purchase card. Once a government-wide license agreement is in place, all we'll need to do is issue an order. (Uh-oh...I wonder which agency will be responsible for negotiating these license agreements?)

By sysdev on Thursday, May 15, 2003 - 11:37 am:

I agree it can be done. I do not agree that every software house will do so. You may have had success. Others have not. Some companies simply are not going to get involved in tracking their licenses to that level and their target customer is not the government.

The highest risk is in the lower level, PC type, software buys made using credit cards. A secondary risk is in larger buys made by unaware purchasing departments. The cover that was lost when the change was made has most effect at those levels.

Perhaps OMB and others are beginning to realize the difficulty in dealing with a hodgepodge of license terms, individual agency rules and an army of buyers not really up on licensing matters. Personally I'd like to see something like the old system back in force. I think this is one experiment that did not work well.

By sysdev on Thursday, May 15, 2003 - 11:46 am:

The license problem is, as far as I know, less acute in what might be termed popular software. Most office software is probably not a real issue. The issues seem to be most acute in niche products most agencies might never use. Many are highly specialized with a small target audience and some still follow practices that have been rejected by the mass market. Do not expect them to make exceptions for an agency.