1. анотація
2. Середовище розробки QNX Momentics як приклад використання ПЗ з відкритим вихідним кодом
3. Підстава відкритого проекту Eclipse.org
4. Проект створення інструментального сховища
5. Від ідеї до поставки продукту - менше 7 місяців
6. Чи можна собі дозволити "подарувати" код?
7. Порівняння ліцензій на відкритий вихідний код
8. Головні проблеми, що виникають при комерціалізації ПО з відкритим вихідним кодом
9. проблеми ліцензування
10. Висновки та рекомендації

анотація

Основна увага в даній статті концентрується на перевагах, стратегічних моментах, що виникають перешкоди і можливості, пов'язаних з використанням в комерційній продукції програм з відкритим вихідним кодом. Використовуючи в якості прикладу інтегровану середу розробки (Integrated Development Environment - IDE) на базі платформи Eclipse, ми обговоримо, які відмінності існують між захисними (protective) і незащитную (nonprotective) ліцензіями на вихідний код програмного забезпечення (ПО). При інтеграції або компонуванні відкритого вихідного коду з "фірмовим" закритим кодом найчастіше потрібна проявляти належну увагу і обережність. Слід мати на увазі і різні правові проблеми, наприклад, потенційну можливість порушення патентних прав. Ми також спробуємо пояснити, чому основні принципи використання ПЗ з відкритим вихідним кодом в середовищі інформаційних технологій (ІТ) не застосовні щодо комерційної продукції для вбудованих пристроїв.

Середовище розробки QNX Momentics як приклад використання ПЗ з відкритим вихідним кодом

Повертаючись у 2001 р, коли багато фірм-розробники боролися за виживання в умовах загального обвалу ринку акцій ІТ-компаній, особливо пов'язаних з електронним бізнесом в Інтернет, компанія QNX Software Systems прийняла стратегічне рішення почати розробку нової інтегрованої середовища розробки (IDE) для ринку вбудованих систем. У компанії вже був солідний досвід по розробці серії інструментальних засобів, що використовуються в розробці вбудованих пристроїв, але керівництво компанії усвідомлювало, що створення середовища IDE дозволить утриматися на гребені хвилі в умовах жорсткої конкуренції. Рішення про створення середовища IDE стимулювалося також зміною акцентів у вимогах клієнтів. У період спаду ділової активності обмежені в коштах клієнти стали більше цікавитися рішеннями, які могли б максимізувати продуктивність роботи і зробити їх більш мобільними (гнучкими) при веденні робіт, дозволили б підвищити загальну економічну ефективність.

Для компанії QNX розробка середовища IDE була "ставкою на майбутнє", так як в той час вартість і зусилля на розробку проекту були поза зоною досяжності для більшості вендорів інструментальних засобів вбудованих систем. На щастя, QNX працювала в тісному контакті з IBM по різним сегментам ринку вбудованих пристроїв. Завдяки тісній співпраці, компанія IBM поділилася з QNX своїми планами по випуску інтегрованого середовища розробки з використанням відкритого вихідного коду - це середовище згодом стала основою для платформи Eclipse.

Компанія IBM запропонувала використовувати досвід QNX для адаптації технології IDE до потреб розробників, що займаються створенням вбудованих додатків на базі мови C / C ++. Фахівці компанії QNX практично відразу вказали на незаперечні принади використання для середовища IDE відкритих вихідних кодів. Наприклад, для такого середовища стало б можливо:

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

І нарешті, розглядалася окрема можливість того, що платформа IDE змогла б завоювати популярність і стати стандартом "де факто", а це дозволило б компанії QNX за допомогою такої платформи захопити для використання ринок великих екосистем розробників і інструментів третіх сторін.

Підстава відкритого проекту Eclipse.org

У листопаді 2001 р компанії Borland, IBM, Merant, QNX Software Systems, Red Hat і SUSE заснували Консорціум Eclipse. На початку 2004 р Рада Керуючих (Board of Stewards) реорганізував Консорціум Eclipse в некомерційну корпорацію з ім'ям Eclipse Foundation.

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

