האם VPN או פרוקסי יכולים להעתיק תוכן מוגן בזכויות יוצרים? שלושה מעשים

העברת מנות, שמירה במטמון ופרסום מחדש נראים זהים מלוח מחוונים ומתנהגים אחרת לגמרי ברגע שמגיעה שאלת זכויות. שירות שמעביר בתים בין משתמש לשרת מבצע מעשה אחד, ואילו שירות ששומר תגובה ומוסר אותה למבקר הבא מבצע מעשה אחר. פרסום חומר של אחר תחת שמכם שלכם הוא מעשה שלישי, ורק המעשה השלישי הזה הוא הפצה במובן הרגיל.

בררו איזה משלושת אלה מבצעת המערכת שלכם בפועל, ואז הצמידו לו את הכלל המתאים. תוויות מוצר לא מכריעות כאן דבר, וגם הפרוטוקול שבשימוש אינו המבחן.

שלושה מעשים שפרוקסי או VPN יכולים לבצע

שער מקבל זרימת TCP, כותב מחדש כתובות ומעביר מקטעים בשני הכיוונים. דבר לא שורד את החיבור על הדיסק, והמטען נשאר אטום לשער אלא אם הלקוח מנהל משא ומתן TLS עם השער ולא עם המקור.

מתווך מטמון פועל אחרת: הוא מנתח את הבקשה, מאחסן את התגובה למשך חיים שהוא מחשב או קורא מכותרות, ואז משחזר את האובייקט השמור ללקוחות מאוחרים יותר. משהו קיים כעת מחוץ לחוט, עם מפתח של URL ומאמת, והחזקתו היא בחירת תצורה ולא תוצאת לוואי.

פרסום מחדש הולך צעד אחד נוסף. החומר יושב על תשתית שאתם שולטים בה, מופנה לקהל שבחרתם, לעתים קרובות לאחר עריכה. שני המעשים הראשונים מתארים הובלה, ואילו השלישי מתאר הפצה.

היכן פרוקסי מפענח הופך נשיאה להעתקה

ההבחנה שמכריעה את רוב הוויכוחים היא אם התיבה מחזיקה אי פעם טקסט גלוי. מנהרה טהורה, בין אם WireGuard, התקן OpenVPN tun או העברת SSH -L, מעבירה טקסט מוצפן בין הקצוות ולא משאירה דבר קריא. פרוקסי שמסיים TLS עושה ההפך: הוא משלים את לחיצת היד, חוצץ את התגובה בזיכרון ואז מצפין מחדש את הזרם לעבר הלקוח. בין הפעולות האלה היצירה קיימת בצורה שהמפעיל יכול לבדוק ולשמור.

17 USC 106 מונה השעתוק וההפצה בין הזכויות הבלעדיות, כל אחת כפופה למגבלות שנקבעו באותו פרק. חוצץ של אלפית שנייה עשוי להיכנס למגבלה בלי ויכוח; אובייקט שמור ובר-שיחזור קשה הרבה יותר למקם שם. משך ומטרה נושאים משקל רב יותר מאשר העובדה שנגעו בזיכרון בכלל.

שום דבר מזה לא הופך VPN לרישיון, ושום דבר לא הופך כל פרוקסי למפר. הובלה היא עובדה אחת מבין כמה, והשאלה ניתנת להערכה נשארת בעינה: איזה מעשה, על החומר של מי, באיזו הרשאה.

כותרות מטמון מתארות הרשאת פרוטוקול, לא הרשאה משפטית

מטמון HTTP מחליט מה מותר לו לאחסן לפי מטא-נתוני התגובה, ו-RFC 9111 קובע את הכללים שהוא פועל לפיהם. Cache-Control: no-store אומר לכל מטמון תואם לזרוק את התגובה, ואילו private מגביל שימוש חוזר למשתמש אחד, ו-max-age ארוך מזמין אחסון משותף. בקשה אחת מספרת לכם איזו מדיניות בחר מקור. הריצו אותה לפני שתתנהלו על דבר אחר.

curl -sI https://origin.example/media/report.pdf | grep -i -E 'cache-control|etag|age'

תגובה שמכריזה על חיי מדף ארוכים אומרת למטמונות ששיחזור מקובל ברמת הפרוטוקול. ההצהרה הזו לא אומרת דבר על האם אתם רשאים לקחת את אותו אובייקט, לארח אותו מחדש ולשלב אותו בשירות שלכם. שתי הרשאות שונות מגיעות משני מנגנונים שונים, וקיום האחת משאיר את האחרת בדיוק במקומה.

מקרה המראה נכשל באותו אופן. HTTPS מקצה לקצה מונע ממטמון שקוף לאחסן דבר, אבל התוצאה הזו לא יוצרת זכות להפיץ את החומר וגם לא שוללת אחת שכבר היתה לכם. התנהגות פרוטוקול מסבירה מה תיבה יכולה לעשות; היא לעולם אינה מספקת הרשאה.

מה לרשום לפני שהשירות עולה לאוויר

תארו את ההסדר במונחים שאדם מבחוץ יוכל לבדוק. ציינו את החומר ואת מקורו, פרטו את המעשים שהמערכת מבצעת, ואמרו כמה זמן חי כל אובייקט שמור.

שמרו את התיאור הזה עם הפריסה ולא בזיכרונו של מישהו. כשמגיעה תלונה, הפער בין עמדה שאפשר להגן עליה לבין ניחוש הוא לרוב פסקה שנכתבה חודשים קודם ושמזכירה את תקופת ההחזקה ואת הרישיון.

רשימת סקירה קצרה מכסה את החורים החוזרים:

• מקור החומר והתנאים הכרוכים בו.
• כל מעשה שמבוצע: העברה, אחסון, עריכה, הגשה.
• החזקה לפי סוג אובייקט, בשעות או בימים.
• ההרשאה או המגבלה שעליהן נשען שלב ההגשה.
• דרכי קשר והסרה לבעלי הזכויות.

הריצו את הרשימה מול התצורה החיה, לא מול תרשים הארכיטקטורה. במקום שחסרה תשובה, הפער הזה הוא המשימה הבאה: השיגו הרשאה למעשה או הפסיקו לבצע אותו. לשירות מסחרי, תנו לעורך דין לקרוא את התיאור הכתוב מול התחום השיפוטי שאתם פועלים בו, כי התיאור הוא מה שמאפשר את הסקירה הזו. כל מה שאינכם יכולים לתאר בכתב הוא עמדה שאינכם יכולים להגן עליה.