DMCA、Easylist、Adblock、版權訪問控制和海軍上將：要知道的 10 件事

已發表: 2017-08-11

Admiral 要求 Easylist 從他們的過濾器中刪除functionalclam[.]com，原因如下：

functionalclam[.]com 不是廣告服務器。
該域是 DMCA 版權訪問控制平台的一部分，Admiral 為出版商提供，因此他們可以以透明的方式讓訪問者參與其受版權保護的內容的價值交換，而不是像我們的一些競爭對手所提倡的那樣，採取意外的廣告重新插入，但訪問者和廣告商不喜歡。
繞過出版商的付費牆或版權訪問控制技術是不行的，我們認為這不是 AdBlock Plus 和 EasyList 使命的核心。
在過去的一年中，我們通過多次直接溝通與 EasyList 和 ABP 分享了這一點。
我們在 24 天前要求他們在原始提交中刪除 functionalclam[.]com。
他們的回應似乎表明他們只會在 GitHub 同意的情況下採取行動。
因此，我們遵循了 GitHub 提交 DMCA 刪除通知的指南，它們需要用於“代碼 [that] ... 用於規避訪問控制”。
我們特別要求提供一種保護存儲庫免受破壞的解決方案——從過濾器中刪除 Admiral 的域。本著透明的精神，我們在下麵包含了該請求。
GitHub 聯繫了 EasyList 以不繞過 Admiral 的平台。
EasyList、ABP 和其他廣告攔截器昨天停止了規避functionalclam[.]com，並在評論中進一步澄清說：“如果它是規避/Adblock-Warning 廣告主機，即使不需要 DMCA 請求，也應該將其從 Easylist 中刪除。”

我們同意並感謝合作解決這個問題。 Admiral 仍致力於在未來與 EasyList、ABP 和其他廣告攔截器合作，以解決此類誤解。我們都在嘗試以自己的方式為子孫後代創建一個可持續的網絡。出版商和訪問者之間的透明參與是其中的關鍵部分。

DMCA 請求重新：Admiral DMCA 版權訪問控制平台

*提交日期：2017 年 8 月 1 日

是的

請提供涉嫌侵權的原始版權作品的詳細說明。如果可能，請包含一個指向其在線發布位置的 URL。

有問題的代碼試圖通過在代碼中添加 functionalclam[.]com 來規避對本次提交標題 (https://github.com/easylist/easylist/commit/1ba8d4afeec6d562a5871fc7504c756e4b2bd5bc) 中列出的站點上受版權保護的內容的版權訪問控制存儲庫。

GitHub 的 DMCA 指南 https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/ 建議使用此流程來處理這種特定情況：“代碼 [that] 可能被指控侵權，而不是因為它是直接複製的，但因為它是用來繞過訪問控制的。”

根據 § 1201(a)(3)(B)，如果“在其正常運行過程中，它需要應用信息、過程或處理，”技術措施“有效地控制對作品的訪問”，在版權所有者的授權下，可以訪問該作品。” 本案中版權所有者使用的版權訪問控制平台正是這樣做的，只有在訪問者滿足版權所有者授權訪問內容的訪問條款後，才允許訪問網站上的受版權保護的內容。版權訪問控制平台有多個部分，包括但不限於域功能clam[.]com上的代碼，稱為有效控制對內容的訪問的技術措施的一部分。

應該刪除哪些文件？請提供每個文件的 URL，或者如果是整個存儲庫，請提供存儲庫的 URL：

該文件是
https://github.com/easylist/easylist/blob/
1ba8d4afeec6d562a5871fc7504c756e4b2bd5bc/easylist/easylistadservers.txt
但我們認為不需要完全刪除存儲庫來解決此問題。見下文。

您是否搜索過涉嫌侵權的文件或存儲庫的任何分支？每個分叉都是一個不同的存儲庫，如果您認為它侵權並希望將其刪除，則必須單獨識別它。

是的。此請求特定於此文件。如果我們發現進一步的規避嘗試，我們也可能會遵循 GitHub 的推薦流程。

作品是否在開源許可下獲得許可？如果是這樣，哪個開源許可證？涉嫌侵權的文件是在開源許可下使用，還是違反了許可？

不

對於涉嫌侵權的最佳解決方案是什麼？除了刪除之外，其他人是否可以進行特定更改？

不需要完全刪除存儲庫。相反，存儲庫所有者可以從相關文件中刪除functionalclam[.]com，而不是替換為替代規避嘗試。

我們建議先通過直接請求存儲庫進行此更改，但我們的請求不成功。我們希望這可以通過我們提出的解決方案以協作的方式解決。 GitHub 的通知流程有助於糾正 17 USC § 1203(c)(5) 意外或無害的違規行為，並確保不會對未來的 DMCA 版權訪問控制規避產生混淆或無知。

如果針對文件或存儲庫報告了進一步的規避嘗試，我們可能會按照 GitHub 對文件、存儲庫或重複侵權者帳戶級別的推薦流程進行處理，如 GitHub 的 DMCA 政策第 E 節所述：https://help.github.com /articles/dmca-takedown-policy/

你有被控侵權人的聯繫方式嗎？如果有，請提供：

我們沒有存儲庫所有者的聯繫信息。我們有關於上傳規避的提交提交者的詳細信息，但我們無法確認他們是否是存儲庫所有者。從 GitHub 的 DMCA 流程中獲取存儲庫所有者的聯繫信息和對管轄權的同意，以在未來合作解決此類問題將很有幫助。

我已閱讀 GitHub 提交 DMCA 刪除通知的指南：https://help.github.com/articles/guide-to-submitting-a-dmca-takedown-notice/
*

感謝您閱讀本文。

有關 Admiral 如何幫助您的網站保護其受版權保護的內容的更多信息，請聯繫我們。