Skip to content

Permissive Licenses and Richard Stallman’s Blindspot on the Rails Community

Recently, I had to go through a very, very difficult contract negotiation that hinged largely upon the inclusion of open source software in client deliverables. Suffice it to say, that at this point, I’m fairly convinced that L/GPL licensed software simply cannot be included in software deliverables if the client intends to a) distribute that software and b) include trade secrets or confidential information in that software. It may be technically possible, but it is a huge nightmare-headache. 

As a result, I took a second look at this essay, by Richard Stallman, arguing that LGPL is, in fact, too lenient in its requirements, and that people releasing open source libraries should really think about releasing them under GPL. The gravamen of his argument is this:

If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way. 

Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising “more users for this library” if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.

In other words, Stallman is concerned that unless software is GPL licensed, then:

1. The free software movement will be left behind.
2. Proprietary software developers actively seek to crush the software industry, and won’t contribute to free software.

Both of these statements, in practice, have turned out to be false, and the proof is in the pudding:

The entire Ruby on Rails community is based on free software – either under the Ruby license, the MIT license or the BSD license, and almost never on the GPL license, probably for the reasons I explained above. Node.js is MIT Licensed. So is JQuery. Stackoverflow is brimming to the rafters with employees of the ‘proprietary’ software industry. These are the tools of choice for many of your favorite web services, and their users are very much in the for-profit business.

Richard Stallman’s fears have simply failed to materialize. The modern web uses permissively licensed software as its lifeblood, and, quite frankly, copyleft licenses are often directly in tension with the perfectly reasonable goals of both public and private interests.

So, in the end, I believe the very mechanisms that Mr. Stallman envisioned would result in GPL licensed software becoming the norm for best coding practices and the gold standard for quality software, have in fact relegated GPL software to the domain of academics and those who do not have to deal in trade secrets or deal with covered information. The upside is that the community of sharing that Mr. Stallman had envisioned has come to exist – it just so happens that it exists under permissive licenses, not copyleft licenses, and the community is populated by a whole lot of people who develop proprietary software.

Legalese or Plain English? Either Way, TechCrunch has it Wrong

There was a post today on TechCrunch about a VC that uses a plain english term sheet, as if this were some earth-shattering innovation. Well, first, it isn’t, and, secondly, TechCrunch seems to really miss the larger point: This term sheet is a summary of a larger, totally standard contract. In other words, the whole goal that TechCrunch seems to be excited about – a contract that is in plain english, hooray! – is false. This is a memorandum of understanding, a letter, a summary, that precedes the formal agreement itself. So, basically, this is a non-story.

However, it does lead to the more interesting question of contract drafting in general, and whether it is a better practice to use plain english or stick to the legalese. As with all things, I argue that it depends highly on context, and the intended audience for a contract.

For instance, when drafting a Terms of Service, or End User License Agreement, it is probably the right thing to draft so that a normal human being can understand what you are writing. However, if you think for a moment that I am going to draft a funding instrument or insurance policy in plain english, you need your head examined. If for no other reason – and there are many – this is because it is the language written on the contract that gets tested in court, and you want to have predictable outcomes when drafting contracts. This means you use language that has already been reviewed and tested by courts, even if it is cumbersome and bulky. So, even in the example of a TOS or EULA, when it comes to HIPAA compliance, I’m going to stick with the language I know won’t get me in trouble.

A good analogy is to code: why don’t engineers just write their code so it is really easy to understand? Well, to anyone who knows anything about coding, this question should appear somewhat clueless: programming is a functional activity. Code is written so that it works, first and foremost. Good code is often – and sometimes must be – easy to understand, but there is plenty good code out there that is very difficult to understand, even for very experienced programmers. Of course, it is always good practice to try to make your code easy to understand, but the reality is that function must dominate over lay-person readability.

The same is true for contracts: when a complex deal is memorialized, the documents about that deal will also necessarily be complex. The problem is that most people assume that because contracts are written in english, and that they understand english, that a contract must be faulty if it is not easy to understand. Well, this is a huge misconception.