Проект створення інструментального сховища

У грудні 2001 р компанія QNX початку створення своєї ОСРВ QNX® Neutrino®, що базується на середовищі IDE платформи Eclipse. У поданні компанії серед IDE повинна була володіти великими функціональними можливостями, орієнтуватися на роботу з мовами C / C ++, мати глибоко інтегровані інструменти для налагодження, профілювання, аналізу та створення вбудованих додатків. З самого початку, за задумом команди QNX, це повинна була бути багатоцільова і багатомовному середовищі IDE, що підтримує безліч інструментальних платформ. Сюди було включено:

• кілька інструментальних платформ: Windows, Solaris, ОСРВ QNX Neutrino (розробка "сама для себе" - "self-hosted");
• кілька цільових архітектур: ARM, MIPS, PowerPC, SH-4, x86;
• мови програмування C, C ++, Java.

З тих часу серед IDE продовжувала розростатися, включивши в себе підтримку платформи Linux і підтримку додаткових процесорних архітектур, включаючи процесори XScale.

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

Групі було дано необхідні повноваження в сфері прийняття рішень, для них було складено жорстке, на межі ризику розклад робіт, з випуском бета-версії продукту через 16 тижнів, а комерційної версії -до 4 липня 2002 року Група уклалася в усі поставлені контрольні терміни і випустила новий продукт - отримав ім'я QNX Momentics® IDE - точно відповідно до розкладу, що стало свідченням закладеного в програмне забезпечення з відкритим вихідним кодом потенціалу щодо скорочення часу виходу продукції на ринок.

Від ідеї до поставки продукту - менше 7 місяців

Спираючись на платформу Eclipse, команда QNX завершила створення дуже потужної і багатосторонній середовища IDE для розробки вбудованого ПО за шість місяців. У середовищі IDE підтримувалася крос-платформна розробка для декількох інструментальних платформ і декількох мов програмування, а також підтримувалися найбільш популярні процесорні плати для вбудованих цільових пристроїв. За допомогою платформи Eclipse компанія QNX змогла:

• використовувати для крос-розробки компілятори GNU і інструменти для роботи через командний рядок;
• здійснити підтримку модулів сторонніх розробників, наприклад, IBM WebSphere для вбудованих додатків Java і Rational ClearCase для модельно-керованих розробок;
• створити додаткові інструменти для побудови систем, управління цільовими пристроями, аналізу пам'яті, профілювання систем і додатків і т.д.

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

Зворотний внесок в роботу спільноти

Сильна сторона успішного проекту з відкритим вихідним кодом укладена в спільній роботі спільноти розробників і в постійному поліпшенні кодової бази. Якщо компанія приймає на озброєння і з користю застосовує відкритий вихідний код, то вона просто зобов'язана вносити свій вклад в роботу спільноти. З цією метою компанія QNX в червні 2002 р взяла на себе керівництво проектом Eclipse CDT.

Метою проекту Eclipse CDT (C / C ++ Development Tools - інструменти розробки для мов C / C ++) є створення спільного набору взаємодіють один з одним інструментальних засобів мов C / C ++ для платформи Eclipse. Eclipse CDT був позиціонується як проект з відкритим вихідним кодом, з правами на управління з боку корпорації Eclipse. Для запуску проекту CDT компанія QNX передала для використання свої ресурси для розробки і вихідні коди проекту QNX Momentics IDE. Компанії Rational і Red Hat як члени спільноти також надали суттєву підтримку проекту.

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

Компанія QNX як і раніше веде супровід проекту CDT, обсяг якого зріс з початку скромних 80 000 строк коду до сьогоднішніх більш ніж 700 000 строк. На початку 2006 р журналу реєстрації ходу робіт за проектом Eclipse CDT внесок компанії QNX оцінювався в 52%. Далі йшла компанія IBM зі внеском 36%. Проект CDT є другим за популярністю проектом корпорації Eclipse після власне самої платформи Eclipse.

Чи можна собі дозволити "подарувати" код?

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

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

