MediaTech Law

By MIRSKY & COMPANY, PLLC

Blog and Writings We Like

This week we highlight three writers discussing timely subjects in copyright and privacy law, as well as the on-boarding process for Software as a Service (SaaS) customers: Eric Goldman wrote in the Technology & Marketing Law Blog about the use of copyright law as a “reputation management” tool; Katie Townley and Christie Grymes Thompson posted in Ad Law Access about a request from advocacy groups that the federal Consumer Product Safety Commission (CPSC) recall the Google Home Mini smart speaker over privacy concerns; and Aleksander Gora provided useful guidance on the Webdesigner Depot website about designing effective sign-up forms.

First Circuit Rejects Copyright Workaround to Section 230 – Small Justice v. Ripoff Report

Eric Goldman published an interesting article in the Technology & Marketing Law Blog about using copyright law as a way to protect one’s reputation. In Small Justice v. Ripoff Report (which was most recently argued before the U.S. Court of Appeals for the First Circuit), the plaintiff, Richard Goren, ran a law firm called Small Justice and one of the defendants, Christian DuPont, wrote two negative reviews about Small Justice on the website Ripoff Report. Goren sued DuPont in state court for libel and intentional interference with prospective contractual relations, and the court awarded Goren a copyright over the reviews as a default judgment. Goren then asserted a copyright claim against Ripoff Report, who had published the reviews. (Interestingly, Professor Goldman questions whether the state court had the authority to award copyright ownership, but notes that the First Circuit did not address this point.)

Read More

The Weird World of Open Source Software Licenses

I like to think that somewhere in America, at this very moment, a college kid has just agreed without reservation to accept five bucks from his friend to drink an entire bottle of hot sauce. Non-lawyers are often surprised to learn that, public policy concerns aside, such an agreement contains all the elements necessary to create a legally binding contract: Offer, acceptance and consideration.

Part of a lawyer’s job is to identify relevant legal issues lurking beneath factual scenarios. Issue spotting can be frustratingly difficult, however, because, as the absurd hot sauce agreement illustrates, the law is often counterintuitive. Counter-intuitions abound in the weird world of open source license agreements. License agreements have become commonplace in our tech-saturated lives. If you’re not sure what they are, jog your memory to the last time you downloaded an app for your laptop or smartphone. Remember being asked to read and agree to an endless list of terms and conditions? That contract that you “read” and agreed to was almost certainly an end user license agreement to use the app for a specific purpose.

Over the past twenty years or so, several copyright licensing movements have gained traction. In general, these new types of licenses challenge traditional notions of copyright protection by granting licensees the right to modify the original copyrighted material for future use free of charge so long as certain promises are kept and/or conditions are met.

One well-known movement is the Open Source Initiative, which reviews and approves open source software (OSS) licenses. OSS licenses typically provide licensees with the right to access the source code of the original software program (hence “open” source) and create new software programs subject to the terms of the license.

Read More

Legal Considerations of Agile Development

An interesting change has occurred across software development projects over the past several years, which has seen the practice of Agile software development overtake that of the traditional Waterfall model. Rooted in the 2001 Agile Manifesto, Agile development favors greater interaction between technical and business teams, resulting in a more fluid development lifecycle. That is in comparison to the Waterfall approach, which operates on the basis of clear defined stages and objective within the project.

In the past, with a Waterfall approach, a software development project would be scoped out in full, with every detail and eventuality planned out, and with a completion date identified. So when asked “When is the project launching?”, a project manager or stakeholder would confidently reply with a set date, possibly months or years into the future.

With Agile development, the understanding is that not every detail can be mapped out, and requirements may change as the project advances. Agile allows for shifting of goals and deliverables as requirements shift during the development lifecycle. For that reason, work is done in small increments – referred to as sprints – with each sprint resulting in some working piece of code or “minimum viable product” (MVP). So when asked “When is the project launching?”, a project manager or stakeholder will likely not have a firm date, and instead reply “We expect a working version of this piece of the project by the end of the next two-week sprint.”

Read More

Deceptive Software: Breaking Down VW’s Emissions Cheating Code Scandal

Introduction

After a university study uncovered code designed to cheat emissions testing standards, Volkswagen Inc. (VW) has been on the defensive, admitting wrongdoing and bracing for the onslaught of regulatory fines, class actions suits, and major repairs and recalls.

The code at the heart of the controversy places the car in one of two operating modes. When the car appears to be driving under conditions simulating an emissions test, the “cheat code” is enabled, delivering proficient emissions results and better gas mileage. When driving conditions denote real-world driving, cheat mode is disabled, delivering increased power and torque, but decreasing gas mileage and outputting a level of emissions 40 times greater than the legal limit as regulated by the Environmental Protection Agency (EPA).

