Category Archives: Uncategorized

Introducing Startups to the Crowd: The SEC’s “Regulation Crowdfunding”

As I discussed in a previous post last spring, startups and investors alike have been eagerly awaiting action by the  U.S. Securities and Exchange Commission (“SEC”) to promulgate rules to facilitate equity-based crowdfunding.  Well, alas, the SEC has proposed crowdfunding rules as mandated by the Jumpstart Our Business Startups Act (the “JOBS Act”).  The JOBS Act, enacted back in April of 2012, is intended to enable startups and small businesses to raise capital through crowdfunding. The public comment period is set for 90 days, which means that equity-based crowdfunding could become a reality in early 2014.

GPL
GPL

The text of the SEC’s notice of proposed rulemaking is an ambitious 585 pages.  Unlike the SEC, I value brevity.  So, after providing a quick refresher on crowdfunding and the Securities Act, the remainder of this post will discuss the key provisions that potential crowdfunding issuers (i.e., the startups) and investors (i.e., the crowd) may find interesting.   Specifically, I will point out a few key aspects of the long-awaited crowdsourcing rule’s requirements for exemption from the registration requirements of the Securities Act.

Background: Crowdfunding and the Securities Act

Currently, the only type of crowdfunding that is authorized in the US are those forms that do not involve the offer of a share in any financial returns or profits that the fundraiser may expect to generate from business activities financed through crowdfunding.  Examples of crowdfunding websites that have become mainstream include the likes of indiegogo and Kickstarter.  These platforms prohibit founders (the project starter) from offering to share profits with contributors (i.e., equity or security transactions) because such models would trigger the application of federal securities laws.  And, under the Securities Act, an offer and sale of securities must be registered unless an exemption is available.

However, newly created Section 4(a)(6) of the Security Act, as promulgated under the JOBS Act, provides an exemption (the “crowdfunding exemption”) from the registration requirements of Securities Act Section 5 for certain crowdfunding transactions.  With the introduction of this exemption, startups and small businesses will be able to raise capital by making relatively low dollar offerings of securities to “the crowd” without invoking the full regulatory burden that comes with issuing registered securities.  Additionally, the crowdfunding provisions create a new entity, referred to as a “funding portal”, to allow Internet-based platforms to facilitate the offer and sale of securities without having to register with the SEC as brokers.  Together these measures were intended to help small businesses raise capital while protecting investors from potential fraud.

Startups:  Limits on Amount Raised

The exemption from registration provided by Section 4(a)(6) is available to a U.S. startup (the issuer) provided that “the aggregate amount sold to all investors by the issuer, including any amount sold in reliance on the exemption provided under Section 4(a)(6) during the 12-month period preceding the date of such transaction, is not more than $1,000,000.”

In the proposed rule, the SEC clarifies that only the capital raised in reliance on the crowdfunding exemption should be counted toward the limitation.  In other words, all capital raised through other means will not be counted against the $1M sold in reliance on the crowdfunding exemption.  As the SEC stated in its notice of proposed rule:

“If an issuer sold $800,000 pursuant to the exemption provided in Regulation D during the preceding 12 months, this amount would not be aggregated in an issuer’s calculation to determine whether it had reached the maximum amount for purposes of Section 4(a)(6).”

Startups: Limits on the Method of Crowdfunding

Under Section 4(a)(6)(C), an offering seeking the crowdfunding exemption must be “conducted through a broker or funding portal that complies with the requirements of Section 4A(a).”  This means that crowdfunding can only occur through an intermediary, and that intermediary must meet the requirements of either (1) a broker, or (2) a funding portal. The SEC proposed two related limitations here:

1)      Single intermediary – Prohibits an issuer from using more than one intermediary to conduct an offering or concurrent offerings made in reliance on the crowdfunding exemption.  For example, you couldn’t use both FundMyStartUp.com and CrowdfundMyDreams.com for the same offering or even for different offerings when conducted concurrently.