Наприклад, стратегія компанії QNX Software Systems полягає в тому, щоб використовувати переваги від участі в роботі корпорації Eclipse, розробляючи в той же час нові функціональні можливості, що підключаються через стандартизовані точки розширення, які вже є в складі платформ Eclipse і CDT. З цією метою компанія QNX має намір залишатися активним членом спільноти Eclipse, отримуючи вигоду з існуючої кодової бази і напрацювань третіх сторін (модулів), допомагаючи в задоволенні реальних потреб клієнтів, створюючи свої фірмові розширення. Описана стратегія ілюструється на рис. 2.

Мал. 2. Своїми напрацюваннями можна робити внесок в роботу спільноти.

Резюме за перевагами

Інструментальна платформа на базі Eclipse є взаємовигідною як для розробників додатків, таких, наприклад, як QNX, так і для клієнтів, які купують інструментальні засоби платформи.

Вигода розробників полягає в зменшенні часу до поставки їхньої продукції на ринок і в можливості скористатися результатами досліджень інших людей (при низьких витратах на це). Серед цих результатів може бути присутнім і високоякісний код, що відноситься до категорії "чистої інтелектуальної власності" ( "clean IP"), наданий шанованими фірмами, такими як IBM і QNX. Ще однією перевагою для розробника є те, що він отримує просту і ясну схему ліцензування, включаючи комерційні права і деяку патентний захист. Більш того, розробник отримує можливість роботи на платформах декількох ОС, які підтримуються в Eclipse, а також отримує в своє розпорядження добре певні в проекті Eclipse точки розширення.

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

Майбутнє корпорації Eclipse

Корпорація Eclipse є активним і енергійним спільнотою. У ньому постійно з'являються нові проекти, в розпорядження солідних інноваційних компаній надаються нові архітектури, і навіть невеликі компанії можуть отримати комерційну вигоду з платформи Eclipse в результаті створення з мінімальними витратами нових модулів, які розширюють наявні функціональні можливості (див. Рис. 3).

Мал. 3. Корпорація Eclipse є енергійним і швидко зростаючим спільнотою розробників модулів.

Порівняння ліцензій на відкритий вихідний код

Не всі ліцензії на ПЗ з відкритим вихідним кодом є рівноправними. Компанія QNX зробила добре продуманий крок, зупинившись на ліцензії Eclipse Public License. Цей вибір був продиктований частково потребами її клієнтів, які використовують вбудовується обладнання, а частково бажанням встановити контроль над технологіями, диференціюючими продукцію (і отримати з цього вигоду).

