VI. Аналіз експертних зауважень та додаткова аргументація

Статус Коментар № 1 Теза (проблема) Прийняття закону передчасне через відсутність вітчизняної ОС. Цитата “Вважаємо за передчасне прийняття даного законопроекту, оскільки на сьогодні в Україні не розроблена вітчизняна локалізована операційна система для ОДВ на базі ОС з відкритими кодами (наприклад, на базі LINUX). За експертними даними, загальна вартість розробки подібної системи приблизно 10 млн. доларів. Разом з тим у проекті Національної програми інформатизації на 2003 рік передбачено започаткувати подібні роботи…” Рецензент МЕУ

Зауваження доводить, що працівник Мінекономіки недостатньо ознайомлений з предметом. Розробляти операційну систему “з нуля” не потрібно. Більше того, така робота нині не під силу Україні, як не під силу і будь-якій державі поза межами “великої сімки” – хоч що там було б написано в Програмі по інформатизації. (Принагідно: “Програми інформатизації” в Україні пишуть з 1994 року, але жодної з них ще не було втілено хоча б частково).

Питання полягає в повній локалізації (тобто українізації у даному випадку) вже готових і постійно поновлюваних продуктів з відкритим кодом, які є вільно доступними. Вартість робіт з повної локалізації (яку можна використовувати і в наступних версіях операційної системи або іншого програмного продукту), як це свідчить досвід Росії, Угорщини, країн Латинської Америки – принаймні на 2 порядки нижче. Тобто не 10 мільйонів, а максимум 100 тисяч доларів. А в умовах України, імовірно – і значно менша, з огляду на ринкову ціну місцевої кваліфікованої робочої сили (наші експерти оцінюють відповідні роботи, за умови проведення їх виключно в Україні, як еквівалент 30 – 40 тис. доларів США).

Роботи з локалізації – цілком під силу невеликим комерційним фірмам під загальним (на рівні технічного завдання та відстеження часових і якісних параметрів) контролем з боку спеціальної парламентської комісії та (або) профільних інститутів.

Більше того: схожі роботи з локалізації вже успішно проведено в Україні або для України. Наприклад, відомо принаймні 2 проекти успішної локалізації універсального офісного пакету OpenOffice.org (аналог Microsoft Office). Відомо також не менше 5 проектів українізації операційних систем – щоправда, через наявну політику держави щодо Вільного ПЗ, більшість з них успішно ведуть закордонні (з формальної точки зору) або міжнародні колективи.

Статус Коментар № 2 Теза (проблема) Проект закону вимагає використовувати лише Вільне програмне забезпечення в держустановах і відповідно лише одну бізнес-модель розробки і поширення ПЗ,.. що порушує права підприємств… Цитата “Обов’язкова вимога до підприємств державного сектору народного господарства використовувати лише відкрите (вільне) ПЗ… порушує вимоги Закону України від 27 березня 1991 року №887-XII «Про підприємництво в Україні» (статті 2, 22, 28), в частині порушення рівності прав підприємств незалежно від форм власності та самостійності підприємств при здійсненні свого матеріально-технічного забезпечення” “Основна ідея проекту закону зводиться… до заборони використання будь-якого програмного забезпечення, що не може бути класифіковане як “відкрите”. “Запропонований… законопроект має на меті докорінне замінення парку ПЗ в державі, а як можливий наслідок – і в усьому суспільстві країни, базуючись на зміні концептуальних та ідеологічних засад ліцензування і розповсюдження ПЗ.”.. “…Пропонується заборонити всі існуючі бізнес-моделі створення і поширення ПЗ (крім однієї)…” Рецензент ДІВ МОН, РПУ, УАППО

Помилка.

Вже в тексті законопроекту, внесеного на заміну раніше поданого 12.11.2002 року (де більша частина змін власне і стосується додаткового роз’яснення і конкретизації порушеного питання) – чітко вказано, що Вільне програмне забезпечення держава бере на себе зобов’язання використовувати не всюди – а лише у сфері публічних сервісів:

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

Остання версія законопроекту (15) містить в цій (тепер 2.4.) статті ще м’якіші вимоги: вимогу тут змінено на рекомендацію:

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

Як бачимо, вибір програмного забезпечення для “непублічних” сервісів не регламентовано законопроектом: для внутрішньовідомчих потреб – вимоги законопроекту також носять рекомендаційний характер:

2.5. Суб’єкти державного сектору для внутрівідомчого використання з юридичних причин мають брати до уваги пріоритетність використання Вільного програмного забезпечення, визначеного в статті 1.24 цього Закону – у всіх випадках, коли таке програмне забезпечення:

а) наявне на ринку або в прямому доступі;

б) не поступається за профільною для сфери застосування функціональністю “закритому” ПЗ та (або) виграє у “закритого” комерційного ПЗ за співвідношенням “ціна – функціональність”.

Окрім того, стаття 6 законопроекту вводить широку можливість застосування інших типів ПЗ в державному секторі:

Стаття 6. Винятки та захист державних інвестицій

6.3. Можливість використання “закритого” (“пропрієтарного”) ПЗ встановлюється також для будь-яких наявних, вже спроектованих та таких, що знаходяться у стані проектування систем внутрівідомчого користування, у випадках, якщо загальна сума вже зроблених витрат на відповідне ПЗ (або відповідне інформаційне рішення чи систему), а також перспективних витрат (на термін до 3 років), включно з наявною та розрахованою вартістю володіння, перевищує вартість введення відповідного рішення на базі Відкритого (Вільного) ПЗ, або доводить неекономічність впровадження такого рішення…

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

Інша ситуація (тобто безперешкодна можливість використовувати у сфері публічних сервісів “закрите” (“пропрієтарне”) програмне забезпечення) – призведе (і вже зараз приводить через ряд обмежень, іманентно властивих “закритому” (“пропрієтарному”) програмному забезпеченню – до грубого порушення статей 6 і особливо 9 “Закону про інформацію” України, де сказано:

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

Це відбувається тому, що інформацію в “закритих” стандартах або створену на базі “закритого” (пропрієтарного) програмного забезпечення за визначенням неможливо отримати вільно. Також політика широкого використання пропрієтарного ПЗ в держсекторі створює небезпеку порушення статей 31, 32 та 40 Конституції України, яка є Законом прямої дії.

Як на характерні (хоча і не найважливіші!) приклади, до яких призводить ігнорування вищевказаних аспектів – можна вказати, наприклад, на вимоги подавати “тексти проектів законодавчого акта та супровідних документів… з використанням текстового редактора Word версії 6.0 або наступних версій” (“Пам’ятка народному депутату України” та “Методичні матеріали щодо підготовки електронних копій документів суб’єктами права законодавчої ініціативи” УКС Апарату Верховної Ради України) – та такі ж самі вимоги ВАК України щодо порядку подання наукових праць. Нагадаємо, що фраза про “редактор “Word версії 6.0 або наступних версій” означає вимогу використання текстового редактору “Microsoft Word” американської корпорації Microsoft, який розповсюджується за жорсткою “пропрієтарною” ліцензією (здебільшого через систему дилерського продажу). Сам редактор для свого функціонування потребує також операційної системи для персонального комп’ютера від того ж самого виробника, розповсюджувану за такою ж “жорсткою” ліцензією (жодних гарантій, зокрема і на збереження даних, право встановити лише одну копію, заборона декомпіляції та вивчення коду, тощо).

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

Статус Коментар № 3 Теза (проблема) Вимогою про регулярну перевірку ринку на предмет присутності необхідного Вільного програмного забезпечення – порушуються права власності особи, що придбала пропрієтарне ПЗ у межах виключного дозволу. Цитата “Закладена в проекті вимога про те, що правовласник (державний заклад – авт.) втрачає право на використання (яке є одним з елементів права власності) належного йому на законних правах майна (пропрієтарних програм, що використовуються у публічному секторі у випадках відсутності відповідних Вільних програм – авт.), грубо порушує право власності особи, що є порушенням чинного законодавства.” Рецензент ДІВ МОН

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

Разом з тим ця теза доводить необхідність змінити пропоновану норму таким чином, щоб гарантувати можливість безперервного використання пропрієтарного програмного забезпечення до моменту появи Вільного аналогу. Відповідні зміни внесені до версії 10 законопроекту (від 15.02.2003).

Статус   Коментар № 4 Теза (проблема) Проект Закону протирічить вимогам Кримінального кодексу України у частині вимог припинити переслідування осіб, які непричетні до масового виготовлення та розповсюдження контрафактних комп’ютерних програм. Цитата …Протирічить нормативному актові вищої, порівняно з Законом України, сили – Кодексу України… Рецензент ДІВ МОН

1. Підміна понять. Проект Закону не пропонує призупинити саму карну відповідальність за злочини у сфері інтелектуальної власності. Він лише звужує невиправдано-широке трактування поняття “злочин у сфері інтелектуальної власності” щодо: \

а) фактів вимушеного використання (але не виробництва і не розповсюдження!) одиничних екземплярів контрафактного програмного забезпечення в умовах фактичної відсутності масово доступних альтернатив (однією з таких альтернатив є Вільне програмне забезпечення), і

б) фактів, коли за контрафактне програмне забезпечення помилково приймається Вільне (Відкрите) програмне забезпечення.

Таким чином проблема полягає не у “замаху на Кримінальний кодекс” – а у трактуванні фактів, які нині пропоновано вважати злочинними згідно низки підзаконних (відомчих) актів. Норма законопроекту дозволяє не перетворювати автоматично більшість комп’ютерно-освіченого населення країни на кримінальних злочинців, як це відбувається зараз – принаймні до появи масово-доступного Вільного ПЗ.

Принагідно слід зауважити, що на момент прийняття нового Кримінального (Карного) кодексу – законодавці не мали уявлення про феномен існування Вільних ліцензій (і Вільних форм інтелектуальної власності) як таких. Що призвело до фактичної незаконності використання в Україні не лише Вільного, але й пропрієтарного ПЗ (детальніше про це – в аналізі аспектів авторського права, коментар № 30).

2. До актуальної версії (15) законопроекту внесено зміни, які знімають вказане формальне протиріччя зняттям посилання на норми відповідного Кодексу.

Статус Коментар № 5 Теза (проблема) Законопроект перешкоджає виконанню міжнародних угод у сфері охорони інтелектуальної власності: статті 14-2 TRIPS Цитата “Стаття… проекту вводить винятки, наявність яких… дозволяє… перешкоджати ефективній протидії актам порушення авторських прав, що протирічить нормам статті 14 Договору Всесвітньої організації інтелектуальної власності… в частині пункту 2…” Рецензент ДІВ МОН

