Кратко

  • Фактический отправитель IETF Contribution и названные соавторы с момента подачи считаются вступившими в юридически обязательное соглашение по RFC 5378; отдельная подпись не нужна.
  • Это событие не доказывает само по себе право распоряжаться материалом работодателя, спонсора, соавтора или третьего лица. Политика опирается на разрешения и заявления в пределах разумного личного знания.
  • Авторское право на исходный вклад может остаться у автора или работодателя, а IETF Trust получает бессрочную, безотзывную, неисключительную, безвозмездную, всемирную и сублицензируемую лицензию; патентные права не входят в неё.

Три момента вместо одного

Первый момент — Contribution. Определение охватывает материал, предназначенный для Internet-Draft или RFC, а также устные, письменные и электронные заявления в контексте деятельности IETF. Реплика на заседании или письмо в рабочую группу может стать вкладом до того, как появился документ.

Второй момент — решение процесса. Рабочая группа или другая полномочная структура может принять идею, изменить её либо отказаться от неё. RFC 5378 прямо говорит, что IETF не обязан публиковать, использовать или распространять Contribution. Несоответствующий материал может быть отозван из использования.

Третий момент — публикация. RFC становится определённой коллективной работой в соответствующем потоке. Его формат, редакционная сборка и исходные вклады образуют связанные, но не одинаковые объекты прав.

Если система хранит только финальный статус «опубликовано», она стирает решения между этими моментами. Появляется ложное впечатление, будто публикация задним числом доказала полномочия отправителя и техническую ценность каждой ранней реплики.

Юридическая связь возникала при действии

RFC 5378 считает, что человек, фактически подавший Contribution, и каждый названный соавтор прочитали и поняли правила и вступили в обязательное соглашение. Дополнительное подтверждение, подпись или действие не требуются.

Это масштабируемый порог. Тысячи участников могут работать без отдельного бумажного договора на каждое письмо. Запись сервера способна надёжно закрепить личность, точное содержание, время и версию политики.

Однако сервер наблюдает подачу, а не всю предысторию прав. Служебное произведение может принадлежать работодателю. Включённый абзац может иметь другого автора. Код мог прийти из проекта с отдельной лицензией. Сильная квитанция о событии не превращается в свидетельство о собственности.

Политика поэтому добавляет другое обязательство: вкладчик считается получившим необходимые разрешения от сторон, о правах которых он разумно и лично знает, включая работодателя или спонсора. Он также заявляет, насколько позволяют знание и способности, что все прямые и косвенные участники признаны, материал не конфиденциален и ему не известны препятствия для обещанных прав.

Предел знания не был пустым исключением

«Разумно и лично известно» означает фактическое знание и то, что человек по своей должности должен был бы знать. Организация не может намеренно оставить сотрудника в неведении, чтобы избежать обязанности. Роль человека является частью оценки.

Но это всё же предел, а не гарантия абсолютной истины. IETF не имеет ресурсов для независимого исследования имущественного статуса каждого документа. Модель помещает заявление возле человека, у которого вероятнее есть доступ к источникам, договорам и разрешениям.

Поэтому заявление должно сохранять автора. Запись «ограничений не знаю» не равна утверждению «ограничений нигде нет». Разрешение работодателя, согласие соавтора и происхождение чужого фрагмента остаются отдельными доказательствами.

Если доказательство отсутствует, система должна показать пробел. Это не автоматический вывод о нарушении, но и не основание выдумать полномочие. Видимый пробел позволяет запросить документ или изолировать материал.

Широкая лицензия не уничтожала собственность

Для защищённой Contribution автор и названные соавторы предоставляют IETF Trust бессрочную, безотзывную, неисключительную, безвозмездную, всемирную и сублицензируемую лицензию. Она охватывает копирование, публикацию, показ, распространение и перевод, а при отсутствии допустимого запрета — модификацию и производные работы.

Безотзывность обеспечивает продолжение стандарта, когда люди и компании меняются. Trust может сохранить и развивать общее произведение, не завися от будущей воли каждого автора.

Исходное авторское право при этом может сохраняться у вкладчика или работодателя. Неисключительность допускает одновременное использование владельцем и Trust. Права в отдельной Contribution также отличаются от прав в коллективном RFC как отредактированной публикации.

Утверждение «IETF забрал авторское право» скрывает эту конструкцию. Вернее сказать, что владелец сохранил базовое право, обременённое выданной безотзывной лицензией, а Trust получил полномочия, необходимые процессу.

Надпись сообщала, но не передавала

Note Well и легенды должны предупредить участника о правилах. RFC 5378 отдельно указывает, что надписи в письменных Contributions сами права не передают. Они сообщают читателю о правовом режиме и ограничениях.

Правильный нижний колонтитул не создаёт разрешение работодателя и не превращает чужой текст в работу отправителя. Следует сохранять отдельно доказательство показа правил, квитанцию подачи, заявление вкладчика и разрешение того, кто контролирует внешнее право.

Эта структура показывает место ошибки. Интерфейс исправляет уведомление. Автор исправляет атрибуцию. Работодатель даёт своё разрешение. Последующий пользователь меняет способ использования, если лицензия не подходит. Один флаг «проверено» не позволяет выбрать средство.

Старый материал сохранял старую границу

Вклады до действия RFC 5378 могли не содержать весь набор прав, требуемый новой политикой. Новый отправитель, включив такой текст в свежий draft, не мог предоставить то, чего прежний автор не давал.

IETF Trust предусмотрел специальную легенду, позволяющую сохранить ограничение производных работ для такого материала. Это было признание происхождения, а не попытка удалить историю. Фрагмент оставался в работе вместе со своей границей.

Новый файл, репозиторий или заголовок не расширяет лицензию старого текста. Для надёжного контроля каждому значимому фрагменту нужны источник, дата, применимая политика и исключение. Хэш текущей версии фиксирует состав, но не объясняет полномочия частей.

Патент шёл параллельно

Лицензия RFC 5378 не предоставляет прав по патентам, патентным заявкам и сходным объектам. Патентные раскрытия и обязанности регулируются BCP 79, ныне RFC 8179. Право копировать описание не даёт автоматически права применять запатентованный способ.

Значит, универсальный статус «IP очищено» неверен по структуре. Отдельно нужны авторское право, полномочие внести Contribution, патентное раскрытие и лицензия на последующее использование. Code Components и обычный текст также могут требовать разных условий по Trust Legal Provisions.

Техническое принятие не заменяет эти проверки. И наоборот, корректная правовая подача не доказывает качество протокола, совместимость реализаций или эксплуатационный результат. Каждое решение принадлежит своему органу и времени.

Семь квитанций по одной цепочке

Практическая модель связывает: уведомление до участия; классификацию высказывания как Contribution; личности отправителя, названных и косвенных вкладчиков; разрешения работодателя и третьих лиц; версию политики и знание автора заявления; входящую лицензию и исключения; исходящую лицензию для дальнейшего использования.

Они могут иметь общий идентификатор, но не должны перезаписывать друг друга. Действительная подача может позднее обнаружить дефект полномочия. Действительная лицензия на текст может сосуществовать с открытым патентным вопросом. Принятый материал может не стать RFC.

Разделение позволяет пропорциональный ремонт. Сомнительный фрагмент изолируется, атрибуция дополняется, разрешение запрашивается, использование ограничивается. История показывает, что было известно и что изменилось, вместо того чтобы объявить весь прошлый процесс полностью правильным или неправильным.