Insights from a Seasoned Startup Lawyer


Building a High Profile Web/Software Company

What Open Source License Should I Choose?

If you are developing a work that you want everybody to have the right to do anything they want to with, including using for a closed source work, then the most appropriate open source licenses are MIT, BSD and Apache.  If your work is a writing or artwork rather than software, then one of the Creative Commons licenses may be more appropriate, again affording full rights to create derivative works.

If you are creating a work that you want to always be open source, with no closed source derivative works, then the most appropriate open source licenses are GPL and APL.  AGPL provides more coverage if you work tends to reside on server / back-end.

Github put together a great site explaining the various open source licenses in more detail:  

SAFT not so SAFE? ... Cooley's SAFT framework takes some heat

Cooley's SAFT Framework presents a nice set of documentation for funding an ICO in two stages: (i) Sale of a right to future tokens to accredited investors; and (iii) once the application is developed, distribution of functional utility tokens to the SAFT investors and general sale to the public of these functional utility tokens.  The SAFT authors posit that a token that has immediate and actual utility on issuance (other than a share in profits or equity stake in the venture) is probably not a security.

In response, the Cardozo Law School Blockchain Project published a paper refuting some of the claims of the SAFT paper.  The criticism focuses on the SAFT suggestion that post-functional utility tokens are generally not securities - which the Cardozo authors suggest is a bright line test that goes too far.  They suggest that each token must be viewed with it's own facts and circumstances to determine if it is a security.  They go on to point out how some aspects of the SAFT framework can hurt and not help the positioning, and increase risks on certain sales.

As Marco Santori pointed out when he released it, the SAFT Framework was an invitation for discussion and not the final word on what is and what isn't a security.  We should expect feedback and possible some adjustment to SAFT to counter these new concerns.


Options for Hosting an ICO for a Security (Equity Token)

So you've considering an ICO of a token that may be considered a security. What are your options?

1.  Reg D - sell to Accredited Investors only, fairly easy to implement, no filing.  Can take a strict or self-certify approach to accreditation (most go for strict now).

2.  Reg A+ - allows Accredited Investors and general public, but the public is limited on how many shares they can buy (up to 10% of net worth). Reasonable effort and filing.

3.  IPO - anything else, if a security, is an IPO (without a market like the NYSE). There's significant filings and expense.

4.  Not sell to the US.  

Also consider that there are differing laws worldwide on what is and what is not a security and what you can sell to whom.

With all of these options, the tokens cannot be traded on a regular exchange like Bittrex or Kaken.  Groups are working on exchanges for Accredited Investors, but these exchanges may not produce the value of open exchanges.  There are also peer to peer exchanges - shady when it comes to equity tokens.

What's so Exciting about Blockchain?

Blockchain is the foundational technology that cryptocurrencies such a s Bitcoin are based on.  Blockchain supports a distributed ledger, meaning the records are stored redundantly across multiple servers.  The data is secured by public/private key encryption in a way that some of the data can be seen by all and some functions limited to the holder of the private key. 

Bitcoin may be the least interesting of Blockchain applications.  Bitcoin’s only function is to move the encrypted block from one place to another.  So if you hold the private key to a bit of Bitcoin, you can tell it to move to a new address, in the holder of the private key for that address now controls where it might move to next.  In that way, people control bits of code with exclusive control that can be verified by all and cannot be subverted (unless the owner’s keys are stolen outside the blockchain).

Where it gets interesting is with blockchain applications like Ethereum, which contain “smart contracts.”  These are not contracts in the legal sense, but bits of code that run inside the block to make it smarter than just ‘move from here to here.’  For example, if one could code an Ethereum token to say that if I give it 1 credit and you give it 1 credit, then it generates a random number from 1 to 100 and if it’s 1-50 I get both credits and if it’s 51-100 you get both credits – the credits being some valuable cryptocurrency like Ethereum itself.  Now this is gambling and illegal in the US, but it’s an interesting simple application of smart contract capabilities.

Now take an enterprise like AirBnB.  AirBnB stores properties and transactions on central servers and supports thousands of employees.  If you programmed a blockchain application (called a dApp for distributed application) to operate similarly, a host could list their property (with details and pictures) in this chain, and a renter could secure dates and even pay the host for the stay directly in the chain.  Instead of taking the 8% to 20% that AirBnB charges, the dApp would take a small processing fee (say 1% to 3%) with that much more going to the host.  Now there would be a loss of some services, such as insurance for guest incidents, but this could be handled by outside parties like insurance.

