Виконання bounty у блокчейн-екосистемі часто сприймається як простий обмін роботи на винагороду. Насправді більшість bounty — це конкурси, де проєкт отримує результат, а ви залишаєтесь із певними юридичними ризиками, якщо не домовилися про умови заздалегідь. Нижче — конкретні кроки, які допоможуть зберегти контроль над своєю роботою.
Що таке авторські права в контексті bounty
Авторське право виникає в момент створення твору автоматично — коду, тексту, дизайну, відео чи аналітичного звіту. Ви не маєте реєструвати його окремо, щоб ним володіти. Проте в контексті bounty є важливий нюанс: сам факт створення роботи не гарантує, що ви зможете нею розпоряджатися далі.
Більшість bounty-завдань у Solana-екосистемі не є трудовими чи цивільно-правовими договорами у класичному розумінні. Це публічні умови конкурсу: ви виконуєте завдання, проєкт обирає переможця (або кількох), і лише тоді визначається доля результату. До моменту оголошення результатів ваші права формально зберігаються, але сам формат участі може їх обмежити.
Три ключові моменти, які варто розуміти з самого початку:
- Створення ≠ дозвіл на використання. Проєкт може технічно взяти ваш код чи дизайн і застосувати його, навіть якщо ви не перемогли, якщо умови завдання це дозволяють.
- Перемога ≠ збереження прав. Отримання винагороди часто супроводжується передачею прав проєкту — але не завжди повною і не завжди беззворотною.
- Відмова ≠ повернення роботи. Якщо результат не прийняли, ви зберігаєте авторство, але не завжди можете використовувати його в портфоліо, якщо умови це обмежують.
Ця інформація має загальний характер і не є юридичною консультацією. Для конкретних ситуацій звертайтеся до фахівця з інтелектуальної власності.
Як перевірити умови використання результату
Перш ніж відкривати редактор коду чи Figma, знайдіть і прочитіть умови. Зазвичай вони розміщені в одному з трьох місць:
- Опис завдання на платформі (Dework, OnlyDust, Superteam Earn тощо) — часто містить короткі правила, але не завжди повні.
- Репозиторій проєкту на GitHub — файл CONTRIBUTING.md, LICENSE або розділ у README.md. Це найнадійніше джерело для технічних bounty.
- Загальні умови платформи — іноді саме платформа визначає, хто володіє результатами завдань, опублікованих на ній.
Що саме шукати в тексті:
- Ліцензія репозиторію. Якщо проєкт використовує MIT або Apache 2.0, ваш внесок автоматично підпадає під ці ліцензії. Це означає, що проєкт може вільно використовувати ваш код, але ви також зберігаєте право використовувати його самостійно.
- Формулювання про передачу прав. Шукайте слова на кшталт «assign», «transfer», «waive», «irrevocable license». Якщо таких слів немає, права формально залишаються за вами — але це не означає, що конфлікту не буде.
- Умови для непереможців. Чітко визначено, що відбувається з роботами, які не отримали винагороду. Можуть використовуватися? Повертаються автору? Видаляються?
- Обмеження на публікацію. Чи дозволяється розміщувати результат у портфоліо, GitHub, Behance чи Dribbble після подачі.
Якщо жоден із цих пунктів не згадано — це не привід розслабитися. Це привід поставити питання організаторам до початку роботи.
Червоні прапорці в договорах та умовах
Деякі формулювання виглядають стандартно, але суттєво обмежують ваші права. Ось що має викликати обережність:
- Повна беззворотна передача всіх прав. Формулювання на кшталт «you assign all rights, title, and interest in the submission» означає, що після подачі ви втрачаєте будь-який зв'язок із власною роботою. Ви не зможете показати її в портфоліо, використати в іншому проєкті чи модифікувати.
- Право на модифікацію без згоди. Якщо умови дозволяють проєкту змінювати вашу роботу без вашої участі та без зазначення вашого імені — це сигнал, що вас розглядають як виконавця, а не як співавтора.
- Відмова від моральних прав. У деяких юрисдикціях моральні права (право на ім'я, право на недоторканність твору) не можна передати, але умови можуть вимагати від вас їх «відмови» — що юридично сумнівно, але на практиці ускладнює захист.
- Розширене трактування «внеску». Якщо умови визначають як внесок усе, що ви створюєте в процесі виконання bounty, включно з проміжними результатами, нотатками, утилітами чи бібліотеками — ви ризикуєте втратити більше, ніж планували.
- Одностороння зміна умов. Якщо проєкт залишає за собою право змінювати правила після вашої подачі — це прямий червоний прапорець.
- Відсутність будь-яких умов. Парадоксально, але повна відсутність правил — теж поганий сигнал. Це означає, що проєкт не продумав юридичну сторону, і в разі конфлікту ви будете захищені лише загальним законодавством, що не завжди працює на вашу користь у міжнародному контексті.
Практичні кроки для захисту своєї роботи
Зафіксуйте факт створення до подачі
Зробіть коміт у приватний репозиторій, завантажте файл у хмару з фіксацією часу або надішліть собі листа з прикріпленим результатом до того, як подасте роботу. Це не гарантує перемоги в спорі, але створює доказову базу, якої у вас інакше не буде.
Не видаляйте проміжні результати
Зберігайте чернетки, скріншоти процесу, версії файлів, історію комітів. Якщо виникне спір про авторство, наявність процесу роботи вагоміша за фінальний файл сам по собі.
Працюйте у власному середовищі
Створюйте код у власному форку репозиторію, а не в гілці проєкту, поки результат не прийнято. Для дизайну — працюйте у власному файлі, а не в проєктному Figma-просторі, якщо є сумніви щодо доступів. Це дає вам контроль над тим, коли саме робота стає доступною іншим.
Поставте питання до початку
Якщо умови нечіткі, напишіть організаторам у Discord або Telegram із конкретним запитом: «Чи зберігаю я право розмістити результат у портфоліо після завершення bounty?» та «Що відбувається з роботою, якщо я не переможу?». Збережіть відповідь — це стає частиною домовленості.
Уникайте неявної згоди
Деякі платформи автоматично прив'язують вас до умов при натисканні кнопки «Take task» або «Submit». Прочитайте те, на що погоджуєтесь, до кліку. Якщо умови неприйнятні — не беріть завдання.
Розділяйте особисте й комерційне
Якщо ви створюєте для bounty утиліту, бібліотеку чи шаблон, який плануєте використовувати й поза цим завданням, продумайте архітектуру так, щоб специфічна для проєкту логіка була відокремлена від повторно використовуваної частини. Це не завжди юридичний захист, але практичний — ви не втрачаєте інструмент, який створили.
Фіксуйте домовленості текстом
Якщо організатор усно сказав у дзвінку, що «звісно, можеш показувати в портфоліо» — попросіть підтвердження текстом. Усні домовленості в міжнародних bounty практично непідтверджувані.
Ніякий алгоритм не дасть стовідсоткового захисту в децентралізованому середовищі, де сторони часто перебувають у різних юрисдикціях. Але послідовність у цих кроках суттєво зменшує ризики й показує проєктам, що ви працюєте професійно — а це саме по собі відсікає більшість проблемних ситуацій.
Після того, як ви переконалися в захисті своєї роботи, наступний логічний крок — коректно подати результат. Як це зробити без типових помилок, читайте в матеріалі Як подати результат bounty та уникнути відмови.