Звіт про авторське право на програмне забезпечення в китайській компанії

Запис про авторське право на програмне забезпечення може пов’язати певну версію ПЗ із зареєстрованим правовласником. Він не засвідчує працездатність програмного забезпечення, відповідність поточної збірки зареєстрованій версії чи те, що постачальник володіє кожним компонентом продукту.

Ця межа особливо важлива під час огляду промислової платформи, мобільного додатка, вбудованого контролера, постачальника SaaS або постачальника смарт-пристроїв. Звіт компанії може виявити корисний запис реєстрації, але питання закупівлі є вужчим: чи підтверджує цей запис заявлену роль постачальника в цьому продукті?

Що зареєстровано?

Китайські Положення про захист комп’ютерного програмного забезпечення визначають програмне забезпечення як комп’ютерні програми та пов’язану з ними документацію. Вихідний код і об’єктний код однієї й тієї ж програми розглядаються як один твір згідно з цим визначенням. Отже, це поняття є більш конкретним, ніж ідея продукту, хмарний сервіс, бренд або весь технологічний бізнес.

Огляд програмного забезпечення ВОІВ проводить ще одну важливу межу: авторське право захищає форму вираження, а не ідеї, процедури, методи ведення діяльності чи математичні концепції як такі. Реєстрація `Warehouse Routing Platform V1.0` не означає ексклюзивного права власності на кожну концепцію або алгоритм маршрутизації складу, описані в презентації для продажу.

Карта використання записів інтелектуальної власності пояснює ширший портфель; ця сторінка залишається прив’язаною до запису програмного забезпечення. Реєстрація є доказом, а не моментом виникнення авторського права

Реєстрація є доказом, а не моментом виникнення авторського права

Заходи щодо реєстрації авторського права на програмне забезпечення заохочують реєстрацію та встановлюють вимоги до заявника та документів. Отже, уникайте двох поширених тверджень:

`Компанія отримала авторське право в дату реєстрації.` Базове право не створюється цією адміністративною датою.

• `Реєстрацію не знайдено, тому компанія не має авторського права.` Відсутність результату пошуку не вирішує питання про наявність програмного забезпечення, що підлягає захисту, або договірних прав.
• Це розрізнення також пояснює, чому обсяг реєстрацій не є рейтингом якості. Національне управління з авторського права повідомило про

Це розмежування також пояснює, чому обсяг реєстрацій не є показником якості. Національне управління з авторського права повідомило 3,182,829 реєстрацій авторського права на програмне забезпечення у 2025. Це широкий адміністративний контекст, а не доказ того, що постачальник із 100 записами кращий за того, хто має п’ять релевантних записів.

Шість полів як картка версії

Повна назва програмного забезпечення та коротка назва

Порівняйте точне формулювання з комерційною пропозицією, екраном входу, посібником користувача та додатком до договору. Схожі назви можуть описувати сімейство продуктів, а не збірку, яка купується.

Номер версії

Номер версії

`V1.0` не є взаємозамінним із продемонстрованою `V3.2`. З’ясуйте, як релізи, модулі та версії з білим лейблом пов’язані із зареєстрованою версією.

Зіставте китайську юридичну назву з компанією, що укладає контракт. Якщо вказано засновника, співробітника, афілійовану особу або стороннього розробника, документуйте ланцюжок володіння або ліцензування, а не сприймайте різницю як автоматично легітимну або підозрілу.

Дата завершення розробки

Це повідомлена точка завершення для зареєстрованого програмного забезпечення. Це не незалежний аудит репозиторію коду, повноти функцій або якості релізу.

Дата першої публікації, якщо вказана

Це може допомогти відтворити хронологію. `Неопубліковано`, пусто або недоступно не слід переписувати як `ніколи не використовувалося` або `ніколи не доставлялося`.

Дата реєстрації та номер

Використовуйте їх для ідентифікації та датування адміністративного запису. Не замінюйте дату реєстрації датою завершення, датою першої публікації або поточною датою випуску продукту.

Правовласник може не бути продавцем

Правовласник може не бути продавцем

Невідповідність вимагає пояснення зв’язків. Програмне забезпечення могло бути розроблене працівниками, створене спільно, замовлене у підрядника, передане, ліцензоване або збережене в іншій компанії групи. Нормативні акти про захист містять конкретні правила за замовчуванням для програмного забезпечення, створеного на замовлення, та певних продуктів, розроблених працівниками, проте покупцю не слід намагатися визначити юридичне право власності на основі коротких публічних результатів.

Запитуйте документи, що відповідають фактичній ситуації: угоду про розробку, положення про інтелектуальну власність у трудових договорах, документ про передачу прав, ліцензію, дозвіл від компанії групи, запис про злиття або зміну назви, а також перелік сторонніх компонентів і компонентів з відкритим кодом. Перевіряйте кожну компанію за її китайською юридичною ідентичністю. Якщо продавець стверджує, що розробник є афілійованою особою, порівнюйте зв’язок із стороною договору та командою, яка надає послуги, а не об’єднуйте обидві назви в одну компанію.