In the end, the term sheet that TechCrunch has talked about is basically something like very good documentation, or comments that are in code. And that is great – we should all endeavor to document and explain our agreements much more thoroughly. However, as any software developer knows, writing good documentation is in no way a replacement for writing software that works, and writing a good term sheet is in no way a replacement for writing a bullet-proof contract.

Open Source Licenses: When to Use Permissive v. Copyleft

If you work in any industry that heavily relies on software (read: all of them) you will eventually run into open source licenses. So let’s take a look at a broad and growing divide between the two main types of open source licenses – copyleft v. permissive. Spoiler: if you are going to be including open source software in client deliverables, it is far easier to stick with permissive licenses, where copyleft licenses should are best used for academic projects, for developer tools or projects that are dedicated to some non-commercial, public good.

Open source licenses were first used in the mid-1980s, under the mantra that “information wants to be free” – not necessarily free in price, but in that it should be freely adaptable to different people’s desires. Unsurprisingly, some of the earliest licenses came out of Berkeley and MIT, including the GNU Project, under Richard Stallman. The whole idea was to distribute software that was the result of – and useful for – academic activities, and to do so in such a way that guaranteed no downstream user would be able to co-opt the software and claim ownership over it. Rather, such software would remain available for people anywhere to implement, study, contribute to, etc. As a result, the the idea was to create a recursive license, so that any software built upon software licensed in this way would also be subject to that license. This license would further require that the original software, as well as all derivatives of the original software, would have to be freely distributable and usable without restriction. The license would also provide mechanisms for submitting improvements back to the original software codebase, potentially to be included with later releases. The first such license was the GNU GPL license, which set the whole open source phenomenon.

The requirements described above – that all derivative software and contributions be licensed under the original license, that source code be freely available, that there be a mechanism for contributing improvements back to the original codebase – form what is generally termed a “copyleft” license – so called for its difference from copyright, which typically locks up ownership and use.

The outcome of the combination of the above features is often (derogatorily) called the “viral effect“: an entire code base may get ‘infected’ if a single LGPL component is included – meaning that all software that ships with an LGPL component may be subject to the above terms.

As a result, it shouldn’t be that hard to see why using a true copyleft license in commercial software is sometimes untenable: granting access to source code necessarily means giving up claims to trade secrets embodied in that source code. Additionally, the right to re-distribute covered software is automatically granted to any recipient of copyleft licensed software. This can make commercialization tricky – not impossible, but tricky – because any recipient of copyleft licensed software can turn around and resell that software, or even give it away for free. Finally, there are still gray areas in interpretations of the L/GPL regarding how it applies differently to interpreted code as opposed to compiled code.

Contrast these licenses with the so-called “permissive,” such as the MIT and BSD: these licenses essentially only require that any software licensed under their terms includes an acknowledgment of prior authors, and they otherwise disclaim all warranties, restrictions and obligations. In addition, they are far, far simpler licenses: the MIT license is literally three sentences long, while the LGPL runs more than a few pages. To be fair, there are still unresolved issues about permissive licenses, such as how BSD interacts with hardware licensing, but by and large, the interpretation and use cases of permissive licenses are far less complicated than copyleft licenses.

The upshot of all this is that as more and more open source code gets built into commercial applications, we are seeing more and more open source code released on BSD and MIT licenses, and less on GPL and LGPL. Say what you will about the philosophy of the movement itself: I believe this is the inevitable outcome of the way that copyleft was originally designed.

Conclusion: If you are going to be integrating open source components into code that you intend to commercialize, it’s probably safest to stick with permissively licensed components. If you are contributing to developer tools, utilities, mathematical libraries, projects for the public good, academic work, or the like, L/GPL may be more appropriate. Either way, you should probably consult your attorney.

Followup on Console Gaming

I recently posted about how a Wired opinion piece seemed to really miss the boat on console gaming. Well, apparently, Sony agrees:

