Skip to content

Чести въпроси, които интересуват производителите на Open Source според gpl-violations.org

1. Като продавач на GPL лицензирани продукти какво се възприема за добра практика?

- помнете че лиценза изисква от вас да предоставите изходния код на клиентите си заедно със самия продукт или да включите писмена оферта. Добър начин да направите това е да включите компресиран файл с кода в дисковете с документацията.

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

- ако предоставяте update-и по Интернет и ако те също включват GPL софтуер, то задължително трябва да предоставите съответния код на update-а при пускане на update
Имайте предвид, че това не са правни съвети и акоимате съмнения е най-добре да се консултирате с адвокат.

2. Какви са обичайните грешки?

- Използването на стандартен текст, който твърди, че целият софтуер е (C) Copyright OurCompany. Това няма да е вярно, ако използвате свободен софтуер в продукта си, авторски права, върху който имат 3-ти страни.

-Забравили сте да включите писмена оферта за изходния код

- включили сте грешна версия на изходния код. Изходният код трябва да съответства 1:1 с изпълнявания от програмата код,който всъщност е и кода на предлагания продукт.

- забравили сте да сложите скрипта(овете), които се използват за контрол върху компилацията и инсталацията на изпълнявания код или иначе казано инструментите, които се изискват за компилация и инсталация на GPL лицензирани компоненти на софтуера.

- включили сте само линк към текста на GPL лиценза вместо дословно копие

- включили сте само линк за даунлоуд на изходния код вместо писмена оферта за доставка на изходния код на физически носител, който обикновено се използва за обмяна на информация.

В случай на разпространение на софтуер, който правите публично достояние за преглед и даунлоуд слагате връзка към текста на лиценза или към изходния код на сървъри, които не са ваши. Това е равнозначно на секция 3c на GPL лиценза (предоставяне на писмен оферта), която е валидна само за некомерсиална дистрибуция.

3. Какво трябва да направя, ако нашата компания е нарушила лиценза?

Поправете нарушението, както бихте постъпили, ако има нарушение на комерсиален лицензен софтуер. Друг ъгъл, от който можете да гледате на това е като си зададете въпроса: бих ли нарушил авторското право на IBM софтуер или Intel или HP? Сигурно не бихте - но ако нарушите лиценза на Linux, то вие нарушавате едновременно Intel, IBM и HP лицензите по едно и също време. И трите компании имат авторско право върху значителна част от ядрото на Linux и нарушавайки GPL вие всъщност нарушавате също така и тяхното авторско право.

4.Като производител откъде бих могъл да получа помощ?

Съществува разнообразие от източници на информация и помощ. Първият ви контакт трябва по всяка вероятност да е вашият доставчик на GPL софтуерни компоненти. GPL лиценза е написан по начин, който да прави текста възможно най-ясен, но адвокатска помощ ще ви е много полезна за сложни въпроси, като производни на софтуер с отворен код.
Сайтове като Sourceforge.net могат да ви помогнат с хостинг за GPL версии на даден софтуер.

5. Как мога да “ощастливя” обществото?

Най-голямата стойност за обществото е достъпът до изходния код. Едно от полезните неща, които една омпания може да направи е да предостави и достъп до промените, които прави по кода. Достъпът до кода през сайтове като sourceforge.net също би било изключително полезно. Някои производители изграждат общности около кода и се опитват непрекъснато да са съпричастни, но други просто захвърлят кода и забравят за него.

6. Няма ли всичко свързано с GPL да ми коста много?

Не. Вашето задължение е или да предоставите иходния код на GPL компонентите или писмена оферта включена в продукта.

Няма задължения за трети страни, няма задължения и за поддръжка на софутер, който е бил създаден като са използвани вашите промени. GPL включва също така и клауза според, която вие не носите отговорност за гаранционна поддръжка. Освен това писмената оферта обикновено предполага да предоставите кода на стойност равна на доставната или по-висока, а не безплатно. Посрещането на изискванията на лиценза е възможно като просто включите копие от лиценза в упътването за софтуера, съответното признание и zip файл със съответния изходен код на CD-то, което придружава продукта.
Големи разходи и проблеми бихте имали само, ако нарушите лиценза.

Често срещани въпроси във връзка с предоставяне на изходния код