Consider a similar blockchain dApp for Uber.  With driverless cars, riders could book rides with the app, smart contracts could decide what cars to send where, and in a world of driverless cars they could respond automatically, and even decide to go for gas or a recharge when needed – all without the support of a traditional company.

Consider a government on blockchain.  Rather than send people to polls, citizens could vote through blockchain – passing laws by majority or whatever margin required – all on the chain immutably reflecting the laws passed by the community.

Certainly, there are downsides to the lack of human intervention – code gone awry, bad code exploited, keys stolen from digital wallets.  What happens if you deed Is recorded in blockchain and you lose the private key that controls it – so you lose your house?  If somebody steals your private key, can they walk in and claim ownership?  Certainly not – but these are issues yet to be addressed.

Blockchain also eases exchanges of value.  Services on blockchain (dApps) are raising money through Initial Coin Offerings (ICO’s) where they sell the tokens that fuel their dApps to investors that either want to use the application or want to hold the token with an expectation that it will rise in value.  Exchanges have been created where holders can trade these tokens and watch market conditions impacting the value.  Where these tokens are considered to have present utility value – meaning they can be used for some real function in an application, they are not generally considered securities and can be traded with anybody around the world without restriction in most jurisdictions.  ICO’s have raised more money in 2017 than VC’s have funded tech.  Of the 300 or so completed utility token sales to date, two raised over $200MM, five raised over $100MM, 25% over $10MM, and 60% over $1MM.  In post-sale trading, about half are trading above the initial sale price, many over 1,000% higher.  With all that promise, however, reports say that less than 20% of these tokens really have the utility, and concerns continue to be raised on meeting the promises claimed.

Regardless, it’s clear that blockchain is a disruptive technology that will change the fundamental nature of much of the internet.  Many client-server applications will move to blockchain as the next wave of disruptors seek to dethrone the Web 2.0 winners.  Once again there will be winners and losers.  The game is on!

Blockchain ICO's and Securities Regulation in the U.S.

On July 25, 2017, The Securities and Exchange Commission issued an investigative report cautioning market participants that Initial Coin Offerings may be subject to the requirements of U.S. securities laws.  The SEC left open whether a particular investment transaction involves the offer or sale of a security, which depends on "the facts and circumstances, including the economic realities of the transaction".

Today, Juan Batiz-Benet, Jesse Clayburgh, and Marco Santori, senior counsels in FinTech at the prominent Cooley law firm released a whitepaper entitled The SAFT Project: Toward a Compliant Token Sale Framework asserting that almost all pre-functional sales of utility tokens are securities, and most post-functional sales aren’t.  The paper further introduces The SAFT Forms, legaldocuments used to convey rights in tokens prior to the development of the tokens’ functionality. These forms provide a framework for sales of pre-functional utility tokens to accredited investors in the U.S.

Assuming SAFT is adopted as effective guidance, this is an important and helpful step in discerning what ICO's (often now called a Token Generation Event or TGE) are subject to U.S. securities which limit sale to accredited investors, or require public filings if sold to the general public.

SUMMARY  issuing a token in an ICO before that token has actual utility is likely a security and subject to U.S. securities law.  Issuing a token that has immediate and actual utility on issuance (other than a share in profits or equity stake in the venture) is probably not a security.  The SAFT forms are helpful legal documents for selling equity tokens and utility tokens that do not yet have utility.

For a more in-depth discussion of the SAFT Forms, check out Mark Santori's supporting article: Appcoin Law: ICOs the Right Way.

Open source for commercial software development: Handle with care

Over the last 10 years, open source has drastically transformed the way enterprises acquire and deploy software to support their operations. As general counsel for an open source and commercially licensed software company, I have been asked by hundreds of customers to review their use of open source software (OSS) and compliance with licensing terms. And as a former developer myself, I’ve gained unique insight into the implications of open source use by enterprises, both for internal applications and as embedded software in the products they license and sell.  

OSS is ubiquitous and offers many advantages for commercial software development, including speed of development at little or no cost — but introducing third party software also introduces risks.

Open Source and the Strings Attached
The right to use another’s software is governed by a legal license agreement. In the case of OSS, the author distributes their software under one of a number of licenses considered to be open source, each with it’s own set of terms and conditions. These licenses fit into two major categories: Permissive and Copyleft. With Permissive licenses, there are few terms and conditions. With Copyleft licenses, the terms and conditions tend to be more stringent and bind any derivative work to the same terms and conditions.