Помилка. Вся стаття 14 TRIPS взагалі не стосується програмного забезпечення. Вона стосується виробників та розповсюджувачів фонограм ( http://www.wto.org/english/docs_e/legal_e/27-trips_04_e.htm ):

“Article 14 Protection of Performers, Producers of Phonograms (Sound Recordings) and Broadcasting Organizations

2. Producers of phonograms shall enjoy the right to authorize or prohibit the direct or indirect reproduction of their phonograms…

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

Статус Коментар № 6 Теза (проблема) Законопроект перешкоджає виконанню міжнародних угод у сфері охорони інтелектуальної власності: статті 16 п.1 Бернської Конвенції Цитата “Проект… фактично дозволяє виготовлення одиничних екземплярів, а, за певними умовами, які залежать тільки від зловмисників, і комерційних об’ємів контрафактного ПЗ, тоді як положення 16 п.1 Бернської Конвенції напряму передбачає обов’язковий арешт контрафактних екземплярів твору…” Рецензент ДІВ МОН

Помилка.

1. Стаття 16 п.1 Бернської конвенції говорить про можливість (“may bе”), а не про обов’язковість (“should be”) арешту:

Article 16

(1) Pirated works may be seized by the competent authorities of any country of the Union where the original work enjoys legal protection.

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

Наприклад: арешт партії неліцензійних лазерних дисків, виготовлених в підпіллі (або підпільно виготовлених на заводі) – є припинення злочину – тобто міра цілком законна і логічна.

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

Не розуміти (або не розрізняти) цього для державної структури – принаймні дивно.

2. Проект Закону ніяк не передбачає можливості безкарного виробництва комерційних обсягів контрафактного ПЗ. Копіювання та використання контрафактного ПЗ у комерційних (промислових) масштабах взагалі не є об’єктом даного законопроекту. (див. також Коментар 7.)

3. В багатьох випадках суб’єктам, які виконують, наприклад, звичайне копіювання власних даних на цифровий носій (зокрема і CD) – буде вкрай важко довести повну юридичну правомірність виготовлення відповідних “одиничних екземплярів”. Отже, така діяльність не може бути суб’єктом державного регулювання: в іншому разі необхідно заборонити продаж і використання будь-яких побутових та офісних пристроїв для запису цифрової інформації, зокрема і лазерних дисків. Фактично така заборона буде адекватна забороні використання комп’ютерної техніки без спеціального дозволу взагалі.

4. Визначення “за певними умовами” не можна прийняти як юридичний термін, тим більше – доказ.

Статус Коментар № 7 Теза (проблема) Законопроект перешкоджає виконанню міжнародних угод у сфері охорони інтелектуальної власності: стаття 61, розділ 5 TRIPS Цитата “Проект… суперечить Угоді TRIPS, оскільки залишає можливість для безкарного виробництва неліцензійних примірників ПЗ, рівень якого може бути доведений зловмисниками до комерційного, а в той же час розділ 5 статті 61 Угоди TRIPS напряму обумовлює застосування членами СОТ кримінальних процедур і штрафів, якщо порушення авторських прав вчиняються на рівні, який визначається за положеннями проекту Закону як комерційний (а не промисловий). Рецензент ДІВ МОН

1. Стаття 61 Угоди TRIPS (принаймні на “рідному” для TRIPS Інтернет-ресурсі) не має розділів:

“Article 61

Members shall provide for criminal procedures and penalties to be applied at least in cases of wilful trademark counterfeiting or copyright piracy on a commercial scale. Remedies available shall include imprisonment and/or monetary fines sufficient to provide a deterrent, consistently with the level of penalties applied for crimes of a corresponding gravity. In appropriate cases, remedies available shall also include the seizure, forfeiture and destruction of the infringing goods and of any materials and implements the predominant use of which has been in the commission of the offence. Members may provide for criminal procedures and penalties to be applied in other cases of infringement of intellectual property rights, in particular where they are committed wilfully and on a commercial scale”.

2. Значно більша проблема полягає в тому, що в сучасному вітчизняному законодавстві відсутні об’єктивні чисельні показники термінів “промисловий” та “комерційний”.

Вираз “commercial scale” при перекладах з англійської часто трактується і як “промисловий рівень”, через присутність в українській мові чотирьох визначень-відповідників (комерційний – промисловий (=виробничий) – індустріальний) проти лише двох базових в англійській (commercial – industrial). Термін “індустріальний” в українській мові передбачає явище не безпосередньо-виробничого, а галузево-економічного масштабу. Це ще раз доводить необхідність вкрай виважено адаптувати тексти міжнародних угод перед приєднанням до них.

Термін “промисловий рівень” однозначно визначає виготовлення партії продукту на промисловому обладнанні, або ж виготовлення партій (накладів) продукту.

Термін “комерційний рівень” – визначає лише абстрактну кількість, достатню для організації комерції (продажу), регулярного отримання зиску.

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

Інша ситуація у країнах третього світу та колишніх країнах СНД, де масовий бізнес значно дрібніший. За “комерційний рівень” тут готові приймати навіть індивідуальну трудову діяльність – тому застосування відповідного терміну повинне бути відповідним чином диференційоване.

Також слід зауважити: якщо, наприклад, у видавничій (книжковій, газетно-журнальній) справі окремій особі важко дістатись “комерційного рівня” без облаштування спеціального виробництва та отримання відповідної ліцензії – то завдяки широкій доступності побутових пристроїв копіювання для комп’ютерних носіїв інформації (дисководи, приводи CD-R, тощо) – можна припустити, що окрема особа, навіть використовуючи звичайний персональний комп’ютер, здатна вдатись до невеличкої приватної “комерції”, яка з огляду на норми авторського права буде протизаконною.

Таким чином, щодо терміну “комерційний рівень”:

а) або цей термін, як нечіткий, тобто такий, що має різне тлумачення в різних правових культурах – не може використовуватись в законодавчих актах, або

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

Без врахування цих важливих аспектів легко прийти до масового порушення громадянських прав, як і до переслідування власників побутових засобів запису на будь-які носії інформації (включно до друкарських машинок); до ідентифікації кожного, хто переписав власну інформацію на CD-R диск, як “комерційного виробника”, тощо. Що, власне, і відбувається в Україні.

Через це в законопроекті (з версії 11) окремо дані визначення понять “Виробництво програмного забезпечення”, “Промислове виробництво програмного забезпечення” (поняття, які не мають прямої кореляції з кількісними параметрами колективу розробників та обсягом його продукції, або із типом бізнесу (малий, середній, великий тощо), як не мають і прямої кореляції з виробництвом носіїв з програмним забезпеченням (примірників програм); “Промислове виробництво носіїв з програмним забезпеченням”, “Промислове виробництво носіїв для програмного забезпечення (даних)”, “Комерційний рівень”, тощо. (ст. 1-37 – 1-42 в актуальній версії 15). Все це є окремі, не тотожні поняття.

Якщо чітко розрізняти наведені терміни та поняття – стане зрозуміло, чому фраза “виробництво неліцензійного (контрафактного) програмного забезпечення”, яку часто застосовують державні службовці, є нонсенсом. Адже фізично можливе лише виробництво оригінального програмного забезпечення, або доробка (переробка) Відкритого програмного забезпечення – що відповідно до Вільної ліцензії не може бути порушенням авторського права (тобто “фактом контрафакту”).

Правильна дефініція – “виробництво носіїв з неліцензійним (контрафактним) програмним забезпеченням”. Коректно також – “розповсюдження контрафактного (неліцензійного) програмного забезпечення” – оскільки факт розповсюдження ПЗ на будь-яких носіях нічого не говорить про походження самого ПЗ (тобто вкрали його, скопіювавши з порушенням відповідної ліцензії, або виробили (створили) власними силами, отримавши при цьому принаймні невідчужувані (немайнові) авторські права)…

Визначення “промислового виробництва носіїв з програмним забезпеченням” наведене в статті 1.41 версії 11 проекту Закону, і ?рунтоване на об’єктивних характеристиках обладнання для виготовлення копій носіїв ПЗ (зокрема, на можливості випуску за одну сесію запису більше екземплярів, ніж максимальна кількість екземплярів, доступних для пристроїв, що використовуються в сегменті неспеціалізованого для даної діяльності малого бізнесу, та в побуті (SOHO-сегмент за міжнародною ідентифікацією).

Іншим є поняття “Комерційого рівня”. Чітке визначення відповідного терміну введено з 11 версії законопроекту з опорою на загальнодоступний тлумачний словник:

1.31. “Комерційний рівень” (виробництва, копіювання, “піратства”, тощо) – рівень комерціалізації відповідного виду діяльності.

Кількісний та якісний рівень виробництва продукції (в контексті даного закону – виробництва копій носіїв з програмним забезпеченням), який дозволяє виробникові отримати регулярний зиск від цілеспрямованої реалізації продукції, достатній для концентрації на відповідній діяльності, як основній.

Зрозуміло, що визначивши порушення на “комерційному рівні” – тобто однозначно ідентифікувавши свідоме виробництво (наприклад, кустарне) контрафактного (!) продукту для продажу з ціллю отримання зиску – правоохоронні органи також повинні вдаватись до каральних дій. Але також зрозуміло, що міри протидії порушенню можуть бути інакші, ніж у разі порушення закону в промисловому масштабі.

Також введено поняття “Паблішера” (видавця програмного забезпечення) – з метою чіткої диференціації між “паблішером” і “виробником” програмного забезпечення (виробник програмного забезпечення не завжди самостійно займається друком накладу на власному обладнанні (і навіть як правило не займається цим!), отже, може і не отримувати від держави спеціальну ліцензію на провадження виробництва, наприклад, партій лазерних дисків).

3. Ні в статті 13 законопроекту (будь-якої версії), ні в будь-якій іншій статті, нічого не сказано про зменшення відповідальності або виведення з-під відповідальності за цілеспрямоване розповсюдження контрафактного ПЗ, яке (як і промислове виробництво контрафактного ПЗ) повинне переслідуватись в першу чергу. Натомість стаття 2 безпосередньо підтверджує правомірність використання лише ліцензійного програмного забезпечення.

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

Статус    Коментар № 8 Теза (проблема) Введення Вільного ПЗ призведе до зміни форматів даних і кола постачальників, що призведе в свою чергу до проблеми несумісності електронних документів. Цитата “Запровадження нових стандартів ПЗ неминуче призведе до використання нових форматів електронних документів та інших інформаційних одиниць” “Державні підприємства будуть зобов’язані майже повністю змінити коло постачальників” Рецензент УАППО

Висновок без достатніх підстав.

Рецензент не бере до уваги:

а) факт існування загальних стандартів у сфері ПЗ поза залежністю від схеми ліцензування ПЗ;

б) факт стандартизації самих відкритих форматів даних;

в) факт забезпечення сумісності за форматами файлів різних за ліцензіями та виробниками, але однакових за функціями програм.

Наприклад: всі сучасні редактори графічних зображень використовують чітко обмежений набір форматів графічних файлів; якщо редактор має внутрішній формат збереження редагованих файлів – обов’язково наявний конвертер до одного або кількох із загальновживаних форматів. Те саме стосується текстових редакторів, систем управління базами даних, тощо.

Тобто: проблема існує, але не носить катастрофічного характеру, і жодним чином не залежить від системи ліцензування ПЗ. Так, наприклад, пропрієтарний виробник, ПЗ якого за фактом домінує у певній частині держсектора України, може вирішити проблему або зміною системи ліцензування та документуванням “закритих” форматів даних, або портуванням (трансляцією) вже готового продукту для Вільної операційної системи (що об’єктивно призведе до розширення його ж сектору ринку ПЗ), або, врешті-решт, введенням додаткових налаштувань до стандартної конфігурації програми.

Те ж саме стосується і кола “прогнозованих і випробуваних часом” (у термінах експерта) постачальників (див. частину 4 коментаря № 28).

Окрім того: комп’ютеризацію державної сфери на даному етапі можна характеризувати як “початкову”, і рівень обізнаності маси держслужбовців із встановленим “пропрієтарним” ПЗ (здебільшого – неліцензійним!) – як “початковий”. З огляду на це зміна загального підходу до використання ПЗ в публічній сфері держсектору (де функціональність взагалі є цілком подібною!) не становитиме якихось нездоланних проблем.

Варто пам’ятати, що законопроект має за основний об’єкт саме публічні служби та публічну інформацію держсектору, а також базові персональні комп’ютерні системи для сфер держбезпеки та оборони – а зовсім не внутрішні виробничі автоматизовані процеси підприємств, наприклад. Хоча світова практика доводить слушність застосування Вільного ПЗ і у виробничій сфері (див. частину 4 коментаря № 26).

Статус Коментар № 9 Теза (проблема) Непродумане впровадження положень Законопроекту… погіршить систему національної безпеки… Цитата “Непродумане (?-Авт.) впровадження положень запропонованого проекту може (? – Авт.) значно погіршити систему національної функціональної безпеки, оскільки поспішне (?-Авт.) їх впровадження… призведе до невизначеності в питаннях уніфікованих підходів до вибору відповідного ПЗ та не дозволить з’ясувати(? - Авт) реальні потреби в об’ємах супроводу функціональності (?- Авт.) інформаційних систем…” Рецензент ДІВ МОН

