Необходимо ли Лицензирование front-end API интерфейса веб-службы на SOAP и REST/JSON?

Question

[nmouse]

Ситуация следующая:
1. У нас есть система, которая имеет внешнее API реализованное на SOAP и REST/JSON.
2. В последнее время мы задумываемся отказаться от текущего вендора и начать разработку системы с нуля, но при этом сделать адаптеры API от старой версии системы.

Внимание вопрос: необходимо ли получать какие-то лицензии на SOAP и REST/JSON от текущего вендора?
Имею ввиду именно на внешний вид протоколов?

Answer 1

[Z-r]

IANAL, TINLA.

Недостаточно данных для осмысленного ответа.

> начать разработку системы с нуля, но при этом сделать адаптеры API от старой версии системы.

Важно не что́ вы собираетесь сделать, а что́ при этом намерены использовать из об’ектов монопольных прав вашего «текущего вендора» (что бы ни скрывалось за этим странным словом).

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

> необходимо ли получать какие-то лицензии на SOAP и REST/JSON от текущего вендора?

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

Comments

[nmouse]

Прошу прощения, действительно мало информации, но давать какие-то конкретные ссылки не могу, так как это может принести излишнюю шумиху и/или репутационные риски.
Давайте, попробую немного детализировать.
У нас на текущей системе несколько сотен тысяч клиентов, которые используют API как по SOAP, так и по REST/JSON. Мы хотим разработать новую версии системы уже со своим API, так как текущий уже устарел и нам немного тесно в нём, а дополнительные расширения делать под каждый случай - в плане поддержки сложно, да и новые клиенты немного путаются.
У текущего вендора заказывать не хотим, по причине того, что за шесть лет он превратился из достаточно юркого и ответственного за качество в крайне медленного и неповоротливого, плюс качество продукта на релиз крайне сильно упало, да и наши наработки вдруг начали всплывать у конкурентов (пусть и не сразу и немного другом виде, но всё же).
Так вот для сохранения текущей пользовательской базы в новой системе придется делать адаптеры API для поддержки старых протоколов.
В итоге нам, при создании адаптеров придется:
Для REST/JSON: скопировать название методов, название переменных и их типы, а так же структуры данных, которые участвуют в ответе на запрос
Для SOAP: скопировать WSDL и к нему прикрутить свой фронт

[Z-r]

nmouse, то, что вы пишете, ведь не просто не должно быть свободным, а вы это вообще это распространять не собираетесь? Ну тогда многие бы, наверное, вовсе и не подумали на вашем месте дергаться.

Но вообще за такими советами на веб-форумы ходить — все равно, что гонорею по Интернету лечить. Обратитесь к вашему юрисконсульту, а еще лучше — адвокату, имеющему понятие о методе «чистой комнаты».

[nmouse]

Z-r: Юристов в любом случае будем привлекать, но сначала хотел поинтересоваться, вдруг кто-то уже сталкивался, так как завтра встреча с людьми (которых будем помещать в "чистую комнату").