Тези въпроси съдържат малко по-детайлна информация за изискванията и най-добрите текущи практики за предоставяне на изходния код на лицензиран под GPL изпълняем код. Информацията е събрана като резултат от многобройни недостатъци и грешки от над 60 случая на успешно налагане на клаузите на GPL лиценза.

Преди да предоставите изходния код както изисква от вас GPL ще е най-добре да прегледате тези FAQ, за да сте сигурни за целостта и взаимното удовлетворение от това, което ще предоставите.

Какъв тип изходен код трябва да публикувам под GNU GPL?

GNU GPL изисква от вас веднага след като разпространите кода на GPL лицензирания софтуер в изпълним формат да направите достъпен “целия съответстващ изходен код (complete corresponding source code)”. GNU GPL също съдържа и дефиниция на този термин:
“Изходния код за дадена работа означава предпочитаната за правене на модификации форма на работата. За изпълнима работа, цялостен изходен код означава целия изходен код за всички модули, които съдържа плюс всички асоциирани файлове, които служат за определяне на интерфейса плюс скриптовете, които се използват за контрол на компилацията и инсталацията на изпълнимата работа”.

Това е доста точно определение. За типична C програма това би се превело като целия изходен код (.c files) плюс хедър файловете (.h files) плюс скриптовете, които се използват за контрол над компилацията и инсталацията.

Винаги помнете, че цел на GPL е да предостави възможност на потребителите да упражняват тези свободи. По-специално свободата да правят модифицирани версии на програмата и да изпълняват такива модифицирани версии на програмите.

Какво представляват “скриптове, които се използват за контрол на компилацията”?

Обикновено всяка по-сложна програма е разделена на много различни файлове с изходен код. По време на процеса на компилация всеки един от тях се компилира (става съставна част) на изпълнимия код, след което те са свързани един с друг. Този процес на компилиране и свързване на индивидуланите файлове с изходен код обикновено се контролира от скриптове. Най-често се използва “make” програмата, чиито скриптове се обозначават като “Makefiles”.

От друга страна някои програми, като ядрото на Linux, обикновено имат compile-time конфигурация (в случая на ядто на Linux .config файл). Тъй като тази compile-time конфигурация без съмнение контролира процеса по компилация, е необходимо да включите също и такива compie-time конфигурационни файлове.

След като трансформирате софтуера от форма изходен код във форма изпълним формат, програмата най-често трябва да се инсталира в системата. Процесът на инсталация обикновено е автоматизиран от инсталационни скриптове. Точно за тези скриптове става въпрос в GPL.

Понякога процесът на инсталация не се подпомага от скриптове, а от други средства, като например изпълними програми. GPL текста споменава само думата “scripts”, но при четене и интерпретация на лиценза става ясно, че се има предвид не само скриптове, но всеки тип програма, които се изискват за инсталация на версия на компилираната програма.

А какво следва да се прави с компилатора, toolchain?

GPL изрично казва:
“Въпреки това, като специално изключение, изходният код, който се разпространява не е необходимо да включва нещо, което обикновено се разпространява с по-големите копоненти (компилатор, ядро и т.н.) на операционната система, на която изпълнимия код ще се използва, освен ако самият компонент не придружава изпълнимия код.” Този параграф е написан за програми, които вървят на съществуващи многоцеливи операционни системи. Така че ако разпространявате такива програми не е нужно да включвате компилатор, ядро, toolchаin и т.н.

Каква версия на изходния код трябва да се предостави?
За всяка една версия на изпълнимата програма вие трябва да разпространите точно съответстващата версия на цялостния съответстващ изходен код. Ако сте разпространили 10 различни версии и те съдържат GPL лицензиран софтуер, то вие трябва да разпространите 10 различни пакети с изходен код по един съответстващ на на всяка изпълнима версия.

Трябва да имате предвид, че ако сте избрали GPL вариант 3b (вместо 3а), тогава задължението ще важи само за 3 години. Това означава, че не е необходимо да предоставяте изходния код за който и да е изпълним код, разпространен преди повече от 3 години. Имайте предвид, че и разпространение на физически носител и посредством мрежа за данни, като интернет се броят за разпространение.

