Важно отметить, что этот сценарий может происходить как в легальной, так и в нелегальной форме.
Это может произойти на законных основаниях, если компания владеет или имеет доступ к авторским правам, связанным с кодом. Например, небольшие независимые команды разработчиков могут пожелать продать или лицензировать свои авторские права более крупной фирме. Аналогичным образом, если можно получить большую часть авторских прав на код, «недостижимая» часть может быть просто выброшена и переписана.
С другой стороны монеты код может быть взят незаконно. New Corp, Inc. может не заботиться о юридических последствиях. Проект может быть слишком старым или заброшенным, или New Corp думает, что они выиграют в судебном процессе. Или New Corp. может быть зарегистрирована в области, где такого рода «приобретение» просто не определено как незаконное. Не все лицензии OSS подлежат принудительному исполнению, особенно те, которые были объединены неспециалистами в законодательстве. Не все владельцы проектов могут иметь возможность обеспечить соблюдение своих требований об авторском праве, и более крупные организации, такие как ФФС, могут не иметь полномочий в этой юрисдикции для такого требования. TL; DR - эта область может стать очень туманной и уродливой.
Переход и профилактика
Как происходит переход и что можно сделать, чтобы предотвратить его, помимо выбора другой лицензии?
Переход происходит, когда New Corp, Inc. приобретает кодовую базу и передает эту копию под свой контроль. Затем разработчики New Corp. начинают работать над своей версией кодовой базы, внося любые изменения, которые корпоративные повелители объявили необходимыми. Фактическая механика этой вилки будет варьироваться в зависимости от хранилища. И хотя это философски важно, на практике это действительно не в восторге. get allиз OpenRepos, а затем checkinв PrivateRepos.
Что можно сделать, чтобы не допустить распространения источника? Ничего. Сожалею.
Давайте использовать в качестве примера GPL (публичная лицензия GNU). GPL требует, чтобы источник был доступен любому, кто получает законную копию проекта. Там нет ни одного положения , которые позволяют держателю источника отказаться от поставки источника законного держателя копии приложения GPL - . Это идет вразрез со свободным программным обеспечением, и именно поэтому авторские права GPL существуют.
Потенциально, у вас есть законный курс действий после факта. Но это все после того, как источник сбежал и был разветвлен, а не раньше. А в некоторых юрисдикциях у вас не будет никаких юридических средств правовой защиты. И все это предполагает, что вы даже знаете, что вилка произошла. Вы можете никогда не узнать.
Этика
Каковы этические или социальные обязанности для компании? (Например: возвращение к проекту с открытым исходным кодом было бы этическим делом)
Этика является локальной для культуры. Так умерить этот раздел с этим зерном соли. Полное обсуждение культурного рассмотрения этики выходит за рамки этого ответа и не по теме для программистов.
Я заметил, что сообщество программистов имеет тенденцию негативно реагировать на враждебную форк. Черт возьми, в некоторых случаях одно и то же сообщество все еще отрицательно реагирует на дружественную и легальную вилку. Это довольно сложное сообщество.
С точки зрения FOSS, ожидается, что New Corp собирается «погасить» сообщество за вклад, который оно раздвоило. Условия и срок такого погашения так же различны, как и количество существующих проектов OSS. Некоторые в сообществе (считают Ричард Столлман) никогда не будут довольны закрытым открытым проектом. Другие будут искать выгоду, предоставленную сообществу в целом, и будут судить на основании этого. А другим просто будет все равно, потому что они никогда не знали и не заботились о проекте происхождения.
Доступность источника
Если доступны версия с открытым исходным кодом и версия с закрытым исходным кодом, как конкуренция влияет на любой продукт?
Это действительно зависит от того, насколько сопоставимы две базы кода по функциональности, производительности и стабильности.
Если базы кода остаются схожими и New Corp дружелюбен к сообществу OSS, они могут вносить свои обновления обратно в базовый проект. В этом случае всем выгодно. В данном случае это не «соревнование», а скорее взаимовыгодное сотрудничество.
Если кодовые базы сильно расходятся, а New Corp не дружелюбен к сообществу OSS, конкуренция по-прежнему отсутствует. Выживающий продукт с большим количеством функций выживает и менее богатый продукт имеет тенденцию отмирать. Обратите внимание, что это может пойти в любом случае - закрытая версия может умереть, если версия с открытым исходным кодом продолжает вводить новшества или лучше удовлетворять потребности сообщества.
Реальность будет где-то между этими двумя концами спектра.
пример
Red Hat имеет два основных дистрибутива - Enterprise Linux и Fedora. EL - это их «закрытая» лицензионная версия, а Fedora - их версия для сообщества. Из-за GPL большая часть, если не все, издания EL выпускаются в виде исходного кода. Другой проект, не связанный с Red Hat под названием CentOS, собирает изменения в EL и распространяет этот проект после небольшого ребрендинга.
Были некоторые недовольства, когда Red Hat разделилась на две отдельные редакции, но в целом это было довольно выполнимое соглашение. Сообщество Fedora хотело, чтобы функции распространялись в дистрибутиве быстрее, чем было удобно корпоративным клиентам Red Hat. Усовершенствования кодовых баз происходят в обоих направлениях.