Kaz Hirai says the PS4 is ‘first and foremost’ a game console, more features to be revealed.

“The most important thing we need to do is agree and understand that the PS4 is a great video game console that appeals to video gamers,” he said. “If we miss that part, I don’t think we get the initial establishment of the console. That formula has worked for us with all our consoles, including the PS3.”

Additionally, this just in from Reddit:

It was posted under the title “A concise list of all the problems with the PS4 (directly from the hardware architect Mark Cerny” and it’s a list of features that gamers consider to be positive. In addition to this, the internet is currently exploding with reviews of The Last of Us, a PS3 exclusive, which is being haled as a “masterpiece.” So we will see how that goes for Sony – but I think it’s safe to say that Wired’s critique is somewhat off the mark.

NSA and Your Digital Life

Right now the internet is on fire with the news that the NSA, through a project called PRISM, apparently has been tapping into a whole bunch of very large internet services for the better part of a decade.

I just wanted to note that we are going to have to wait a few days to get a clear look at this, because within about 90 minutes of each other, these two posts went up on Techcrunch:

Report: NSA Collects Data Directly From Servers Of Google, Apple, Microsoft, Facebook And More 

Google, Facebook, Yahoo, Microsoft And Apple Deny Participation In NSA PRISM Surveillance Program

You can read more at the NYTimes, its Editorial Board,  Guardian, Washington Post - the last two seem to have been the original source of this information.

Also, this is particularly great: NSA chief, two weeks ago: ‘We’re the only ones not spying on the American people.’

I’d encourage everyone to take the chance to read this essay, written by former Supreme Court Justices Brandeis and Warren about the Right to Privacy.

This American Life Inaccurate on Historical Patents

This American Life had a great episode about patents this last weekend. It is well worth the listen, and makes several very good criticisms of patent trolls.

However, I think that TAL missed a few broader issues about patents. First off, the story about Eli Whitney needing patents in order to successfully commercialize his business is just a retcon – it’s not remotely true. Successful commercialization of new inventions is about market timing, making a good product and continually improving it. Eli Whitney, in fact, got rich off of being one of the first people to master mass manufacturing, and his big commercial success was muskets, not the cotton gin. Patents were largely irrelevant to his commercial success. In fact, it seems that Whitney’s attempt to use patents to commercialize the cotton gin was rather unsuccessful:

In hopes of making a patentable machine, Whitney put aside his plans to study law and instead tinkered throughout the winter and spring in a secret workshop provided by Catherine Greene. Within months he created the cotton gin. A small gin could be hand-cranked; larger versions could be harnessed to a horse or driven by water power. “One man and a horse will do more than fifty men with the old machines,” wrote Whitney to his father. . . . “Tis generally said by those who know anything about it, that I shall make a Fortune by it.”
But patenting an invention and making a profit from it are two different things. After considering possible options, Whitney and his business partner, Phineas Miller, opted to produce as many gins as possible, install them throughout Georgia and the South, and charge farmers a fee for doing the ginning for them. Their charge was two-fifths of the profit — paid to them in cotton itself.
And here, all their troubles began. Farmers throughout Georgia resented having to go to Whitney’s gins where they had to pay what they regarded as an exorbitant tax. Instead planters began making their own versions of Whitney’s gin and claiming they were “new” inventions. Miller brought costly suits against the owners of these pirated versions but because of a loophole in the wording of the 1793 patent act, they were unable to win any suits until 1800, when the law was changed. 

Struggling to make a profit and mired in legal battles, the partners finally agreed to license gins at a reasonable price. In 1802 South Carolina agreed to purchase Whitney’s patent right for $50,000 but delayed in paying it. The partners also arranged to sell the patent rights to North Carolina and Tennessee. By the time even the Georgia courts recognized the wrongs done to Whitney, only one year of his patent remained….

While Eli Whitney is best remembered as the inventor of the cotton gin, it is often forgotten that he was also the father of the mass production method. In 1798 he figured out how to manufacture muskets by machine so that the parts were interchangeable. It was as a manufacturer of muskets that Whitney finally became rich. 

In the end  Eli Whitney didn’t get rich because of patents: he got rich because he finally sold his products at prices that the market would bear in spite of the presence of business competition. In fact, Whitney’s use of patents seemed to do more harm than good. Interesting to note is that another set of famous historical inventors, the Wright brothers, had similar woes: the Government had to intervene and require the Wright brothers to license their patents because their patent litigation was slowing the development of the US airplane industry

Jump to today, and we see the exact same thing happening: the smartphone is covered by literally hundreds of patents, and you are likely paying more in patent licensing fees when you buy a smartphone than you are for any actual physical component of the phone. Similarly, the main reason that 3d printing is now exploding is because the original patents filed on it in are now expiring. In other words, for innovative new products, it seems the companies that rely on a patent litigation strategy have pretty mixed results, while as stated in a recent post, over 90% of recent innovative products that won awards from the journal Research and Development simply were not covered by patents. As far as I know (please correct me if I’m wrong), its a relatively recent phenomenon that tech companies have relied heavily on patent litigation as a day-to-day business strategy - Apple didn’t sue anyone for patent infringement for its first thirty years, and the original iPod was without almost certainly in violation of of patents, including the one on that episode of TAL. 

Basically, the main problem with patents is that the fundamental hypothesis underlying patents – that giving an exclusive monopoly to the first person to have a particular type of idea drives innovation – was a hypothesis from the late 1600s and early 1700s, before there was anything remotely resembling modern economics or business theory. (Interesting side note, the original form of patent was a Royal Charter from the English Crown, that granted an exclusive right to perform a particular enterprise. Historical companies that had “patents” included the Dutch East India Company and the British South Africa Company.) In the time since patents became ensconced in the constitution and the law, I don’t think we have seriously re-assessed whether they have been causal or correlative in the history of innovation, i.e. whether patents drove innovation, or were simply along for the ride.

So, the issue I take with TAL’s coverage of the patent system is that they seem to buy the fundamental hypothesis without any examination, and I find that very frustrating. Their analysis treats patent trolls as an unfortunate outcome that can be eradicated from the system, but I argue that the necessary result of this patent system is precisely this type of behavior, troll or not – companies that fail to compete in business will rely on patents to tax innovative companies. Quite simply, the strong odds are that the first person to come up with an idea will fail to make a successful business around it, and businesses that are bad at doing what they do should fail – that’s the American way. In fact, the vast, vast majority of businesses, even ones founded around great ideas, fail. 

I wish TAL would have examined what types of patents, if any, do drive innovation, rather than focusing on the trolls. No one thinks trolls are good. But the more important question is: what part of patents actually are good? Right now, we are all so distracted by trolls and obviously poor software and method patents that we are distracted from this much more fundamental issue: how do patents actually promote innovation? This cannot be addressed without acknowledging that the number of patents being issued is probably more than a few orders of magnitude too high. Any reform that doesn’t take these fundamental factors into account is just applying a band-aid to a grievous wound.

Business Insider’s Bizarre Take on Musks’s “Hyperloop”

Jay Yarrow at Business Insider just penned this piece about Elon Musk’s “hyperloop” concept.

While I’m sure that Mr. Must has something very interesting up his sleeve, I just wanted to point out that the idea discussed in that article, an underground vacuum maglev system detailed in a 1972 RAND paper, is utter, fantastical nonsense. Not only are tunnels fantastically expensive and time consuming to build (Second Avenue Subway? LIRR / GCT connection? Anyone?) the idea of sustaining a vacuum in anything remotely that large is pure, unabashed science fiction. It is literally impossible. No amount of money or clever engineering could make that happen. It would literally be the most expensive engineering project in history by a few orders of magnitude, and it would still fail.

My guess is that Mr. Musk – a fully qualified engineer – has nothing of the sort in mind, simply because it is a child’s fantasy. However, what Mr. Musk has described, a magnetically propelled super-sonic levitating train, is not much different than magnetic trains that are already all over the planet. The trick is to ensure stability past the sound barrier on the ground, a non-trivial problem, as well as ensuring that friction is low enough. My bet is about 100:1 that this is what is on the table, and not a gigantic vacuum tube system.

Wired Misinterprets the Market Failure in Console Gaming

Wired had an article recently about the new Xbox One announcement. The Xbox One announcement has been really, really panned, and for a whole lot of good reasons. I won’t get into the details of all the criticisms, such as the fact that you may have to pay a subscription service to MSFT to play your pre-existing subscription cable, or that it is an ‘always-on’ service, etc. etc. However, I will talk about the fact that it seems that the Xbox One it isn’t really for gamers. Wired’s Chris Kohler notices this, but draws the wrong conclusions, stating that:

It’s not hard to figure out what the gaming-first crowd wants: a super-powered box that connects to the TV, has a handheld controller and has a huge library of games from the biggest-budget epics to the breakout indie hits. They don’t want a PC because they don’t want to mess with settings and deal with crashes; they want a standard platform that Just Works. It can do other things, sure, but games are the meat and everything else is somewhere between the gravy and the pepper shaker.

Hey, that sounds like an awesome product! Tuned precisely to our very needs. Say, do you know how many companies — in the entire world — currently offer such a product?


From there basically goes on to say that the above must be either impossible to do properly or not be worthwhile financially. He hypothesizes:

There may be no way to make money selling a bleeding-edge $500 games-only box with $60 games anymore. The expense of producing it all may be well out of whack with what players are willing to spend to get it.

This smacks of speculation, because no one is even bothering to try to implement that business model. And the frank reality is that the systems that are currently being produced are vastly overpowered – you can still get really great graphics out of consoles that are not nearly as beefy as the latest releases. Further, because so much groundwork has been laid into the development of gaming engines, it is cheaper to produce games now, and millions are willing to pay good money to play them. Just ask Gabe Newell

So, Kohler has missed two important points.

First off, the actual lesson is that there is a current market failure: up until a decade ago, Sony was raking in the money in console video games - I don’t think those consumers all died, rather, I think they are older and probably have more purchasing power, economic downtown notwithstanding. I’d argue that Sony’s failure to capitalize on this same market is because it is pushing bloated multifunction set-top boxes focused on media into the market, and has lost focus on its core audience of gamers and gaming consoles. In other words, as demonstrated by the above historical console sales, there is a demand and no one is delivering.

Second, the point to take is that MSFT and Sony are both “out” of the gaming game and are in the middle of huge media plays. Right now they are trying to use their consoles as a way to shoehorn their media businesses into the living room, directly in competition with Apple. In fact, Sony’s entire electronics division is losing money, while it is making most of its profits in media and insurance. Microsoft, in the meantime, has hired a former CBS executive, set up its own studio, and has signed a deal with the NFL. So the problem is that MSFT and Sony are competing with cable companies, HBO, Apple and Hollywood with this new generation of consoles, rather than competing with Nintendo and targeting gamers. Nintendo itself may have stumbled with the WiiU, because it is also crammed with distracting features, but the 3DS is doing fine and I’m sure the WiiU will hit its stride.

Currently, it seems that Sony and MSFT are more interested in getting your parents to watch the latest episode of Real Housewives of Microsoft, your siblings to watch HaloTV, the whole family to enjoy a movie from a wholly owned subsidiary, or the guys to socialcast their fantasy stats while they watch football, than to make a play at the core gaming audience once serviced by millions upon millions of, PSs, Xboxes, PS2s, and Xbox360s.

So fundamentally, where I see market failure and a big demand, Kohler has taken the fact that a) the market is being flooded with devices that intentionally address a totally different market segment – casual media consumers – to mean that b) that it is impossible to create a product that gamers do want, either because gamers aren’t there or because it isn’t profitable. Quite simply, b) does not follow from a).

