Communications of the ACM
Software Stories: Legal Trouble
Software development can be hard enough just dealing with bits and bytes. Legal troubles represent another collection of potential pitfalls where developers often find themselves unprepared. Any organization either writing or utilizing or development software should periodically conduct a legal review to determine whether a) the organization is in any trouble now, or b) the organization is likely to be in trouble in the future. These are some of my own experiences on these topics.
Open Source Software
There are many types of open source software licenses, and this is a rough categorization of license-types based on potential liabilities:
Generally Permissive – Apache, MIT, etc.
Potentially Restrictive – LGPLv2, etc. The most common area of concern are software redistribution clauses.
Talk To Your Lawyer – LGPLv3, Affero (all versions), etc. More changes to licenses, especially for redistribution & cloud services.
Keeping track of open source licenses is harder than it sounds and often taken for granted. A software company going through technical due diligence for an acquisition, for example, will typically need to have their codebase reviewed by a 3rd party and explain the origins and license for every library and .jar file. The middle of due diligence is a bad time to discover pervasive or critical usage of a library with an unfavorable or non-compliant license. Even aside from an acquisition scenario, there can be real legal consequences for businesses from violating redistribution clauses and other license strictures. It's best to stay on top of this and avoid potential problems in the first place.
Commercial Software
Commercial software represents some portion of just about any software solution, but keeping track of the licenses can be a challenge given the myriad ways software can be licensed.
Commercial Licenses – The good news is there are many options for licensing software. Per CPU socket? Per core? Per machine? Per cluster? Or it could be licensed per storage utilized (e.g., per MB/GB/TB). Or perhaps named user or concurrent users. The bad news is that there are many options for licensing software.
OEM Licenses – An "OEM" (Original Equipment Manufacturer) license is one where a component is licensed inside a larger solution and the user of the outer solution isn't supposed to be aware of – and be able to utilize – the internal component. I would expect this type of arrangement was more common in on-premise deployments of software solutions, but it will probably never totally go away. In a prior company we OEM'd an embedded database from a well-known company known for aggressive sales tactics. Getting audited at least once on how we were utilizing their product was unfortunately a cost of doing business. OEM agreements can be useful, but the devil is in the details, and it takes a lot of communication between the technical partners to make sure nobody feels that they are being taken advantage of or overly burdened.
Cloud Native Services – This is worth a mention because usage-based (e.g., invocation, CPU time utilized, data scanned, etc.) billing is at the heart of cloud native services, and such services are now widely utilized in solutions based on public cloud platforms. The good news is that this makes service/component licensing simpler and initial release of a solution arguably easier. But as with so many things in computing there are trade-offs, and often the next set of challenges are about optimizing usage of said services and reducing service charges which will build up automatically as the solution grows. Nothing is ever free from cost or worry.
Patents
Patents are one of those subjects that people either care a lot about or they don't think about at all.
I have some software patents and most came from my time at IBM. While I like to think of myself as reasonably innovative, using the number of patents as a measure-stick of innovation is limiting because the patent process is now dominated by large companies who have the resources to spend large amounts of money on patent attorneys. IBM's innovation process is probably typical of other large corporations in that there are "innovation points" granted per patent application per inventor, and then a few more points and a certificate suitable for framing are granted in the event a patent is issued. There is a small amount of money attached (~$1,500 for application, ~$750 for issue, or there abouts) as well. There are "innovation plateaus" that come with small bonuses, and another certificate suitable for framing. My patent collection is small potatoes compared to researchers with 50 or 100 patents or more, as from a corporate perspective it's rarely about a single patent anyway but rather a *portfolio* of patents. It's about building a shield-wall of intellectual property. Or a bludgeon. Or both.
A curious corporate example was a patent application that was filed when I was at Explorys, a healthcare analytics startup. IBM later acquired Explorys. That patent was still working its way through the system for a few more years, but it was eventually issued while I was still at IBM. Even though I was an IBM employee and IBM was now the holder of that patent, IBM would not award any "innovation points" to the co-inventors (me being one of them) - the rationale being that it was not invented "on IBM time." This denial seemed overly and humorously cheap given that there was so little at stake for the co-inventors at this point besides a few hundred dollars and another certificate suitable for framing. Such is life in the corporate innovation game.
Filing a patent application is one thing. *Defending* a patent is an entirely different proposition, and this is where the patent system gets both expensive and ugly. I haven't experienced this myself as most software engineers only experience the application part of the process, but an example described in Blood In The Water: America's Assault On Innovation is telling. Google managed to invalidate some targeted advertising patents from a small company called B. E. Tech that had been filed *before* Google was even a company. The fact that the PTAB (Patent Trial and Appeal Board) for that case was headed by a former Google executive, and that individual had the authority to stack the PTAB with similar sympathies, was an amazing coincidence.
Per Blood In The Water, the B. E. Tech inventor described the experience as "robbers break into my home and steal everything. I'm reeling because I've got nothing left. At least I know who did it. But then, as I'm getting ready to bring action against them, the robbers turn around and sue me for having owned the house in the first place. We go to court, and the judge rules in their favor, and awards them my house."
While just about anyone can file a patent application, patent defense and enforcement is dominated by large corporations. This would appear to be something in need of review, if not an overhaul, if we collectively wish the patent system to be anything more than a mechanism for generating certificates suitable for framing.
How To Get Deposed In A Lawsuit
In a prior job, our unit was named in a lawsuit. Specifically, our unit was named in a lawsuit aimed at the parent company. As was explained to me, the complaint originated from a company that had once worked with our parent company on a project but the business relationship had run its course, and it wasn't apparently an amicable breakup. This company was claiming that the parent company had taken their technology and was utilizing it in other efforts. If that were true that would indeed be bad, but our unit had never heard of this company so there was no way we could have appropriated said technology. Somebody still had to go on the record and say that, so this is where I had to learn how to get deposed in a lawsuit.
I had to fly to Manhattan and head to a fancy legal office, just like on TV. I was seated at the head of a rectangular table and across from me was a video camera and operator. At my left elbow was a court stenographer. On the left side of the table was opposing counsel, and on the right side was the counsel representing my company. I had to be sworn in. "This is just like TV," I thought. Getting deposed is a life experience however, like being almost mauled by a tiger or seeing a tornado far too up-close, that sounds cooler than it really is. Fortunately, I was prepared.
The essential preparatory lessons were:
- Answer the question that was asked.
- If somebody asks you about lunch on Wednesday, don't offer details about breakfast and dinner, much less describe the menu for Tuesday and Thursday.
- If confused, ask to speak to counsel.
- Invoke the phrase "I need to speak to counsel," just like on TV.
- Don't write anything down.
- This can be tricky for habitual note takers, as writing something down during a legal deposition is the same thing as saying it out loud.
I had to answer "No" or "No, that is not correct" for about 2 hours of questioning from opposing counsel, and that fortunately concluded my involvement in the litigation response.
Copyright Law
Copyright law is another category of potential problems. The long-running case between Oracle vs. Google on APIs that just went before the U.S. Supreme Court in 2021 is a prime example. I lived through an experience conceptually similar to that case. At a prior company, we were hired by a customer to integrate to a particular vendor system, however that particular vendor stated that our company couldn't do that because their APIs were copyright and proprietary, according to that vendor. The vendor in turn made stern warnings to the customer. I am not at liberty to say any more about that particular case, other than this got really ugly and had lots of lawyers involved, though it did not escalate anywhere near the Oracle vs. Google case.
Irrespective of how the Oracle vs. Google case ended, software engineers would be wise not to remove copyright law from the list of potential concerns. Per the Electronic Frontier Foundation article, the case is now apparently supposed to be known as "Google vs. Oracle" as Google petitioned to have the Supreme Court hear the case.
And Finally
Talk to your lawyer. And good luck.
References
Open Source Licenses: https://opensource.org/licenses/category
Google vs. B. E. Tech – Targeted Advertising Patent Case: https://www.ipwatchdog.com/2017/11/13/ptab-targeted-advertising-patents-google-ad- revenue/id=90076/
Blood In The Water: America's Assault On Innovation: https://bloodinthewaterbook.com/
Google vs. Oracle API Lawsuit: https://www.eff.org/cases/oracle-v-google
See Also
Explorys & IBM Watson Health: https://cacm.acm.org/blogs/blog-cacm/252055-what-happened-to-watson-health/fulltext
Doug Meil is a portfolio architect at Ontada. He also founded the Cleveland Big Data Meetup in 2010. More of Doug's ACM articles can be found at https://www.linkedin.com/pulse/publications-doug-meil
No entries found