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

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

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

[juvf]

спор о том, что лучше PAL или SECAM. Правостороннее движение или левостороннее. На вкус и цвет товарищей нет.

ps

#define GITHASH "(2017-02-03 db74878)"

ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02? И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?
в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?

я пробовал прикрутить контроль версий.... не вкатило.... не понравилось. Системы контроля версий (СКВ) вообще может не быть, а автобилд нужен... да и с автобилдом тоже всё автоматизировано. ведётся журнал ревизий, по номеру билда и дате сборки можно быстро найти нужную ревизию (если есть СКВ).

В документации точно так же ведется список фич и пофиксенных багов по билдам и информативность такая же

+1

[johnshadow]

ps ну вот мне не понятно что было раньше... например 2017-02-03 или 2017-03-02?

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?
в readme проекта можно указать формат интерпретации даты yyyy-dd-mm или yyyy-mm-dd - для новых
участников проекта. Там же можно указать и стили оформления кода и т.п.

И во вторых.... как по db74878 найти в гите 734713bc047d87bf7eac9674765ae793478c50d3?

Уверяю вас - это возможно. Вы же не думаете, что короткий hash создатели git придумали just for fun?
И еще момент - "db74878" это первые символы полного hash.

в 3-их: у пользователя (или у наладчика на флешке) есть две сборки "(2017-02-03 db74878)" и "(2017-02-03 df56a87)" - какая свежея?
я пробовал прикрутить контроль версий.... не вкатило.... не понравилось.

Два варианта:
1) выводить в переменную и время. для избегания разночтений - в UTC.
2) в логе git посмотреть полную дату-время коммитов.
Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.

[juvf]

А как вы в оффлайне определяете такое написание? Например на сроке годности продуктов?

Ни как. На продуктах пишут 07.02.2017, другого написания не встречал. 2017.07.02 - такое написание не определяется.

2) в логе git посмотреть полную дату-время коммитов.

в каком логе? ещё раз... вводная.... наладчик/пользователь поехал на обновление ПО в устройстве. на флешке две прошивки... какая свежея? Нету ни проетка, ни клиента гит, ни инета....

в readme проекта можно указать формат интерпретации даты

какое ридми? пользователь должен зайти в эбаут приложения и должен увидеть номер сборки и/или дату и время сборки, и/или номер версии. И должен понять, на сколько программа свежая.

Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.

вы так говорите, какбудь-то я вас убеждаю не использовать версирование сборок. Я предложил свой вариант. Они ни чем не хуже вашего. По мне, так он удобнее, чем брать его из СКВ. на вскидку.... откройте в хроме chrome://help/ - Версия 55.0.2883.87. Нету ни каких диких хэшей из гита, нет даты... Объясните гуглу, что они не правильно версию пишут, и скажите им Контроль версий, как и баэкапы можно не любить, но жизнь вынуждает их применять... рано или поздно.
По мойму в qip было Версия 2005 build 8095.... Firefox - 51.0.1, FreeCommander XE 2016 Build 715, в нотепад++ версия и время сборки.... во всех программах версия/сборка/время сборки.... привязки к номерам ревизий из СКВ не встречал.... хотя не значит что их нет, и не значит, что это плохой способ... просто мне удобней автобилдом контролировать номера релизов.

Эскизы прикрепленных изображений

 

[johnshadow]

просто мне удобней автобилдом контролировать номера релизов.

Вы с этим проектом один работаете? Как без систем контроля версии выполняете модификацию кода?
Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения?

Нету ни каких диких хэшей из гита, нет даты...

По поводу билдов. Зайдите в FireFox в about:buildconfig и обнаружите:

Код

Built from https://hg.mozilla.org/releases/mozilla-beta/rev/d171c36d484800b1bb00db1612460a7120dd2fdf

Аналогично для Хрома в about:version:

Код

Версия    0e9a9a6f3676ae439b78cd9b3f62b4193c3ac7d5-refs/branch-heads/2924@{#895}

Сообщение отредактировал johnshadow - Feb 7 2017, 09:44

[juvf]

Как без систем контроля версии выполняете модификацию кода?
Т.е. каким образом разделяете релизную копию и копию в которой сейчас вносите изменения?

Давайте отделим мух от котлет. Я свой код контролирую либо с помощью svn, либо с помощью git (есть и cvs). Я использую систему контроля версий. Хотя не во всех проектах. если программа простая... её дольше в СКВ заносить, чем писать.
Что касается сборок.... не ревизий, а именно сборок. Есть задача - точно знать, какую версию использует пользователь и какую версию заливает. Для этого я во всех проектах применяю номер сбрки и/или время и дату сборки. номер сборки автоматически инкримитируется при компиляции. К СКВ номер сборки не привязан, как и СКВ к номеру сборки. Релизная копия отделена от проекта.... собирается релиз и выкладывается в общее хранилище, от куда релиз могут взять производство и служба сервиса. В хранилище лежат все релизные сборки... от 1 до 1234. Релизу задается имя name_1234.hex, 1234 - номер сборки. Там же в хранилище ведётся редми, с указанием изменений.

ps допустим пользователь обнаружил проблему.... говорит, что у него сборка 1201. Я вижу, что текущая 1234. Если проблема новая... то я буду эту проблему искать и устранять в 1234 и если найду, то выпущу 1235 и отправлю пользователю. Если проблема была.... то она решена гденить в 1220.... я просто отправлю ему 1234.

1)зачем по билду искать в репозитории релиз сборки 1201?
ну допустим вы захотите откатиться на 1201 и поискать там проблему и потом проверить есть ли она в 1234.... допустим.... но
2)вам чтоб откатится до билда 1201, от пользователя нужен хэш от гита? если он вам сообщит, что он пользуется хромом версии 55.0.2883.87, вы от него потребуете сообщить версию ad0be09aa3ca814168d079b52825f6f80e22f0e8-refs/branch-heads/2883@{#723}? Не думаю.... я думаю вы по 55.0.2883.87 сами найдете нужный релиз и нужный срез. тогда вопрос - зачем пихать в ПО этот жуткий хэш? Как говориться: в чем профит?

[johnshadow]

Как говориться: в чем профит?

Так ведь в распределенных СКВ нет возможности проводить сквозную нумерацию билдов\коммитов.
Допустим я создал ветку от вашего проекта и работаю с ней, параллельно с вами.
У меня свои номера билдов теперь, у вас свои. И как их дальше сравнивать?
На mercurial пытались прикрутить сквозную нумерацию, но по моему это отход от идеологии распределенных СКВ.
А так как есть дата коммита, то полный hash для однозначного определения конкретного коммита и не нужен.