文/李金招、蒋晓焜  

本文由作者投稿于无讼APP，未经作者许可禁止转载。

2016年，微梦公司（新浪微博的运营商）以“第三方数据侵权”为由起诉淘友技术公司、淘友科技公司（脉脉软件和脉脉网站的共同运营商），并最终胜诉（下称“脉博之争”）。该案件被称为“大数据不正当竞争第一案”，轰动一时，引起互联网公司对第三方应用的关注。

2019年，腾讯计算机公司、腾讯数码公司和腾讯科技公司（微信、QQ的共同运营商）再次以“第三方数据侵权”为由起诉北京微播视界公司（抖音运营商）、北京拍拍看看公司（多闪运营商），由于本案两造（下称“头腾大战”）分别坐拥数亿用户，影响性远胜“脉博之争”，因此，第三方应用如何合规运营的争议又一次被迅速激起。

所谓的“第三方应用”，是指APP运营商为了快速积累用户资源，与开放平台签订《开发者协议》，通过开放平台的应用编程接口（OpenAPI）接入平台，在成为平台生态圈组成部分的同时，利用双方的段位差，将平台的用户流量顺势导入自己的应用程序，这些APP运营商被称为“第三方应用”。其中，“脉博之争”的第三方应用指代“脉脉”，“头腾大战”的第三方应用指代“抖音”和“多闪”。

由上可知，开放平台和第三方应用本是互联网生态圈相互依赖的存在，为什么两者会出现难以调和的矛盾呢？网上传得纷纷扬扬的“脉博之争”和“头腾大战”究竟在吵什么？法院对“脉博之争”和“头腾大战”是怎么判的？法院的判决对第三方应用以后的发展有何影响？第三方应用该如何做好数据合规工作？下文中，笔者将结合“脉博之争”的判决书和“头腾大战”的裁定书，逐一分析并解答上述疑惑。

一、“数据之争”的争议焦点

“脉博之争”和“头腾大战”的本质实际上是“数据之争”，是微博、微信和QQ平台不愿开放数据给脉脉、抖音和多闪等第三方应用，但是脉脉、抖音和多闪等第三方应用仍试图多途径获取数据的喂养。具体而言，开放平台一般允许第三方应用在接入应用程序接口（OpenAPI）后，仅能获取平台用户的头像、名称等基础数据，并且头像和名称仅能作为登陆的依据，不能援作他用；然而第三方应用为了快速构建自己的社交链或者完成用户的原始积累，更倾向于获得平台用户更多的数据，以及将数据应用于更多的场景中，两者相互背离的诉求最终引爆了“数据之争”。

（一）“脉博之争”的争议焦点

在“脉博之争”中，微博的诉求有二：第一，微博控诉脉脉非法抓取新浪微博的用户信息，用户信息包括头像、名称、职业信息、教育信息、用户自定义标签及用户发布的微博内容；第二，微博控诉脉脉利用用户手机通讯录与新浪微博用户的对应关系构建脉脉的社交链。

该案争点在于微博认为脉脉获取的用户信息已经超过了《开发者协议》约定的范畴，此外，脉脉还在构建自己的社交链上具体运用了用户信息。

换言之，脉脉不仅在用户信息的“获取链”上存在问题，在“应用链”上也存在问题。对此，脉脉的抗辩理由是微博用户信息的获取，或是得到用户的授权同意或是利用技术手段获取，不存在非法获取的问题，进而社交链的建构也就不存在问题。

（二）“头腾大战”的争议焦点

在“头腾大战”中，腾讯的诉求有四：第一，腾讯控告抖音在向用户推荐好友时使用了平台数据；第二，腾讯控告抖音向第三方多闪提供了平台数据；第三，腾讯要求抖音和多闪立即删除平台数据；第四，腾讯要求多闪不得在构建社交链时运用平台数据。

该案争点在于腾讯认为抖音未经授权许可，将用于登陆功能的平台数据不仅运用于构建社交链，还将平台数据传输给第三方，作为第三方登陆的接口，并且第三方还运用该数据构建社交链。对此，抖音的抗辩理由是抖音对用户数据的获取已经得到了用户的授权同意。

可以看出，“头腾大战”较之于“脉博之争”，法律上的问题更为复杂。“脉博之争”的焦点在于脉脉是否越权获取了微博数据以及是否在社交链构建中运用了微博数据。“头腾大战”的焦点除了抖音是否将用于登陆功能的数据用于建构社交链外，还涉及是否将平台数据转授权给第三方，并允许第三方运用数据建构社交链。两者之间的争点详见下图：

