Важливо зауважити, що цей сценарій може відбуватися як в законних, так і в незаконних формах.
Це може статися на законних підставах, якщо компанія володіє або має доступ до авторських прав, пов’язаних з кодом. Наприклад, менші незалежні розробники можуть захотіти продати або ліцензувати свої авторські права більшій фірмі. Так само, якщо основну частину авторських прав коду можна придбати, "недосяжна" частина може бути просто викинута і переписана.
З іншого боку монети код може бути просто взято незаконно. New Corp, Inc. може не байдуже, якими є юридичні наслідки. Проект може бути занадто старим або занедбаним, або New Corp думає, що вони виграють у позові. Або New Corp може бути зареєстрований у районі, де подібне "придбання" просто не визначається як незаконне. Не всі ліцензії на ОСС підлягають застосуванню, особливо не ті, які були об'єднані не експертами в законі. Не всі власники проектів можуть мати можливість застосовувати свої вимоги щодо авторських прав, а більші організації, такі як ФФС, можуть не мати права на цю претензію. TL; DR - ця область може швидко стати туманною та потворною.
Перехід та профілактика
Як відбувається перехід і що можна зробити, щоб запобігти його поза вибором різницької ліцензії?
Перехід відбувається, коли New Corp, Inc. набуває кодову базу та місця, які копіюють, під їх контролем. Потім розробники New Corp починають працювати над своєю версією кодової бази, вносячи будь-які зміни, які визнали корпоративними оверлорд необхідними. Дійсна механіка цієї вилки буде залежати від сховища. І хоча це філософсько велика справа, це насправді досить непомітно на практиці. get allвід OpenRepos, а потім checkinдо PrivateRepos.
Що можна зробити, щоб не допустити, щоб він ніколи не поширював джерело? Нічого. Вибачте.
Давайте використаємо GPL (публічну ліцензію GNU) як приклад. GPL вимагає, щоб джерело було доступне для кожного, хто отримав законну копію проекту. Не існує положень, які дозволяють власнику джерела відмовитись від доставки джерела законному власнику копії програми GPL'd. Це суперечить зерну вільного програмного забезпечення, і саме тому GPL copyleft працює на місці.
Потенційно у вас є юридичні напрямки дій, які слід здійснити. Але це все після того, як джерело втекло і роздвоєне, не раніше. І в деяких юрисдикціях ви не матимете законних прав. І все це передбачає, що ви навіть знаєте, що вилка сталася. Ви ніколи не дізнаєтесь про це.
Етика
Які (етичні чи соціальні) обов'язки компанії? (Наприклад: Повернення до проекту з відкритим кодом було би етичним завданням)
Етика є місцевою для культури. Тож загартуйте цей розділ тим зерном солі. Повна дискусія щодо культурного розгляду етики виходить за рамки цієї відповіді та поза темою для програмістів.
Я помітив, що спільнота програмування схильна негативно реагувати на ворожу вилку. Чорт забирає, в деяких випадках та ж громада все ще негативно реагує на доброзичливі та законні вилки. Це досить складна громада.
З точки зору FOSS, очікується, що New Corp "виплатить" громаді за внесок, який вона внесла. Терміни, умови та тривалість цього погашення настільки ж різняться, як і кількість існуючих проектів ОСЗ. Деякі в громаді (думають, Річард Сталлман) ніколи не будуть задоволені відкритим проектом, який закриється. Інші шукатимуть вигоди, яка надається громаді взагалі, і будуть судити на цьому. А іншим просто не байдуже, оскільки вони ніколи не знали і не піклувалися про проект походження.
Доступність джерела
Якщо версія з відкритим кодом та версія з закритим кодом доступна, то як конкуренція впливає на продукт?
Це дійсно залежить від того, наскільки дві бази кодів порівнянні щодо функціональності, продуктивності та стабільності.
Якщо бази коду залишаються схожими і New Corp є привітним для спільноти OSS, вони можуть внести свої оновлення в базовий проект. У цьому випадку всі виграють. Це не "конкуренція" в цьому випадку, а більше взаємовигідна співпраця.
Якщо основи коду дико розходяться, а New Corp не є дружнім для спільноти OSS, тоді все ще немає конкуренції. Чим вищий продукт, тим багатіший на функції, тим менш багатий продукт має тенденцію до відмирання. Зауважте, що це може піти в будь-який спосіб - закрита версія може відмовитися, якщо версія з відкритим кодом продовжить інновації або краще задовольнить потреби громади.
Реальність буде десь між цими двома кінцями спектру.
Приклад
Red Hat має два основні дистрибутиви - Enterprise Linux та Fedora. EL - це їх "закрита" ліцензована версія, а Fedora - їхнє спільне видання. Завдяки GPL, багато, якщо не все, видання EL випускається у вихідному вигляді. Інший проект, не пов'язаний з Red Hat під назвою CentOS, приймає зміни до EL та розповсюджує цей проект після незначного ребрендингу.
Були певні бурчання, коли Red Hat розщедрився на два окремі видання, але, за великим рахунком, це було досить дійовою угодою. Спільнота Fedora хотіла, щоб функції дистрибуції перетворювались швидше, ніж тим, що було задоволено корпоративним клієнтам Red Hat. Вдосконалення баз коду протікають в обох напрямках.