Protecting Commercial Works, Protecting Your Fees
Most dangerous is the inclusion of Copyleft OSS in a closed source product. Under the GNU General Public License (GPL), the most frequently used Copyleft license, anyone who distributes that code or a derivative work must make the source code for the entire derivative work available under the same terms as the GPL license. Most commercial applications are developed on the premise that the source is closed and paid for. Requiring the release of source for free redistribution can be financially devastating for a commercial product.

Even Permissive open source licenses have requirements, such as retaining the copyright notices and providing prominent notice if the source has been changed (Apache). Failure to comply does not force the disclosure of source, but it could give rise to a claim of copyright infringement where the terms of the license are not followed.

Hidden Risks
There are often hidden risks associated with OSS packages. GPL code buried deep in software could give rise to a demand that you release your source code. When using larger packages, be sure to check not only the license for that package, but for all the included software.

If you use OSS from a project that is developed by a large pool of contributors, there may be little control over the source contributions. The larger the codebase, the larger the potential for problems. Risks include (1) contributors without a signed Contributor License Agreement (CLA), (2) contributors without permission from their employer to make a contribution; and (3) contributors who introduce code they’ve taken from elsewhere.

Quality Risks
Be sure to check the quality of an OSS package. Many projects may be good starting points, but are not “ready for prime time” for enterprise applications. OSS may be created by a developer or group of developers as a side project, without the same level of rigor and attention to quality as a commercial application.

Maintenance Risks
There’s also the issue of support and long-term maintainability. Organizations that use OSS in commercial offerings may not have a safety net of support if their application breaks as a result of third party code. They may have to turn to the community for support, versus paid, professional support from the vendor.

With open source projects, version-to-version breakage can also be an issue. Maintenance challenges are compounded when organizations build commercial offerings in part by assembling multiple open source components. The product becomes unstable as the developers struggle to keep the disparate components working together in the face of browser, operating system, and platform updates.

Mitigate Your Legal Risk
You can mitigate your risks by following some key steps. Some best practices:

  • Track all third party software included in your distribution and the license type, and keep it up to date. Consider each addition carefully, examining the risks and the benefits.
  • Be sure to republish the license text of each work (and subwork), particularly if you are distributing object code only.
  • For Apache works, be sure to republish a copy of the Apache license, together with a prominent notice on any modified files that you have changed the files.
  • Consider the use of any GPL work in a closed source application very carefully. If your application can be considered and extension of the GPL work, you may be required to disclose your source. Seek counsel if your rights are in doubt.
  • Is the project supported by a specific group of developers and is there a thriving community dedicated to delivering a quality application? Or, is the software built by a single developer as a part-time project? Are contributions well vetted and under CLA?
  • Consider the effort and expense of replacing the software should you encounter any issues. Can it be swapped out easily, or is it intimately entangled with your application?
  • Consider the value of the contribution when compared to self-developed or commercial alternatives. Could you benefit from vendor engagement and professional support?

Open source software will continue to have a profound impact on how enterprises acquire and deploy software to support their operations. However, you should clearly understand the licensing implications and follow the rules. Consider quality, longevity, maintainability, community, contributors, and other risks before embracing or including a specific open source offering within your commercial product. By taking the several simple steps outlined in this article, you can reduce your risk and maximize returns.

(Published in SD Times, August 21, 2017.)

Blockchain and the Law

Many of us have watched the rise of blockchain ICO's (Initial Coin Offerings) and considered some to be in violation of US securities laws.  This week, the SEC published a report relating to a failed ICO, confirming that the issuance was a security and subject to US securities regulation.  Though this report addresses only that entity and its ICO directly, the implication is that similar ICO's (where the coin represents an interest in the profits or ownership of the enterprise) are securities regulated by the SEC.  As such, in the US, they can only be sold to accredited investors (net worth of at least $1,000,000, or income at least $200,000 / $300,000 combined if married).

This is not surprising.  Securities laws are intended to protect the investing public from scams and poor investments.  The ICO landscape is littered with terrible investments and little to no accountability.  Their failing taints what is transformative when used legally.   It can be helpful that there is some reasonable regulation when it comes to these investments.

The SEC is not attempting to exert regulation over all ICO's.  May ICO's are for advance services (similar to the way Kickstarter sells products in advance of production) or other purposed.  The SEC is not claiming that these sales are securities.  Some of these sales may be just as dubious - but not regulated at this time.  

