2016年，微夢公司（新浪微博的運營商）以“第三方數據侵權”為由起訴淘友技術公司、淘友科技公司（脈脈軟件和脈脈網站的共同運營商），并最終勝訴（下稱“脈博之爭”）。該案件被稱為“大數據不正當競爭第一案”，轟動一時，引起互聯網公司對第三方應用的關注。2019年，騰訊計算機公司、騰訊數碼公司和騰訊科技公司（微信、QQ的共同運營商）再次以“第三方數據侵權”為由起訴北京微播視界公司（抖音運營商）、北京拍拍看看公司（多閃運營商），由于本案兩造（下稱“頭騰大戰”）分別坐擁數億用戶，影響性遠勝“脈博之爭”，因此，第三方應用如何合規運營的爭議又一次被迅速激起。
所謂的“第三方應用”，是指APP運營商為了快速積累用戶資源，與開放平臺簽訂《開發者協議》，通過開放平臺的應用編程接口（OpenAPI）接入平臺，在成為平臺生態圈組成部分的同時，利用雙方的段位差，將平臺的用戶流量順勢導入自己的應用程序，這些APP運營商被稱為“第三方應用”。其中，“脈博之爭”的第三方應用指代“脈脈”，“頭騰大戰”的第三方應用指代“抖音”和“多閃”。
由上可知，開放平臺和第三方應用本是互聯網生態圈相互依賴的存在，為什么兩者會出現難以調和的矛盾呢？網上傳得紛紛揚揚的“脈博之爭”和“頭騰大戰”究竟在吵什么？法院對“脈博之爭”和“頭騰大戰”是怎么判的？法院的判決對第三方應用以后的發展有何影響？第三方應用該如何做好數據合規工作？下文中，筆者將結合“脈博之爭”的判決書和“頭騰大戰”的裁定書，逐一分析并解答上述疑惑。
一、“數據之爭”吵什么？
“脈博之爭”和“頭騰大戰”的本質實際上是“數據之爭”，是微博、微信和QQ平臺不愿開放數據給脈脈、抖音和多閃等第三方應用，但是脈脈、抖音和多閃等第三方應用仍試圖多途徑獲取數據的喂養。具體而言，開放平臺一般允許第三方應用在接入應用程序接口（OpenAPI）后，僅能獲取平臺用戶的頭像、名稱等基礎數據，并且頭像和名稱僅能作為登陸的依據，不能援作他用；然而第三方應用為了快速構建自己的社交鏈或者完成用戶的原始積累，更傾向于獲得平臺用戶更多的數據，以及將數據應用于更多的場景中，兩者相互背離的訴求最終引爆了“數據之爭”。
（一）“脈博之爭”吵什么？
在“脈博之爭”中，微博的訴求有二：第一，微博控訴脈脈非法抓取新浪微博的用戶信息，用戶信息包括頭像、名稱、職業信息、教育信息、用戶自定義標簽及用戶發布的微博內容；第二，微博控訴脈脈利用用戶手機通訊錄與新浪微博用戶的對應關系構建脈脈的社交鏈。
該案爭點在于微博認為脈脈獲取的用戶信息已經超過了《開發者協議》約定的范疇，此外，脈脈還在構建自己的社交鏈上具體運用了用戶信息。換言之，脈脈不僅在用戶信息的“獲取鏈”上存在問題，在“應用鏈”上也存在問題。對此，脈脈的抗辯理由是微博用戶信息的獲取，或是得到用戶的授權同意或是利用技術手段獲取，不存在非法獲取的問題，進而社交鏈的建構也就不存在問題。
（二）“頭騰大戰”吵什么？
在“頭騰大戰”中，騰訊的訴求有四：第一，騰訊控告抖音在向用戶推薦好友時使用了平臺數據；第二，騰訊控告抖音向第三方多閃提供了平臺數據；第三，騰訊要求抖音和多閃立即刪除平臺數據；第四，騰訊要求多閃不得在構建社交鏈時運用平臺數據。
該案爭點在于騰訊認為抖音未經授權許可，將用于登陸功能的平臺數據不僅運用于構建社交鏈，還將平臺數據傳輸給第三方，作為第三方登陸的接口，并且第三方還運用該數據構建社交鏈。對此，抖音的抗辯理由是抖音對用戶數據的獲取已經得到了用戶的授權同意。
可以看出，“頭騰大戰”較之于“脈博之爭”，法律上的問題更為復雜。“脈博之爭”的焦點在于脈脈是否越權獲取了微博數據以及是否在社交鏈構建中運用了微博數據。“頭騰大戰”的焦點除了抖音是否將用于登陸功能的數據用于建構社交鏈外，還涉及是否將平臺數據轉授權給第三方，并允許第三方運用數據建構社交鏈。兩者之間的爭點詳見下圖：
二、“數據之爭”怎么判？
從上述內容可以看出，無論是“脈博之爭”還是“頭騰大戰”，它們的訴訟爭點大致相同，即開放平臺認為自己擁有用戶數據的占有權，第三方應用侵犯了自己的占有權；而第三方應用認為自己使用用戶數據已經得到了用戶授權同意，并沒有侵犯開放平臺的權利。針對此類訴訟糾紛，兩起案件的法院一致認為開放平臺擁有的用戶數據是平臺重要的商業資源，開放平臺有權維護自己的商業利益，并都做出了有利于開放平臺的判決和裁定。
（一）“脈博之爭”怎么判？
在“脈博之爭”中，針對脈脈非法抓取用戶信息，一審法院認為脈脈既侵犯了開放平臺的合法權益，同時侵犯了用戶的知情權。首先，法院認為微博用戶是微博的重要商業資源，這些用戶信息是微博開展經營活動的基礎，也是保持競爭優勢的必要條件，脈脈的行為侵犯了微博的合法權利；其次，法院認為脈脈抓取用戶信息并且將其應用在社交鏈上侵犯了用戶的知情權。
二審法院在肯定一審法院判決的基礎上，總結OpenAPI開發合作模式中第三方應用應遵循“三重授權”原則，即開放平臺向第三方應用開放數據的前提是開放平臺已經取得了用戶的同意，第三方應用在使用用戶信息時還應當明確告知用戶其使用的目的、方式和范圍，再次取得用戶的同意。因此，在OpenAPI開發合作模式中，第三方應用通過OpenAPI獲取用戶信息時應堅持“用戶授權”＋“平臺授權”＋“用戶授權”的三重授權原則。
最終，一二審法院一致認為脈脈非法獲取或應用數據的行為損害了公平的市場競爭秩序，一定程度上損害了微博的競爭利益，因此支持微博的訴訟請求，判決脈脈立即停止涉案不正當競爭行為，并賠償微博經濟損失200萬元及合理費用208998元。
（二）“頭騰大戰”怎么判？
在“頭騰大戰”中，法院同意“脈博之爭”中二審法院提出的“三重授權”原則，認為該原則已經成為開放平臺領域網絡經營者應當遵守的商業道德。同時，法院進一步規定第三方應用在獲得平臺授權后，在數據的獲取和使用中應遵循“合理、正當、必要”原則，即第三方應用僅能將數據用于登陸目的，而不能用于授權登陸外的任何用途，因此第三方應用既不能將用戶數據用于社交鏈的建構，也不能將數據轉授權給第三方，轉授權的第三方更不能使用該數據。
換言之，“頭騰大戰”中法院在肯認“脈博之爭”提出“三重授權”原則的基礎上，又細化了“三重授權”中“平臺授權”的具體要求，即經平臺授權的數據要遵循“最小必要原則”，平臺授權的數據僅能用于登陸目的。基于此種思路，法院裁定抖音和多閃的行為已經侵犯了騰訊的合法權利，因此支持騰訊提出行為保全的訴請，要求抖音和多閃立即停止侵權的行為。
三、“數據之爭”怎么看？
從“脈博之爭”到“頭騰大戰”，實際上法院在實務操作中已經建構出一套具體審理第三方應用的審查基準，即首先數據控制者在遵循“合理、正當、必要”原則的基礎上，在獲取用戶同意后可以收集并使用用戶的信息；因數據控制者經過多年的苦心經營，累積了大量的用戶數據，這類用戶數據是數據控制者的商業資源，數據控制者對其擁有合法權益，任何第三方非法獲取或使用該類數據，將會侵犯數據控制者的合法權益；第三方應用如果想快速獲取用戶流量，可與數據控制者簽訂《開發者協議》，在經過數據控制者授權同意后，通過應用編程接口（OpenAPI）接入平臺，但第三方應用對于平臺數據的使用十分有限，并且該部分數據僅能適用于登陸目的，無法援作他用。同時，第三方應用在經過平臺授權后，還需要經過用戶的另一次同意，才能最終完成數據的登陸使用。第三方應用的審查基準流程詳見下圖：
從上述內容可以看出，實務操作中，司法機關不僅認可數據控制者對用戶數據享有商業權利，并且賦予這種權利極大的保護。例如，“頭騰大戰”中法院具體要求“平臺授權”下第三方應用對數據的使用僅限于登陸目的，實際上該規定已經框限住第三方應用對該部分數據的應用，該部分數據自始至終都只能用于登陸目的，第三方應用即使獲得用戶授權也不能進行任何數據的再收集和再處理，無形之中數據已經被開放平臺所獨占使用。
實際上，筆者認為法院所確認的“三重授權”原則存在一定的討論空間。法院認為第三方應用需要經過“平臺授權”，但是“平臺授權”的權利來自哪里？法院認為“平臺授權”的權利來自平臺對用戶資源的長期管理和使用，也即平臺本身的長期積累使其自動獲得對用戶數據的占有權。那么，當平臺不愿意授權給第三方應用，但用戶認為平臺需要授權給第三方應用的情況下，如何處理該類問題？按照法院的觀念，是否在這種情況下，用戶已經喪失掉自己對數據的所有權，無權要求平臺授權第三方應用？如果真出現這種情況，是不是已經和“用戶信息自決權”的理念發生了背離？
仔細研究會發現，即使是騰訊平臺本身，都不認為自己擁有了主動轉移數據的權利。微信的《隱私政策》規定微信不會主動共享或者轉移用戶的個人信息到騰訊集團外的第三方，除非征得用戶的明示同意；
[①]QQ的《隱私政策》同樣規定未經用戶同意，QQ以及QQ的關聯公司不會與任何第三方分享用戶的個人信息。
[②]可見，即使是開放平臺本身，都認為用戶數據的所有權始終歸于用戶所有。而將眼光投向國外會發現，針對用戶數據轉移的行為，歐盟制定的《一般數據保護條例》（General Data Protection Regulation,簡稱GDPR）已規定用戶擁有可攜帶權，即權利主體有權從控制者處獲得結構化、通用化的，機器可讀的，能共同操作的以格式形式提供的個人數據，并允許該等數據傳輸給其他控制者。
[③]換言之，歐盟針對第三方應用所設置的審查基準是“雙重授權”原則，即“用戶授權”+“用戶授權”模式。而中國為維護數據控制者的權利，在雙重授權之外，再追加“平臺授權”，構成“三重授權”模式。
當然，歐盟的個人信息保護法根植于歐盟對隱私權本源的追求，所以其成文法上的規定更側重于數據主體的權利保護。由于國情不同，我國對于隱私的重視程度不如歐盟，相反地，我們更側重于“奉獻自我，成就集體”，效率的發揮顯得尤為重要，因此實務中賦予開放平臺權利，以激發市場競爭活力的行為便可以理解。但筆者認為即使實務操作允許“平臺授權”，但現今“平臺授權”的審查基準仍顯粗糙，為避免出現“平臺不愿授權第三方應用”與“用戶執意授權第三方應用”之間的矛盾，“平臺授權”的規則應作更精細的技術設計。
四、第三方應用如何做好數據合規？
眾所周知，隨著云計算、物聯網、人工智能等高新技術的快速發展，數據已經成為互聯網公司的核心資產，大多數互聯網公司都已將數據保護上升至公司戰略的高度。因此，即使開放平臺開放了應用編程接口（OpenAPI），但它們并不會放棄對數據的保護，相反地，它們會設置各種限制第三方應用獲取數據的要求；而另一方面，第三方應用要想存活，就需要用戶數據的喂養，獲得用戶數據是它們的天然屬性。“脈搏之爭”和“頭騰大戰”便是開放平臺與第三方應用之間矛盾無法調和的產物，并且該糾紛只是開端，第三方應用如不做好數據的合規審查，糾紛還會繼續出現。那么，第三方應用該如何做好數據的合規審查呢？筆者認為可從以下幾個方面入手：
第一，由于“三重授權”原則已經獲得實務上的認可，因此對于平臺授權第三方應用的數據，該類數據僅可作為登陸目的使用，不能用于其他目的。第三方應用應運用技術手段，嚴格區分平臺授權下獲取的數據和自身獲取的用戶數據，建立隔離機制和定期審查機制，并對自身獲取用戶數據進行安全備份，以便當自身獲取的數據與平臺授權的數據發生競合時，有抗辯的依據。
第二，當第三方應用完成初期的用戶積累后，如果OpenAPI開發合作模式不能再促進第三方應用有效地導流，由于“平臺授權”因素的干擾，第三方應用往后不僅很難完成有效導流，更可能因為《開發者協議》的規定掣肘了自身獲取用戶數據的能力。當出現這種情況時，筆者認為第三方應用應果斷放棄OpenAPI開發合作模式，而選擇運用別的模式引流。
第三，如果第三方應用同時也是開放平臺，那么第三方應用在草擬《開發者協議》中要做好自身數據的保護措施，可規定數據收集方在收集用戶任何數據時，必須事先獲得用戶的明確同意，且僅應當收集為應用程序運行及功能實現目的而必要的用戶數據，同時應當告知用戶相關數據收集的目的、范圍及使用方式等，保障用戶知情權。
[③] 京東法律研究院.歐盟數據憲章:《一般數據保護條例》GDPR評述及實務指引[M].北京：法律出版社，2018.63.