1. В смисловому відношенні зауваження дуже “темне”, і не піддається однозначній інтерпретації.

“Непродумане”, “Поспішне”, “може змінити” – неюридичні терміни, в яких неможливо заперечувати положення проекту закону.

Незрозуміло, що означає термін “супровід функціональності” (адже безпосередньо закладена в програмно-апаратні системи функціональність не є предметом супроводу!), і чому саме введення можливості застосування Вільного ПЗ не дозволить з’ясувати “реальні потреби”.

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

Незрозумілим є і термін “національна функціональна безпека”. Якщо його слід розшифровувати буквально, тобто як “безпечне функціонування нації” – то слід зауважити, що комп’ютеризацією “охоплено” в Україні на загал лише близько 4 – 5 відсотків населення (за даними 2004 року). Через те навіть якісь ризикові (а широке введення Вільного ПЗ не є фактором додаткового ризику!) експерименти в галузі ПЗ можна провести цілком безболісно, не порушивши функціонування національного організму…

2. Щодо програмного забезпечення в сфері національної безпеки і оборони, як і загальнодержавних заходів із додержання безпеки у галузі застосування ПЗ (а тут до важливих чинників входять: зменшення технологічної залежності від закордонних постачальників, можливість перевірки ПЗ на відсутність не вказаної в документації функціональності, запобігання застосуванню в критичних сферах ПЗ “подвійного призначення”, можливість модифікації ПЗ для введення власних алгоритмів та процедур шифрування інформації, тощо) – то єдиним рішенням є відкритість та доступність програмного коду. Тобто – Вільна ліцензія на ПЗ.

Статус Коментар № 10 Теза (проблема) Можливість вільного доступу до кодів призведе до фальсифікації ПЗ, яке застосовується в режимних організаціях. Цитата “Маючи вільний доступ до кодів програми (як це передбачено GPL) – багато хто з професіоналів буде мати можливість змінити їх з метою отримання конфіденційної інформації та подальшого використання в своїх інтересах.” Рецензент

1. Щодо вільного доступу до кодів: наочні одночасно дві помилки.

Перша, і більш загальна, є результатом ігнорування факту, що лише можливість всебічного аналізу коду фахівцями (як тими, що працюють в самій організації, так і зовнішніми) – дозволяє взагалі ставити питання про безпеку використання програмного рішення і планування відповідних заходів. Тоді як “чорна скринька” (якою у розумінні безпеки є будь-яке пропрієтарне ПЗ) за визначенням не відповідає найпершій вимозі безпеки – прозорості системи, що застосовується.

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

Нонсенсом є вважати, що в державній організації застосовуватимуться саме ті примірники (носії) програмного забезпечення (коду) – з якими працюватимуть і будь-які фахівці, не пов’язані з роботою в даній конкретній організації. Пояснимо інакше: яким чином ваш особистий примірник коду текстового редактора, в якому ви провели зміни “в своїх інтересах” – потрапить до приміщення спецслужби, і буде встановлений на комп’ютерах спецслужби замість “чистого” (або зміненого “в інтересах” спецслужби фахівцями спецслужби ж) текстового редактора? І яким чином на цю ситуацію впливає тип ліцензії на ПЗ, про яке йдеться?

Очевидно, що жодним чином. І що через це наведені Рецензентом аргументи є абсурдними.

2. Слід також взяти до уваги, що при використанні “закритого” (пропрієтарного) ПЗ маємо справу з двома рівнями можливого порушення заходів безпеки: передбачуваного (наприклад, зумовленого вимогами уряду країни, на яку працює компанія-розробник) і випадкового (помилка).

При застосуванні Вільного ПЗ перша проблема “знімається” саме доступністю коду для всебічного експертного аналізу; друга – можливістю організації набагато більшого кола “тестерів” продукту (або відповідної репліки програмного продукту), ніж це можливо для будь-якої окремої софтверної компанії.

Статус Коментар № 11 Теза (проблема) Державна сфера потребуватиме частого оновлення ПЗ, що призводитиме до витрат. Цитата “…Зі зміною умов та завдань діяльності державних органів (що в сучасних умовах може траплятись досить часто) – знов і знов буде виникати необхідність в специфічних програмних продуктах, що буде потребувати матеріальних витрат…” Рецензент ДІВ МОН

Ця ситуація ніяк не впливає та тип ліцензування ПЗ і ніяк не залежить від типу ліцензування ПЗ (пропрієтарне або Вільне). Варто також враховувати, що розробка Вільного ПЗ в цілому значно дешевше, а окремий екземпляр (особливо такого масового ПЗ, як Інтернет-броузери, поштові системи, серверні системи тощо) – може бути офіційно отриманий користувачем безкоштовно.

Статус   Коментар № 12 Теза (проблема) Імовірно, що сукупна вартість використання Вільного ПЗ є вищою, ніж пропрієтарного. Цитата “…В ціну готової продукцію Вільного ПЗ необхідно закладати не тільки виробничі витрати, але й вартість засобів на технічну підтримку, супровід, адміністрування, подальший розвиток продукту (в тому числі і на дослідницьку діяльність). А тоді сукупна вартість вільного ПЗ значно зросте…” Рецензент ДІВ МОН, РПУ, УАППО

1. Всі витрати, вказані в даному запереченні, безумовно повинні бути включені і до розрахунку вартості використання пропрієтарного ПЗ. За виключенням хіба що “дослідницької діяльності”, що витрати виробників на неї у випадку застосування пропрієтарного ПЗ компенсуються за рахунок високої початкової ціни окремої копії програмного продукту. Власне кажучи, у запереченні наведено скорочену форму обрахунку TCO (Total Cost of Ownership) для будь-яких програмних продуктів та рішень.

2. З не меншою вірогідністю ТСО для пропрієтарного ПЗ буде більшим ТСО для Відкритого (Вільного) ПЗ. З огляду на специфіку ліцензій для Відкритого та пропрієтарного ПЗ можна гарантувати лише одне: ТСО для Вільного ПЗ чисто-теоретично може бути нульовим (наприклад, якщо екземпляр програми отриманий безкоштовно, а зусилля на оволодіння програмою користувач для себе не оцінює у грошовому еквіваленті), а ТСО для пропрієтарного ПЗ – не може дорівнювати нулю навіть теоретично.

3. У разі необхідності нової розробки (“розробки з нуля”) – вартість Відкритого ТЗ однозначно буде меншою через доступність великої кількості репозиторіїв Вільного ПЗ, з яких весь або частина коду програми може бути отримана безкоштовно. У цьому разі витрати “на дослідницьку діяльність” дорівнюватимуть витратам на модернізацію (або локалізацію) ПЗ, що в кілька разів менше, ніж повна вартість розробки нового продукту (див. Коментар №1).

Статус Коментар № 13 Теза (проблема) Законопроект передбачає використання лише одного типу Вільної ліцензії – “Linux/GNU style”(вочевидь, мається на увазі “GNU GPL-style”- Авт.) … Ситуація примусового використання такої ліцензії є порушенням правил добросовісної конкуренції (проявом монополізму)… У якості “монопольної” операційної системи проект Закону передбачає ОС “Linux”… Цитата “З наведеної до законопроекту пояснювальної записки можна зробити висновок, що всім вимогам, що пред’являються, відповідає лише один вид ПЗ – Linux/GNU style… Ситуація, коли вся країна, на підставі прийнятого закону, вимушена буде користуватись лише програмним забезпеченням від одного виробника… є грубим порушенням прийнятих в світовій практиці правил добросовісної конкуренції… та суперечить вимогам Закону України… “Про захист від недобросовісної конкуренції”… Рецензент ДІВ МОН

Ряд суттєвих помилок.

1. Законопроект не передбачає використання лише одного типу Вільної ліцензії, а пропонує використання будь-яких типів Вільних ліцензій. В статті 1.21. (1.18 для старих версій законопроекту) законопроекту написано:

1.21.“Вільна” ліцензія – будь-яка ліцензія на програмне забезпечення, що гарантує користувачеві права та можливості використання програми, не менші, ніж такі:

– використання програми для будь-яких цілей;

– доступ до програмного коду;

– будь-які дослідження механізмів функціонування програми;

– можливість використання механізмів (принципів) функціонування і будь-яких довільних частин коду програми для створення інших програм та (або) адаптації до потреб користувача;

– можливість копіювання (тиражування) і публічного поширення копій програми;

– можливість зміни і вільного поширення як оригінальної програми, так і зміненої, за тими ж умовами, під які підпадає і оригінальна програма.

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

Легко бачити, що у статті 1.21. застосовано термін “можливість” а не термін “обов’язковість” (поширення програми за тими ж умовами, під які підпадає оригінальна програма). Це означає, що факт субліцензування може мати, а може і не мати місце. Тобто – що проектом закону передбачене використання повного спектру Вільного ПЗ.

2. Linux/GNU style – це не вид ПЗ, а вид Вільної ліцензії на ПЗ (вочевидь під “Linux/GNU style” рецензент має на увазі “GNU GPL-style” ліцензію).

3. Навіть застосування лише якогось одного виду ліцензії на ПЗ жодним чином не може означати використання “програмного забезпечення від одного виробника”. Ліцензія певного виду – це лише стандартизований тип юридичного документу (угоди). І під одним або схожим типом ліцензій випускають ПЗ багато виробників – так само, як багато юридичних осіб укладають однакові за структурою господарчі угоди.

4. Навіть якщо програмне забезпечення, випущене під Вільною ліцензією (і навіть якимось одним виробником!), займає домінуючу позицію в окремому сегменті ринку ПЗ – самі умови ліцензування виключають монополізацію, якщо процедура замовлення (закупівлі) товару або послуги є конкурентною.

(Принагідно: остання помилка свідчить окрім іншого і про те, що рецензент (працівник патентного відомства!) осмислює поняття “виробництво” та “монополізація” лише у відношенні конкретних примірників товару, але не у відношенні ПЗ як творів, об’єктів творення або об’єктів застосування ліцензій…)

5. Кожен виробник ПЗ може випустити власний програмний продукт під будь-якою кількістю ліцензій (типів ліцензій). Яскравим прикладом є корпорація Microsoft, що випускає одні і ті ж самі продукти під великою кількістю варіантів пропрієтарних ліцензій: EULA (End User License Agreement), OLP, OL (Microsoft Open License – не слід плутати ці “відкриті ліцензії” з ліцензіями на Відкрите ПЗ, адже маємо в даному випадку суто-маркетинговий хід!), Select License, Enterprise Agreement, тощо… Це означає, що будь-який виробник закритого ПЗ матиме можливість впроваджувати свої продукти в державних установах, встановивши відповідний тип Вільної ліцензії та забезпечивши доступ до програмного коду. За схожою схемою успішно працюють компанії MySQL, Sun Microsystems, тощо… Тобто, застосування Вільних ліцензій в держсекторі – призведе до збільшення обігу і в пропрієтарних компаніях…

Статус Коментар № 14 Теза (проблема) Проект Закону передбачає використання ОС “Linux”, як “монопольної” операційної системи… У ОС Linux дуже мало прикладних програм, низький рівень безпеки, обмежений інструментарій, немає жодних стандартів, несумісні версії… Цитата “ОС Linux з’явилася в результаті експеримента Лінуса Торвальдса по модифікації ядра ОС UNIX. У Linux немає хазяїна,.. можна відмітити дуже малу кількість прикладних програм, нижчий рівень безпеки, обмежений інструментарій, відсутність будь-яких стандартів та формалізованої схеми розробки, підвищений рівень витрат на оплату праці та багато чисельні і несумісні версії установки (станом на лютий 2002 року нараховувалося 118 різних варіантів поставки)…” Рецензент ДІВ МОН

Ряд грубих помилок.

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

2. Linux є лише однією з багатьох тисяч Вільних за ліцензією програмних систем, і лише однією з кільканадцяти Вільних операційних систем. Більше того: існують Linux-базовані системи та програмні комплекси із змішаним типом ліцензування…