The US Department of Justice also acted this week to indict and arrest the owner of BTE-e, an exchange that laundered stolen bitcoin.  Again, it's not surprising that illegal activities related to blockchain draw attention and action.  

Though a new frontier, this is still the real world, and governed by real world law, which for the most part is there for a reason.

OSI Responds to React.JS License Issues

Earlier this year, OSI indirectly responded to the React.JS license issue by approving a BSD+Patent license, with the stated goal of providing: a) a simple permissive license; b) that is compatible with the GNU General Public License (GPL), version 2; and c) which also has an express patent grant included.  

The BSD license alone has no express patent grant, and a patent license is considered to be implied.  Facebook and other organizations have taken advantage of the silence to add an express patent grant with sometimes concerning restrictions.  This new BSD+Patent license provides and OSI approved permissive open source license, without condition on downstream development.  It positions the React.JS and similar licenses as non-standard OS licenses, which should further scrutiny of the implications of that non-standard license.  On the other hand, OSI issued a new license rather than updating the standard BSD license, which leaves some justification for the restrictive use. 

In any case, restrictive patent riders to the BSD license can present challenges to the use of that software.  OSI's recent action does not change any existing license, but hopefully will put some pressure on licensors not to use the subtle trick Facebook has used to turn freely permissive open source into a full scale patent grab.

When to use BCC and When not to

I've noticed there are at least two good times to use the BCC in an email and otherwise the use can be disingenuous and dangerous.

1.  Use BCC when emailing a group where it would be inappropriate to share the distribution list with all the recipients.  For this purpose you can often use yourself as the visible recipient so it's clear there is a distribution that you're not showing.

2.  Use BCC in a reply after an introductory email or where a party is no longer relevant, noting in the response that you are moving them to BCC to continue the thread without them.

Otherwise, in the case where you want to advise somebody of the content of a email, but you don't want to add them to the thread or advise the other party of the communication, you're better off sending the email/reply without a BCC, and then forwarding the email/reply to the third party.  Else, your BCC could be a setup for the BCC'ed third party to reply to the thread if they don't notice the BCC - something that clearly alerts the original recipient to your hidden intent.  Also, a forward is somewhat less disingenuous in that you are not hiding the communication, you're taking action after the fact.

Moderated Forums & Websites Lose DCMA Protection

If you host a forum or website with user generated content, you can generally shield yourself from liability for any infringing works they post by filing as a DCMA Designated Agent and posting simple procedures for claimants to request the takedown of infringing materials.  This is a simple procedure which can save headaches down the road. 

When it comes to moderated content, these safe harbor protections may no longer be afforded. On April 7, the Ninth Circuit ruled in the case of Mavrix Photographs, LLC v. LiveJournal, Inc., (Mavrix) that hosting platforms are ineligible for safe harbor based on the acts of its agents, such as a moderator or curator.  In other words, where content is user generated but moderated or curated by a site (including even unpaid moderators at large), the site can be held accountable for infringement itself, even where there is a simple procedure for removing infringing content.

Consider the implications of moderating user content on your liability for copyright infringement (say, if a user posts a picture for which they have no rights, or a code that they are not entitled to).  It may be better to enforce an Acceptable Use Policy removing offending content after the fact, than inserting a moderator to review before publication.

Fenwick published a great post which covers this decision and related matters in more detail.

React.JS Developers Beware!

The React.js license is problematic in that licensees cannot sue Facebook for patent infringement (for any related or unrelated infringement), without losing the license to React.  In essence, by using React.js you grant Facebook the right to use (infringe) on your present and future patents.

React is licensed under BSD with a patent rider.  This means that Facebook, while granting patent rights, has also restricted the BSD license such that the terms are not the pure open source terms of the standard BSD license.  This patent rider has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook, the patent license automatically terminates- which means that Facebook can then sue you for patent infringement for using React.

Both Apache and GPL licenses have express patent license grants.  The BSD license does not, and though it’s not settle law, it’s generally considered that there is an implicit grant which cannot be revoked.  Facebook added an express patent license grant under the patent rider, but conditioned it on not suing Facebook for patent infringement, in any regard.  If you do, you lose the patent license, and likely the right to use React as may then be an integral part of your platform.

This means that if you use React, you may not be in a position to stop Facebook from leveraging your patents.  This should be an important part of any framework decision.