二、“数据之争”的裁判结果？

从上述内容可以看出，无论是“脉博之争”还是“头腾大战”，它们的诉讼争点大致相同，即开放平台认为自己拥有用户数据的占有权，第三方应用侵犯了自己的占有权；而第三方应用认为自己使用用户数据已经得到了用户授权同意，并没有侵犯开放平台的权利。

针对此类诉讼纠纷，两起案件的法院一致认为开放平台拥有的用户数据是平台重要的商业资源，开放平台有权维护自己的商业利益，并都做出了有利于开放平台的判决和裁定。

（一）“脉博之争”的裁判结果

在“脉博之争”中，针对脉脉非法抓取用户信息，一审法院认为脉脉既侵犯了开放平台的合法权益，同时侵犯了用户的知情权。首先，法院认为微博用户是微博的重要商业资源，这些用户信息是微博开展经营活动的基础，也是保持竞争优势的必要条件，脉脉的行为侵犯了微博的合法权利；其次，法院认为脉脉抓取用户信息并且将其应用在社交链上侵犯了用户的知情权。

二审法院在肯定一审法院判决的基础上，总结OpenAPI开发合作模式中第三方应用应遵循“三重授权”原则，即开放平台向第三方应用开放数据的前提是开放平台已经取得了用户的同意，第三方应用在使用用户信息时还应当明确告知用户其使用的目的、方式和范围，再次取得用户的同意。因此，在OpenAPI开发合作模式中，第三方应用通过OpenAPI获取用户信息时应坚持“用户授权”＋“平台授权”＋“用户授权”的三重授权原则。

最终，一二审法院一致认为脉脉非法获取或应用数据的行为损害了公平的市场竞争秩序，一定程度上损害了微博的竞争利益，因此支持微博的诉讼请求，判决脉脉立即停止涉案不正当竞争行为，并赔偿微博经济损失200万元及合理费用208998元。

（二）“头腾大战”的裁判结果

在“头腾大战”中，法院同意“脉博之争”中二审法院提出的“三重授权”原则，认为该原则已经成为开放平台领域网络经营者应当遵守的商业道德。同时，法院进一步规定第三方应用在获得平台授权后，在数据的获取和使用中应遵循“合理、正当、必要”原则，即第三方应用仅能将数据用于登陆目的，而不能用于授权登陆外的任何用途，因此第三方应用既不能将用户数据用于社交链的建构，也不能将数据转授权给第三方，转授权的第三方更不能使用该数据。

换言之，“头腾大战”中法院在肯认“脉博之争”提出“三重授权”原则的基础上，又细化了“三重授权”中“平台授权”的具体要求，即经平台授权的数据要遵循“最小必要原则”，平台授权的数据仅能用于登陆目的。基于此种思路，法院裁定抖音和多闪的行为已经侵犯了腾讯的合法权利，因此支持腾讯提出行为保全的诉请，要求抖音和多闪立即停止侵权的行为。

三、“数据之争”的法律分析

从“脉博之争”到“头腾大战”，实际上法院在实务操作中已经建构出一套具体审理第三方应用的审查基准，即首先数据控制者在遵循“合理、正当、必要”原则的基础上，在获取用户同意后可以收集并使用用户的信息；因数据控制者经过多年的苦心经营，累积了大量的用户数据，这类用户数据是数据控制者的商业资源，数据控制者对其拥有合法权益，任何第三方非法获取或使用该类数据，将会侵犯数据控制者的合法权益；第三方应用如果想快速获取用户流量，可与数据控制者签订《开发者协议》，在经过数据控制者授权同意后，通过应用编程接口（OpenAPI）接入平台，但第三方应用对于平台数据的使用十分有限，并且该部分数据仅能适用于登陆目的，无法援作他用。同时，第三方应用在经过平台授权后，还需要经过用户的另一次同意，才能最终完成数据的登陆使用。第三方应用的审查基准流程详见下图：

从上述内容可以看出，实务操作中，司法机关不仅认可数据控制者对用户数据享有商业权利，并且赋予这种权利极大的保护。

例如，“头腾大战”中法院具体要求“平台授权”下第三方应用对数据的使用仅限于登陆目的，实际上该规定已经框限住第三方应用对该部分数据的应用，该部分数据自始至终都只能用于登陆目的，第三方应用即使获得用户授权也不能进行任何数据的再收集和再处理，无形之中数据已经被开放平台所独占使用。