3. “Хазяєва” (цей термін, вочевидь, треба трактувати і як “основні або постійні розробники”?) є не у Linux взагалі – а у конкретних сімейств операційних систем, як-от RedHat, KSI, Debian, Lindows, MacOSx, тощо і тощо… Так само, як вони є у конкретних програм, але не у загальних, вже прийнятих de-facto, стандартів.

4. Експерт помиляється і у міркуваннях щодо ступеня контролю над розробкою ядра Linux. Самі лише проекти з розробки модифікацій ядра, як-от OpenMosix (кластеризація), RTLinux, RTAI (системи реального часу) – вже є ?рунтовним спростуванням думки про “обмежений інструментарій, відсутність стандартів та формалізованої схеми розробки”. Останнє зауваження взагалі є дивним – з огляду на функціонування численних депозитаріїв Вільного ПЗ світового масштабу (тобто впорядкованих систем реєстрації, оновлення та зберігання програмних бібліотек та їх версій, на базі яких збираються нові цілісні версії ПЗ згідно проектних планів команд розробників).

5. Розмаїття варіантів поставки не означає несумісності прикладних програм (переважна більшість з тисяч прикладних програм для Linux запускаються під керуванням будь-якої з сімейства Linux-базованих ОС саме через якісну стандартизацію). Різні версії підпрограм установки не означають несумісність операційних систем (одна і та ж операційна система може встановлюватись за допомогою різних підпрограм установки).

На даному етапі розвитку інформатики забезпечено певну сумісність всіх основних операційних систем для персональних комп’ютерів через підтримку:

а) операцій зчитування/запису для різних файлових систем;

б) старту однієї операційної системи під керуванням іншої операційної системи через емулятор/транслятор “дочірньої” ОС;

в) запуску кількох операційних систем на одному комп’ютері.

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

Щодо “нижчого рівня безпеки” – автори мають протилежні дані; див. також наступний коментар.

Статус Коментар № 15 Теза (проблема) Linux – вразлива ОС, тому що кількість атак на неї зростає (за даними Мі2g). Цитата “Дослідження, проведене британською компанією Mi2g виявило, що число атак хакерів на Web-сервери з Linux зростає. В той час, коли відповідний показник для серверів з Microsoft IIS, навпаки, падає. Що може слугувати непрямим доказом вразливості даної операційної системи.” Рецензент ДІВ МОН

Низка логічних помилок, або підміна понять.

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

2. Згідно контексту, Рецензент має на увазі “Web-сервер (апаратний) з операційною системою Linux”. Атаки провадяться не на операційну систему як таку – а на програмні Web-сервери (Microsoft IIS, Apache, ін.), що взаємодіють з відповідною операційною системою. (Якщо вже зовсім точно – то навіть не на web-сервери – а на «прикладні» web-програми, що працюють під керуванням web-серверів.) Таким чином можна говорити або про порівняння двох операційних систем, або двох Web-серверів, або двох програмних комплексів на основі “Операційна система – найрозповсюдженіший для неї Web-сервер – набір додаткових програм” – але не порівнювати операційну систему із Web-сервером (тут маємо або неточність, або логічну помилку однорідності об’єктів порівняння).

3. Відповідно тим самим дослідженням, кількість успішних атак на найрозповсюдженіший Вільний Web-сервер “Apache” – у кілька разів менша, ніж на будь-який з пропрієтарних Web-серверів. (Ще раз нагадаємо, що в законопроекті не йдеться безпосередньо про Linux!)

Неупередженому рецензентові буде цікаво в цьому контектсті подивитись на “розподіл ринку між найпопулярнішими серверами” (дані від серпня 1995 по квітень 2005 року, з яких видно, що “Apache” використовується в 70 відсотках випадків) ( http://netcraft.com/survey/ ):

Навряд чи ринок так високо оцінив би вільний сервер Apache (та відповідні вільні операційні системи, до речі) – якби їх надійність була нижчою за рішення від Microsoft…

Статус   Коментар № 16 Теза (проблема) Законопроект відкриває шлях до зловживань у сфері оподаткування через надання можливості укладати договори з суб’єктами підприємництва. Цитата “Представлений законопроект дає широке поле для зловживань у сфері оподаткування. Підприємства будуть мати можливість укладати договори з суб’єктами підприємництва (в основному тими, які сплачують єдиний фіксований податок), перераховувати їм кошти за розробку ПЗ, на суму цих коштів збільшувати відрахування податку на прибуток. Скалькулювати затрати на ПЗ з боку податкових органів та довести факти ухилення від оподаткування буде вкрай проблематично (за відсутністю методики оцінки об’єктів інтелектуальної власності), що зробить такий механізм ухилення від оподаткування вкрай привабливим для недобросовісних платників податків, що, в свою чергу, призведе до зменшення податкових надходжень до державного бюджету України.” Рецензент ДІВ МОН

Ряд грубих помилок. За цим аргументом необхідно заборонити будь-які господарські відносини.

Детально:

1. Змальована апокаліптична схема ніяк не залежить від типу ліцензування ПЗ. Адже виробників пропрієтарного ПЗ, (зокрема і тих, які платять єдиний податок) – не менше, а більше за кількістю, ніж виробників Вільного ПЗ (хоча частка виробників Вільного ПЗ і має сталу тенденцію до зростання).

2. Можливість юридичних осіб (=підприєміств) укладати угоди з іншими юридичними/фізичними особами (=суб’єктами підприємництва) є основою економічних відносин, закріплених Конституцією. Якихось інших ринкових відносин, окрім договірних/фінансових – не існує. Принаймні нашим економістам не вдалося уявити “позадоговірну” та “позафінансову” систему відносин, внаслідок якої підприємство в “демократичній правовій державі” (див. Конституцію України) – отримало б будь-який програмний продукт, незалежно від схеми його ліцензування.

3. Дискримінація учасників ринку згідно схеми, за якої юридична особа сплачує податок – “грубо порушує прийняті в світовій практиці правила добросовісної конкуренції та суперечить вимогам Закону України “Про захист від недобросовісної конкуренції”, Цивільному кодексу України, іншим законодавчим актам – на чому наголошував сам рецензент в попередніх запереченнях.

4. Проблеми, які виникають під час взаємодії юридичних осіб, що сплачують “єдиний податок” за спрощеною схемою оподаткування, з однієї сторони, і юридичних осіб, що сплачують податки за звичайною схемою (або не сплачують податків взагалі через те що є органами державної влади) – є результатом НЕ намагань проведення законопроекту “Про використання Відкритих форматів даних та Вільного ПЗ…” – а результатом глобальної податкової політики держави. Через це згадані проблеми, художньо описані експертом, не мають жодного відношення до законопроектів про використання тих або інших типів ліцензування на програмне забезпечення.

Статус Коментар № 17 Теза (проблема) Введення в дію законопроекту про використання Вільного ПЗ (якщо ми правильно “перекладаємо” цитату – див. нижче – авт.) заборонить використання комерційного ПЗ Цитата “Введення в дію Вільного ПЗ негативно позначиться на продовженні інформатизації в нашій країні, оскільки на невизначений термін заборонить використання продуктів українських компаній, виробників комерційного ПЗ, які, в першу чергу, були зорієнтовані на виробництво, постачання та супровід програмних систем, які відповідають за інтеграцію управління інформаційними та матеріальними ресурсами … А самі корпоративні споживачі таких продуктів… можуть бути вимушені призупинити встановлення … необхідних для щоденної роботи нових систем, оскільки виникне необхідність налаштування функціональності (сумісності) цих систем в рамках базової операційної системи” Рецензент ДІВ МОН

Ряд грубих фактичних і логічних помилок, незнання предмету.

1. Законопроект не може “забороняти… використання комерційного ПЗ”, бо Вільне ПЗ так само є комерційним, як і пропрієтарне. Відмінність між ними полягає не у можливості бізнес-застосування, а у кількості основних майнових прав, які передає користувачеві відповідна ліцензія. Вільна ліцензія передає всі основні майнові права, пропрієтарна – не всі (здебільшого – лише право використання однієї копії ПЗ) – що недостатньо для потреб держсектору. У разі ж випуску різних версій цілком оригінального продукту під Вільною та пропрієтарною ліцензіями одночасно – власник прав може застосовувати одночасно цілий спектр бізнес-концепцій.

У документі “Визначення концепції відкритого вихідного коду (Open Source) (версія 1.9, переклад Романа Шкіля), зазначено:

“Ліцензія не повинна обмежувати будь-яку сторону від продажу чи передачі програмного забезпечення…

Ліцензія не обмежує будь-кого щодо використання програми у визначених напрямках застосування. Наприклад, це не обмежує використання програми в бізнесі…”

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

З юридичної точки зору

“Вільне програмне забезпечення формує публічний ринок, будь-яка послуга на якому… може продаватись та купуватись на конкурентному ринку через вільну контрактацію двох сторін – постачальника та покупця послуги, без апеляції до третьої сторони (автора або іншого власника прав на твір)” (М. Отставнов, Libertarium.ru).

Звідси легко бачити, що думка про “заборону законопроектом комерційного ПЗ” – безпідставна.

2. Пропрієтарні комерційні компанії після введення законопроекту в дію можуть отримати лише додаткові замовлення – наприклад, на портування (трансляцію) їхніх програмних продуктів для ряду Вільних операційних систем, що пришвидшить, а не призупинить інформатизацію. Але вартість трансльованих продуктів, якщо держава “підключається” до їх масового тиражування та розповсюдження – буде не кількасот або кілька тисяч доларів за екземпляр, а від одиниць до кількох десятків гривень за екземпляр.

3. Українського виробника пропрієтарного ПЗ (у розумінні цілісних програмних пакетів для ділової сфери) – практично не існує (як сфери виробництва!) – якщо не брати до уваги виробників кількох утиліт (дрібних допоміжних програм) та ПЗ для забезпечення бухгалтерії. Існують компанії, які просувають на ринок програмні рішення на основі програмних продуктів західних (або східних) пропрієтарних виробників, і виконують з допомогою таких продуктів проекти інформатизації в Україні.

4. Функціонування програмних комплексів ніяк не залежить від типу ліцензії на ПЗ.

5. Законопроект ясно визначає, що у всіх випадках, де не може бути застосоване Вільне ПЗ – можна за відповідною процедурою застосувати пропрієтарне ПЗ, і особливо це стосується “внутрівідомчого (критичного для застосування) функціонування” (ст.. 2.3) – тобто саме “систем, які відповідають за інтеграцію управління інформаційними та матеріальними ресурсами”.

6. Законопроект не передбачає обов’язкову заміну базової операційної системи. Поміж всім розмаїттям інших очевидних рішень – постачальник будь-якої пропрієтарної операційної системи може просто застосувати Вільну ліцензію замість “закритої”.

Статус Коментар № 18 Теза (проблема) Відкрите ПЗ позбавлене технологічної залежності від виробника лише на першому етапі використання. Цитата “Відкрите ПЗ позбавлене технологічної залежності від виробника лише на першому етапі свого використання. Всі доробки, які будуть створюватись на його базі, вже будуть являтись інтелектуальною власністю розробника. Користувач не зможе контролювати, змінювати і виправляти програму, пристосовуючи її до своїх специфічних потреб, так як це буде порушенням авторських прав розробника… Користувачі не одержують можливість домовитися з будь-яким програмістом… про виправлення помилок або зміну функціональних можливостей, через те, що такі дії будуть протиправними” Рецензент ДІВ МОН

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

1. Всі Вільні ліцензії дозволяють, а ліцензія GNU GPL-style – вимагає, щоб права замовника на змінену програму були не менші, ніж на оригінальну. Всі Вільні ліцензії забезпечують передачу більшості (=основних) майнових прав. Таким чином, похідні від якоїсь Вільної програми або комплексу програм так само є Вільними.

У будь-якому випадку ліцензія на похідний твір Вільного ПЗ GNU GPL-style не може бути “вужчою” за ліцензію на базовий твір. Наприклад: похідна програма від програми, випущеної під ліцензією GNU GPL-style обов’язково буде підпадати під ліцензію GNU GPL-style. Похідна програма від програми, випущеної під ліцензією BSD – може бути будь-якою – але задля збереження вигод, які несе Вільне ПЗ – більшість похідних від програм, ліцензованих за схемою BSD, випускається під ліцензією BSD, ширшою, або подвійною.

2. Автори програм (та інших творів) не втрачають всю “інтелектуальну власність” на них (в термінах рецензента). Вони завжди зберігають немайнові авторські права на твір, які є невід’ємною частиною авторських прав (інтелектуальної власності). Що ж до майнових прав – то вони передають замовникам (користувачам) більшу або меншу частину майнових прав відповідно до застосованої ліцензії. Більше того: як ми бачили у попередньому випадку – частина майнових прав, що передаються, узвичай є або сталою від оригіналу до останньої похідної, або навіть більшою (тому що Вільні ліцензії не забороняють передавати більші права).

Таким чином висловлене припущення, що Відкрите ПЗ спочатку не є інтелектуальною власністю (!), але у випадку доробки або зміни раптом “набуває” рис інтелектуальної власності – є відвертим нонсенсом.

3. “Користувачі не одержують можливість домовитися з будь-яким програмістом” саме за використання моделі “пропрієтарного” ПЗ – через те що випуск версій пропрієтарного ПЗ диктується виключно внутрішніми планами розробника, а не потребами користувача. Тут в дію вступає не так залежність від типу ліцензії – як властива “закритому” ПЗ модель розробки.

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

Статус Коментар № 19 Теза (проблема) Дорогим є перехід існуючих інформаційних систем на Вільне програмне забезпечення. Повна вартість користування Вільним ПЗ є високою (варіант: вищою за повну вартість користування пропрієтарним ПЗ) Цитата “…Програмний комплекс що використовується для інформаційного забезпечення держустанов, складається, за невеликим винятком, з комерційного програмного забезпечення, на яке вже витрачено значні кошти…” “…Не проведено економічне об?рунтування переходу хоча б однієї державної організації на використання Вільного програмного забезпечення.” “…Незрозуміло, чому мірою вартості програмного забезпечення для державної установи є вартість виключно програмного забезпечення, а не повна вартість володіння…” Рецензент МЕУ

1. Проблема вже встановлених програмних систем (тобто збереження державних інвестицій) вичерпно враховується законопроектом починаючи з версії 9а. Наведемо цитати з поточної версії (15):

2.5. Суб’єкти державного сектору для внутрівідомчого використання з юридичних причин мають брати до уваги пріоритетність використання Відкритого (Вільного) програмного забезпечення, визначеного в статті 1.24 цього Закону – у всіх випадках, коли таке програмне забезпечення:

а) наявне на ринку або в прямому доступі;

