LINUX.ORG.RU

GPL в веб-приложении


0

1

Допустим есть отдельный внутренний REST сервис, который работает на GPL библиотеке. Есть веб-приложение с которым работают юзеры. Оно или косвенно или непосредственно контактирует с сервисом.

Как работает лицензия в этом случае с веб-приложением? Нужно возиться с распространением сорцов?

★★★★★

Нужно возиться с распространением сорцов?

Нет

r_asian ★☆☆
()

>Нужно возиться с распространением сорцов?

Нет, не нужно. Для этого есть AGPL.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Ха, посмотрел. Интересующая либа таки AGPL. Посему нужно вообще все веб-приложение дистрибутить в сорцах, даже если взаимодействие через JSON по REST?

vertexua ★★★★★
() автор топика
Ответ на: комментарий от vertexua

Лицензия AGPL предназначена для закрытия так называемых «лазеек для провайдеров услуг» (Application Service Provider), имеющихся в GPL, которые позволяют использовать для обеспечения работы сервисов код под лицензией GPL без возвращения сообществу добавленных улучшений. В случае использования лицензии AGPL разработчик веб-сервиса обязан открыть его исходный код.

Пруф тут: http://www.opennet.ru/opennews/art.shtml?num=30086

sniper21 ★★★★★
()
Ответ на: комментарий от sniper21

Но лишь код веб-сервиса, а не других сервисов, которые его юзают? А если он вообще сугубо внутренний и не торчит снаружи? Давать код разработчикам проекта? )))

vertexua ★★★★★
() автор топика

Нужно обеспечить доступность исходников внутреннего REST-сервиса, исходники веб-приложения открытать не нужно, коли они контактируют по REST.

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

Вообщем, в данном случае немного все спорно - все определится на суде)

BigAlex ★★★
()

а что если выделить некоторое кол-во человеко-часов на написание своей неГПЛ (м.б. даже проприетарной) библиотеки и заменить ею ту?

anonymous
()
Ответ на: комментарий от anonymous

а вроде кажется в мире сущетвует только одна [популярная] AGPL-программа....

...это.... MongoDB :-)

чтобы её переписать нужно очень много МНОГО человекочасов :-) ...или использовать Apache CouchDB .. она под Apache вроде

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

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

anonymous
()
Ответ на: комментарий от user_id_68054

и кстати у монги не agpl, а слегка интереснее http://www.mongodb.org/display/DOCS/Licensing


To make the above practical, we promise that your client application which uses the database is a separate work. To facilitate this, the mongodb.org supported drivers (the part you link with your application) are released under Apache license, which is copyleft free.

anonymous
()
Ответ на: комментарий от anonymous

> а почему бы тогда не запользовать стабильный и надежный постгрес, а не это непоймичоноуэскьюэль?

а он маштабируется? (ну например также как bigcouch-версия couchdb)... всмысле имея ввиду:

1. разные данные храняться на разных серверах

2. для доступа (чтение/запись) к данным можно использовать НЕ единственный-proxy (который может стать «узким горлышком бутылки»), а ЛЮБОЙ сервер из определёного-набора-серверов, набор который можно увеличить в количестве

# p.s.: вопрос НЕ реторический :-) ...так как софта для Postgresql понаписанно очень много разного

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

> а вроде кажется в мире сущетвует только одна [популярная] AGPL-программа....

...это.... MongoDB :-)

Допустим, что я сделал некоторый интернет-ресурс, использующий MongoDB. Какие исходники в этом случае я должен предоставить?

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

Никакие. Осильте уже файлик лицензии прочитать что ли

BigAlex ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.