Некомерційна корпорація Open Source Initiative ( http://www.opensource.org ) Запропонувала корисне, що складається з 10 пунктів визначення відкритого вихідного коду. В даний час на веб-сайті представлено більше 50 схвалених OSI ліцензій, включаючи Eclipse Public License. У цих ліцензіях можуть міститися значні відмінності, які потрібно чітко усвідомлювати. Ці відмінності можуть істотно впливати на інтелектуальну власність (ІВ) розробників і на здатність її захисту. Найбільшою мірою це відноситься до випадку використання відкритого вихідного коду (або похідних розробок на базі відкритого вихідного коду) у вбудованих пристроях.

Захисна і незащитную ліцензія

Ліцензії з категорії "відкритого вихідного коду" можуть бути двох видів: захисні (protective) і незащитную (nonprotective).

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

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

Що розуміється під "вірусної ліцензією"

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

Питання отримання компенсацій

Останнім часом питання відшкодування втрат за порушення прав інтелектуальної власності (IP Indemnification) стали для розробників головною темою обговорення. У відповідь на це деякі вендори відкритого вихідного коду оголосили про те, що вони будуть захищати клієнтів від судових позовів, пов'язаних з порушеннями патентних або авторських прав. І в найновіших ліцензіях на відкритий вихідний код роз'яснюються міри покарання для користувачів, які намагаються відстоювати свої патентні права щодо інших користувачів кодової бази.

Головні проблеми, що виникають при комерціалізації ПО з відкритим вихідним кодом

Порівняння вбудованих та ІТ-додатків

Успіху сфери відкритого вихідного коду сприяло прийняття ІТ-організаціями ОС Linux. Вигода від використання Linux була пов'язана з роботою на відносно однорідному і стабільному обладнанні (зазвичай сімейства x86) і з використанням гнучкої, багатою ресурсами комп'ютерної платформи.

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

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

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

проблеми ліцензування

Невизначеність правового статусу

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

Деякі обхідні шляхи, які дозволяють вендорам комерційної продукції впровадити в Linux "фірмові" драйвери (наприклад, Loadable Kernel Modules [LKMs] - завантажувані модулі ядра), ґрунтуються швидше на аргументах типу "він сказав, вона сказала", ніж на прямих посиланнях на текст ліцензійної угоди. Фактично такі драйвери, які використовують модулі LKM, таять в собі небезпечний обхід вимог ліцензії GPL. Впадаючи в крайність, можна інтерпретувати справу так, що кодова база Linux може бути представлена ​​як марна для більшості практичних застосувань, якщо в неї не включені деякі з цих самих "фірмових" драйверів. Така ситуація здатна досить ефективно знецінити ідею ліцензії GPL.

Відсутність компенсацій при порушенні прав інтелектуальної власності

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

У деяких ліцензіях є явні посилання на патенти. Наприклад, в ліцензії Eclipse Public License є явне згадка про патентні права, і в ній міститься пункт про заходи покарання в разі, якщо хтось спробує відстоювати патентні права по-іншому. Корпорація Eclipse докладає також багато зусиль для перевірки коду і з'ясування джерела його походження з точки зору ліцензійних, патентних або авторських прав.

Додаткові зусилля для збереження ІС

Для використання відкритого вихідного коду компанія повинна затратити значні зусилля в наступних напрямках:

• управління поширенням продукції;
• управління ліцензіями;
• вирішення правових конфліктів в частині зобов'язань клієнтів;
• належну увагу правових питань: дотримання чистоти прав ІВ, перевірка прав ІВ на відкритий код, встановлення джерела походження коду, відстеження змін у версіях ліцензій, наприклад, GPL v3 і т.д.

Ухвалення вимог клієнта

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

Проблеми, пов'язані з ІВ

Чи зачіпають умови вашої ліцензії на використання відкритого програмного коду ту інтелектуальну власність, яка є відмінною рисою вашого продукту? Якщо так, то ваша ІС знаходиться під загрозою.

Якщо у вбудованих системах використовується суміш ПО вашої власної розробки і програм з відкритим вихідним кодом, то ви повинні представляти суть, походження та взаємозв'язок всіх компонентів вбудованого ПО. Без такого глибокого проникнення в суть предмета ви можете ненавмисно порушити права чиємусь ІС або навіть втратити права на ПО власної розробки.

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

Висновки та рекомендації

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

Тим не менш, ви повинні розуміти різницю, яка існує між різними ліцензіями на відкритий вихідний код, і вибирати серед них ту, яка відповідає вашому додатку і потребам клієнта. Більш того, будьте готові відповідати за ліцензійними зобов'язаннями обраного вами ПО. Вам повинно бути відомо про інші вимоги, що стосуються ІС (наприклад, про патентні права) і пов'язаних з програмним кодом. З обережністю поставтеся до кодової базі, для якої на екран не виводиться повідомлення про наслідки порушення ІС. Пошукайте краще проекти, де пропонується відшкодовувати можливі збитки і де виводиться екранне повідомлення про грошові пожертвування за розробку коду для компенсації витрат, пов'язаних з порушенням авторських або патентних прав і так далі. Переконайтеся також в тому, що Ваш слуховий ПО з відкритим вихідним кодом узгоджується в вашою політикою охорони інтелектуальної власності і уникайте захисних ліцензій, на підставі яких вас можуть змусити розкрити відмітні фрагменти вашого коду. Якщо ж ваш продукт вбудований в систему, то розглядайте також можливість пропозиції умов комерційного ліцензування вашої ІС.

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

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

джерело: html?programid=15362> http://www.qnx.com/download/feature.html?programid=15362