LINUX.ORG.RU

История изменений

Исправление another, (текущая версия) :

Еще раз пишу в попытке обобщить (втч, для себя, так что «спасибо» не надо) свой опыт как представителя заказчика.

В договоре желательно^Wобязательно чётко прописывать что нужно сделать и сколько это стоит. По пунктам. Чем более детализирована смета, тем легче будет при возникновении проблем. Ибо в случае единой суммы заказчику будет легко тебя послать и сказать, что _всё_ сделанное ненужно. Ты работал - денег нет. Может сложиться и обратная ситуация, что ты не сделал, но заказчик должен, но это сложнее и нужно быть опытным троллем.

Если ты делаешь продукт на основе уже готового каркаса, то так и нужно прописывать. В итоге ты сдаешь не «афигенный лична написоный пацнский кУУлSiTe», а «программное решение, прдставляющее собой веб-сайт на основе фреймворка Joomla(c)(r)(tm)». Соответственно ты передаешь исключительные права не на сам фреймворк, а на ту надстройку, которую ты написал. Это как с SAP, 1c и прочим. Передается только _твоя_ работа, представляющая собой доработку уже существующего решения. Уже существующее решение - отдельно, под своей лицензией, твоя доработка - отдельно. Если конечно такое допускается лицензией платформы. При этом желательно^Wобязательно сразу уточнять, что если платформа, на основании которой делается сайт, проприетарная, то либо заказчик сам разбирается с лиценизированием, либо это включается в стоимость. Про то, в каком виде может передаваться результат, я писал в посте выше.

Если в состав разработки сайта входит его наполнение графикой и текстом, то условия лицензирования графики и текста писать надо отдельно (если ты не художник/писатель и не пишешь всё сам, и все права передаешь Заказчику). Речь о графике, распространяющейся под свободными лицензиями. И кстати, общественное достояние != GPL. Причем ни разу не равно, и даже близко не лежало. Так что про это выкинь из текста договора.

Если ты хочешь часть своей работы выложить под GPL, то это надо сразу писать в договоре. В идеале: ты сначала пишешь, выкладываешь под GPL, а только потом заключаешь договор на адаптацию уже готового решения для Заказчика. Иное - обман. Обман - это плохо, дети. :)

Да, все исполнители жульничают. И разработанный и проданный ранее код используют повторно. Причем они сами очень часто не понимают, что это грубое нарушение (не раз беседовал на эту тему с разрабами и их манагерами) условий ГК РФ и договора. Не делай так, будь честным. Хотя это сложно, все задания типовые, а заказчик требует исключительных прав, ибо юристы. В идеале ты передаешь только неисключительные права на произведение (лицензия). Но на это мало кто соглашается.

Все изменения в техзадание (да и вообще в договор) оформляются только письменно с пересмотром сроков и суммы, если это необходимо. Это обязательное условие. Без него никуда. Данное условие по дефолту в законодательстве идёт, так что не надо его акцентировать (как это у тебя прописано с правом требования продления сроков в случае изменения задания), вполне хватит четких требований к решению в ТЗ и ссылки, что _любые_ изменения к договору (ТЗ - тоже часть договора) оформляются путем заключения дополнительного соглашения.

Порядок сдачи и приемки работ должен быть детально оговорен. Обычно это выглядит как:

Не позднее _ дней до окончания срока, исполнитель предоставляет результаты" вместе с актом сдачи работ. Результаты предоставляются путем ______________________________.

Заказчик в течение _ дней подписывает акт или выкатывает список недоработок. При необходимости (нужно только для больших работ) проводятся приемочные испытания на основании методики разработанной исполнителем и утвержденной заказчиком (опять же надо в этом случае указывать порядок утверждения)

В случае отсутствия замечаний в указанный срок работа считается принятой и подлежащей оплате (это условие зовется автоприемкой, Заказчик его не любит и старается выкинуть; даже при выкидывании «разумный срок на рассмотрение результата» никто не отменяет).

В случае наличия замечаний Исполнитель в течение _ дней устраняет замечания и повторно направляет результат вместе с актом.

В заключение:

При написании шаблона договора следует всё стандартное вписать в сам текст договора (типа функции в программировании), а всё изменяемое (втч, размер аванса) вынести в приложения к нему (типа переменной). Если ты решил всерьез заняться фрилансерством, то никто за тебя это не сделает, это уже лично твое дело как оформлять отношения.

А я тебе советую пойти просто работать обычным погроммистом и пообщаться с заказчиками, манагерами и юристами. Получить опыта, а потом уже с высоты этого опыта пытаться сделать что-то самостоятельно.