Discovering the Cheat Code

Researchers at West Virginia University uncovered the higher emissions during a study funded by the International Council on Clean Transportation, a nonprofit with offices in the U.S. and Europe, to test the emissions of diesel vehicles while driving. Traditionally, emissions testing occurred in a stationary location by placing the front-wheels of a car on a rolling treadmill while the rear wheels remained static. Emissions that escaped through the tail pipe were then collected and measured. The WVU researchers took the tests to the open road by creating a mobile testing rig. Sensors attached to the tailpipe captured the emissions and fed the data to testing equipment stored in the trunk and backseat of the cars. The test results captured the greater emissions and lower fuel efficiency since the cheat code was disabled on open road conditions. Upon discovering the discrepancies and conducting multiple follow up tests, WVU contacted the EPA and the California Air Resources Board, who conducted their own tests and issued a citation to VW.

Read More

Twitter API and Legal Issues for App Developers

Much has been made lately of tension between Twitter and its outside developers.  The issues stoking the fire are less legal issues than business issues brought to front-burner by two particular factors:

(1) The maturity of Twitter as a development platform, or in the words of Ryan Sarver of Twitter, “In the early days, all the clients except Twitter.com were built out by ecosystem companies, mainly because Twitter was so focused on keeping the lights on.  But we learned that in order for us to really grow, we had to start taking over that core experience.” (quoted in the NY Times, 7/17/11).

(2) A reported Federal Trade Commission inquiry into the relationship by the , which has (in some views) caused Twitter to re-think its liberal open-door policy when it came to permitting outside development on its platform.

An excellent story and accompanying podcast on this subject appeared in the NY Times last week, written by Claire Cain Miller.

Bottom line: Twitter is seeking to control the applications that control access to Twitter, meaning desktop and mobile, and leaving the field open to enterprise applications, usability applications, analysis and similar applications.

Certainly the business reasons seem pretty clear, in that Twitter seeks to control core functionality – and the development of that core functionality – of the mother ship.  Although it is not terribly surprising that that strikes some critics as cynical, see for example here (“Twitter, just be honest: ‘The only way we can figure out how to make money is same ol’ display ads and we need to own the client for that.’”)

There are legal issues here, namely the ability of the platform to restrict access to its API.  As Claire Miller and others have noted, part of the problem for Twitter is that developer expectations may have been artificially inflated.  But there is more.  The FTC hint of antitrust scrutiny may be causing Twitter some heartburn about its historical open-ness.  Some analogy from two unrelated contexts: In trademark law, the concept “use in commerce” requires confirmation of continued public use of a registered trademark every 5 years or so.  In real property law, a property owner’s failure to restrict public access to property – and thus demonstrate its private claim – can, under some circumstances, support a court’s granting a permanent public right of way.

Quoting Rob Diana from Regular Geek, “Twitter also now owns the platform as a whole and must be as reliable as a utility company.  They must provide all of the capabilities that consumers need in the clients.” (emphasis added) A danger for a “public utility” of the information superhighway is creeping expectation of the duties and obligations of public purpose: Loss of commercial freedom, permanent regulatory scrutiny and public stakeholder claims.  It may very well be that Twitter is acting much like New York’s Rockefeller Center, which closes public access to traffic one day a year as a legal “fiction” in order to continue to assert private ownership rights.

Twitter rolled out its new API TOS (“Developer Rules of the Road”) in March of this year.  Rob Diana noted at that time that the announcement may have been – or perhaps should have been – anticlimactic, in that “A basic Twitter client is a terrible idea in today’s ecosystem.”  Wrote Diana:

Unless there is major functionality outside of the existing solutions, a new client is a losing idea. There is a high barrier to entry when we already have third-party clients like Tweetdeck, Seesmic, HootSuite and PeopleBrowser. This does not include some of the other applications that focus on team or brand management. So, by saying not to develop a new client, Twitter has saved us and investors a lot of time and money.

Read More

App and Software Ownership – Misidentification of Value

You go into a conversation from a lawyer’s perspective, expecting the discussion to be all about “ownership, ownership and ownership”.  You might expect app and other software developers to focus on nothing other than ownership.

Many times you’d be wrong.  One problem with ownership: Misidentification of value.

As Dan Berger of Social Tables pointed out, many technology companies aren’t strictly “technology” plays at all, and their value isn’t in their code, but rather in their execution or implementation.