I suspect the pendulum will swing back the other way, and not too long from now either. 

Contract Drafting: Software Development Agreements

Recently, I was presented with a form software development Agreement. I asked a junior associate to give it a markup for outstanding issues as a learning exercise. It reminded me that many critical areas of contract drafting are simply not taught in law school, so consider this a first in a series of tips and pointers for drafting practical agreements.

Software development contracts are a lot like other creative development agreements, in that a person or corporation is creating a new work and transferring the IP rights to its employer. As a result, here are a few things to consider in any contract that controls the transfer of IP rights:

  • Clearly define “Intellectual Property.” Make sure that such definition includes not just copyright, but trademark, trade secret, and all patent rights. This definition covers what will, and will not, be owned by the client at the end of the engagement. 
  • Work for Hire. As a client, you will want to ensure that all materials are being made as work for hire, and, if they are not deemed to be work for hire, then all IP rights are assigned to the employer.
  • Further Assurances. Again, as a client, you will want to ensure that the the party rendering the services will agree to execute any documentation acknowledging that the employer owns the IP created, assigning IP created, etc.
  • Further Assistance. Often, the developer’s assistance will be needed in the future, whether for the purposes of litigation or aid in filing patents. Typically, such assistance is compensated at the averages rates paid during the original engagement.
  • Limitation of Liability. As a developer/contractor, you are going to want to waive all special and consequential damages, lost profits, interruption of services, and limit only to actual damages. Alternatively, you can limit to the fees paid to the contractor over the last [x] months, or a mutually agreed upon cap. It is not unusual for there to be a separate cap for indemnification liability over IP infringement, i.e., the general cap is at the fees paid over the last three years, but liability for indemnification provisions at 2x-3x those fees. There is often a lot of negotiation on this issue. 
  • Warranty. It is typical to disclaim any and all warranties, but often a client is going to want some sort of warranty that the work product is non-infringing. Carefully consider, either as contractor or client, the level of IP representations made: are you going to make a strict representation of non-infringement? One based on knowledge or negligence? As above, there will usually be negotiation on this issue. I find that, generally, as risk increases for the contractor / developer, rewards should increase as well. So it doesn’t make a ton of sense to make a strict IP representation if you aren’t getting well paid, as you are basically extending an insurance policy over the IP delivered for very little money.
  • Indemnification. largely the same considerations as the previous two. Consider what acts, either as a contractor or client, you want to indemnify the other party for. It is not unusual to indemnify the other party against third party claims made for breaches of the representations and warranties in the contract or due to your own negligence of willful misconduct.