2)      Online-only requirement – Requires that an intermediary (i.e., the broker or funding portal) effect crowdfunding transactions exclusively through an intermediary’s platform. The term “platform” means “an Internet website or other similar electronic medium through which a registered broker or a registered funding portal acts as an intermediary in a transaction involving the offer or sale of securities in reliance on Section 4(a)(6).”

According to the SEC’s notice, with respect to the online-only requirement:

“We believe that an online-only requirement enables the public to access offering information and share information publicly in a way that will allow members of the crowd to decide whether or not to participate in the offering and fund the business or idea.  The proposed rules would accommodate other electronic media that currently exist or may develop in the future. For instance, applications for mobile communication devices, such as cell phones or smart phones, could be used to display offerings and to permit investors to make investment commitments.”

A Quick Note about Funding Portals

As mentioned above, to fit within the crowdfunding exemption, the offering must be conducted through a broker or funding portal that complies with the requirements of Securities Act Section 4A(a).

Exchange Act Section 3(a)(80) (added by Section 304 of the JOBS Act), defines the term “funding portal” as any person acting as an intermediary in a transaction involving the offer or sale of securities for the account of others, solely pursuant to Securities Act Section 4(a)(6), that does not: (1) offer investment advice or recommendations; (2) solicit purchases, sales or offers to buy the securities offered or displayed on its platform or portal; (3) compensate employees, agents or other person for such solicitation or based on the sale of securities displayed or referenced on its platform or portal; (4) hold, manage, possess or otherwise handle investor funds or securities; or (5) engage in such other activities as the Commission, by rule, determines appropriate.”

Under the SEC’s proposed rules, the definition of “funding portal” is exactly the same as the statutory definition, except the word “broker” is substituted for the word “person”.  The SEC is making clear that funding portals are brokers (albeit a subset of brokers) under the federal securities laws.

Investors: Limits on Amount Invested

Under Section 4(a)(6)(B), the aggregate amount sold to any investor by an issuer, including any amount sold in reliance on the exemption during the 12-month period preceding the date of such transaction, cannot exceed: “(i) the greater of $2,000 or 5 percent of the annual income or net worth of such investor, as applicable, if either the annual income or the net worth of the investor is less than $100,000; and (ii) 10 percent of the annual income or net worth of such investor, as applicable, not to exceed a maximum aggregate amount sold of $100,000, if either the annual income or net worth of the investor is equal to or more than $100,000.”

Because the statutory definition above creates some potential ambiguity, the SEC’s rule seeks to clarify the relationship between annual income and net worth for purposes of determining the applicable investor limitation.  Essentially, the proposed rules take a “whichever is greater” method for measuring whether limitation (i) or (ii) applies.  As the rule proposes,

  • Where both annual income and net worth are less than $100,000, then the limitation will be set at the greater of (a) $2,000 or (b) the greater of (x) $5% of annual income or (y) 5% of net worth.
  • Where either annual income or net worth exceeds $100,000, then the limitation will be set at the greater of (a) 10% of annual income or (b) net worth; provided, however, in either case (a) or (b) may not exceed $100,000.

Related to investor limits, but more important for startups to understand, the proposed rules alleviate burdens associated with vetting investor suitability.  Specifically, the rule allows startups to reasonably rely on the efforts that the intermediary takes in order to determine that the amount purchased by an investor will not cause the investor to exceed investor limits.

DiOS Mio! Apple’s License for Internal Apps (Part 2 of 3)

In this second part of the three-part post discussing the Apple iOS Developer Enterprise Program (the “Program”), I will continue by describing the terms of Apple’s iOS Developer Program Enterprise License Agreement (the “License”) that specifically govern the apps developed from the Apple Software.  Where Part 1 was limited to the rights and restrictions as they relate to the use of Apple Software, this Part 2 focuses on the rights and restrictions as they relate to the use of Internal Apps.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s (i.e., the “Licensee’s”) employees.