б) не поступається за профільною для сфери застосування функціональністю “закритому” ПЗ та (або) виграє у “закритого” комерційного ПЗ за співвідношенням “ціна – функціональність”.

Окрім того, стаття 6 (“Винятки та захист державних інвестицій”) вводить можливість використання “закритого” (“пропрієтарного”) ПЗ –

“для будь-яких наявних, вже спроектованих та таких, що знаходяться у стані проектування систем внутрівідомчого користування, у випадках, якщо загальна сума вже зроблених витрат на відповідне ПЗ (або відповідне інформаційне рішення чи систему), а також перспективних витрат (на термін до 3 років), включно з наявною та розрахованою вартістю володіння, перевищує вартість введення відповідного рішення на базі Відкритого (Вільного) ПЗ, або доводить неекономічність впровадження такого рішення”.

Таким чином, економічне об?рунтування має бути розроблене для кожного конкретного випадку, а режим роботи більшості “пропрієтарних” систем, які вже знаходяться в користуванні – не змінюватиметься аж до того часу, як вони морального застаріють.

Проте загальний розрахунок “за аналогами” – наприклад, порівняння вартості операційних систем та офісних пакетів – демонструє від дворазового до десятикратного зменшення витрат. Те ж саме стосується і такого показника, як “повна вартість володіння” (який, треба зауважити, є не суто-економічним, але також і маркетинговим показником, що треба обов’язково брати до уваги).

