小編精選 - 技術文章翻譯 · 08月20日

在 AWS 上驗證類似 YouTube 的服務時，碰上了電信事業法與著作權法的門檻

今，正在 AWS 環境下驗證能做到多像 YouTube 的影片串流服務。
影片上傳、轉碼、傳送基礎架構這一類，只要把 EC2、S3、CloudFront 組合起來，技術上其實都能正常運作。
但當我想再加上留言區或使用者之間的 DM 功能時，手突然就停住了。

「這會不會變成需要辦理電信事業申報的服務呢？」

一查之下，不只牽涉到電信事業法，還延伸到著作權法，以及資訊流通平臺對應法（舊《提供者責任限制法》），比我原本想像的門檻高很多。
我切身感受到「技術上做得出來」和「能不能公開上線」是兩回事，所以把查到的內容整理在這裡。

另外，我不是律師，所以這篇文章只是以個人開發者身分做的調查筆記。
如果真的要把服務當成正式事業長期營運，還是請務必諮詢專業人士。

是否「媒介他人的通信」，決定了電信事業法是否需要申報

先看電信事業法。依照是否自行持有線路設備，分成登記（第9條）與申報（第16條）；像 AWS 這種部署在雲端上的服務，因為不是自己鋪設線路設備，所以如果有適用的話，基本上會落在申報（許認可 Navi 的解說）這一側。

判斷的分水嶺是「是否媒介他人的通信」。
LRM 的解說很容易理解，簡單說就是：
「如果不是使用者彼此之間互相傳訊，而只是和服務提供者之間發生往來，或者根本沒有訊息功能，那就不需要申報。」
大致是這個意思。

套用到影片串流服務上，如果只是單向傳送影片，那就屬於「自己的通信」，不算「媒介他人的通信」。
反過來說，如果加入 DM、留言的即時雙向傳輸、直播聊天室的轉送這類
「媒介使用者之間的互動」
功能，就需要開始檢討是否有申報義務。

如果只是上傳自己的影片給自己看，其實幾乎是裸奔狀態

如果我是投稿者，觀看者也只有我自己，這種「個人作品集型的影片串流 App」可以整理成下面這樣。

電信事業申報：不需要。因為沒有媒介他人的通信，不在適用範圍內
資訊流通平臺對應法：不適用。因為沒有其他人上傳的 UGC，也就不會產生受理刪除申請的窗口等義務
個人資料保護法：如果要做觀看者帳號功能（登入、保存觀看紀錄等），形式上會落入適用範圍；但若是個人開發、非營利、小規模運作，我認為先準備一份隱私權政策，實務上就足夠了。

如果是這種模式，就可以像過去其他專案一樣，用「做完就公開」的感覺來處理。
事實上，我至今在 AWS 上公開的應用程式大多都是這種形式，所以到這裡都還算在預期之內。

「任何人都能投稿」的瞬間，法規就開始排隊出現

問題出在把服務改成「其他使用者也能上傳影片」，也就是變成真正意義上的 UGC 平臺。從這裡開始，情勢就變了。

電信事業申報方面，如果再加上留言、聊天室這類相互通信功能，就會進入需要檢討的區域。不過以個人開發規模來說，實務上被取締的風險幾乎不存在，所以把它理解成理論上有點灰色地帶就好。

比較實際會影響營運的是資訊流通平臺對應法。
這是 2024 年 5 月公布、2025 年 4 月 1 日施行，對舊《提供者責任限制法》的修正版；核心就是要設置能受理誹謗中傷與著作權侵害內容刪除申請的窗口。
如果是 UGC 服務，
不論規模大小，幾乎都可視為必須要做的對應。

規模變大後，義務也會變重。
如果月平均發信者數達 1,000 萬以上，或總傳送者數達 2,000 萬以上，就會被指定為「大型特定電信役務提供者」，並追加公開刪除申請處理狀況等義務。
截至 2025 年 4 月，總務省指定的業者有 Google、LINE Yahoo、Meta、TikTok 這 4 家（北濱法律事務所的解說）。個人開發幾乎不可能達到這個規模，所以現實上只要做到
「準備一個聯絡用電子郵件地址」
這種最低限度就夠了。

著作權法方面，還有一個論點是：為了適用安全港條款（提供者責任限制法系），需要建立相應的處理體制。
即使沒有類似 Content ID 的自動偵測機制，
只要先準備刪除請求窗口，法律責任就會被限制
——制度設計上大致是這樣。

另外也不能忽略另一個風險：把「第三者可以上傳侵權影片」這種設計本身做出來，就有風險。若把原始碼公開到 GitHub，除了技術問題之外，還可能被視為「助長著作權侵害的工具」。

真正的難題其實是著作權法，「公眾」這道牆

調到這裡，我才發現其實最棘手的不是電信事業法，也不是情資平臺法，而是著作權法。

著作權法裡有規定「公眾」的定義的條文。
第 2 條第 5 項規定：「本法所稱『公眾』，包括特定且多數的人。」這個規定的目的，似乎就是要防止「只租給會員，所以不是對不特定人開放」這類規避說法。
至於多少人才算「多數」，會依個案而定；一般常用的目安是超過 50 人，而過去的判例（中田英壽選手詩作遭未經授權刊載的案件）則把「是否滿足 300 名以上這類多數人的需求」當成判斷材料之一。