I recently spoke with Eric Gunderson of Development Seed, whose open-source mapping technologies illustrate the same principle of technology execution: In the case of Development Seed’s MapBox, the great strength is speed.  Big data use means great mapping potential, but also means big processing problems.  Big processing problems reward innovative design execution.  If speed of mapping capability and management of data is a priority, ownership is less of a concern than execution and capabilities.  This is true even with proprietary products rather than services.  One might of course say, “Use our system, use our product,” but why should we use it?  The answer is that you do something better than everyone else out there using comparable – and perhaps even identical – technologies.  You wrap it up and package it – and execute it – better and faster.

The coding is valuable, but the greater value is in the execution of the coding and coupling of the organic coding with acquired knowledge from third-party applications and libraries, including (for example) Javascript libraries and other open-source software under GPL, MIT or other licenses.

The code itself may, or may not be open-source, but the value often is in the packaging, in the delivery, in the execution and the support.  In reality, I – the end user – cannot do much with the code itself beyond the immediate and narrow need of my specific use, and that will be without support, without updates, modifications, improvements and all the other benefits from open-source collaboration.  From the developer’s standpoint, the ability to develop products that continue to feed a renewable support business drives further continued product development.

Whether or not open-source, Social Tables, like MapBox, can benefit from copyright protection as a “collective work” or compilation, and that protection has meaningful value.  But as Dan Berger of Social Tables is quick to recognize, the copyright protection has less meaning to his potential market than the elegance of his design and the ease-of-use of his execution.   As technologist Piotr Steininger told me recently, referring to SproutCore, with increasing use of open-source, developers – and technology businesses – have realized that “the framework has potential but it can only benefit from open collaboration.  So in a sense the company gives up a product but in return gains a better product by sharing it.”

Read More

Podcast #9: App Development Legal Issues: Open Source, Copyright, API Terms of Use and More


Today, we will discuss the business and, particularly, the legal landscape faced by application (App) developers dealing with mobile platforms (iOS, Android and Blackberry being dominant), including dealing with application interfaces (APIs) when developing based on existing applications, and, of course, client relationships.

I am joined today by Liz Steininger, co-founder of Tapangi Consulting and project manager in the DC Government’s Office of the Chief Technology Officer.  Tapangi Consulting specializes in mobile and HTML5 application development as well as content management.  Liz is also an active member of the DC Tech community and you can find her on Twitter as @liz315.

Some of the issues we discuss today are these:

  • Protecting ideas in early stages of pitching to potential clients.
  • Application developer agreements and API Terms of Use (TOUs).
  • Platform question: As a developer, how do you think about development based on different platform (e.g. Android or iOS or Blackberry) or a specific API?
  • Copyright and “open source” issues, GPL, libraries, use of third-party code.
  • Ownership and Rights Issues
  • Privacy and uses of personal information (PI).

Please click here for the podcast.

Read More

App Developer Legal Issues: API TOUs, Copyright and Trademark

Our Twitter chat last week with technology and entertainment lawyer Joy Butler highlighted legal issues with app development, including contract issues between app developers and clients, on one end, and intellectual property (IP) and API issues between the app and the intended development platform, on the other end.

Privacy issues become pressing later when the app goes public for end users, although the biggest privacy problems tend to arise when app publishers get tripped up by commitments made in their own end user license agreements (EULAs) or privacy policies, more so than from any violations of privacy laws.  More on privacy and the app/API problems in a separate blog post.

Immediate issues are copyright and trademark, both governed by federal laws, but also governed by API terms of use and similar application development agreements with hosting platforms.  Apple’s software developer kits (SDK) for the iPad and iPhone encompass similar purposes as part of broader packages of developer protocols for use of those APIs.

Read More

Twitter Chat: App Development/API Legal Issues with Andrew Mirsky and Joy Butler

The following is our first twitter chat on trending legal issues. This one focused on legal issues involved with app development and APIs and featured thoughts from attorneys Andrew Mirsky and Joy Butler (@joybutler). Be sure to stay tuned to the @MirskyLegal twitter account for more information on the next #lawchat and please tweet in using the provided unique hashtag!

Read More

Software License vs. Sale: Copyright’s “First Sale”

An interesting case comes out of the West earlier this month under Copyright law’s “first sale” doctrine, involving computer software under a license agreement.

Copyright’s “first sale” doctrine

The “first sale” doctrine involves this concept: If you buy a copyrighted work (say, a painting, or a book, or – as in this case – software – you have an unqualified right to transfer your copy of that work to anybody as you please.  That doesn’t mean you can make additional copies and sell those too, but generally it does mean that you are free to resell something that you purchase.  (As will be discussed below, the operative term is “purchased”.)

The doctrine was first recognized by the Supreme Court in a 1908 case, and later codified by Congress into the Copyright Act in the 1976 amendments to the Act.

Read More