实际上，笔者认为法院所确认的“三重授权”原则存在一定的讨论空间。法院认为第三方应用需要经过“平台授权”，但是“平台授权”的权利来自哪里？法院认为“平台授权”的权利来自平台对用户资源的长期管理和使用，也即平台本身的长期积累使其自动获得对用户数据的占有权。那么，当平台不愿意授权给第三方应用，但用户认为平台需要授权给第三方应用的情况下，如何处理该类问题？按照法院的观念，是否在这种情况下，用户已经丧失掉自己对数据的所有权，无权要求平台授权第三方应用？如果真出现这种情况，是不是已经和“用户信息自决权”的理念发生了背离？

仔细研究会发现，即使是腾讯平台本身，都不认为自己拥有了主动转移数据的权利。

微信的《隐私政策》规定微信不会主动共享或者转移用户的个人信息到腾讯集团外的第三方，除非征得用户的明示同意；[1]QQ的《隐私政策》同样规定未经用户同意，QQ以及QQ的关联公司不会与任何第三方分享用户的个人信息。[2]

可见，即使是开放平台本身，都认为用户数据的所有权始终归于用户所有。而将眼光投向国外会发现，针对用户数据转移的行为，欧盟制定的《一般数据保护条例》（General Data Protection Regulation,简称GDPR）已规定用户拥有可携带权，即权利主体有权从控制者处获得结构化、通用化的，机器可读的，能共同操作的以格式形式提供的个人数据，并允许该等数据传输给其他控制者。[3]

换言之，欧盟针对第三方应用所设置的审查基准是“双重授权”原则，即“用户授权”+“用户授权”模式。而中国为维护数据控制者的权利，在双重授权之外，再追加“平台授权”，构成“三重授权”模式。

当然，欧盟的个人信息保护法根植于欧盟对隐私权本源的追求，所以其成文法上的规定更侧重于数据主体的权利保护。由于国情不同，我国对于隐私的重视程度不如欧盟，相反地，我们更侧重于“奉献自我，成就集体”，效率的发挥显得尤为重要，因此实务中赋予开放平台权利，以激发市场竞争活力的行为便可以理解。但笔者认为即使实务操作允许“平台授权”，但现今“平台授权”的审查基准仍显粗糙，为避免出现“平台不愿授权第三方应用”与“用户执意授权第三方应用”之间的矛盾，“平台授权”的规则应作更精细的技术设计。

四、第三方应用数据合规的几点建议

众所周知，随着云计算、物联网、人工智能等高新技术的快速发展，数据已经成为互联网公司的核心资产，大多数互联网公司都已将数据保护上升至公司战略的高度。因此，即使开放平台开放了应用编程接口（OpenAPI），但它们并不会放弃对数据的保护，相反地，它们会设置各种限制第三方应用获取数据的要求；而另一方面，第三方应用要想存活，就需要用户数据的喂养，获得用户数据是它们的天然属性。

“脉搏之争”和“头腾大战”便是开放平台与第三方应用之间矛盾无法调和的产物，并且该纠纷只是开端，第三方应用如不做好数据的合规审查，纠纷还会继续出现。那么，第三方应用该如何做好数据的合规审查呢？笔者认为可从以下几个方面入手：

第一，由于“三重授权”原则已经获得实务上的认可，因此对于平台授权第三方应用的数据，该类数据仅可作为登陆目的使用，不能用于其他目的。第三方应用应运用技术手段，严格区分平台授权下获取的数据和自身获取的用户数据，建立隔离机制和定期审查机制，并对自身获取用户数据进行安全备份，以便当自身获取的数据与平台授权的数据发生竞合时，有抗辩的依据。

第二，当第三方应用完成初期的用户积累后，如果OpenAPI开发合作模式不能再促进第三方应用有效地导流，由于“平台授权”因素的干扰，第三方应用往后不仅很难完成有效导流，更可能因为《开发者协议》的规定掣肘了自身获取用户数据的能力。当出现这种情况时，笔者认为第三方应用应果断放弃OpenAPI开发合作模式，而选择运用别的模式引流。

第三，如果第三方应用同时也是开放平台，那么第三方应用在草拟《开发者协议》中要做好自身数据的保护措施，可规定数据收集方在收集用户任何数据时，必须事先获得用户的明确同意，且仅应当收集为应用程序运行及功能实现目的而必要的用户数据，同时应当告知用户相关数据收集的目的、范围及使用方式等，保障用户知情权。