Software as a Service - Supply or Service?

7030 works for me.  

A a software license is a supply, not a service.  Your order should set a delivery date, not a period of performance.

I wish I could recover the source from my experiences, but I remember reading that software could be considered a service if there was a regular deliverable identified (such as scheduled updates). Otherwise, a license would indeed be a supply.

Software as Service can be done in a few different ways... Imagine a per user per month scenario, where charges are based by actual users per month. Still FFP, but billed at the actual usage. Would still have a POP.  Also many software companies have converted "subscription licenses" to SaaS. They own the IP and the actual software, and charge for access for the most recent version. I look at SaaS as more of a payment option. Doesn't change the product, or how its being delivered, just how its being billed.   

Now I have no clue on the PSC question. 

sdvr,

I agree that SaaS is a payment arrangement -- given that we must categorize software license purchases as either supply or service (we have no other choice), SaaS is still a supply (notwithstanding the second "S" in SaaS).  In all commercial software buys, all we get is a license -- in all of them, "they" still own the IP and the actual software.

If anyone is curious this is the software...it's called "Ideascale" and it's one of SECNAV's projects.  It's a user based, crowd sourcing platform.  The Navy can only guess as to how many users will be signed up in the coming years so it's difficult to estimate the price.  The current product is offered by Alamo City Engineering Services, Inc.  They are on GSA.

https://doninnovation.ideascale.com/a/index

On March 24, 2016 at 9:41 AM, ji20874 said:

7030 works for me.

A a software license is a supply, not a service.  Your order should set a delivery date, not a period of performance.

On March 24, 2016 at 3:46 PM, ji20874 said:

sdvr,

I agree that SaaS is a payment arrangement -- given that we must categorize software license purchases as either supply or service (we have no other choice), SaaS is still a supply (notwithstanding the second "S" in SaaS).  In all commercial software buys, all we get is a license -- in all of them, "they" still own the IP and the actual software.

I see no rationale in either of those responses for claiming that the acquisition of a software license is an acquisition of supplies. All I see is insistence.

Supplies are property, except real property. All of the examples in FAR 2.101 are tangible things. An acquisition of supplies is an acquisition of property and property rights. But a software license is a use agreement. A license typically does not transfer any property rights, except, perhaps to any physical medium on which the software is delivered. But that's like the cardboard box in which the book arrives from Amazon. Do you own the box? Sure. Why not? Do you care that you own it after you take the book out?

What do you get when you obtain the license right to use software? Automated information processing services. Right? Then why is the acquisition of a software license an acquisition of supplies?

In any case, why must a software license be categorized as either? What if it's neither? Shouldn't we think outside the box?

The FAR speaks to supplies and services (and construction), and FPDS-NG and so forth do as well.  Given that choice, the original poster should choose supplies.  The suggestion of neither might be true in a strict semantic sense, but probably isn't practical in a FAR context.   

That said, I would be interested in exploring how software could be bought (licensed) while seeing it as neither supplies nor services.

Quote

That said, I would be interested in exploring how software could be bought (licensed) while seeing it as neither supplies nor services.

Before we discuss that, which I'll be happy to do, I need you to explain why the original poster should choose supplies as the right category for a software license. You have said that several times, but you have never given a reason. (Did I miss it?)  I might agree with you if you would give me a reasonable argument.

shall7:

Can your questions be answered by reviewing the GSA contract? It should have the clauses (services or supply), NAICS, and PSC. 

You might find luck directing your questions directly to the GSA contracting officer.

Supply or service?  We have to pick one, right?

A software license does not engage employees to perform a task -- hence, not a service contract.  A license is delivered (so to speak) to the customer and kept in the agency's files.  A software license might be thought of as an intangible supply item, like health insurance.  We pay for it one time, up front.  My health insurance does not engage the services of nurses and doctors, and if purchased under the FAR, should be purchased as s supply.  Or, like a subscription -- my magazine subscription does not engage the services of writers and editors, and if purchased under the FAR, should be purchased as a supply.  My recent automobile purchase did not engage the services of welders, machinists, and rubber plantation workers, and is best thought of as a supply rather than a service (although I could write a service contract to build a car).  Well, this last one wasn't intangible.

 It simply makes no sense to call commercial software, for which we seek a license, a service where we pretend like we are engaging the services of coders and so forth.  We aren't hiring coders to develop software for us if we're talking about a license for commercial softeare.  Given the structural bi-modal choice of supply or service, it is better and professionally honest to call it a supply with a delivery date (delivery of the license and shrunk-wrapped or downloadable software) rather than a service with a period of performance (where the period of performance is the license term).  The terms and conditions for standard FAR supply contracts work better for software licenses than the service clauses.  And imagine the joke of trying to impose a Service Contract Act wage determination on a commercial software firm -- it simply can't be done.  

