Showing posts with label patent. Show all posts
Showing posts with label patent. Show all posts

Wednesday, May 02, 2018

State of Intellectual Property protection, or lack of thereof, by cloud services providers

In 2015 AWS started making the news regarding its aggressive “Non-Assert Clause” in its terms of services. This type of clause exists to protect the cloud providers from being sued for patents, copyrighted works or trademarks infringement by their customers in perpetuity. 



Now, most explanations given for the use of these type of clause tends to revolve around open source and patent troll defence. While patent troll defence is rather obvious, open source defence is slightly more tenuous but still valid. If Amazon uses your open source (in some way that is a violation of the license), and you use AWS, you can't sue them. 
However, it became slightly more difficult to digest when such clause is used to fight a patent suit. Which indicate that any cloud provider using such clause could duplicate your products without fear of legal repercussion.

Fast forward a couple of years later, AWS start to feel a little bit more pressure from its competitor and drops its controversial clause in July 2017. This is perceived to be a move to woo the more traditional enterprise market that starts to adopt cloud deployment. The objective is to reassure more legally astute customers.
A month later AWS also decided to mimic to some extent Microsoft Azure patent protection scheme. While not as extensive as Azure offering this is still a start. Microsoft IP shared protection is far more comprehensive than AWS as it expands the company’s existing indemnification policy to include its patents portfolio available to Azure customers to help defend themselves from possible infringement suits; and pledges to Azure customers that if Microsoft sells patents to an NPE they can never be asserted against them. 
The shared protection scheme is quite attractive as well as dangerous for the provider. If one customer falls prey to an IP lawsuit and loses because of a cloud provider infringement. This can become really quickly a complete bloodbath as every customer might become a target. Because of such scheme, the cost can easily snowball. As a result, I can only foresee the biggest player in the fields offering such protection.

I decided to do a quick check to see the current state of the cloud provider terms of services regarding IP protection or lack of thereof. I specifically focused on trying to pinpoint which one used the “Non-Assert Clause” and which one offer Share protection ( to varying degree) in the Table below. 



Cloud Provider
Share protection
No Non-Assert Clause
Reference
AWS
🗸 (since Aug 2017)
🗸 ( since July 2017)
Azure
🗸
🗸
Google
🗸
🗸
Digital Ocean
Clause 15.2
Oracle
🗸
🗸
SAP
Clause 10.3
OVH (VmWare)
🗸
Alibaba Cloud
🗸

Disclaimer: I am not a lawyer, and this is based on documents available at the time of publication. The terms can change at any time and you are free to try to negotiate terms with your cloud providers yourself. In any case, I recommend having a qualified lawyer to give you advice on this matter.



The result: Pretty much all cloud provider DO NOT use Non-Assert clause except two: Digital Ocean and SAP. While I would understand why Digital Ocean might do that based on their business model and market size. SAP seems a little bit more surprising in their aggressive stance. However, its customers tend to be more legal savvy and might negotiate the clause out more easily.
When it comes to shared protection scheme, half of the provider do not mention any shared protection scheme. As for the other half, your mileage may vary. Azure offer the most comprehensive one. While most of the others that do offer a protection tend to offer legal and/or financial support only.

It is clear that, as more institutional customer move to the cloud, providers will gradually need to offer more legal protection regarding intellectual property risks. However, this might come at a cost and risk that only the biggest one will be able to bear.

Tuesday, September 05, 2017

[Links of the Day] 05/09/2017 : Patent Surviving Alice, Hot Cloud 17 conference papers

  • 7 Post-Alice Patent Cases That Survived 101 Rejections : Alice US supreme court decision started a slaughter in the US patent office regarding IT related patent: 8400 applications dropped and 60k+ rejected. While courts invalidated the vast majority of patent litigation. However, it seems that there is a way to survive the onslaught, and it's quite simple. You just need your patent to satisfy the following criteria: novelty, enablement, non-obvious, and last but not least useful. it seems like a no brainer, but it seems that the USPTO allowed itself to be flooded by sub par applications that gamed the system. Not to mention that the agency financially gained from such practice to some extent also. 
  • Hot cloud 17 : hot cloud conference just finished, here is a selection of interesting paper
    • JavaScript for extending low-latency in-memory key-value stores : Adrian Colyer takes a look at in memory javascript engine using RamCloud. RamCloud project is entering the use case phase of the research project,  eyeing the comercialisation. Sadly most solution put forward are extremely niche. The risk is for great people to be stuck in a zombie startup if they try to run with it. Taking separately, the tech that came out of the RamCloud project is amazing. However, the solution as a whole doesn't really have a great killer app or any potential beyond some niche market.  [paper]
    • Towards Index-based Global Trading in Cloud Spot Markets :  the authors propose to use an index based prediction model rather than per spot instance in order to obtain greater reliability at lower cost.
    • DAL: A Locality-Optimizing Distributed Shared Memory System :  Different take on the whole in memory K/V system, the authors aggressively move the data to the computation rather than offering remote access. This allows great data reuse. We used something similar in hecatonchire. However, there is a certain risk when you have a high level of churn or serial data access and local caching of data generate a high level of eviction, effectively doubling the bandwidth usage. 
    • Leader or Majority: Why have one when you can have both? : raft is a great consensus protocol ( and easier to understand). However, the over reliance on the leader is the main bottleneck for scalability of operations. The authors ( from cockroachdb ) propose a quorum based read operations that allow alleviating the load on the leader while still retaining strong consistency. This allows them to improve write by 4x write perf and increase throughput by 60%. Which is quite impressive. 
    • DCCast: Efficient Point to Multipoint Transfers Across Datacenters : the authors proposed an efficient multipoint data transfer protocol allowing greater efficiency and bandwidth usage.


Wednesday, October 21, 2015

Links of the day 21/10/2015: #blockchain consensus protocol, Awesome #aws resources, Killing patents