Further,  a potential acquirer of your company or software my look elsewhere, since an acquisition would imperil the acquirer’s patents as against Facebook, even if unrelated.  Google, Apple, Microsoft, and other big players may no longer have interest in your company as an acquisition target, unless your use of React.JS can be replaced - often a non-trivial or impossible task.

For reference, the relevant text from the React.js patent rider is:
The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software. […]  A "Patent Assertion" is any lawsuit or other action alleging direct, indirect, or contributory infringement or inducement to infringe any patent, including a cross-claim or counterclaim.


Dangerous NDA's

Recently, an NDA came across my desk for review that shocked me.  This NDA included the following:

The Consultant hereby assigns to the Corporation its entire right, title and interest in or to any idea, invention, product, program (including written programs and documentation) and written works hereafter made, developed, created, discovered, conceived or written wholly or in part by the Consultant: 1. at any time while hired by the Corporation, or assigned to perform an executive, managerial, planning, technical, research, programming, system analysis, or engineering capacity (including development, manufacturing, systems, field and customer engineering) for or on behalf of the Corporation; and 2. which relates in any manner to the actual or anticipated business, research or development of the Corporation, or is suggested by or results from any task assigned to the Consultant or work performed by the Consultant for or on behalf of the Corporation.

Not only does an assignment of rights have no place in an NDA, but this assignment purports to assign anything and everything that relates to the corporation’s business developed by the consultant after the date of the NDA.  This grant may be too outrageous to be enforceable, but it’s dangerous at that.

The lesson here is be careful what you sign.  Don’t assume the boilerplate isn’t meaningful or dangerous.

There’s more on what to look at when signing an NDA here.

Form License Agreement (EULA) for Attorneys Nationwide

I'm honored to be selected to draft the form End User License Agreement (EULA) by the American Intellectual Property Association (AIPLA), the preeminent association of Intellectual Property lawyers in the United States.  This form was completed with the help of Aashish Kapadia, Esq. and the other lawyers participating in the forms project for the AIPLA, a joint committee project to compile a series of forms and templates for IP-related business transactions. This form EULA is intended to set the standard for EULA drafting throughout the country.

Open Source Licensing

If you have created software for others to use, you need to decide what license to use in distributing that software to others.  Open source licensing means you give your source code so that others can modify or create derivative works from your software.  What others can do with your work is governed by which license you choose.  Alternatively, you can commercially license your work, where you set the terms of what others can do with it in the written license to which they must agree if they want to use your work.  In many cases, a commercial license requires a fee.  Commercial licenses can cover both source code releases and object code release where the licensee never has access to the source and cannot create derivative works.  You can also dual license your work such that a user has the option of using it under an open source license or under your commercial license.

You may want to use an open source license if you want to release your work into the world for any use at all without compensation – say if you just want to be helpful, or you want the notoriety for creating something and hope to see the widest use.  You may also create a business where you provide services and support for the work.  Or you may host related closed source offerings, possibly server side.  Typical permissive open source licenses include MITBSD, and Apache.  MIT and BSD are quite simple.  Apache is equally permissive, but carries more protections for the author.

You may also choose an open source license that requires any further distribution of your software to be open source.  This is called a copy-left license, where the license requirements flow downstream to software that includes your code.  The most common such license is the GPL v3 (the GNU General Public License version 3).  Where your software is an SDK or code that’s included in the users’ applications or website, then this would require that the user release the source to their distributed applications.  This is an effective way to force closed source users to seek a paid commercial license from you for the same code, to cover the closed source use.  The perspective here is that closed source uses are usually for profit, and if a

If you offer up a commercial license along side an open source license for the same code, you’re welcome to set any terms you like.  A good example of such a commercial license that I’ve worked on is the Sencha Software License Agreement.

If you’d like to explore the various open source licenses more, check out GitHub’s Choose a License site, which is quite helpful.

TechFundedopen sourceComment
Participation Preferences

Participation preferences for investors are often stated in terms of a preference multiple and a participation cap multiple – which are two entirely different things.  The preferred investor is first paid their investment at the preference multiple, and then participates with the common shareholders in the remainder of the purchase price (per the percentage interest each has in the company) until the preferred investor is paid a total equal to the original investment time the participation cap (including the amount already paid out).