Even if the license includes upgrades, patches, and fixes, it is still a supply.  Even if it includes up to a certain number of service center calls.

For all these reasons, I choose to look on commercial software licenses as supplies rather than services.  

If if there is a third way, please share it.

ji20874 said:

Supply or service?  We have to pick one, right?

A software license does not engage employees to perform a task -- hence, not a service contract.  A license is delivered (so to speak) to the customer and kept in the agency's files.  A software license might be thought of as an intangible supply item, like health insurance.  We pay for it one time, up front.  My health insurance does not engage the services of nurses and doctors, and if purchased under the FAR, should be purchased as s supply.  Or, like a subscription -- my magazine subscription does not engage the services of writers and editors, and if purchased under the FAR, should be purchased as a supply.  My recent automobile purchase did not engage the services of welders, machinists, and rubber plantation workers, and is best thought of as a supply rather than a service (although I could write a service contract to build a car).  Well, this last one wasn't intangible.

 It simply makes no sense to call commercial software, for which we seek a license, a service where we pretend like we are engaging the services of coders and so forth.  We aren't hiring coders to develop software for us if we're talking about a license for commercial softeare.  Given the structural bi-modal choice of supply or service, it is better and professionally honest to call it a supply with a delivery date (delivery of the license and shrunk-wrapped or downloadable software) rather than a service with a period of performance (where the period of performance is the license term).  The terms and conditions for standard FAR supply contracts work better for software licenses than the service clauses.  And imagine the joke of trying to impose a Service Contract Act wage determination on a commercial software firm -- it simply can't be done.  

Even if the license includes upgrades, patches, and fixes, it is still a supply.  Even if it includes up to a certain number of service center calls.

For all these reasons, I choose to look on commercial software licenses as supplies rather than services.  

If if there is a third way, please share it.

So, you are saying that you are essentially purchasing a product or the rights to use the product, not the services to produce the product right?

ji20874:

I am on a train with unreliable wifi going to a remote place with even less reliable wifi, if any. I will respond, but it might take a few days. Please bear with me.

Vern

Service or Supply? – these might help.

https://dap.dau.mil/aap/pages/qdetails.aspx?cgiSubjectAreaID=14&cgiQuestionID=108481

http://www.gao.gov/assets/520/510646.pdf

And just because Jamaal proposed a great idea on how to solve the PSC question itself as posed by the OP…..confirms that 7030 as the correct code it appears.

https://www.gsaadvantage.gov/ref_text/GS35F0598S/0PDAL3.3A0VJT_GS-35F-0598S_ACESGSAPRICELISTMARCH102016.PDF

Joel,

For a commercial software license, the services to produce the software application have already been completed.  It's not so much that I insist that a software license must be called a supply (it is sort of an intangible supply), but rather, I most strenuously object to calling it a service and treating it as a service for FAR purposes.  Given our bi-modal scheme in the FAR, supply works better than service, and service simply doesn't fit at all.

In this thread, I am only discussing a license for already-existing commercial software -- I am not discussing situations where the Government contracts for software developers and coders and so forth, tasks them to develop software, and pays them by the hour.

Wow, interesting read!  Just for the record, it is commercial software without any software development.  The GSA contract is GS-35F-0598S.  Here is the price list, see IS-15.

ACES GSA pricelist IdeaScale April 21 2015.pdf

On March 24, 2016 at 9:41 AM, ji20874 said:

7030 works for me.  

A a software license is a supply, not a service.  Your order should set a delivery date, not a period of performance.

A question: Would PSC W070, "Lease or rental of equipment - Information technology equipment (Including firmware), software, supplies, and support equipment" work for you? If not, why not?

I could find no official guidance on the use of W070.

I've found several FBO notices about software license renewals that were categorized as D, "Information technology services, including telecommunication services." Here's a  link to one posted by DOD's Washington Headquarters Services for license renewals: https://www.fbo.gov/?s=opportunity&mode=form&id=21c0fe1483c8506fc7daa26527d9d810&tab=core&_cview=0.

Well, we usually think in terms of buying a license, not leasing a license.

Isn't a software license just a kind of lease? You're acquiring the right to use the software for a specified period. Right?

If calling it a lease means we have to do complicated lease-versus-purchase computations, then I don't want to call it a lease.  Besides, I don't think industry will accept us calling it a lease.  But if it is a lease, then it is necessarily a supply rather than a service, right?

Note:  I understand that software leasing does occur in the commercial marketplace...