Attribution: Zacfranks
Attribution: Zacfranks
Note: Yes, I am aware that this is an Android App :)

As I mentioned in Part 1, the Licensee retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Nevertheless, the Licensee should be well advised that Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including the Internal Apps.  This means that Apple may use and freely disclose any such information on an unrestricted basis without notifying the Licensee.

APIs and Functionality

The following are requirements that a Licensee’s Internal Apps must adhere to with respect to Application Programming Interfaces (APIs) and functionality.

  • Internal Apps may use documented APIs only in the manner prescribed by Apple
  • Internal Apps must not use or call any private APIs
  • Internal Apps must not download or install executable code
  • Internal Apps must not facilitate commerce, credits, or purchases of any kind
  • Internal Apps may only read data from, or write data to, the Internal App’s designated container area on the device
  • Internal Apps must have at least the same features and functionality when run by a user in compatibility mode on an iPad, except where any feature or functionality is not supported by a particular hardware device
  • Internal Apps must comply with Apple’s Human Interface Guidelines

Data & Privacy

Under the License, a company’s Internal Apps may not collect user or device data without prior end-user (i.e., employees’) consent.  This consent requirement means the Licensee must provide clear notice to users regarding the company’s collection, use, and disclosure of user or device data.  Further, even where consent is obtained, the data collected can only be used to provide a service or function that is directly relevant to the use of the Internal App.  Under no circumstances, can a Licensee use analytics software in their Internal Apps to collect and send device data to a third party.  Additionally, the Licensee must take appropriate steps to protect such data from unauthorized use, disclosure, or access by third parties.  If a user ceases to consent or affirmatively revokes consent for the Internal App’s collection, use, or disclosure of his or her user or device data, the Licensee must promptly cease all such use.  In other words, the company must provide its employees with an opt-out mechanism.

Internal Apps that offer location-based services or functionality must notify and obtain consent from an end-user before his or her location data is collected, transmitted, or otherwise used by the Internal App.  If such Internal App uses location-based APIs to provide real-time navigation, the Licensee must have an end-user license agreement (e.g., a Terms of Service) that includes the following notice: YOUR USE OF THIS REAL TIME ROUTE GUIDANCE APPLICATION IS AT YOUR SOLE RISK. LOCATION DATA MAY NOT BE ACCURATE.

If the Licensee develops Internal Apps that collect or record images, pictures, or voice content (collectively “Recordings”), then the company must comply with all applicable privacy laws and regulations.  Depending on the type of Recording and the intended use of such Recording, this may require notice be provided and/or consent be obtained from employees; as, for example, consent to use the employees’ likeness or image, to the extent the Internal App contains photo-capture functionality.  In addition, per the License, a company’s Internal Apps must display an obvious audio, visual, or other indicator to the end-user as part of any Internal App that is making an active Recording.

Specific Types of Content

All content used within the Licensee’s Internal Apps must either be owned by the company, or properly licensed by the company from the content owner.  If the company’s Internal Apps allow employees to send SMS messages, then the company must inform its employees, prior to their use of such functionality, that standard text messaging rates or other carrier charges may apply.  Internal Apps may include sweepstake or contest functionality; however, the Licensee must be named as the sole sponsor of the promotion.

Security

The Licensee is responsible for preventing any unauthorized person from having access to Provisioning Profiles, digital certificates, and corresponding private keys.  Additionally, the Licensee must immediately notify Apple in writing if it has any reason to believe there has been a compromise of any Provisioning Profiles, digital certificates, or corresponding private keys.  The Licensee cannot provide or transfer Apple-issued digital certificates or Provisioning Profiles provided under the Program to any third party, except for a third party who is developing an Internal App on the company’s behalf.

Additional Functionality

