Обычной практикой является внесение некоторых изменений или исправлений в сторонний код (будь то простая сущность или целая библиотека). Но также распространено, что многие из этих кодов имеют свои собственные правила лицензирования и в конечном итоге заголовок каждого файла с информацией об авторских правах.
После внесения этих изменений, что делать дальше? Сохранить информацию о лицензии неприкосновенной или попытаться обновить ее, в том числе себя, с помощью чего-то вроде @authorили @revisionтегов?
Другая распространенная проблема - изменение стороннего пространства имен / пакета, чтобы оно соответствовало соглашениям вашего проекта. Некоторые типы лицензий включают такую информацию в свой блок лицензий. Могу ли я изменить ее свободно?
Я знаю, что ответ на эти вопросы зависит от каждого типа лицензии, поэтому, чтобы сделать мой вопрос более конкретным ...
Учитывая общие лицензионные правила (обычно они различаются в незначительных аспектах, верно?), Этично (или, по крайней мере, разрешено), что я свободно добавляю информацию в блок лицензии о своих модификациях и, возможно, также изменяю, как я ссылаюсь на это в своем коде (например, использовать YACorp.YALibкак Utils.YALib)?
Ответы:
Я думаю, что вы путаете лицензию на программное обеспечение и любые прологи, которые могут быть частью программного обеспечения.
Лицензия - это когда владельцы авторских прав на программу определяют условия использования (лицензию) для других людей. Некоторые лицензии очень разрешительные, другие гораздо более строгие.
Пролог , где авторы вставки
@authorи@revisionметки , чтобы обеспечить возможность отслеживать изменения в исходный код. В некоторых случаях, становясь автором нетривиального дополнения к коду, вы можете претендовать на авторские права на этот раздел кода. Распутывание проблем с авторским правом может быть непростым делом и лучше всего решается адвокатами. Тем не менее, вы специально заявили, что вас не волнует этот аспект, поэтому я буду двигаться дальше.Это действительно зависит от условностей проекта.
Если вы разветвляете проект, вы можете делать все, что захотите.
Если вы планируете внести свои изменения обратно в проект, вам следует придерживаться установленного соглашения. Если есть веская причина для изменения пространства имен, вам необходимо представить это сообществу приложения.
Не меняйте лицензию!
Во-первых, вы, вероятно, не имеете законных прав на изменение лицензии. Во-вторых, любые внесенные вами изменения могут испортить лицензию. Оставьте изменения лицензии для адвокатов.
Что касается обновления пролога, то это зависит от норм проекта. Некоторые проекты не хотят пролога, потому что они используют систему контроля версий для отслеживания этого. Другие проекты делают. Следуйте соглашениям проекта.
Если вы сохраняете свои изменения при себе, почему вас волнует, что думают другие? То, что вы используете только для себя и никогда не распространяете среди других, никак не влияет на первоначальный проект. Поэтому им все равно, что вы делаете.
Если вы планируете распространять свои изменения или вносить их обратно в проект, вам необходимо оценить условные обозначения этого проекта. Некоторые проекты не хотят быть разветвленными и имеют лицензию, предотвращающую это. Другие заходят так далеко, что говорят «делай, что хочешь», и тебе дают карт-бланш делать так, как ты считаешь нужным. В конечном счете, ответ здесь зависит от конкретного проекта, на который вы смотрите.
источник
Я хотел бы добавить комментарий, частично чтобы показать читателю, что файл не «ванильный», со ссылками на любую соответствующую документацию или систему отслеживания проблем.
Изменить: Таким образом, эта ситуация напоминает мне, когда дистрибутив Linux, например, библиотека. У Debian есть руководящие принципы и стандарты относительно того, как следует собирать и называть пакеты, что может отличаться от того, как библиотека обычно распространяется предварительно собранной.
Я не думаю, что вам следует стесняться называть / строить / модифицировать библиотеку, так как я предполагаю, что вы не будете распространять результат по всему миру? В этом случае я бы включил README вместе с источником, который описывает, какие изменения вы сделали и почему. Например, README. $ {CompanyName} .changes
источник
Вам придется ознакомиться с правилом лицензирования кода.
В целом, многие приложения с открытым исходным кодом (например, Firefox, OpenOffice) рассматривают название и логотип своего приложения в качестве товарного знака; поэтому, если вы выпустите модифицированную версию приложения, вы не сможете использовать оригинальные товарные знаки / фирменный стиль (например, IceWeasel, Torbrowser, LibreOffice).
Тем не менее, большинство программных библиотек часто меньше заботятся о товарных знаках, если довольно ясно, кто что делает (обычно это можно найти в метаданных контроля версий).
Информация автора служит двум целям:
Последнее становится более важным, поскольку ваши изменения становятся больше. Фактическую информацию об авторстве обычно можно найти в системе управления версиями, но некоторые проекты формально указывают группу авторов в отдельном файле. Точка отсечения, в которой люди будут официально зачислены, варьируется для каждого проекта, в случае сомнений свяжитесь с авторами оригинала.
источник