ji20874:

You're not going to have to do a lease versus purchase analysis, and the industry is not going to care what you call it for government purposes as long as they get their terms.

FAR 12.212 tells us to acquire commercial software under the terms of commercial licenses unless those terms are inconsistent with Federal law. FAR 27.405-3 prescribes a clause to use "when there is any confusion" in that regard.

I don't think there is any need to declare the acquisition of a license either a supply or a service, except for purposes of FBO and FPDS and maybe some agency contract writing software. I can't say anything about the contract writing software, because I don't use the stuff. As for FBO and FPDS is appears to me that agencies are using all kinds of PSC codes, not just 7030. The confusion is probably due in part to the fact that GSA develops the services codes and DLA  develops the supply codes, and they are not mutually exclusive. The fact that DLA develops the supply codes suggests to me that they are thinking in terms of tangible items, not stuff like software, but I don't know.

This strikes me as an area in which the rules are inconsistent and non-determinative. I think a CO can put an acquisition of software licenses into whatever category he or she wants to as long the category isn't nonsensical.

Just for fun, I'll say that when you use a company's software you are hiring the company to provide information processing services as performed by a surrogate employee (the software) using GFP (the computer). It's like having a contractor employee in the cubicle next to you, doing what you tell him or her ("it") to do. It's not really the software that you care about, it's the quality of the output.

The product service codes (PSC) manual is managed by GSA.  It is used to describe products, services, and research and development purchased by the government.  While PSC codes are used for other means (e.g. FBO notices), it is primarily used for coding transactions in FPDS.  While one should endeavor to select the correct code to help ensure data in reports are correct, I don’t think selecting the wrong one is of significant consequence.  Unlike a NAICS code (when using small business set-asides), a PSC doesn’t have any impact on the solicitation.

https://www.acquisition.gov/?q=Acquisition_Systems and https://www.federalregister.gov/articles/2015/05/28/2015-12891/federal-procurement-data-system-product-service-code-manual-update

Having said that, it appears that 7030 (Information Technology Software) would be a good code to use if one is simply purchasing software that is not being developed, designed to Government unique specifications, or include other supporting services. 

The notes section of 7030 (product) states:

“Notes Software is a series of instructions or statements in a form acceptable to a CPU, designed to cause the Information Technology Equipment or Automated Data Processing Equipment configuration to execute an operation or operations; or a collection of data in a form capable of being processed and operated on by a computer.  Includes: System programs, such as operating systems, assemblers, compilers, executive routines, interpreters, translators; utility programs, such as sort/merge programs, media conversion, maintenance diagnostic programs; and application programs, such as payroll, inventory control, and engineering analysis programs.

Excludes: Software designed to Government specifications to satisfy the requirements of a particular user or for use with ADPE properly classifiable in an FSG other than FSG 70. Also excludes operating manuals and programmers' manuals properly classified in FSG 76.”

Code D318 (service)

“IT and Telecom- Integrated Hardware/Software/Services Solutions, Predominantly Services

Includes: Contracts Buying Hardware, Software, and Related Services, Where Services Are The Predominant Portion of The Contract Value”

The author of the manual (GSA) would probably be the most appropriate organization to advise on which code is the most appropriate.  However, I don’t know that it is worth pursuing for the reason stated above.

While not applicable to PSCs, NAICS code definitions may be helpful to determine how best to classify a software purchase (manufacturer of a product vs service provider).   

Manufacturing

334614  Software, packaged, mass reproducing

NAICS definition.  This U.S. industry comprises establishments primarily engaged in mass reproducing computer software or other prerecorded audio and video material on magnetic or optical media, such as CD-ROMs, DVDs, tapes, or cartridges. These establishments do not generally develop any software or produce any audio or video content.

Information

511210  Software publishers (uses a revenue size standard which is typically used for service providers versus manufacturers)