更麻煩的是第 23 條（公眾傳送權等）。在自動公眾傳送的情況下，「送信可能化」也包含在權利範圍內。
所謂送信可能化權，是指只要把檔案上傳到伺服器，讓別人可以下載的狀態一成立，權利就成立；是否真的有人存取過並不影響判斷。
也就是說，「有做認證，所以還沒有人看，或只有少數人能看」這種實際營運狀態，並不能成為法律上的關鍵分界。

與此相對的是第 30 條的「為私人使用而複製」。
像自己或家人這種極有限範圍內的使用，就能受到這個例外條款保護。
判例上也是以「極有限的人際結合關係」作為標準；在音樂教室與 JASRAC 的最高法院判決（2022 年 10 月 24 日）中，法院認定教師對學生反覆持續進行的演奏，屬於「對公眾的演奏」。
即使是一對一演奏給每個人聽，
只要對象不斷更替並反覆進行，就可能被認定具有公眾性
——這種想法套到影片串流上，也非常可能成立。

加上認證，不代表就安全

這裡我一開始有個誤解：
「只要加上密碼認證，限制給熟人看，就應該還算在私人使用範圍內。」
實際查過之後，才發現這個想法對了一半、錯了一半。

界線不是由「有沒有認證」決定，而是由「觀看對象的人數與關係」決定。
如果只是配偶、家人、同住者這種非常親密且人數極少的範圍，通常較容易被當作私人使用。
但如果是透過逐一核准朋友、熟人來開放存取，當人數變多，或彼此關係沒有家人那麼緊密時，就可能被認定為「特定且多數」，風險會往公眾傳送的方向上升。
即使有認證機制，這個風險也不會消失。

也就是說，「只要是可以接受的人就全部核准」這種設計思維，在法律上往往會被視為接近公開，而不是私人範圍。這點完全出乎我的意料。
我原本以為只要做了認證功能就安全，所以如果不是為了寫這篇文章去查，可能就直接照樣實作下去了。

這裡補充一點。
前面提到的「私人使用／公眾傳送」問題，只有在內容裡包含未經著作權人授權的第三方內容時才會真正成為問題。
像錄影裡夾帶了背景音樂、或不小心混入他人影像之類，就是這種情況。
如果是 100% 由自己拍攝、自己製作的原創內容，著作權屬於自己，那麼無論提供多少人觀看、無論是否公開，從著作權法上都可以自由傳送。
我回頭看了一下，發現「投稿者就是著作權人本人」這個前提說明得不夠清楚，所以特地在這裡補上。

一旦加上付費或年齡確認，又會冒出其他法律

到這裡為止，講的都還只是影片串流的核心功能。
如果再加功能，其他法律也會跟著進來。

只要涉及觀看紀錄或帳號資訊，就基本上需要處理個人資料保護法的對應（隱私權政策、明示利用目的等）。
如果預想會有未成年人使用，還要把《青少年網際網路環境整備法》的年齡確認與過濾機制納入考量。
如果加入抖內、訂閱制收費、廣告收益分潤這類涉及金錢的功能，還會另外碰到資金決算法與特定商取引法。

若是個人開發、非公開、非營利的範圍，我認為這些大致上只要「先知道有這回事」就夠了。
我自己的理解是：每次加新功能時，再回頭確認一次就好。

結論，個人開發規模到底做到哪裡就夠了

整體查下來之後，我的感想是：風險的核心
往往不是「其他人能不能投稿」，而是「有沒有公開」。
如果是完全非公開、加上存取控制、而且 URL 也不對外揭露，那麼作為私人使用被允許的範圍就會很大。
即使自己錄下來保存的影片裡包含著作物，只要僅限私人觀賞，基本上通常不會有問題。

相對地，只要一旦公開部署、或在部落格上貼出 URL，讓第三者可能存取到，馬上就很可能落入公眾傳送。
而私人使用的例外並不適用於公眾傳送，所以即使投稿者只有自己一人，只要放了未經著作權人授權的第三方內容，也可能構成侵權。

我認為現實中的對策有 3 個。

第一，是用存取控制維持非公開。只要加上認證，且不公開 URL，就能維持在私人使用範圍內，因此保存侵權內容本身的風險較低。
第二，是公開示範時只使用自己製作、或免版稅素材。
像 GitHub README 用的截圖、影片範例、或任何會在公開部署環境中讓人都看得到的內容，都不要使用有著作權的節目或音樂，而只用自己拍攝的影片，或 CC0、免版稅素材。
第三，是在 README 或 ToS 補上一句。
例如寫明：「本應用程式預設為投稿者的私人使用情境，不預期上傳包含第三方著作物的內容。」
這樣一來，萬一真的發生問題時，也能作為說明設計意圖的依據。

像音訊指紋比對這種技術性的自動檢測，我認為對單一使用者、非公開營運的個人 App 來說太過頭了。
目前看來，只要保持非公開，並妥善挑選示範素材，應該就已足夠涵蓋大部分風險。

結語

老實說，在碰到影片串流服務之前，我完全沒預料到自己會在法律面調查到這個程度。
最後雖然得到「如果只是投稿者只有自己一人的個人作品集型 App，法律手續幾乎可以省略」這個安心的結論，
但「加上認證就等於私人使用」這個既有想法被推翻，還是讓我相當意外。
下次如果我又想實作 DM 功能或留言區，大概還是會回頭重看這篇文章。

我目前還在持續驗證在 AWS 環境下到底可以做到什麼程度，如果有進展，我會再寫下來。

感謝你讀到最後。