Login to MyACC
ACC Members

Not a Member?

The Association of Corporate Counsel (ACC) is the world's largest organization serving the professional and business interests of attorneys who practice in the legal departments of corporations, associations, nonprofits and other private-sector organizations around the globe.

Join ACC

This Wisdom of the Crowd, compiled from questions and responses posted on the Intellectual Property, IT, Privacy & eCommerce, and Small Law Departments eGroups*, addresses issues involving software license agreements and digital contracts in general. The issues discussed include:

I. Acceptance of Software License Agreements II. Requirement of Acceptance III. Click-Wrap Agreements

*(Permission was received from the ACC members quoted below prior to publishing their eGroup comments in this Wisdom of the Crowd resource.)

Rate this Wisdom of the Crowd

I. Acceptance of Software License Agreements


I am interested in hearing about how companies are asking customers to affirmatively accept license terms for software embedded into specialized hardware that does not have a display.

We are all aware of the "click to accept" software license terms on a computer, but the display permits showing the text of the license. We are also all aware of the license terms presented as a paper document with terms that recite that use or execution of the software is deemed to be acceptance.

Are there any creative ways to make a software license 1) available, 2) conspicuous and 3) affirmatively accepted without a click to accept or physical paper? Would a sticker on the device that would have to be broken before power on with a URL that points to a license qualify as affirmative acceptance of the terms? Any other ideas?

Wisdom of the Crowd