Как-то так.

Выдохнул. :)

Исправление another, :

Еще раз пишу в попытке обобщить (втч, для себя, так что «спасибо» не надо) свой опыт как представителя заказчика.

В договоре желательно^Wобязательно чётко прописывать что нужно сделать и сколько это стоит. По пунктам. Чем более детализирована смета, тем легче будет при возникновении проблем. Ибо в случае единой суммы заказчику будет легко тебя послать и сказать, что _всё_ сделанное ненужно. Ты работал - денег нет. Может сложиться и обратная ситуация, что ты не сделал, но заказчик должен, но это сложнее и нужно быть опытным троллем.

Если ты делаешь продукт на основе уже готового каркаса, то так и нужно прописывать. В итоге ты сдаешь не «афигенный лична написоный пацнский кУУлSiTe», а «программное решение, прдставляющее собой веб-сайт на основе фреймворка Joomla(c)(r)(tm)». Соответственно ты передаешь исключительные права не на сам фреймворк, а на ту надстройку, которую ты написал. Это как с SAP, 1c и прочим. Передается только _твоя_ работа, представляющая собой доработку уже существующего решения. Уже существующее решение - отдельно, под своей лицензией, твоя доработка - отдельно. Если конечно такое допускается лицензией платформы. При этом желательно^Wобязательно сразу уточнять, что если платформа, на основании которой делается сайт, проприетарная, то либо заказчик сам разбирается с лиценизированием, либо это включается в стоимость. Про то, в каком виде может передаваться результат, я писал в посте выше.

Если в состав разработки сайта входит его наполнение графикой и текстом, то условия лицензирования графики и текста писать надо отдельно (если ты не художник/писатель и не пишешь всё сам, и все права передаешь Заказчику). Речь о графике, распространяющейся под свободными лицензиями. И кстати, общественное достояние != GPL. Причем ни разу не равно, и даже близко не лежало. Так что про это выкинь из текста договора.

Если ты хочешь часть своей работы выложить под GPL, то это надо сразу писать в договоре. В идеале: ты сначала пишешь, выкладываешь под GPL, а только потом заключаешь договор на адаптацию уже готового решения для Заказчика. Иное - обман. Обман - это плохо, дети. :)

Да, все исполнители жульничают. И разработанный и проданный ранее код используют повторно. Причем они сами очень часто не понимают, что это грубое нарушение (не раз беседовал на эту тему с разрабами и их манагерами) условий ГК РФ и договора. Не делай так, будь честным. Хотя это сложно, все задания типовые, а заказчик требует исключительных прав, ибо юристы. В идеале ты передаешь только неисключительные права на произведение (лицензия). Но на это мало кто соглашается.

Все изменения в техзадание (да и вообще в договор) оформляются только письменно с пересмотром сроков и суммы, если это необходимо. Это обязательное условие. Без него никуда. Данное условие по дефолту в законодательстве идёт, так что не надо его акцентировать (как это у тебя прописано с правом требования продления сроков в случае изменения задания), вполне хватит четких требований к решению в ТЗ и ссылки, что _любые_ изменения к договору (ТЗ - тоже часть договора) оформляются путем заключения дополнительного соглашения.

Порядок сдачи и приемки работ должен быть детально оговорен. Обычно это выглядит как:

Не позднее _ дней до окончания срока, исполнитель предоставляет результаты" вместе с актом сдачи работ. Результаты предоставляются путем ______________________________.

Заказчик в течение _ дней подписывает акт или выкатывает список недоработок. При необходимости (нужно только для больших работ) проводятся приемочные испытания на основании методики разработанной исполнителем и утвержденной заказчиком (опять же надо в этом случае указывать порядок утверждения)

В случае отсутствия замечаний в указанный срок работа считается принятой и подлежащей оплате (это условие зовется автоприемкой, Заказчик его не любит и старается выкинуть; даже при выкидывании «разумный срок на рассмотрение результата» никто не отменяет).

В случае наличия замечаний Исполнитель в течение _ дней устраняет замечания и повторно направляет результат вместе с актом.

В заключение:

При написании шаблона договора следует всё стандартное вписать в сам текст договора (типа функции в программировании), а всё изменяемое (втч, размер аванса) вынести в приложения к нему (типа переменной). Если ты решил всерьез заняться фрилансерством, то никто за тебя это не сделает, это уже лично твое дело как оформлять отношения.

А я тебе советую пойти просто работать обычным погроммистом и пообщаться с заказчиками, манагерами и юристами. Получить опыта, а потом уже с высоты этого опыта пытаться сделать что-то самостоятельно.

