Вопрос по лицензированию, GNU GPL v2 Опции

[Мусатов Констант...]

FreeRTOS распространяется по лицензии GNU General Public License (version 2).
Правильно ли я понимаю, что, если прошивка контроллера реализована с использованием FreeRTOS, то и на код программы, который не модифицирует исходный код ОС, а только использует его как библиотеку, все равно распространяется лицензия GNU GPLv2, что означает, что покупатель устройства с этим контроллером вправе запросить и получить полный исходный текст всей прошивки?
Так же, поскольку у контроллера есть дисплей, то прошивка обязана выводить лицензионную информацию: FreeRTOS и авторство, ссылка на лицензию или это не обязательно?
Последний вопрос, как внутри кода считать версию ОС, что бы не вписывать ее руками при обновлениях?

[AHTOXA]

У них не совсем GPL, у них с модификациями.
В общем, код можно не показывать.
Плюс к этому, нельзя сравнивать FreeRTOS с другими осями

[Мусатов Констант...]

У них не совсем GPL, у них с модификациями.
В общем, код можно не показывать.
Плюс к этому, нельзя сравнивать FreeRTOS с другими осями

Спасибо!
А на счет сравнивать. Как я понял сравнивать можно, но надо взять разрешение на публикацию, что бы они проверили корректность.

Да, а по поводу считывания из FreeRTOS ее версии?
И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

[juvf]

И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции;
__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю.

[Мусатов Констант...]

я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции;
__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю.

Да, Дата у IAR есть, но они вместо цифрового кода, печатают строку в американском убогом формате.
В Микрософтовском я пользовался, еще были в других, но все это для больших машинок.

А какой смысл считать сборки? Когда вставляется номер ревизии (или какая-то подобная информация), то тут профит ясен - узнав номер ревизии, можно посмотреть по логу системы управления версиями, что реально прошито. А номер билда говорит только о количестве запусков тулчейна. Или тут что-то другое имеется в виду?

А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки.

[dxp]

А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки.

Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются?

[Мусатов Констант...]

Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются?

Важно то, что когда собрал и она пошла в производство, она точно будет по билду выше прошлой. А на сколько - уже не важно

[dxp]

Важно то, что когда собрал и она пошла в производство, она точно будет по билду выше прошлой. А на сколько - уже не важно

А какая в этом практическая польза, если вы не знаете, чем оно отличается? Вот у вас номер билда прошлой версии в производстве 100, а текущий счётчик показывает 105 - какая в этом полезная информация, кроме той, что просто проект ещё пять раз собрали - может там ровно а же версия, что и в производстве? Или одна версия в производстве имеет ревизию 200, а следующая - 250, но по факту это может быть одна и та же версия. От количества сборок качество кода не меняется, ошибки не исправляются, фичи не появляются.

Другой подход - когда вставляется ревизия (тег) из системы управления версиями - вот тут всегда можно быстро посмотреть (по логу системы управления версиями), что конкретно прошито. Вот такой вариант представляется очень полезным и удобным, решает и обозначенную вами задачу. Почему не использовать этот подход?