A few things make software development, in particular, different than most other creative materials development contracts. Let’s review them:

  • Pre-existing Materials. Often a contractor will include software developer prior to engagement, outside the scope of engagement, or generally applicable to the contractor’s business, to the client. The contractor will want to retain ownership of this material, so they should make sure that the agreement specifies which software, if any, falls into this category, or specify which mechanisms will be used during the engagement for identifying such software. The client will want to consider how this affects pricing as well: essentially, the client will be leasing, and not buying, such software, so they should not expect to pay full freight for it. 
  • Open Source Materials. Contractors may include open source materials in final deliverables. Both parties will want to be up front about what open source agreements they are comfortable with (for instance, corporations tend to really dislike LGPL, for pretty understandable reasons), and make sure that both parties will have clearly established mechanisms for complying with the terms of such licenses. Additionally, the contractor must be sure that they are not incorrectly representing that they are transferring ownership of these materials, as that is simply not within their power.
  • Third party materials. Rather like open source materials, but privately owned software. For instance, if the developer delivers say, copies of Word® or OSX Server® to the client, the client will typically be responsible for procuring / maintaining such licenses. Again, as above, the developer must make sure that it is not incorrectly representing it has the power to transfer ownership of those materials.
  • Residuals. This one is often a big sticking point: typically, there are very strong non-disclosure provisions in software development agreements. Residuals clauses usually read something like this: 
    The Receiving Party shall be free to use for any purpose the Residuals resulting from access to or work with the Confidential Information of the Disclosing Party. “Residuals” means information retained in unaided memory by persons who have had access to the Confidential Information, including ideas, concepts, know-how or techniques contained therein. The Receiving Party shall not have any obligation to pay royalties for work resulting from the use of Residuals. However, this clause shall not be deemed to grant to the Receiving Party a license under the Disclosing Party’s copyrights or patents.
  • Often, developers gain a lot of important insight from complex projects. If clients are unwilling to agree to the above residuals clause, it may be worth considering if extra compensation is warranted.
