Алекс Белов

Если лицензия самого видео позволяет это сделать, то можно.
Но как правило надо будет всё равно указать исходного автора.

Так как подобные видео делаются из общедоступных материалов с лицензией free/royalty free, то технически, может совпасть что созданное видео будет полностью совпадать с видео на чужом канале.

А звук? А монтаж? А работа по склейке/нарезке разных частей?
Не все свободные лицензии идут share-alike

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

PS Ну а снятие копий, почему не исключить таблицы при выборке? Плюс, есть другие решения для разработчика, например, наборы тестовых данных (у Laravel есть соответствующий инструмент).

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

Я, кажется, начинаю понимать суть тостера.
Habra - профессионалы делятся опытом, бесплатно.
Hantim - профессионалы реализуют себя за зарплату.
Freelansim - самовлюбленные профессионалы и начинающие пытаются себя реализовать за зарплату.
Brainstorage - все, кто считает себя профессионалом ищут себе подобных и добавляются в друзья.
Toster - памагите вы же профессианалы напешыте код!!!!

Вы меня простите, но вряд ли вам дадут совет, как наиболее оптимизированно сломать себе руку - в большинстве своем люди либо не ломали себе рук, либо это было очень неприятно.
Надеюсь, метафора вам понятна.

На мой взгляд базисные знания следующие:

1) Клиентская верстка и стили (html, css). Можно пробежаться глазами хотя бы по теме. Почитать про правила верстки.
2) Клиентская логика, работа с DOM (Javascript, Jquery). Важная тема — стоит уделить ей время.
3) Теория распределенных приложений. — Веб приложения чаще всего являются распределенными. Поэтому стоит изучить архитектурные принципы распределенных приложений. API и т.д.
4) Базы данных (SQL, etc.) — Конечно начать стоит с классического сиквела — но стоит посмотреть и шире — например на nosql решения.

Далее стоит выбрать технологическую платформу. С вашим бэграундом вероятно стоит посмотреть в сторону Microsoft ASP.NET MVC. Это великолепное решение и погружение в обширный мир разработки в рамках решений MS. У них сейчас самые развитые языки программирования (C# 5.0), самые развитые инструментальные среды (MS Visual Studio), одна из самых совершенных виртуальных машин (.Net).
Решение удобнее всего для серьезных и масштабных проектов, хотя и для небольших вполне подойдет.
Следующий кандидат — Ruby on Rails. Это развитое решение с замечательным языком программирования и отличными каркасными решениями, заточенное именно под веб. Возможно лучше подойдет для небольших приложений — но и промышленные продукты без проблем потянет.
Он также очень распространен.
Ну и конечно PHP. Язык программирования данной технологической платформы отстает от требований к разработке больших решений — он скорее подходит для написания скриптов. Однако существует колоссальное количество каркасных решений для данной платформы, которые позволяют реализовывать даже приличного объема продукты. Кроме того данное решение наверное самое распространенное из всех.
И оно потихоньку подтягивается до уровня платформ для разработки промышленных продуктов.
Существует также множество других решений. Например огромный мир Java и решения на базе серверного Javascript.

Скоп работ будет состоять из следующих частей:

1) Клиентская часть (html, css, javascript). Тут вам понадобятся знания по верстке как раз и жаваскрипту. Также следует использовать различные базовые решения и фреймворки. Эта как раз та часть, где слишком глубокие знания (например использование чистого некроссбраузерного javascript) могут быть вредны и лучше все базировать на готовых платформах.
Часто эта часть в web приложениях бывает больше чем хотелось бы.

2) Серверная часть. Тут все определяется технологической платформой описанной в предыдущем абзаце. В веб приложениях как правило немного серверной логики — почти все можно заменить на внешние библиотеки. Но у разработчиков десктопных приложений всегда есть соблазн развивать именно эту часть потому что она им знакома — не поддавайтесь. Специфическая для проекта серверная логика нужна не очень часто. Если ее много — значить кто то увлекся велосипедами. Тоже касается разработок API и систем взаимодействия с внешними сервисами.

3) Базы данных. Конечно обязательно! стоит использовать развитые ORM системы. То есть нужно их изучить под выбранную вами технологическую платформу. Ну и конечно базовые знания баз данных тут тоже очень понадобятся — сиквел, реляционная модель и все остальное.

Дерзайте. Я за вас болею.

GPL позволяет изменять исходные коды для собственных нужд и не распространять изменения. Если же изменённый код распространяется, то он должен распространяться под GPL. Видимо, партнёры не хотят распространять код под GPL и, следовательно, не могут распространять его вообще.

Никак

Именно поэтому через контакт адекватные люди авторизацию не прикручивают. У мордокниги https есть, хотя бы. А гугл скоро прикрутить auth по смскам.