Response #1

    The key issue is the following: Does the hardware require registration for warranty or activation purposes? If so, the product could be shipped with directions to register/activate for warranty purposes via your website and they could be directed to the terms of the license agreement there in order to register/activate. I would assume since it is hardware there is some mechanism to communicate warranty terms that you could piggyback the legalese upon. 1

    Response #2

      I think one of your suggestions is one possible way to address and believe that it's a reasonable approach.

      For example, providing a sticker with a prominent disclosure that states, 'IMPORTANT NOTICE: OPENING AND USING THIS SOFTWARE IS YOUR ACCEPTANCE OF THE TERMS OF THIS SOFTWARE LICENSE', then pointing the customer to a URL for the full license (or other hard copy) so that a customer can review.

      In any event, I don't think there are any "perfect" solutions but think whatever is the most commercially reasonable will be deemed acceptable.

      I'm also guessing there's likely existing case law that defined how or when an end-user's conduct/actions was an implied 'Acceptance' of a software license and is probably more helpful with establishing guidelines. 2

      Response #3

        It's a very interesting question and in addition to the suggestions put forth, there are several other possibilities: requiring a negotiated agreement between the licensor and the end customer as a condition of allowing resale of the license by OEM manufacturer; licensor relying on the OEM manufacturer's agreement with the end user customer; OEM manufacturer including licensor's software terms in its agreement with end user customer.

        Very complex, fact dependent. 3

        Response #4

          For software included as part of an OEM hardware application, the OEM will have a EULA on their hardware application- so you should require certain substantially equivalent minimum terms be included as a sublicense in the OEM's end user license for the specialized hardware application. For example- there is third party software included as part of the product that is licensed not sold, may not be reverse engineered, title to the software is not passed to the sublicensee, etc. You don't want to set out the license terms for the OEM's application, just your software. Or if it is obvious who owns the software (ex. you're supporting the OEM's customers, it's co-branded with your logo, etc.) and it's best to do in your circumstances, write the full EULA for them as long it is clear it is just for your software, not for the application it runs on.

          Going back to method of acceptance for hardware- you have to cover this for both those who are buying directly from you and also indirectly through your channel. You could do stickers with the URL of where the EULA may also be found, reference where the URL is in your product manuals so the customer sees it when installing the product, have the link to the EULA appear in your sales quotes, purchase terms, and in your webstore so anyone purchasing it directly from you will see it. There is also the issue of hardware purchased by the end user through the channel, making it more difficult to ensure the end user sees the EULA since some channel partners do the installation in addition to making the purchase. You can require that the channel ensure the customer sees the EULA prior to purchase as part of the terms in your channel agreements (ex. as part of the channel marketing ensure the customer receives materials that also contain the URL) and also if you are supporting the customer directly, whether as first or second tier, you could require that the customer click accept the EULA prior to being able to receive support when they open the support ticket. If you require that your hardware products be registered by the customer in order to be covered by warranty, have the EULA agreed to at product registration. If the hardware application is an OEM's, any or all of these steps might be suggested as a way of accepting terms. 4

          II. Requirement of Acceptance


          I am curious why there is a perceived need to require an affirmative acceptance of a software license embedded into specialized hardware to begin with. By way of example, I have a smartphone. I didn't need to "click to agree" to run the OS that powers the smartness of my phone. Does your company sell specialized hardware that embeds someone else's software, and the someone else is the stickler about wanting affirmative proof of having clicked to accept?

          Wisdom of the Crowd

          Response #1

            I think the major difference is that software packages purchased "on line" are stand alone packages where the shrink-wrap license conditions spell out the terms required to avoid unauthorized use and unauthorized copying (although this can also be prevented through copyright actions). When you order embedded software, the software goes with the product, i.e. both are undissociable in that use of the product without the software and vice versa is impossible. The terms of software use are consequently embedded in the terms of equipment use (if any), no further acceptance notices are really required. 5

            Response #2

              It might be true that for simple phones you don't need to agree to a license, but I don't think it is for smartphones. E.g., you have to accept a license agreement if you have an iPhone.

              "Review the software license agreement, ensure I have read and agree to iPhone Software License Agreement is selected then click Continue."

              I haven't had an Android phone for a while but I'd be surprised if you could activate one without an explicit agreement to some kind of EULA from the hardware manufacturer.

              There are certainly devices with embedded software that don't require an affirmative acceptance of a license (e.g., your car), so this still might be a good question. I just don't think smartphones are the right example. 6

              Response #3

                The reason could be the difference in the licenses of the two operating systems on the phones- I think Android is licensed under Apache whereas iOS is closed/proprietary. 7

                III. Click-Wrap Agreements


                We are an online business. When our customers sign up for services, they agree to our "click-wrap" agreement (they click a box that says they have read and agree to our Master Services Agreement). However, we don't have any way of proving after-the-fact that they have actually clicked the box. Can anyone recommend a way that we can modify our process so that we can prove the customer's agreement to the MSA? I know we will never abandon the click-wrap procedure, but surely there must be some way to prove the customer clicked.

                Wisdom of the Crowd

                Response #1

                  Most sites that use "click-wrap" won't let you progress past the agreement screen unless you accept the agreement. If yours does that, don't you have a pretty strong prima facie case that a customer cannot have become a customer unless he or she clicked the box? 8

                  Response #2

                    And don't you have proof that they downloaded the software, and maybe proof that they have used it? Doesn't that constitute acceptance by use? 9

                    Response #3

                      You should also be able to set up the page and "Accept" button so that it records the IP address of the Acceptor and other unique identifying session information. It would take some forensics to tie back to a specific location or computer if it was ever really challenged, but together with the programmed inability to move forward without accepting, and the following business relationship with the entity you believe to have accepted, I think it builds a pretty strong case. 10

                      Response #4

                        I would work with your internal IT group or the company that created the click through software code. My thought would be that there should be a logging feature for this operation. You have either a name or a numerical indicator of who is accepting the click through and it should have a log function. Whether or not the logging function has been turned on would be a different question. If you don't have this functionality, it's time to request it as it should be very simple to develop. 11

                        1 Karen Barry Boyd, Attorney (Intellectual Property, Jan. 4, 2013). 2 Anonymous (Jan. 2013). 3 Rudy Guyon, OEM Alliances Attorney, McAfee, Inc. (IT, Privacy & eCommerce, Jan. 15, 2013). 4 Michelle Petrone-Fleming, In-House Counsel, Digium, Inc. (IT, Privacy & eCommerce, Jan. 17, 2013). 5 Erik Verbraeken, Senior Group Counsel, Johnson Controls, Inc. (Intellectual Property, Jan. 7, 2013). 6 David Munn, General Counsel, Pramanta Corporation (IT, Privacy & eCommerce, Jan. 17, 2013). 7 Michelle Petrone-Fleming, In-House Counsel, Digium, Inc. (IT, Privacy & eCommerce, Jan. 19, 2013). 8 Denis Quinlan, General Counsel, Calix, Inc. (Small Law Departments, Oct. 17, 2012). 9 Stuart Senescu, Attorney (Small Law Departments, Oct. 17, 2012). 10 Terry Fund, General Counsel, Accelerated Payment Technologies (Small Law Departments, Oct. 18, 2012). 11 John Bates, Contract Negotiations Manager, IT Strategic Sourcing & Vendor Management, U.S. Cellular (Small Law Departments, Oct. 18, 2012).

                        Published on February 15, 2013
                        Region: United States
                        The information in any resource collected in this virtual library should not be construed as legal advice or legal opinion on specific facts and should not be considered representative of the views of its authors, its sponsors, and/or ACC. These resources are not intended as a definitive statement on the subject addressed. Rather, they are intended to serve as a tool providing practical advice and references for the busy in-house practitioner and other readers.

                        This site uses cookies to store information on your computer. Some are essential to make our site work properly; others help us improve the user experience.

                        By using the site, you consent to the placement of these cookies. For more information, read our cookies policy and our privacy policy.