For example, say A and B own Company X equally (50/50).  They then create a 20% ESOP, so they now own 40% each.  An investor invests $10MM at a $100MM (pre) valuation, with a 1x preference and a 2x participation cap.  The investor now owns 10%, A owns 36%, B owns 36%, and employees account for 18% (assuming options for all ESOP shares are granted and exercised).

If the company sells for $20MM, the preferred investor first gets paid back its $10MM.  The remaining $10MM is distributed per ownership, for an additional $1MM to the investor (it owns 10%).  The investor takes $11MM, and the original owners and employees share the remaining $9MM.  This is much better result for the owners and employees than a 2x preference, where the preferred investor in this example would get the entire $20MM and the owners and employees would get nothing.

If the company is sold for $110MM, the investor first gets paid back its $10MM, and the remaining $100MM is distributed per ownership, for an additional $10MM to the investor. Here the investor has reached its cap.  So for prices from $110MM to $200MM, there is no difference in return to this preferred investor since they have reached the cap.  This is known as the “Dead Zone.”

At prices over $200MM, the investor would convert to common and share per ownership – yielding somewhere over $20MM depending on the sales price (the investor gets 10% of the sales price).

Cashing Out

There are quite a few routes to cashing in on your idea or business.  The quickest and easiest is to sell early.  Most larger tech companies have a budget for building their business by acquiring smaller companies.  Depending on the value that you bring to the table, whether that is a technology, talent, community, etc., you may be able to get a quick return if that’s what you are looking for.  By positioning yourself for visibility, you better attract early interest.  This may be by virtue of your website, yours or other blogs, showcase conferences, etc.  Good open source projects also fit here, where companies can acquire you in support of their open source initiatives.  Almost all acquisitions will come with a job, since the talent is almost always an important part of what they are acquiring.

If you’re not acquired early, there are more options for cashing a little out before your final liquidity event.  In each round of serious financing – Series-A, Series-B, Series-C – you may be allowed to sell some shares.  This is negotiated up front and if you’re interested in it you should look for investors that are either in for or will allow a secondary sale.  There are two ways a secondary can take place: (1) you sell your shares direct to buyers in a transaction that takes place just after the financing, or (ii) the company purchases your shares and the resells the to the investors as part of the financing.  If the investment is a second round of funding or later, you may be asked to discount the price on the shares that you sell.  If the transaction is structured as (i), then your shares are somewhat less valuable as they carry no preference, or a lower preference from an earlier round.  If the transaction is structured as (ii), you’ll be asked to discount just the same, since the later round now has a larger pool.  Discounts are usually 10% to 20% – depending on the difference in preference.


Each round of financing carries a preference, in for the amount invested and possibly a multiple on that.  So a 2x preference on a $5MM investment mean that that investor will get the first $10MM out of any liquidity event.  This is true until a later investor gets a preference of a higher priority preference as approved by all the investors including the one with the earlier preference.  These preferences are much of what make preferred shares preferred over common shares.  Employee stock options are convertible into common shares and carry no preference.  Preferences play into the sales price of a company, in that if a 10% investor gave $10MM at a 2x preference, you’ll need to sell the company for $200MM or the preference will eat into the amounts payable to the other owners.

Angel Funding

One of the first questions that comes up in Angel Funding is “how much am I getting” and “how much am I giving away”.  Angel funding is often achieved with a convertible note, which makes answering the second question much easier.  Whatever the amount you get, a convertible note will have an option to convert to equity on a future funding, at a discount.  So for example, if you get $100,000 on a convertible note that offers a 10% discount – and the later round is for $1MM, then after conversion your investor would own 11% based on the discount.  This means that you don’t have to set a value until the later investment when you have more to base that value on.  There will often be a lower bound on the conversion – so that more angel financing would not trigger the conversion and could be brought in under additional convertible notes.  There is sometimes also an upper bound to insure that the investment is not diluted if the first round is much bigger and farther away.  Discounts tend to range from 10% to 20%.  If an investor brings more to the table in terms of contribution to the company, they may also want a direct equity grant.  Som convertible notes carry a preference (1.5x to 2x) insuring that multiple on the investment is the first paid out on a liquidity event.

Arbitration and Class Action Suits

In a 5-4 ruling this week in the case of AT&T Mobility v. Concepcion, the Supreme Court said that clauses in contracts in which consumers agree to arbitration block them from later joining class-action lawsuits.  This means that by adding an arbitration provision to your contracts, you can effectively block class-action suits.

Here is an interesting post on what to use for an arbitration provision,