NAICS definition.  This industry comprises establishments primarily engaged in computer software publishing or publishing and reproduction. Establishments in this industry carry out operations necessary for producing and distributing computer software, such as designing, providing documentation, assisting in installation, and providing support services to software purchasers. These establishments may design, develop, and publish, or publish only. (From U.S. Census Bureau website http://www.census.gov/cgi-bin/sssd/naics/naicsrch?code=511210&search=2012 NAICS Search)

Services

541511  Software analysis and design services, custom computer

NAICS definition.  This U.S. industry comprises establishments primarily engaged in writing, modifying, testing, and supporting software to meet the needs of a particular customer.

541512  Computer software consulting services or consultants

NAICS definition.  This U.S. industry comprises establishments primarily engaged in planning and designing computer systems that integrate computer hardware, software, and communication technologies. The hardware and software components of the system may be provided by this establishment or company as part of integrated services or may be provided by third parties or vendors. These establishments often install the system and train and support users of the system.

541519  Software installation services, computer;

Note from SBA Size Standard Manual “NAICS code 541519 – An Information Technology Value Added Reseller (ITVAR) provides a total solution to information technology acquisitions by providing multi-vendor hardware and software along with significant value added services…” (additional text in SBA size standard table).

Unless services are the predominate portion of the contract value, I would use 7030 to acquire the right to use an existing software product (intellectual property).  While software may not be “personal property”, that is transportable, it is still property and a product sold for authorized use.  Also, unless some sort of additional services are being acquired with the software, it may or may not classify as a service for which the Service Contract Labor Standards statues apply (see DOL Field Handbook http://www.dol.gov/whd/FOH/FOH_Ch14.pdf).

For what it’s worth, I would also use NAICS 511210, which is neither in a manufacturing or services NAICS code series, but rather the “information” series.

I don't care about NAICS codes. They categorize industries, not products and services. To the extent that they tell us anything, they tell us something about the groups we buy buy things from, not about the nature of the things we buy.

Vern Edwards said:

Isn't a software license just a kind of lease? You're acquiring the right to use the software for a specified period. Right?

It depends on the specific software.  Some (most) software licenses are perpetual.  Some software licenses are term licenses.

1.  Where is the software? 

2.  Is it on the cloud? 

3.  Is there a license being acquired or are you acquiring something from an owner's cloud?

We need to keep the conversation contained -- we're talking about commercial software, already developed at contractor expense, for which the Government seeks a license.

It's pretty well known that it's a service if the software is in the cloud. GSA has a special service code for that. See also DFARS Subpart 227.

Vern Edwards said:

*snip*

Just for fun, I'll say that when you use a company's software you are hiring the company to provide information processing services as performed by a surrogate employee (the software) using GFP (the computer). It's like having a contractor employee in the cubicle next to you, doing what you tell him or her ("it") to do. It's not really the software that you care about, it's the quality of the output.

Am I using a multifunction copier as a contractor's surrogate employee to make copies?

Am I using a claw hammer as a contractor's surrogate employee to pound nails into wood?

Am I using a commissioned portrait of myself as a contractor's surrogate employee to secure my ostentatiousness?

(EDIT on the last one): That is, once the portrait is complete and hanging up over my fireplace.

Quote

Am I using a multifunction copier as a contractor's surrogate employee to make copies?

No.

Quote

Am I using a claw hammer as a contractor's surrogate employee to pound nails into wood?

No.

Quote

Am I using a commissioned portrait of myself as a contractor's surrogate employee to secure my ostentatiousness?

No.

Vern Edwards said:

No.

No.

No.

How is software any different, keeping in line with your argument that software is like having a surrogate employee perform work?

Quote

How is software any different, keeping in line with your argument that software is like having a surrogate employee perform work?

1. Software is not tangible. It is information. The only reason we're having this discussion is that there is some disparity in the way that agencies categorize software license acquisitions. As I showed in an earlier post, some agencies categorize such acquisitions as services, some as supplies. We're trying to think of how best to resolve that issue. No such disparity exists with regard to tangible items like copiers (leasing copiers is a service; purchasing them is supplies), hammers, and portraits.

The medium (disk) on which software may be provided to a user, while tangible, is not the object of the purchase. It is merely the means of delivery. Think of it as a shipping container. The software exists independently of such media, which is why the cloud is increasingly used. Who needs a disk?

2. While a copier makes a copy automatically, needing only input, it is a tangible thing. There is no question as to its status as an item of supply. It's not a good analogy for that reason.

3. A hammer is also a poor analogy, both for the reason given in 2, above, and because it cannot drive a nail without the full-time active participation of the user. Software requires only input. It processes data by itself. You know -- automatic data processing.

3. I frankly don't understand your portrait analogy. It seems entirely off the mark to me. I just don't get it.

Appears to be a "gray area" to me😄 See recent discussion...

It is! It is a gray area!  That's why we can have fun with it.  Brain exercise. They want us to think outside the box. Innovate. We can do that here.

I always thought of software as instructions more than information.  It instructs your computer to perform the physical task of shooting photons at your eyeballs.

Here's an analogy: Sheet music is instructions to a musician to perform certain physical actions.  The paper the sheet music is printed on is the physical container for the instructions.  I'd still have to pay Boosey & Hawkes if I perform their music from memory, though.

Don't know where I'm going with this, or if this analogy is useful.  Is sheet music a supply?  I think it is.   The musician's time and effort is a service. The *sound* that comes out of the musician is the end product, though.  What is that?

Sometimes the musician is a robot (or synthesizer) and the service aspect is removed.

(Sheet music is almost exclusively black and white.  Rarely gray.  Or grey.)

Vern Edwards said:

1. Software is not tangible. It is information. The only reason we're having this discussion is that there is some disparity in the way that agencies categorize software license acquisitions. As I showed in an earlier post, some agencies categorize such acquisitions as services, some as supplies. We're trying to think of how best to resolve that issue. No such disparity exists with regard to tangible items like copiers (leasing copiers is a service; purchasing them is supplies), hammers, and portraits.

The medium (disk) on which software may be provided to a user, while tangible, is not the object of the purchase. It is merely the means of delivery. Think of it as a shipping container. The software exists independently of such media, which is why the cloud is increasingly used. Who needs a disk?

2. While a copier makes a copy automatically, needing only input, it is a tangible thing. There is no question as to its status as an item of supply. It's not a good analogy for that reason.

3. A hammer is also a poor analogy, both for the reason given in 2, above, and because it cannot drive a nail without the full-time active participation of the user. Software requires only input. It processes data by itself. You know -- automatic data processing.

3. I frankly don't understand your portrait analogy. It seems entirely off the mark to me. I just don't get it.

The purpose of the portrait analogy is to argue using an example of something that the value (and thus function) of some *thing* (that is, the painting is a *thing* I can touch) can be intangible, yet that value (and thus function) still lingers once it leaves the possession of its producer. I concede my analogy is sloppy, but trying to argue how commercial software licenses would be always best labeled as a supply is difficult.

The physical tangibility of the medium is irrelevant. I use a key to open my front door, and that key needs to hold certain information in order to provide the desired outcome (the door locking or unlocking).

The functionality of a license key indistinguishable from a physical key; when you are purchasing commercial software, you are purchasing a digital key.

Quote

The purpose of the portrait analogy is to argue using an example of something that the value (and thus function) of some *thing* (that is, the painting is a *thing* I can touch) can be intangible, yet that value (and thus function) still lingers once it leaves the possession of its producer. I concede my analogy is sloppy, but trying to argue how commercial software licenses would be always best labeled as a supply is difficult.

What?! Honestly, Jason, that first sentence is simply awful. Let's not linger on it. Let's put it behind us. Let's just go directly to your concession and leave it at that.

Quote

The physical tangibility of the medium is irrelevant.

What's your point? I don't see an argument. So what that you think tangibility is irrelevant? You're entitled to your opinion, but the mere fact that you hold that opinion isn't persuasive of anything, even if I knew what it is you are trying to persuade me of. Declare whatever you want to be irrelevant. A declaration is just that. It's not an argument.

Quote

The functionality of a license key indistinguishable [sic] from a physical key; when you are purchasing commercial software, you are purchasing a digital key.

Wrong on the facts. When you purchase a software license you purchase permission to use the software in certain ways. The digital key is just a mechanism that gives you access to what you've purchased permission to use.

Software is covered by copyright and can be thought of as text, as that is what it is.  The fact that information can be input and different information is output doesn't make it any more a service than a calculator (which will output information after you input).

Software is a product just like a manufactured supply.  Contractor personnel labor to produce the end product.

Software leases grant use of the product for a period of time just as if we're buying the use of other supply products for a period of time (e.g. cars, equipment, hotel rooms).

Software and software leases are supplies.

Quote

Software leases grant use of the product for a period of time just as if we're buying the use of other supply products for a period of time (e.g. cars, equipment, hotel rooms).

Emphasis added.

Where did you get your information? According to the PSC Manual, renting (leasing) equipment is a service, Category W. Lodging, Hotel/Motel, is a service, Code V231. (Do you really think hotel rooms are supplies? Really? They're real property. See the definition of supplies in FAR 2.101.)

Quote

The fact that information can be input and different information is output doesn't make it any more a service than a calculator (which will output information after you input).

When you buy a calculator you buy a tangible object in which software is embedded. We're not talking about embedded software. Bad analogy.

Think of a software license as a performance-based service contract. You get the license so that the software can work automatically in order to produce a given result or output.

Assert and insist all you want, but it takes more than that. Assertion and insistence is not argument. Come back at me after you've done at least some research. I'm not going to surrender to an unarmed opponent.

FAR 8.1104 Contract clauses directs the inclusion of certain FAR clauses in solicitations and contracts for leasing of motor vehicles.  Specifically, FAR 8.1104(e) directs the K.O. to insert "The provisions and clauses prescribed elsewhere in the FAR for solicitations and contracts for supplies when a fixed-price contract is contemplated..."

One could argue that if fixed price vehicle lease contracts are supposed to be treated as supply contracts, it would be appropriate to treat other equipment lease contracts similarly.  In the alternative, one could argue that equipment leases are generally treated as service contracts, and that is why the FAR explicitly directs use of supply clauses in this case.

In addition, I found this from Leonardo Manning, Director, DAU Center for Contracting:

https://dap.dau.mil/career/cont/blogs/archive/2014/02/10/is-your-acquisition-a-supply-or-a-service.aspx

" Put simply, a commodity or supply is an item that the customer (the Government) can touch or hold in its hands. FAR Part 2 defines supply items as"...all property except land or interest in land..." It does not matter whether the items are owned or leased by the Government."

Personally, I think treating a lease of equipment as a supply makes more sense, but there seems to be plenty of conflicting info and guidance out there.

Lionel Hutz said:

FAR 8.1104 Contract clauses directs the inclusion of certain FAR clauses in solicitations and contracts for leasing of motor vehicles.  Specifically, FAR 8.1104(e) directs the K.O. to insert "The provisions and clauses prescribed elsewhere in the FAR for solicitations and contracts for supplies when a fixed-price contract is contemplated..."

One could argue that if fixed price vehicle lease contracts are supposed to be treated as supply contracts, it would be appropriate to treat other equipment lease contracts similarly.  In the alternative, one could argue that equipment leases are generally treated as service contracts, and that is why the FAR explicitly directs use of supply clauses in this case.

In addition, I found this from Leonardo Manning, Director, DAU Center for Contracting:

https://dap.dau.mil/career/cont/blogs/archive/2014/02/10/is-your-acquisition-a-supply-or-a-service.aspx

" Put simply, a commodity or supply is an item that the customer (the Government) can touch or hold in its hands. FAR Part 2 defines supply items as"...all property except land or interest in land..." It does not matter whether the items are owned or leased by the Government."

Personally, I think treating a lease of equipment as a supply makes more sense, but there seems to be plenty of conflicting info and guidance out there.

I think Vern's argument focuses on the fact that a vehicle is a tangible thing whereas software is not.

In an effort to determine if a purchase of existing software is generally considered as a purchase of "goods" or "a service" in business law, I searched Google.com using the key phrase: "is software purchase under ucc article 2 goods".  This article addresses the issue from the legal perspective:

https://www.uakron.edu/dotAsset/ca5ba1c1-239f-47a3-b4a9-4729c5304fb1.pdf

i had earlier gone down the sales tax rabbit hole, in an effort to see if software purchases are generally taxed as goods or exempt from sales taxes as services.  There is too much inconsistency between tax jurisdictions these days to use sales taxes as a qualifier to establish a commercial software purchase as an example of buying supplies (outside of The Federal acquisition system).

I haven't read it yet, but note that the article that Joel has provided is dated 1987 and is almost 30 years old. A lot can happen in courts over the course of 30 years, especially with respect to topics as dynamic as information technology and intellectual property. Don't get too excited, one way or another.

Vern Edwards said:

I haven't read it yet, but keep in mind that the article that Joel has provided is dated 1987 and is almost 30 years old. A lot can happen in courts over the course of 30 years, especially when dealing with topics as dynamic as information technology and intellectual property. Don't get too excited, one way or another, until someone checks the current state of the law.

I forgot to check the date of the article.  

I know that a lot of changes have occurred in the taxing jurisdictions as they dig deeper into our pockets to ever expand what they can tax.  

As Vern said, a lot can happen over 30 years in the area of business law.

Examples of more contemporary articles include: "The Undue Reliance on Physical Objects in the Regulation of Information Products," by Pascale Chapdelaine," in Journal of Technology Law & Policy (June 2015), 20 J. Tech. L. & Pol'y 65 and "Installation Failure: How the Predominant Purpose Test Has Perpetuated Software's Uncertain Legal Status Under the Uniform Commercial Code," by Spencer Gottlieb, in Michigan Law Review (March 2015), 113 Mich. L. Rev. 739. Unfortunately, copyright prevents me from providing copies to everyone. However, the dates on the articles show that this continues to be an issue.

I also remind everyone that the government categorizes acquisitions for at least three related, but not entirely common reasons: (1) to determine what laws and policies apply, (2) to determine what boilerplate contract clauses to use, and (3) for record-keeping purposes. As far as I can tell there is no common and internally consistent system of classification for all three purposes. For example, the definition of "supplies" in FAR 2.101 includes alteration and installation of supplies, and for years contracting personnel have debated whether elevator maintenance and painting were services or construction.

You can download a copy of "The Undue Reliance on Physical Objects in the Regulation of Information Products, by Pascale Chapdelaine" from SSRN.com.  I think it is kosher to excerpt a small passage from it (I added the emphasis):

Quote

The peculiarity of the requirement of a physical object for information products to qualify as goods is even more apparent when contrasted to how other areas of law deal with the immateriality of copies of information products. For instance, international classifications (e.g., in the area of trademarks), classify software as goods regardless of the presence of a supporting tangible medium. In the United States, the Copyright Act defines "copy" as: "material objects . . . from which the work can be perceived . . . either directly or with the aid of a machine . . . ."** If "copy" was defined narrowly (i.e., as requiring the form of a material object (book, CD, DVD)), innumerable unauthorized copies would not be deemed to infringe copyright.** Pointing to the U.S. Copyright Act definition of "copy" as including "immaterial" machine-readable copies, Jean Braucher notes the incongruity that results from not also treating copies of software as goods under sale of goods law: "There is no good reason not to extend this version of tangibility, assuming tangibility is necessary, to the realm of Article 2." "Software copies are perceivable by a machine and in that sense tangible, making them easily ‘things,’ which may not require tangibility."

It's clever to point out the double standard.  Software operated from the cloud or downloaded without a physical object shoots the same photons into your eyes as the software that is installed with a physical CD.  The author notes that we get this when it comes to copyright, but not with software.  I like the argument, too bad it may not be a winning one yet.

I won't link to SSRN since there is some advertising there.  If you want to read more, though, it's free to set up an account and you can create a "briefcase" which is a list of articles you won't get around to reading. If you are curious about anything whatsoever, it's worth setting up an account.

Just Google the title. You can get the second one the same way.

My bad. I should have thought of Googling.

Vern Edwards said:

What?! Honestly, Jason, that first sentence is simply awful. Let's not linger on it. Let's put it behind us. Let's just go directly to your concession and leave it at that.

What's your point? I don't see an argument. So what that you think tangibility is irrelevant? You're entitled to your opinion, but the mere fact that you hold that opinion isn't persuasive of anything, even if I knew what it is you are trying to persuade me of. Declare whatever you want to be irrelevant. A declaration is just that. It's not an argument.

Wrong on the facts. When you purchase a software license you purchase permission to use the software in certain ways. The digital key is just a mechanism that gives you access to what you've purchased permission to use.

I don't see how a line can be drawn between purchasing (licensing) the software and being granted permission to use that software. The digital key represents delivery of the supply. If you can't access what you've bought, you can't take acceptance of it. Until you hold the key, the seller has not provided you anything of use.

Some especially high-value software uses dongles as a security measure to protect the software from unauthorized distribution. The dongle is a literal key which must be plugged into the computer for the software to work. The software relatively is easy to come by; the key is what makes the software work.

P1. Software license keys exist in both physical (tangible) and non-physical (intangible) forms.

P2. The seller of the licensed software controls distribution of the license keys.

P3. Licensed software is useless without the appropriate license key.

P4. An end user cannot accept delivery of the licensed software without delivery of the appropriate license key.

C1: (P2, P3, P4)Therefore, delivery (and acceptance, as appropriate) of a licensed software's appropriate license key constitutes delivery (and acceptance, as appropriate) of the licensed software.

C2: (P1, P4) Therefore, whether the license key is tangible or intangible is irrelevant to delivery of the licensed software.

EDIT: Cleaned up phrasing calling software "licensed software".

EDIT 2: Attempted to clarify C1.

Jason:

???

What bearing does the argument in your last post have on the topic at hand? I mean, you can talk about whatever you like, of course, and you're entitled to your opinion about what you choose to talk about, but I'm not interested in the tangibility or intangibility of digital keys. The question thus far has been whether, in the context of government contracting, a software license is (a) a supply item, (b) a service, or (c) neither. Even if your conclusions were true, what bearing would they have on that issue?

Vern Edwards said:

I also remind everyone that the government categorizes acquisitions for at least three related, but not entirely common reasons: (1) to determine what laws and policies apply, (2) to determine what boilerplate contract clauses to use, and (3) for record-keeping purposes. As far as I can tell there is no common and internally consistent system of classification for all three purposes. For example, the definition of "supplies" in FAR 2.101 includes alteration and installation of supplies, and for years contracting personnel have debated whether elevator maintenance and painting were services or construction.

Right. We need to know the purpose of the classification before we can classify. There is no universal classification system. The response to the question "is software a supply or a service?" should be "for what purpose are you classifying it?"

From the OP is seems that the objective was to classify it for purposes of synopsis and to determine what PSC to use. My own checks at FBO showed me that different people used different classifications. Those choices were not necessarily arbitrary, but I don't know how to determine how the choices were made.

On Monday, April 04, 2016 at 1:33 PM, Vern Edwards said:

This strikes me as an area in which the rules are inconsistent and non-determinative. I think a CO can put an acquisition of software licenses into whatever category he or she wants to as long the category isn't nonsensical.

I'm okay with this thought.  As for me an my house, so to speak, we will pick supply.

On Monday, April 04, 2016 at 1:33 PM, Vern Edwards said:

Just for fun, I'll say that when you use a company's software you are hiring the company to provide information processing services as performed by a surrogate employee (the software) using GFP (the computer). It's like having a contractor employee in the cubicle next to you, doing what you tell him or her ("it") to do.

I'll play.  Does this mean that when buying a washing machine, I would be hiring the company to provide clothes-washing services as performed by a surrogate employee (the washing machine) using GFP (my soap, water, and electricity)?

Quote

I also remind everyone that the government categorizes acquisitions for at least three related, but not entirely common reasons: (1) to determine what laws and policies apply, (2) to determine what boilerplate contract clauses to use, and (3) for record-keeping purposes. As far as I can tell there is no common and internally consistent system of classification for all three purposes. For example, the definition of "supplies" in FAR 2.101 includes alteration and installation of supplies, and for years contracting personnel have debated whether elevator maintenance and painting were services or construction.

Another reason to add to the list is to help notify potential offerors who register to receive e-mails from FBO.

ji20874 said:

I'll play.  Does this mean that when buying a washing machine, I would be hiring the company to provide clothes-washing services as performed by a surrogate employee (the washing machine) using GFP (my soap, water, and electricity)?

No. A washing machine is tangible property other than real property. If you buy one, you've clearly and indisputably bought an an item of supply as defined in FAR 2.101. It is not analogous to software, which is more like a hired mind. The analogy fails for that reason alone.

Software itself is intangible, which is the only reason we're having this discussion and which is the reason businesses and the courts struggle with the problem of the applicability of Article 2 of the U.C.C. The tangible disk on which software is recorded is not the software, so the fact that software is on a disk does not make it a tangible thing. What sense does it make to call the acquisition of a software license a supply contract because the software arrives on a disk? What matters most, the conformity of the disk to a specification or the functioning of the software? Saying you should inspect the disk would be like saying you should inspect janitorial services based on the condition of the van in which the janitors arrive.

If you go to a laundromat to use someone else's washing machine, almost everyone would say that you're receiving a service, even though you load the clothes yourself and use your own soap. Think of buying a license to use someone else's software is analogous to using someone else's washing machine, and even more analogous to contracting for the provision of a temporary employee.

All:

I have nothing more to add, so I'm moving on.

The bottom line for me is that the categories of supplies, services, construction, etc., are multipurpose, multifaceted, internally inconsistent, and, therefore, have vague boundaries.

I don't think software should be considered any category other than, well, software. The simple fact is that the definitions of "supplies" and of "service contracts" are very old, and the policymakers have been too passive or lazy to revisit them as industries and markets have changed and to revise them or add new ones as needed. The result is disparate outcomes as people try to put new wine into old wineskins. It we had energetic, proactive, and knowledgable people making policy at the top, we'd have better polices, regulations, and outcomes at all levels.

I have enjoyed this discussion. It's been fun. I thank everyone who has participated. Please continue to enjoy yourselves.

Vern

I think the NAICS designation is important - if it is a supply the non-manufacture rule may apply and if it is a service the limitation of subcontracting rule may apply.

I also think that the use of operational funds versus capital funds is important - with services being more aligned with operational funds. From industry, revenue recognition is important, anything that creates a future obligation may encumber the entire recognition of the revenue of the effort until the final obligation is performed. I am speaking of revenue not cash. Therefore, services need to be carefully crafted.

I would also like to know how DFARS 227 supports cloud software/computing as a service.

Sorry to revive an old thread. Something caught my eye on this discussion mentioned by "Whynot". In the example of cloud services (paid monthly for example Amazon Computing) would the NAICs have to be specific to a IT VAR such as 541519 or could 541512 work? Or would 541512 be considered just for services (Where contractors perform work)

I wouldn't let the appearance of the word "services" in the NAICS code title become the dispositive answer that the acquisition in question is for services.

On September 1, 2016 at 3:49 PM, ji20874 said:

I wouldn't let the appearance of the word "services" in the NAICS code title become the dispositive answer that the acquisition in question is for services.

Thanks. Good point