Next time, I’ll discuss how Statements of Work – the above notes are only for the Master Services Agreement. On top of that, in order to ensure that both parties are happy, there should be a detailed Statement of Work that explains what is being developed, milestones, testing criteria, etc. It is a document that requires as much careful thought as the underlying contract itself, and worthy of its own post. 
After that more to come on NDAs, Software Licenses, EULAs, TOS’s…
In the meantime, happy drafting.

Entertaining List of Prohibited Businesses for Credit Card Processors

Examining the Stripe TOS today, I discovered that they have a very long list of businesses that they will not service, including:

(1) door-to-door sales, (2) offering substantial rebates or special incentives to the Cardholder subsequent to the original purchase, (3) negative response marketing, (4) engaging in deceptive marketing practices, (5) sharing Cardholder’s data with another merchant for payment of up-sell or cross-sell product or service, (6) evading Card Network’s chargeback monitoring programs, (7) engaging in any form of licensed or unlicensed aggregation or factoring, (8) airlines, (9) age verification, (10) age restricted products or services, (11) bail bonds, (12) bankruptcy lawyers, (13) bidding fee auctions, (14) collection agencies, (15) chain letters, (16) check cashing, wire transfers or money orders, (17) counterfeit goods, (18) currency exchanges or dealers, (19) embassies, foreign consulates or other foreign governments, (20) firms selling business opportunities, investment opportunities, mortgage consulting or reduction, credit counseling, repair or protection or real estate purchases with no money down, (21) credit card and identity theft protection, (22) cruise lines, (23) essay mills, (24) flea markets, (25) drug paraphernalia, (26) extended warranties, (27) fortune tellers, (28) “get rich quick” schemes; (28) gambling (including but not limited to lotteries, Internet gaming, contests, sweepstakes, or offering of prizes as an inducement to purchase goods or services), (29) sports forecasting or odds making, (30) illegal products or services, (31) mail-order brides, (32) marijuana dispensaries and related businesses, (33) money transmitters or money service businesses, (34) multi-level marketing or pyramid schemes, (35) online or other non-face-to-face pharmacies or pharmacy referral services, (36) prepaid phone cards, phone services or cell phones, (37) pseudo pharmaceuticals, (38) quasi-cash or stored value, (39) securities brokers, (40) sexually-oriented or pornographic products or services, (41) shipping or forwarding brokers, (42) substances designed to mimic illegal drugs, (43) telemarketing, (44) telecommunications equipment and telephone sales, (45) timeshares, (46) travel agencies or travel clubs, (47) online or other non-face-to-face tobacco or e-cigarette sales, (48) weapons and munitions (49) virtual currency that can be monetized, re-sold or converted to physical or digital goods or services or otherwise exit the virtual world, (50) personal computer technical support, (51) selling video game or virtual world credits (unless you are the operator of the video game or virtual world), (52) selling social media activity, such as Twitter followers, Facebook likes or Youtube views, (53) human hair, fake hair or hair-extensions, (54) any product or service that infringes upon the copyright, trademark or trade secrets of any third party, or (55) any product, service or activity that is deceptive, unfair, predatory or prohibited by one or more Card Networks.

Well where’s the fun in that?