Наприклад, звіт Бюро перепису населення (США) (Lisa R. Wolfisch, Rachael LaPorte Taylor. Open Source at the Census Bureau and FedStats // Proc. of Conf. “Open Source: A Case for e-government”, Washington, D.C., Oct. 16-18, 2002) наводить дані про скорочення витрат від 62 до 100% за проектами публікації даних для МВФ – в порівнянні з використанням пропрієтарного ПЗ:

“Пропрієтарне” ПЗ, $ тис. “Вільне” ПЗ, $ тис. Скорочення витрат ОС та обладнання 80 30 62,5% Web-сервер 3 0 100% СУБД 80 12 85% Програма пошуку 195 5 97,4% На загал 358 47 86,9%

Дані про структуру бюджету на інформатизацію державних структур м. Києва¹ свідчать, що від 60 до 80 відсотків загальних витрат на інформатизацію припадає (або повинно припадати при використанні ліцензійного програмного забезпечення) на придбання ліцензій у пропрієтарних виробників – тоді як за умови застосування Вільного ПЗ цієї статті витрат просто немає.

Великі суми економії в процесі застосування (=володіння) пояснюються також можливістю легкого перенесення Вільних програм для різного програмного (зокрема і системного) оточення; відсутністю затримок з поставкою, доступністю підтримки від авторів, відсутністю видатків на ліцензування та доступом до програмного коду. У межах конкретного проекту вирішальними аргументами виявились: можливість швидкої прикладної розробки, зниження витрат на підтримку (!) та можливість сконцентруватися на розповсюдженні даних – тобто на основному завданні організації, а не на технології, яка цю роботу забезпечує.

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

– Існування великого пулу вже готових Вільних програм (замовлення на доробку, модифікацію, адаптацію, локалізацію, документування існуючої програми, тощо – значно дешевше і менш ризиковане, ніж замовлення розробки “з нуля”);

– Право безкоштовного введення до господарчого обороту додаткових екземплярів (відсутні витрати на придбання додаткових ліцензій та їх облік);

– Право на модифікацію та доступ до програмного коду (послуги з виправлення, адаптації та модифікації можуть бути замовлені на конкурентній основі);

– Можливість переносу програми до іншого програмного або апаратного середовища (до того ж більшість Вільних програм доступні більш ніж для однієї ОС або апаратної платформи);

– Існування кінцевих користувачів в інших секторах народного господарства та приватного ринку послуг (як результати держконтрактів в сфері Вільного ПЗ стають доступні приватним користувачам – так і результати контрактів в приватному секторі – стають доступні державі як одному з кінцевих користувачів, що знижує масштаби витрат);

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

2. Не існує загальновизнаної методики підрахунку та визначення ТСО: показник є не так економічним, як маркетинговим.

Поза тим – з версії 11 законопроекту (див. Пояснювальну записку до законопроекту) введено економічне об?рунтування для типової державної установи.

Статус Коментар № 20 Теза (проблема) Прийняття закону вимагатиме додаткових витрат Цитата “Необхідно звернути увагу на те, що прийняття цього проекту буде вимагати додаткових витрат, і ці витрати можуть бути дуже суттєвими. Так, не визначено, за які кошти і який орган буде проводити фінансування повторного дослідження ринку і підтвердження відсутності альтернатив для подальшого використання відповідного програмного забезпечення… а також за який рахунок буде здійснюватися повне страхування ризиків, що виникли внаслідок застосування закритого комерційного ПЗ, зокрема, за позовами громадян.” Рецензент ГНЕУ

1. Порушено правила формальної логіки (висновок без достатніх підстав). Із факту, що в тексті законопроекту прямо не вказано, хто (в кожному конкретному випадку!) проводитиме дослідження ринку, і хто (знов-таки, за вимогою – в кожному конкретному випадку!) здійснюватиме страхування ризиків – зроблено висновок про те, що “прийняття законопроекту буде вимагати додаткових витрат”, і що “ці витрати можуть бути (а можуть і не бути? – авт.) дуже суттєвими”. Незрозумілими також є категорії “суттєвості” та “додатковості” витрат в даному контексті.

Поза тим відповідь на “ресурсні” запитання може бути різною у різних випадках. Наприклад, дослідження ринку можуть вести як спеціалізовані наукові або громадські інститути (які є в розпорядженні держави), так і приватні фірми на конкурсних (що знижуватиме або й нівелюватиме витрати) засадах.

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

Згідно чинного законодавства відповідачем першої черги в цьому випадку повинна бути установа, дії якої призвели до втрат або порушення прав. Але відповідачем другої черги – цілком може бути і постачальник закритого комерційного ПЗ (звісно, за умови коректно складеної угоди між держустановою та постачальником!) В останньому випадку державна установа фінансово не постраждає.

Статус Коментар № 21 Теза (проблема) Для роботи з Вільним ПЗ немає кадрів. Цитата “Загальновідомою є проблема низької оплати спеціалістів з інформаційних технологій в держустановах. Використовуване на даний момент комерційне програмне забезпечення є загально розповсюдженим і відомим (наприклад – програмне забезпечення фірми “Microsoft”), і це дещо запобігає витоку кваліфікованих кадрів… У разі ж використання Вільного програмного забезпечення треба буде не тільки знайти спеціаліста, але й дати йому змогу (і умови) оволодіти програмним забезпеченням в необхідному обсязі. Крім того, за умов низької обізнаності спеціалістів з програмним забезпеченням, зменшується ймовірність успішної його експлуатації.” “Переважна більшість користувачів ПЗ не вміє користуватися програмним забезпеченням з відкритим кодом” Рецензент ІЗ, ДКЗІ, УАППО

1. Принциповий момент полягає у трактуванні “кадрового питання”. Слід розуміти, що у розрізі програмування (=виготовлення) та застосування – Вільні (Відкриті) програми не представляють собою нічого принципово відмінного від програм “закритих”, і що “відкритість” або “закритість” ПЗ – це питання типу застосованої до продукту ліцензії, і (можливо, але не обов’язково!) методики ведення проекту – проте аж ніяк не зміни принципів програмування і не підготовки якихось “окремих фахівців із Вільного ПЗ”.

Таким чином, поняття “нестача фахівців” тут слід звузити виключно до поняття “нестача системних адміністраторів” (які у переліку кваліфікованих кадрів складають нижчу за кваліфікацією ланку відносно програмістів, системних архітекторів, менеджерів софтверних проектів тощо) – та “нестача досвідчених користувачів”. До того ж і гасло про “нестачу системних адміністраторів та користувачів” слід також уточнювати – через те, що загальні принципи роботи прикладного ПЗ, локальних і глобальних мереж, адміністрування користувачів, інсталяції програм на персональні комп’ютери – для обох класів ПЗ є ідентичними (що обумовлено єдиними відкритими базовими стандартами для всього комп’ютерного ПЗ), і лише аспекти практичного використання мають відмінності.

Кадрова проблема також не є специфічною для Вільного ПЗ, хоча поза сумнівом необхідно на державному рівні вирішувати і кадрові проблеми. Наприклад, не можна вважати нормальним, коли державна сфера освіти вкладає величезні кошти у підготовку висококваліфікованих фахівців-програмістів (будь-якого профілю!), які вже за рік – два по закінченні учбового закладу або щезають за кордоном, отримавши “зелену візу” в одній з країн Заходу – або змінюють фах.

Запобігти цьому можна лише через розвиток національної сфери програмування. А такий розвиток на сьогодні доступний саме у сфері Вільного та Відкритого програмного забезпечення. Адже штатні розклади “пропрієтарних” компаній є відносно сталими, а за період 2000 – 2003 року навіть зазнали істотного скорочення (за рахунок низки банкрутств, “злиття” та “взаємопоглинання”). Використання ж Вільного ПЗ “генерує” велику кількість малих та середніх профільних компаній, які здатні докорінно змінити ситуацію на внутрішньому ринку програмного забезпечення.

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

Окрім того, діють автоматизовані та напівавтоматизовані депозитарії для всіх основних типів Вільних операційних систем та програмних комплексів – з допомогою яких користувачі можуть проводити автоматизоване покращення (upgrade) встановленого програмного комплексу, або збирати нові його версії.

Окрім того – “репліки” або “дзеркала” таких депозитаріїв діють і в Україні.

Таким чином базова система підтримки проектів Вільного ПЗ – набагато краща, ніж у “пропрієтарного”. Питання полягає лише в адаптації цієї системи до українських потреб (що здебільшого не перевищує потреб на локалізацію).

2. Більшість так званих “фахівців” з “пропрієтарного ПЗ” в Україні насправді є “фахівцями з контрафактного ПЗ” – тобто “самоучками”, для яких відповідна фірмова документація до програм ніколи не була доступною.

Через широку доступність документації Вільне ПЗ має більший потенціал для вивчення та “генерації” фахівців.

В цьому контексті варто також згадати про сертифікаційні курси, які існують в Україні що для “пропрієтарного” що для “вільного” ПЗ: наприклад, ряд курсів за тематикою Вільних ОС веде “Квазар-Мікро”.

Статус Коментар № 22 Теза (проблема) Вільне ПЗ важко шукати, і невідомо, хто його розробляє. Цитата “Вільне ПЗ треба знайти або розробити… Незрозуміло, хто, у разі потреби, розробить програмне забезпечення…” Рецензент ІЗ

Проблема пошуку Вільного ПЗ освітлена у відповіді на попереднє зауваження (міжнародні та локалізовані депозитарії) (див. також розділ 1 коментаря № 26).

Проблеми розробки локалізованого Вільного ПЗ частково вирішуються наявними в Україні силами (перелік учасників конференції з Вільного ПЗ у вересні 2002 року містив понад 200 учасників, включаючи до 60 представників юридичних осіб, 2004 – близько 300 учасників).

Проблема розробки оригінального Вільного ПЗ (взагалі) – принципово тотожна проблемі розробки оригінального пропрієтарного ПЗ, і жодним не залежить від типу ліцензії. Якщо, звісно, не враховувати таких додаткових можливостей Вільного ПЗ, як повторне використання коду, тощо… Тобто розробляти і Вільне, і “пропрієтарне” ПЗ може один і той самий розробник.

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

Статус Коментар № 23 Теза (проблема) Вільне ПЗ в принципі не забезпечується гарантією та підтримкою Цитата “Виробник Вільного ПЗ несе відповідальність і підтримує Вільне ПЗ виключно “з власної доброї волі”, на відміну від виробника комерційного ПЗ, який виконує це в рамках зобов’язань перед покупцем”. “Для таких (пропрієтарних – Авт.) програм компанії-власники забезпечують створення системи підтримки їх використання, оновлення, навчання користувачів і т. ін…” Рецензент

Помилка. Режим підтримки ПЗ та гарантій на ПЗ ніяк не пов’язаний з моделлю ліцензування (тобто з тим, “пропрієтарним” “вільним” або якимось іншим є ПЗ) – і як правило становить зміст окремої угоди (або частини комплексної угоди) між виробником ПЗ та користувачем. Отже, гарантійні умови та умови підтримки є питанням окремих договірних відносин.

“Загальна практика роздрібного розповсюдження програм, як вільних, так і “пропрієтарних” – пише Максим Отставнов (фонд “Нова економіка”) – звичайно включає відмову від гарантій з приводу можливості застосування; такі контракти прийнято оформлювати як окремі контракти на обслуговування”.

І зрозуміло, чому: за умови роздрібного або OEM-продажу автор (або паблішер, тобто видавець) програми ніколи не знає, на якому точно обладнанні та в якому точно програмному оточенні програму намагатимуться використати…

Якщо автори цього зауваження зайдуть (фізично, або через Інтернет) на будь-який сайт розробника Вільного ПЗ (для прикладу можна спробувати RedHat, KSILinux, AltLinux, тощо) – вони обов’язково знайдуть пропозиції та форми угод додаткової підтримки – поруч з умовами стандартної підтримки через он-лайнові тематичні конференції. Такі угоди можна знайти і на сайті практично будь-якого “пропрієтарного” розробника.

Окрім того: ніякої “підтримки” за вкрадене (!) у пропрієтарного виробника ПЗ ще ніхто отримати не зміг. Так само, як немає повноцінної підтримки проданого за найдешевшими ліцензіями (для сфер науки, освіти, для державних закладів, роздрібними) пропрієтарного ПЗ в Україні (а Україна якщо купує ліцензії, то саме такі, найдешевші). Вільне ПЗ тут має хоча б ту перевагу, що примірник програми може бути отриманий безкоштовно на законних підставах…

Статус Коментар № 24 Теза (проблема) В Україні відсутня система підтримки розробки та розповсюдження ПЗ з відкритим кодом Цитата “Відсутня система підтримки розробки та розповсюдження ПЗ з відкритим кодом”. Рецензент ДКЗІ

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

2. Підтримка користувачів. Частково проблему вирішує наявність розвинутої міжнародної системи підтримки користувачів через тематичні конференції. Таким чином глобально питання організації локалізованої підтримки користувачів зводиться до завдання локалізації.

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

2. Із “закритим” ПЗ ситуація така ж сама, а подекуди – й гірша. Наприклад, київський телефон підтримки кінцевих користувачів продуктів Microsoft лише переключає користувача на московську лінію, де менеджер просить «говорить по-русски», бо не розуміє української мови; за кожним складним технічним запитанням сам московський центр звертається до європейського – бо в московському представництві немає технічних фахівців відповідної кваліфікації…

Статус Коментар № 25 Теза (проблема) Створення безкоштовних аналогів для спеціалізованих програм за рахунок ентузіазму розробників є неможливим Цитата “Створення безкоштовних аналогів для великих спеціалізованих програм за рахунок ентузіазму розробників сьогодні є неможливим”. Рецензент ДКЗІ

Поверховий погляд на проблему.

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

Варто навести хоча б кілька джерел отримання Вільного ПЗ, що не ?рунтуються на “чистому ентузіазмі”, проте широко практикуються розробниками:

– випуск одного і того ж ПЗ під різними типами ліцензій (наприклад – під “пропрієтарною” та “вільною” ліцензією) – для різних схем (галузей) застосування (це дозволяє BSD-стиль ліцензування);

– трансляція вже готового ПЗ під нову операційну систему із зміною типу ліцензування;

– розробка Вільного ПЗ на основі іншого, вже готового, але такого, що має недостатню для даного проекту функціональність (=використання депозитаріїв Вільного ПЗ та повторне використання програмнорго коду);

– розробка Вільного ПЗ з орієнтацією на найнижчу ціну екземпляру (принцип отримання необхідного обсягу коштів з великого накладу замість отримання необхідного обсягу коштів від великої ціни за екземпляр);

– паралельна розробка версій ПЗ під різними ліцензіями для різних ринків (як всередині держави, так і на міжнародному ринку);

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

2. Не завжди потрібні саме аналоги якихось конкретних спеціалізованих програм: через те, що для Вільних операційних систем існують схожі за функціональністю Вільні ж прикладні програми – в більшості випадків достатньо сумісності форматів даних.

Статус Коментар № 26 Теза (проблема) Вибір Вільного ПЗ вкрай обмежений. Абсолютна більшість спеціалізованих програм є пропрієтарними, і для них не існує еквіваленту серед ПЗ з відкритим кодом. Лише пропрієтарні програми забезпечуються підтримкою… Програми для управління великими системами є лише пропрієтарні… Цитата “Стосовно ПЗ з відкритим кодом, то вже існують прийняті до загального вжитку програми, які здатні забезпечити підтримку на окремих обчислювальних пристроях (в основному, персональних комп’ютерах та невеликих серверах) найбільш загальних завдань… До цих програм належать: Unix-подібні операційні системи; текстові редактори для таких операційних систем; програми для перегляду веб-сторінок (браузери) та роботи з електронною поштою; веб-сервери… Одночасно слід зазначити, що абсолютна більшість спеціалізованих програм, що створені для управління великими системами, є пропрієтарними, і для них не існує еквіваленту серед програмного забезпечення з відкритим кодом. Навіть у тих випадках, коли створюється спеціалізована програма для операційної системи з відкритим кодом – вона поширюється її власником в режимі пропрієтарного програмного забезпечення…” “На сьогоднішній день не існує серйозних, рівня великого підприємства чи корпорації, рішень для систем управління базами даних,які були б побудовані за принципами ВПЗ” Рецензент

Ряд неточностей, які в сумі приводять до негативного висновку.

1. Рецензенти позиціонують ПЗ з відкритим кодом лише як таке, що здатне вирішувати найбільш загальні завдання на рівні персональних комп’ютерів та невеликих мереж. Такий “аналіз” ринку не є коректним, через складність та багатосегментність самого ринку, а також необхідність врахування низки географічних та інших факторів.

Наприклад, якщо розділити ринок на найбільш значимі сегменти, то отримаємо таку картину (усереднені дані DataQuest + IDC Data Group за 2003 рік):

Сегмент Вільне ПЗ Пропрієтарне ПЗ Глобальні мережі (Інтернет) Абсолютне домінування (>70 відсотків) Близько 30 відсотків, проте з них близько 20 – пропрієтарні версії Unix-систем Локальні мережі та рішення корпоративного рівня Близько 35 – 40 відсотків; аналіз ускладнений через використання “змішаних” рішень Нечітке домінування (понад 60 відсотків) аналіз ускладнений через використання “змішаних” рішень Локальні мережі середнього та малого бізнесу Абсолютне домінування (до 80 відсотків) Близько 20 відсотків Елементарні (2-3 ПК) однорангові локальні мережі Менше 10 відсотків Абсолютне домінування (близько 90 відсотків) Операційні системи ПК Близько 20 відсотків Абсолютне домінування (близько 80 відсотків)

Якщо аналізувати ринок за географічним показником – то побачимо, що, наприклад, в США та в європейському регіоні домінують пропрієтарні програмні системи, а в азійсько-тихоокеанському регіоні – Вільні (наприклад, 34 відсотки поставок всіх Вільних операційних систем в 2001 році прийшлося саме на азійсько-тихоокеанський регіон).

А для “пострадянського” регіону питання розповсюдження того або іншого типу ліцензій або відповідного ПЗ взагалі не має сенсу – адже більшість інсталяцій (до 92 відсотків прикладних програм за даними на початок 2001 року, близько 85 відсотків за даними на початок 2005 року) є взагалі неліцензійними (тобто власники ПК купують ПЗ на ринку, не цікавлячись типом ліцензії і питанням правомірності продажу ПЗ конкретним продавцем, – що цілком закономірно, тому що покупець не зобов’язаний перевіряти законність діяльності продавця).

Щодо вузького функціонального спектру Вільних програм – то навіть незважаючи на те, що автори зауваження явно звужують функціональність перелічених напрямків застосування (використовуючи, наприклад, дефініцію “текстовий процесор” замість “офісний пакет”, адже в “офісний пакет” стандартно входять електронні таблиці, програма створення презентацій, програма бізнес-графіки, редактор математичних формул, тощо) – цю тезу легко спростувати. Варто лише звернутись до першого-ліпшого депозитарію Вільних програм та проектів, і подивитись на статистичні дані щодо спектру та функціональної направленості доступних програм і рішень.

Так, лише на одному сервері http://freshmeat.net за станом на 9 березня 2005 року наявні 36511 окремих програмних розробок (і 158910 програм якщо рахувати окремі релізи (версії)) за всім спектром можливої тематики (див. http://freshmeat.net/stats/). Ці програми поширюються як Вільні, і доступні для завантаження через Інтернет. Не кажучи вже про те, що для Вільних операційних систем, які підтримуються виробником (Debian, наприклад) – кількість пакетів (функціонально-закінчених програмних розробок) перевищує тисячі (більш як 8000 для нашого прикладу, ОС Debian).

Цікаво у зв’язку з цим проаналізувати також кількість проектів, що знаходяться в стані інтенсивної розробки лише у межах одного центрально-європейського серверу (Німеччина), за даними спеціалізованого сервера розробників www.berlios.de/ (стан на грудень 1992 року):

Communications (52 projects) Printing (3 projects) Database (24 projects) Scientific/Engineering (38 projects) Desktop Environment (22 projects) Security (15 projects) Documentation (16 projects) Software Development (79 projects) Education (22 projects) System (55 projects) Games/Entertainment (39 projects) Terminals (4 projects) Internet (95 projects) Text Editors (10 projects) Multimedia (37 projects) Other/Nonlisted Topic (20 projects) Office/Business (31 projects) Разом 562 проекти

З цих даних цілком зрозуміло, що мову слід вести не про обмеженість спектру доступного Вільного програмного забезпечення – а про проблему локалізації та адаптації відповідних рішень і програм для українського ринку, що якраз і вирішує законопроект та проект Концепції переходу на Вільне ПЗ. А також – про необхідність цілеспрямованих програм трансляції (“портування”) тих (як правило - допоміжних) програм, які необхідні для масового використання в держсекторі, проте відсутні у версіях для Вільних операційних систем.

2. ПЗ для публічних сервісів та офісних потреб, щодо яких виставляє вимоги законопроект – то вони підпадає під правило “80 на 20”: 80 відсотків потреб забезпечують 20 відсотків пропозицій. Так, операційні системи, офісне ПЗ, Інтернет-браузери та програми електронної пошти, засоби контролю та адміністрування локальних мереж та елементарні засоби організації колективної роботи – задовольняють більше 80 відсотків загальних потреб в ПЗ для держсектору – а експерти ДКЗІ підтверджують, що саме для цього сегменту рішення у сфері Вільного ПЗ існують.

Що ж до ПЗ спеціалізованих комплексів та внутрівідомчого користування – то законопроект передбачає широкі можливості використання в цих сегментах будь-якого ПЗ.

3. Щодо поширення спеціалізованих програм лише як пропрієтарних – то тип ліцензування і факт спеціалізованості програми не мають очевидної кореляції.

Так, тиражування (тобто здійснення лише одного з майнових прав) Microsoft Windows та MacOS 6 – 8x, Caldera Linux – неправомірне без спеціальної угоди з володарем прав (тобто відповідно до типу застосованої ліцензії). А тиражування Corel Linux, RedHat, AltLinux, окремих версій ядра Mac OSX тощо – правомірне. Тиражування операційної системи Соляріс (Solaris) версії 6 – неправомірне, а версії 7 – правомірне, а версії 9 – знову неправомірне. Тиражування спеціалізованого пакету Microsoft Office – неправомірне. А Open Office.org та більш як 20 похідних офісних комплектів – правомірне. Тиражування графічного редактора Adobe Fotoshop неправомірне, а Gimp – правомірне. Тиражування програми тримірної графіки Caligari TrySpace неправомірне, хоча існують безкоштовні версії – а всього комплекту програм тримірної графіки OpenVRML – правомірне за ряду умов…

А що вже до використання…

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

4. Кінець-кінцем – наводимо цитату з поважного джерела (Звіт про Linux-конгресс, що проведено у Москві Hewlett-Packard та Oracle, подробиці – http://www.cnews.ru/topnews/2002/12/17/content6.shtml , яка добре ілюструє хибність думки про те, що Вільне ПЗ (зокрема Linux) не використовується або майже не використовується “для управління великими системами”:

“По прогнозам IDC, сегодня ОС Linux является одной из наиболее динамично развивающихся операционных систем, и в ближайшие годы станет основной платформой для корпоративных решений…

Как заявили специалисты из Hewlett-Packard, их компания рассматривает ОС Linux как одну из базовых ОС в секторе корпоративных информационных приложений, за счет ее возможности поддерживать высокопроизводительную архитектуру IA-64…

Копания Oracle, по словам ее представителей, была настроена на поддержку ОС Linux с момента появления этой платформы, и стала первым поставщиком, предложившим поддержку ОС Linux в своих коммерчески доступных продуктах - реляционной СУБД, сервере приложений и полном наборе инструментов разработки. Оracle уделяет большое внимание разработке решений, позволяющих строить информационную инфраструктуру экономно. Технология Real Application Clusters в СУБД Oracle9i позволяет корпоративным заказчикам сократить расходы на внедрение и администрирование СУБД. По мнению представителей Oracle, кластерное решение Oracle в сочетании с серверами НР на базе процессоров Intel и ОС Linux является достойной альтернативой дорогостоящим вычислительным системам и идеально подходит для растущих организаций…

Корпорация Intel поддерживает ОС Linux наравне с остальными операционными системами - в среде Linux работают серверы Intel, решения для встраиваемых систем, сетевые и прочие продукты. В целом Intel давно и плодотворно сотрудничает с сообществом разработчиков ПО с открытыми исходными кодами. Так, в преддверии выпуска первого процессора семейства Intel Itanium специалисты корпорации Intel совместно с отраслевыми разработчиками провели большую работу по переносу ОС Linux и инструментальных средств на новую платформу. Intel разрабатывает программные продукты для Linux: оптимизирующие компиляторы для C/C++ и Fortran, высокопроизводительную библиотеку Intel Integrated Performance Primitives (IPP), реализующую множество функций - например, обработки сигналов и изображений…

В сочетании же с кластерным решением Oracle и техникой НР ОС Linux является не только экономичной, но и надежной, масштабируемой, защищенной платформой, утверждают представители Oracle. По их словам, кластерное решение на OC Linux является достойной альтернативой дорогостоящим RISС-серверам и намного надежнее аналогичного решения на ОС Windows.

В Intel также считают, что в последние годы ОС Linux получила признание на корпоративном рынке, в том числе как основа для построения решений для бизнес-критичных задач…”

Довідка: за даними авторів в Українському бізнес-секторі на весну 2002 року працювало лише 4 комп’ютерних кластерних комплекси на базі 64-бітної архітектури IA-64, всі – у банківській сфері. За станом на 2005 рік ця ситуація кардинальних змін не зазнала. Причина проста: в Україні поки що немає “великих систем”, для яких ефективним було б застосування стандартних для західного корпоративного ринку рішень…

Статус Коментар № 27 Теза (проблема) В проекті не вказаний єдиний державний орган, який видаватиме ліцензії на програмне забезпечення Цитата “В разі якщо проектом передбачено видачу ліцензії на програмне забезпечення… то необхідно вказати, який саме орган буде видавати ліцензії, і які саме ліцензії мають видаватися, а також умови, за якими будуть видаватися такі ліцензії…” Рецензент ІЗ

1. Намагання “заліцензувати” якомога більше областей діяльності – є, на думку авторів законопроекту (а також, наприклад, Держкомпідприємництва ) – вкрай негативним.

У сфері виробництва програмного забезпечення якась “централізована діяльність із видачі ліцензій” взагалі полишена жодного змісту з огляду на велику кількість типів ліцензій на ПЗ взагалі і величезне розмаїття програмних засобів зокрема. У відношенні до Вільної ліцензії проведення повторного “державного ліцензування” тим більше є нонсенс: ширших майнових прав користувачеві надати неможливо, а звуження таких прав призведе до автоматичної втрати Вільної ліцензії…

В цілому умови ліцензування є предметом виключно відносин власника прав на ПЗ та користувача – хто б конкретно у ролі власника/користувача (фізична особа, юридична особа, держава) не виступав.

Імовірно, що автори аргументу переплутали проблему ліцензування з проблемою сертифікації – тобто процесу “документального підтвердження відповідності продукції певним вимогам, конкретним стандартам або технічним умовам”.

Зрозуміти таку помилку можна, тому що за реальними прецедентами ряд відомчих актів дійсно намагається “підмінити” ліцензування (як дозвіл на певну діяльність) – сертифікацією. Так, пункт 4 Наказу Міністерства освіти та науки № 783 запроваджує “обов’язкову сертифікацію в державній системі УкрСЕПРО програмного забезпечення, що створюється або локалізується”. Проте такі намагання є незаконними з огляду на діюче українське та міжнародне законодавство, де сертифікація є добровільною справою виробника.

(Принагідно: за станом на листопад 2000 року працівники УкрСЕПРО взагалі не мали інформації про сертифікацію в Україні якоїсь іншої операційної системи, окрім Microsoft Windows, підтверджували необов’язковість сертифікації ПЗ в Україні, а у якості прикладу Вільної ліцензії – цитували пропрієтарну ліцензію OLB фірми Microsoft…)

2. Щодо трактування терміну “Ліцензія” в контексті розповсюдження комп’ютерних програм – див. Коментар № 35.

Статус Коментар № 28 Теза (проблема) Де-факто в Україні стандартом є використання пропрієтарного ПЗ, через те що виробник пропрієтарного ПЗ несе відповідальність за його використання Цитата “…В Україні стандартом де-факто стало використання ПЗ, побудованого за принципами та концепцією ППЗ (пропрієтарної моделі – Авт). Такий стан речей пов’язаний з розповсюдженням в нашій країні акцепції більш перевіреної часом концепції ППЗ, за якою відповідальність за належне функціонування та забезпечення розвитку за життєвим циклом ПЗ, повною або частковою мірою покладається на виробника ПЗ…” Рецензент УАППО

1. Відповіді щодо гарантійних та інших обов’язків подані в коментарі № 23 (гарантійні зобов’язання не залежать від типу ліцензії).

2. Проте наявна інша цікава помилка – ситуаційна. Ніякої “відповідальності” на пропрієтарного виробника того ПЗ, яке нині використовується в Україні, покласти не можна – через те, що:

а) переважна більшість ліцензій на пропрієтарне ПЗ містить спеціальний пункт про зняття з виробника відповідальності за наслідки використання ПЗ;

б) за статистикою близько 90 відсотків ПЗ в Україні використовувалися неліцензійно – тобто без прийняття користувачем умов тієї або іншої ліцензії (і особливо – пропрієтарних ліцензій). Таким чином, основна маса користувачів ніколи не могла скористатись підтримкою “пропрієтарних” виробників: адже за таку підтримку ніколи не сплачувалися гроші.