The following sections describe terms that are specific to certain services available with the Apple Software that may be used to develop additional functionality in connection with a Licensee’s Internal Apps.

  • APN (Apple Push Notification service) or Local Notifications

If the Licensee’s Internal Apps send Push Notifications via the APN or Local Notifications, the Licensee must first obtain end-user consent prior to receiving such notifications.  The company cannot disable or interfere with any Apple implemented consent panels or any Apple system preferences for enabling or disabling Notifications functionality.  If an employee’s consent to receive Push Notifications is denied or later withdrawn, the company may not send that employee any further Push Notifications.  As a condition to using the APN or delivering Local Notifications, the company may not transmit sensitive personal or confidential information belonging to an individual (e.g., a social security number, financial account or transactional information, or any information where the individual may have a reasonable expectation of secure transmission) as part of any such notification.  Any Push Notifications that the Licensee sends via the APN, may be transmitted across various public networks, in various forms of media.

  • Mobile Device Management (MDM) Service

Like the Internal Apps themselves, the Licensee’s use of the MDM Service is solely for its internal, in-house management of employees’ Deployment Devices.  Before a company can use the MDM Service, it must install an MDM Profile on each iOS Product that will be managed under the MDM Service.  Use of the MDM Service requires the Licensee to maintain a secure server to interact with Apple’s APN server.  As part of the MDM Service, Apple will provide the Licensee with the “MDM Protocol”, which must be treated as Apple’s Confidential Information.

Prior to installation of the MDM Profiles, the Licensee must provide notice to its employees that it will be able to interact with their Deployment Devices remotely.  Such interaction includes: inspecting, installing, or removing profiles; viewing which Internal Apps are installed; using secure erase functions; and, enforcing device passcodes.  All information that the Licensee obtains through the use of the MDM Service may only be used for the company’s internal information technology and device management purposes; such as, locking the device for security purposes, or remotely wiping a lost device.

  • iCloud Storage

The Licensee’s use of the iCloud Storage APIs and the iCloud service is governed by additional terms governing the iCloud service for software development and testing in connection with the Licensee’s Internal Apps.  Most importantly, the Licensee’s Internal Apps are only permitted to use the iCloud service and the iCloud Storage APIs for the purpose of (1) storage and retrieval of key value data (e.g., a list of stocks in a finance App) for Internal Apps, and (2) allowing its employees to access user-generated documents and files through the iCloud service.

  • Passbook

The Licensee’s development of Passes, and use of Pass IDs, must be in accordance with the terms of the License and the Additional Terms for Passes.  “Pass(es)” are one or more digital passes (e.g., movie tickets, coupons, loyalty reward vouchers, boarding passes, membership cards, etc.) developed by the company, under the company’s trademark or brand, and which are signed with the company’s Pass ID.  A “Pass ID” means the combination of an Apple-issued certificate and Push Application ID that is used to sign the company’s Passes and/or communicate with the APN.

The Licensee may only use the Pass ID for purposes of digitally signing Passes and/or for purposes of using the APN service with Passes.  The Licensee is limited to distributing Passes only to its employees for internal purposes.  Passes may only operate and be displayed in Passbook, which is Apple’s designated container area for the Pass, or through Passbook on the lock screen of an iOS Product.  Within the Passes, the Licensee must state its name and address, and the contact information to which any employee questions, complaints, or claims with respect to its Passes should be directed.  Apple reserves the right to review and approve or reject any Pass that the company intends to distribute for use by its employees.

  • Twitter

If the Licensee’s Internal Apps access the Twitter service through the Twitter API, such access is subject to Twitter’s terms of service (http://dev.twitter.com).

  • Address Book

If the Licensee’s Internal Apps access data from an employee’s Address Book through the Address Book API, then the Licensee must notify and obtain consent from the user before his or her Address Book data is accessed or used by the Internal App.

To be Continued…

In the third and final part of this three-part post, I will address the terms governing app deployment, as well as the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.  Stay tuned!