Как-то так.

Исходная версия another, :

Еще раз пишу в попытке обобщить (втч, для себя, так что «спасибо» не надо) свой опыт как представителя заказчика.

В договоре желательно^Wобязательно чётко прописывать что нужно сделать и сколько это стоит. По пунктам. Чем более детализирована смета, тем легче будет при возникновении проблем. Ибо в случае единой суммы заказчику будет легко тебя послать и сказать, что _всё_ сделанное ненужно. Ты работал - денег нет. Может сложиться и обратная ситуация, что ты не сделал, но заказчик должен, но это сложнее и нужно быть опытным троллем.

Если ты делаешь продукт на основе уже готового каркаса, то так и нужно прописывать. В итоге ты сдаешь не «афигенный лична написоный пацнский кУУлSiTe», а «программное решение, прдставляющее собой веб-сайт на основе фреймворка Joomla(c)(r)(tm)». Соответственно ты передаешь исключительные права не на сам фреймворк, а на ту надстройку, которую ты написал. Это как с SAP, 1c и прочим. Передается только _твоя_ работа, представляющая собой доработку уже существующего решения. Уже существующее решение - отдельно, под своей лицензией, твоя доработка - отдельно. Если конечно такое допускается лицензией платформы. При этом желательно^Wобязательно сразу уточнять, что если платформа, на основании которой делается сайт, проприетарная, то либо заказчик сам разбирается с лиценизированием, либо это включается в стоимость. Про то, в каком виде может передаваться результат, я писал в посте выше.

Если в состав разработки сайта входит его наполнение графикой и текстом, то условия лицензирования графики и текста писать надо отдельно (если ты не художник/писатель и не пишешь всё сам, и все права передаешь Заказчику). Речь о графике, распространяющейся под свободными лицензиями. И кстати, общественное достояние != GPL. Причем ни разу не равно, и даже близко не лежало. Так что про это выкинь из текста договора.

Если ты хочешь часть своей работы выложить под GPL, то это надо сразу писать в договоре. В идеале: ты сначала пишешь, выкладываешь под GPL, а только потом заключаешь договор на адаптацию уже готового решения для Заказчика. Иное - обман. Обман - это плохо, дети. :)

Да, все исполнители жульничают. И разработанный и проданный ранее код используют повторно. Причем они сами очень часто не понимают, что это грубое нарушение (не раз беседовал на эту тему с разрабами и их манагерами) условий ГК РФ и договора. Не делай так, будь честным. Хотя это сложно, все задания типовые, а заказчик требует исключительных прав, ибо юристы. В идеале ты передаешь только неисключительные права на произведение (лицензия). Но на это мало кто соглашается.

Все изменения в техзадание (да и вообще в договор) оформляются только письменно с пересмотром сроков и суммы, если это необходимо. Это обязательное условие. Без него никуда. Данное условие по дефолту в законодательстве идёт, так что не надо его акцентировать (как это у тебя прописано с правом требования продления сроков в случае изменения задания), вполне хватит четких требований к решению в ТЗ и ссылки, что _любые_ изменения к договору оформляются путем заключения дополнительного соглашения.

Порядок сдачи и приемки работ должен быть детально оговорен. Обычно это выглядит как:

Не позднее _ дней до окончания срока, исполнитель предоставляет результаты" вместе с актом сдачи работ. Результаты предоставляются путем ______________________________.

Заказчик в течение _ дней подписывает акт или выкатывает список недоработок. При необходимости (нужно только для больших работ) проводятся приемочные испытания на основании методики разработанной исполнителем и утвержденной заказчиком (опять же надо в этом случае указывать порядок утверждения)

В случае отсутствия замечаний в указанный срок работа считается принятой и подлежащей оплате (это условие зовется автоприемкой, Заказчик его не любит и старается выкинуть; даже при выкидывании «разумный срок на рассмотрение результата» никто не отменяет).

В случае наличия замечаний Исполнитель в течение _ дней устраняет замечания и повторно направляет результат вместе с актом.

В заключение:

При написании шаблона договора следует всё стандартное вписать в сам текст договора (типа функции в программировании), а всё изменяемое (втч, размер аванса) вынести в приложения к нему (типа переменной). Если ты решил всерьез заняться фрилансерством, то никто за тебя это не сделает, это уже лично твое дело как оформлять отношения.

А я тебе советую пойти просто работать обычным погроммистом и пообщаться с заказчиками, манагерами и юристами. Получить опыта, а потом уже с высоты этого опыта пытаться сделать что-то самостоятельно.

Как-то так.