Законопроект запропонований саме як захід для забезпечення передумов масового використання ліцензійного ПЗ – незалежно від типу ліцензії.

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

4. “Концепція ППЗ” не є “більш перевіреною часом”. Початок руху Відкритого ПЗ датується 1968 роком, тобто появою мережі ARPANET, яка одразу ж почала використовуватися і як середовище для розробників Вільного ПЗ. В 1969 році було опубліковано другу версію UNIX, яка дороблялася саме як Вільна ОС в університетському середовищі всі 70-ті роки… Звичні ж для більшості Рецензентів пропрієтарні ОС з’явилися в широкому доступі лише в середині 80-х: їх популярність була пов’язана з використанням “дружнього” для кінцевого користувача графічного інтерфейсу. Варто зауважити принагідно, що концепція графічного інтерфейсу була “позичена” з відкритої розробки лабораторії Hewlett-Packard, а, наприклад, Windows 2000 – XP є в певному розумінні і розвитком ядра Digital Unix… Це свідчить, що високий рівень конвергенції ідей та технологій в сфері ПЗ не можна не брати до уваги.

В цьому контексті слід говорити не про “перевіреність часом” – а про бурхливий розвиток графічних програм та “оболонок” для Вільних операційних систем в останні 4 роки…

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

Статус Коментар № 29 Теза (проблема) Використання Вільного ПЗ погіршить стан освітніх закладів Цитата “Положення… законопроекту вводять механізм отримання державними науковими та освітніми закладами пропрієтарного комерційного ПЗ лише за умови попередньої оплати авторських прав з власного бюджету або за умов легітимного безкоштовного отримання ліцензій на ППЗ. За умов недостатнього бюджетного фінансування наукових та освітніх закладів, та, зважаючи на той факт, що процедура формування бюджетів цих закладів по відношенню до видаткових статей, пов’язаних з придбанням ЗПЗ, ускладниться… рівень технологічної конкурентоспроможності наукових та фахових кадрів погіршиться.” Рецензент УАППО