Сфера діяльності може надати контекст щодо розробки програмного забезпечення або технологічних послуг, але вона не визначає право власності на авторські права. Використовуйте огляд сфери діяльності для цієї окремої галузі.

Три дати не формують історію випусків

Реєстрація може надати вам дату завершення, дату першої публікації та дату реєстрації. Жодна з них обов’язково не повідомляє, яка збірка працює в демонстраційній версії сьогодні, коли було додано функцію, хто супроводжує виробничу систему та чи може постачальник відновити сервіс після збою.

Створіть коротку хронологію на основі записів, створених для поставки програмного забезпечення:

1. зарегістрована назва, версія та заявлена дата завершення;
2. примітки до випуску та ідентифікатори збірки для зазначеної версії;
3. датировані записи про прийняття клієнтом або внутрішнє прийняття;
4. докази з репозиторію, розгортання або депонування, відповідні до угоди;
5. поточний власник підтримки, субпідрядники та політика завершення життєвого циклу.

Мета полягає не в тому, щоб вимагати вихідний код для кожної покупки. Мета — зробити докази пропорційними залежності: офлайн-інструмент, який використовує один аналітик, потребує менше доказів безперервності, ніж програмне забезпечення, що керує виробничою лінією або зберігає регульовані дані.

Приклад: у звіті зазначено V1.0, у демоверсії — V3.2

Уявний постачальник демонструє `PlantWatch 3.2`, платформу моніторингу, постачану разом із заводськими датчиками. У звіті компанії зазначено `PlantWatch Equipment Monitoring Platform V1.0`, зареєстровану три роки раніше на ту саму китайську юридичну особу. Назва, власник і хронологія виглядають правдоподібними. Запис підтверджує зв’язок між компанією та попередньою версією продукту.

Це не підтверджує автентичність V3.2. Покупець запитує примітки до випуску, які пов’язують V1.0 з V3.2, номер збірки, показаний у демоверсії, перелік функцій за версіями, недавні докази прийняття та розкриття інформації про компонент мапування, наданий іншим розробником. Далі в контракті зазначаються версія результату робіт, термін підтримки, метод експорту даних, зобов’язання щодо безпеки, тести прийняття та відповідальність за ліцензії третіх сторін.

Отриманий висновок не є ні «авторські права підтверджено, схвалити», ні «невідповідність версій, відхилити». Він такий: «Реєстрація підтверджує зв’язок між попереднім продуктом і компанією; право власності на поточну версію, компоненти та контроль доставки вимагають наведених доказів».

Що не перевіряє реєстрація

• Функціональність: чи працюють обіцяні функції під навантаженням покупця.
• Безпека: управління вразливостями, контроль доступу, шифрування, реагування на інциденти або безпечна розробка.
• Походження коду: чи є кожен модуль оригінальним, ліцензованим, з відкритим кодом або наданим підрядником.
• Операційна діяльність: право власності на хостинг, резервне копіювання, аварійне відновлення, штат підтримки та час безперебійної роботи.
• Права на продукт: чи має продавець повноваження ліцензувати поточну збірку на території покупця та для його випадків використання.

Це вимагає технічного тестування, аналізу складу програмного забезпечення або перевірки безпеки, договірних доказів, а іноді й спеціалізованих юридичних консультацій. Запис компанії може допомогти сфокусувати ці перевірки, але не може замінити їх.

Сформулюйте обмежений висновок у звіті компанії

Чітко зазначте конкретний запис, збіг ідентичності, зв’язок версій, часові обмеження та наступні дії. Наприклад:

Звіт ідентифікує `PlantWatch Equipment Monitoring Platform V1.0`, зареєстровану на перевірену сторону договору. Це підтверджує зв’язок програмного забезпечення з компанією для зазначеної версії станом на зафіксовані дати. Це не встановлює право власності, безпеку або продуктивність зазначеної збірки V3.2. Перед схваленням отримайте ланцюжок випусків, розкриття компонентів, докази прийняття та договірну ліцензію.

Додайте витяг із джерела та відповідь постачальника до файлу затвердження постачальника. Зразок звіту компанії показує, як модуль інтелектуальної власності розташовується поряд із даними про ідентичність і операційну діяльність; його не слід розглядати ізольовано.

Передавайте питання щодо цінної індивідуальної розробки, спірного права власності, доступу до вихідного коду, транскордонного ліцензування, занепокоєння щодо порушення прав або критичної для бізнесу безперервності кваліфікованим технічним і юридичним експертам. Для звичайних закупівель розмістіть результат у послідовності доказів до укладення договору та зафіксуйте обмежене формулювання в внутрішньому меморандумі на затвердження.