Как да проверя, че изходният код, който съм разпространил е пълен?
Това е доста лесно. Ако използвате само изходен код, предоставен в дадена версия и можете да използвате този изходен код, за да произведете разботеща форма на изпълнимия код, значи изходния код би трябвало да е пълен. Ако процеса на изграждане не може да се завърши или като резултат получите неработещ изпълним код, или няма никакъв начин да инсталирате получения изпълним код, значи определено нещо ви липсва.

Какво се цели при налагнето на GPL клаузите?

- да стане ясно какви са последствията от нарушение на лиценза и да се разпространи информация за случаи на нарушение

- да се подпомогнат производителите в усилията им да спазват и да се придържат към GPL

- да се налагат клаузите и да се предотвратят злоупоребите със свободен софтуер

Има ли възможност и власт gpl-violations наистина да постигне горните цели?

В ситуации, в които нарушения наистина са намерени и са предприети действия налгането на лиценза е имало успех. Това включва въпроси уредени извън съда с няколко големи производители и законово съдебно предписание спрямо Sitecom. Ние се стремим да разрешаваме въпросите приятелски, а когато това няма успех тогава ги разрешаваме посредством законови действия.

Колко голям е големия производител според посоченото тук?

Fujitsu-Siemens е голям и те не са единствения пример.

GPL има ли законова сила?

Поне в Германия, да, а тъй като сме виждали плашещи истории и на други места не виждаме причина да вярваме, че няма законова сила в глобален мащаб.

Какъв процес, последователност от действия следва gpl-violations.org?

Целта на gpl-violations.org е да разрешава въпроси, при които има нарушение. Ние знаем, че компаниите допускат грешки. Търсим дружелюбни решения, когато това е възможно, но само ако решенията водят до решение на въпроса с нарушението.

Как можем да помогнем на gpl-violations.org?

На първо място, като не реагирате на техническо нарушение на лиценза по твърде краен начин. На второ място като проверявате дали дадено нарушение наистина е нарушение. Присъединете се към мейл листовете и обсъдете въпроса първо там. Бъдете учтиви, но твърди, когато се занимавате с компании и помнете, че целта е да сме сигурни, че дадена компания ще престане да нарушава GPL и че няма да го наруши отново, вместо да оставите димящ кратер пред главния им офис, поне не и след първото нарушение.

Водете си бележки на проведените от вас разговори с компаниите. Координирайте се и с други. Трудно се води комуникация с компания, която се изправя пред 8 различни истории. Компания, към която е отправено едно точно обвинение, или й е предоставена информация от един източник ще може да отговори по-добре.

Имайте предвид така наречената бомба на “публичен срам”. Много е лесно да я взривиш, но много е трудно да не й се вярва, ако е допусната грешка или ако проблемът е бил много малък и е било бързо разрешен.

Какво мога да направя, ако се натъкна на нарушение на GPL?

gpl-violations.org записва всички докладвани нарушения във вътрешната си система за проследяване на нарушенията. Ако искате да докладвате за непотвърдено нарушение моля пишете на icense-violation@gpl-violations.org и включете колкот се може повече информация и детайли.

Законови въпроси

За какви щети и обезщетение се борите, когато въпросът стигне до съдебен процес?

От законова гледна точка щетите са съвсем различен въпрос от това да се прекрати дадено нарушение. Във всички случаи, в които сме стигали до съда ние сме се интересували само от това да прекратим даденото нарушение, но не и от щетите. Въпреки това, ако сте претърпели щети можете да ги измерите в цифри. Вижте проекти като MySQL, които успешно печелят пари на база двоен лиценз. Така че ако нарушаващият производител договори вариант на GPL лицензиране, носителите на авторските права биха могли да спечелят пари на база задълженията по GNU GPL. Случаят на Linux е съвсем друг тъй като правата за ползване са разпространение между толкова много потребители, че е нереалистично да постигнете споразумение с всеки един от тях. Посочвайки тези бизнес модели на двойно лицензиране сме уверени, че можем да оспорим твърдения от рода на “не сте изгубили пари, защото сте го предоставили безплатно”.

Защо изпращате първо предупредително писмо на производители нарушаващи лиценза, вместо да се свържете с тях?

Официалните предупредителни съобщения изпратени от нашите адвокати винаги привличат вниманието на съотвеното управленско ниво и така им се обръща подобаващо внимание и сериозност особено за големи нарушения.