1. Бюджет окремого закладу бюджетної сфери складається а) з частини державного бюджету (власне результату процесу “бюджетування”); б) з додаткових коштів, що находять до бюджету закладу від його легальної бізнес-діяльності (якщо таке уможливлено структурою закладу та законодавством). Таким чином вимога законопроекту є ні чим іншим, як вимогою сплачувати гроші за відповідні пропрієтарні ліцензії – що є і основною ідеєю, наприклад, “Концепції легалізації програмного забезпечення та боротьби з нелегальним його використанням”…

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

2. Використання Вільного ПЗ може лише збільшити технологічну конкурентоспроможність в освітніх та наукових закладах.

По-перше – через ціновий фактор (тобто принципову можливість отримати необхідну кількість додаткових копій ПЗ безкоштовно, так само як можливість і самостійно дублювати будь-яку документацію, що поставляється з “коробковою” копією ПЗ, або доступна іншим чином).

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

По-третє – через відкритість програмного коду, що дає можливість вивчати не лише графічний інтерфейс програми – а й принципи її функціонування, а також покращувати і модифікувати програму. З огляду на це використання пропрієтарного (“закритого”) ПЗ в навчальній сфері є вкрай небажаним.

Статус    Коментар № 30 Теза (проблема) Законопроект слід узгодити із Законом України “Про авторські і суміжні права”. Цитата “Згідно зі статтями 24 та 31 цього Закону особа, яка правомірно володіє примірником комп’ютерної програми, має право без згоди автора або іншої особи, яка має авторське право на цю програму… 1) внести до комп’ютерної програми зміни (модифікації),.. декомпілювати комп’ютерну програму… з метою одержання інформації, необхідної для досягнення її взаємодії із незалежно розробленою комп’ютерною програмою,.. вивчати, досліджувати функціонування комп’ютерної програми з метою вивчення ідей та принципів, що лежать в основі її функціонування… Рецензент

Анекдотичність ситуації полягає в тому, що Закон України “про авторські та суміжні права” не протирічить умовам застосування Вільних ліцензій безпосередньо (хоча має суттєві опосередковані обмеження для використання Вільного ПЗ в статтях, які регулюють норми авторського відшкодування за використання інтелектуальної власності).

А от застосування пропрієтарного програмного забезпечення, якщо суворо дотримуватись цього Закону – нині в Україні є неможливим. В першу чергу – через те, що майже будь-яка пропрієтарна ліцензія недвозначно забороняє декомпіляцію та модифікацію комп’ютерних програм (і якщо в тексті ліцензії є відповідне “послаблення” щодо “вимог місцевого законодавства” – то за фактом програмний код однаково не надається).

Таким чином, формально в Україні застосування, приміром, програмного забезпечення фірми “Microsoft” є незаконним через невідповідність “майкрософтівських” ліцензій (та практики) статтям 24 та 31 Закону України “Про авторські та суміжні права”…

З іншого боку – визначення та інструкції, які надаються представникам преси та силовим органам з метою визначення “ліцензійності” або “неліцензійності” програмного забезпечення – унеможливлюють і використання Вільного програмного забезпечення, шляхом “інституалізації” виключно форм та методів оформлення пропрієтарного ПЗ. Цитуємо інструкцію, опубліковану “Українським центром ліцензійного ПЗ” (мовою оригіналу):

“Необходимо предъявить “счет-фактуру от компании-поставщика, расходную накладную, по которой получено ПО, упаковку (коробки), сопровождающую документацию и наклейки с голограммами, которые должны быть прикреплены на видном месте системного блока”

Через те, що вказані зовнішні характеристики “вільні” програмні продукти мають лише в окремих випадках, а отримати ці програми можна (не порушуючи міжнародних законів і юридичних норм!) і зовсім безкоштовно, зокрема як файл або набір файлів через мережу Інтернет – доводиться констатувати, що у протиріччя з діючим законодавством, в сфері розробки ПЗ в Україні формується прецедентна система отримання прибутків шляхом “юридичного підприємництва”, тобто переслідування не лише порушників, а й добросовісних користувачів програм судово або адміністративно.

Отже, узгоджувати потрібно не так окремі українські закони з окремими українськими законами (хоча і такий процес є необхідним) – як українське законодавство з міжнародним правом в питаннях застосування всесвітньо-прийнятих типів ліцензій. Ця проблема стосується також і наступного зауваження.

Статус Коментар № 31 Теза (проблема) Міжнародні стандарти визначено в законопроекті як національні стандарти, що не передбачено Законом України “Про стандартизацію” Цитата “…В статті (законопроекту – Авт.) визначено механізм запровадження міжнародних стандартів як національних стандартів… Пункт 1.6. (1.18 в новій редакції – Авт.) статті 1 проекту слід доопрацювати з урахуванням Закону України “Про стандартизацію”, який є базовим у сфері стандартизації, і зокрема статті 11 цього Закону, де сказано, що залежно від рівня суб’єкта стандартизації… розрізняють: національні стандарти, кодекси усталеної практики та класифікатори, прийняті чи схвалені центральним органом виконавчої влади у сфері стандартизації, видані ним каталоги та реєстри загальнодержавного застосування, стандарти, кодекси усталеної практики та технічні умови, прийняті чи схвалені іншими суб’єктами, що займаються стандартизацією…” Рецензент Мінюст

Трактування національної системи стандартів як вищої за міжнародні стандарти може мати сенс за умови суттєвої “закритості” країни (феномен “залізної завіси”), або у тих сферах, де споживається здебільшого вітчизняний продукт. Однак такий підхід призводить до серйозних протиріч, коли йдеться про продукцію високотехнологічних галузей, аналогів якої не виробляють в середині країни. Саме невизнання міжнародних стандартів, з одного боку, і відсутність відповідної за рівнем технічної бази для проведення власної стандартизації продуктів, що їх аналогів внутрішній виробник не випускає – призводить до ситуації, коли процес “української стандартизації” перетворюється лише на додатковий податок на високотехнологічну продукцію. В Україні це повною мірою стосується як апаратного, так і програмного комп’ютерного забезпечення.

Так само, як країна, яка взагалі не виробляє напівпровідників сучасного рівня, не може інакше, ніж суто-формально, сертифікувати партію сучасних процесорів – вона не може інакше, ніж формально, сертифікувати і, наприклад, сучасні операційні системи або прикладні програми, якщо не має розвинутого виробництва ПЗ співмірного рівня складності (“промислового виробництва ПЗ” в термінах законопроекту). Звісно, якщо тільки внутрішній розробник не бере участі у відповідних міжнародних проектах розробки та локалізації прикладних програм.

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

Проблема, вочевидь, вирішується:

1) визнанням формальності української системи сертифікації продуктів, структура та якість яких не може бути перевірена та протестована через відсутність у сертифікаційної системи відповідної бази та фахівців;

2) Переорієнтацією української системи сертифікації програмних засобів на аспекти локалізації та адаптації програмних продуктів (або норм та принципів такої роботи);

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

Статус Коментар № 32 Теза (проблема) Дотримання правил нормопроектувальної техніки Цитата “…У вітчизняній нормопроектувальній техніці не застосовується така нумерація частин і пунктів, як це запропоновано проектом… Закону (1.1., 5.1., 6.2.1. та тому подібне)” Рецензент Мінюст

В документі “Правила оформлення проектів законів та основні вимоги законодавчої техніки” Юридичного управління Секретаріату Верховної Ряди України”, з цього приводу сказано:

“Нумерація розділів, глав, статей є наскрізною у відповідності з порядковим номером, що не змінюється при внесенні змін до закону…

Законопроект поділяється на статті, які можуть поділятися на частини і пункти. Частини статей і пунктів, у свою чергу, можуть поділятися на абзаци і підпункти. Нумерація статей здійснюється арабськими цифрами. Коли стаття велика і містить декілька частин, вони для зручності застосування також нумеруються… Частини статті - це завжди правова норма, а пункт - окреме питання. Пункти також нумеруються цифрами або буквами.”

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

Така ж нумерація використовується в багатьох інших документах українського законодавства. Для прикладу варто подивитися хоча б такий нормотворчий документ, як Регламент Верховної Ради України, який визначає не те що окремі норми – а самі нормативні правила прийняття будь-яких законодавчих норм. Наприклад:

Стаття 2.1.2.

1. Чергові сесії скликаються Президією Верховної Ради в

порядку, визначеному ст.2.3.1. Тривалість сесії визначається Верховною Радою…

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

Статус Коментар № 33 Теза (проблема) Незрозуміло, на яких умовах можна все ж таки розповсюджувати програми… Цитата “…Деякі положення проекту неоднозначно, що не є прийнятним в законодавчих актах (ст.ст.2,6,7 проекту, наприклад, на яких умовах можна все ж таки розповсюджувати копії програми?).” Рецензент ГНЕУ

Умови розповсюдження програмного забезпечення залежать від ліцензії, під якою розповсюджується конкретне програмне забезпечення. В статті 1 законопроекту вичерпно характеризовано типи ліцензій, про застосування яких йдеться в законопроекті. Подані в статті 1 визначення є цілком вичерпними і прозорими. Таким чином, дізнатись, наприклад, що Вільні програми в цілому можуть розповсюджуватись вільно, а “закриті” – не можуть розповсюджуватись користувачем взагалі – можна, прочитавши статтю 1 (“Визначення термінів”) законопроекту.

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

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

Статус + Коментар № 34 Теза (проблема) Дотримання правил техніко-юридичного оформлення документу. Більш повне розкриття термінології предметної області. Цитата “Деякі статті проекту не мають предмету регулювання… не відповідають одна одній… Законодавче поле України не містить такої категорії, як “блокуючий” пакет акцій,.. “бізнес-підприємств”… Необхідно визначити, який саме орган буде визначати точну дату та механізм втрати дозволу (на використання невідповідного ПЗ – Авт.)… Стаття1, стаття 2 та стаття 13 проекту містять певні розрізнені визначення… Проект містить нумерацію статей та пунктів, що повторюється…” Рецензент ГНЕУ, МЕУ

Вимоги до вдосконалення техніко-юридичного оформлення проекту Закону максимально повно враховані починаючи з 10 версії законопроекту (від 15.02.2003).

Зокрема, на вимогу рецензентів в статті 1 законопроекту “Визначення термінів” – дане додаткове визначення термінів “Програмний продукт”, “Програмна бібліотека”, “Активи”, “Вартість володіння активом”, “Державна установа”, “Державні підприємства”, “Наукові заклади”, “Суб’єкти державного сектору”, “Основна діяльність суб’єкту державного сектору”, “Господарча діяльність суб’єкту державного сектору”, “Державні послуги”, “Специфічні потреби”, “Промислове виробництво програмного забезпечення”, “Контрафактне (неліцензійне) виробництво програмного забезпечення”, “Ліцензія на програмне забезпечення”, “Авторський договір”, “Комерційний рівень”, тощо.

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

Замість терміну “Державні установи і підприємства державного сектору народного господарства” та похідних – введено термін “Суб’єкти державного сектору”. Змінено відповідно вимог рецензентів статті 4, 5, 6, 7, 9, 10, 11, 13 Законопроекту. До статті 6 введено додаткові положення, що сприяють однозначному економічному трактуванню норм законопроекту. Ряд визначень перенесено зі Статті 13 до Статті 1.