[horde] Use of the HORDE product : GNU/GPL conformity case ?

Jan Schneider jan at horde.org
Fri Oct 26 14:40:46 UTC 2012


Zitat von "Stuart C. Naifeh" <scnaifeh at hotmail.com>:

>
> On Fri, Oct 26, 2012 at 7:28 AM, Bernard TREMBLAY <
> bty-opendev.horde at trebly.net> wrote:
>
>> Le 26/10/2012 10:26, Jan Schneider a écrit :
>> >
>> > Zitat von Bernard TREMBLAY <bty-opendev.horde at trebly.net>:
>> >
>> >> Hi,
>> >>
>> >>     Do the fact, that a provider of internet services to use your
>> product
>> >> as one of the goodies into a pack, but this with the suppression of some
>> >> important functions as "transmit" email without any change of help file
>> >> nor version number (i.e. 3.3.5 modified... restricted...), is according
>> >> to GNU/GPL license in your opinion ?
>> >>     In my opinion not : this non conformity with original product
>> >> functionalities, can be confused by user with a bad achievement of the
>> >> product or with bugs. Then the time lost by the user of the modified
>> >> version with restrictions, which can be followed by errors done into his
>> >> own specifications (using HORDE product knowledge in conformity with
>> >> version number) transmitted to his own clients can create damages to the
>> >> client and to the "name" of HORDE , is it not true ? GNU/GPL does not
>> >> mean do "what you want" with our sources".
>> >
>> > It depends. Does he distribute the modified software, or does he only
>> > offer it as a service. As a service he can modify the code like he
>> > wants, limiting features to his users etc.
>> > If he distributes or even sells the modified Horde version as a part of
>> > his product, he can still do so, but has to disclose the modified source
>> > code to the public.
>> >
>> > IANAL
>>
>> Hi,
>>
>> OK. This confirms to me that me are fully GNU/GPL without application
>> complements thoughts.
>> He simply offers as a service, and says that he has not changed anything
>> to the product (3.3.5).
>> In fact the use of transmit mail from filters is not operational (see
>> farther).
>>
>> But, such complements, as I discuss here "oblige provider of service to
>> inform the next level of changes made", could be, as for the text of the
>> laws and contract, what is named in French "Décret d'application d'une
>> loi" translated (Google as) "Enforcement Decree of Law", supplemented by
>> some rules for which I am fighting because of the reasons I explain in
>> my header message and develop here in the application meaning and reasons.
>>
>> In this :
>> When the functions are restricted even by changes in code or
>> installation restrictions,
>> 1- the version number should need to be a little altered (see farther
>> suggestion)
>> 2- the provider (service or distribution) must create a link (could be a
>> parameter in GNU/GPL products : text to display into a popup or url)
>> which would describe the changes or restrictions.
>>
>> Generally when there is a distribution of a GNU/GPL product they are
>> enhancements so this is practically always done, the author describe
>> what his provided by his enhanced version  but versus this is quite
>> never done when it is a free service which is provided.
>>
>> The free service offered around a main commercial service, always adds a
>> value to the main one to make his integration. Often there is an
>> automated install process, the product is not listed into the user
>> directory etc. The limit between free service and distribution is so
>> thin in this case (continuous cases between simple download as a mirror
>> and integration into a commercial product or services).
>>
>> So I fight to oblige these free services providers of GNU/GPL products
>> to deliver a product with all the functionalities operational and, if
>> not, have to redact the restrictions done.
>>
>> Practically this could be done, for example, by adding to version number
>> a keyword or simply a letter.
>> Details : [i.e. 3.3.5.F(ull) 3.3.5.r(estricted) 3.3.5.a(dd-ons)
>> 3.3.5.p(arametered). Some Combinations of the codes can be done as in
>> the "3.3.5.rp" sample]
>>
>> The rule is too to be applied when :
>> 1- parameters of the product can modify access to various functions and
>> particularly implement restrictions without changing the code
>> 2- the corresponding parameters can't be accessed by the common user
>>
>> As comment to my mail header, a sample of trick and deception :
>>
>> 1- I have been tricked because a service provider who offers HORDE as a
>> service but not full functionalities (The filters cannot transmit
>> mails). You can understand that in this case that many functions (most
>> of groupware) can't be operational (simply defined as useful functionality)
>>
>> 2- As I have just said to a client, after looking at the HORDE version
>> number, it is possible to... as a standard, my client has been upset
>> when I had to explain to him that we had to implement new mailbox on
>> another server... because it was not "true ?"
>> 3- Anybody will recognize that it is not possible to test each function
>> on a standard known product before saying "this function will be
>> available"...
>>
>> So this case leads to a real deception case, into the context of the use
>> of "HORDE" reference and "NAME". It can be very difficult to explain the
>> nature of the problem and the trick to some clients and it is not normal
>> that the consultant and/or opensource developer should be shown as the
>> responsible of such situations (which seems to be frequent).
>> The provider confirms that he has made no change but at the same time
>> says "the webmails are just setup for consultation ans sending mails"
>> and at the question which version of HORDE do you provide he answers :
>> 3.3.5... !!!
>>
>> For my own, I use, install, develop opensource into opensource teams and
>> make enhancements or changes for particular applications.
>> I always indicate into the header of footer "Application using .....
>> product GNU/GPL version :.... changes done in code and configured
>> parameters".
>> Into code I always add references to changes done.
>>
>> I think that we have to setup rules to avoid such situations.
>>
>> The incompetent or cheaters should be put out of harm's way.
>>
>> Best regards
>>
>> Trebly

> It might not be a violation of the GPL, but it could still be a violation
> of the Horde trademark to use the name "Horde" on a crippled version of the
> product.  But it all depends on the terms of Horde LLC's licensing of its
> mark.
>
> Mozilla restricts to a certain extent when the Firefox name can be applied
> to a browser based on its source code. Only unmodified distributions of
> official stable release's can be called Firefox.  If you modify it or if
> you distribute a beta, you can't call it Firefox or use the Firefox icon or
> other Firefox artwork.

Neither the Horde name or the Horde logos are trademarks, so there  
isn't much we could do, even if we wanted to.

It's always a tradeoff between having your logo prominently in the  
product to spread the word, and getting bad reputation because users  
confuse the Horde software with their e-mail or groupware services. I  
rather don't want to open that can of worms, especially since we  
simply lack the resources to take this on a legally safer ground and  
enforce our rights.

Regarding Bernard's discussion about modified GPL software being  
provided as a service without mentioning any modifications: this is  
difficult terrain. As you already noticed, there is a thin line  
between code modifications and configuration, especially in such a  
flexible product like Horde which has tons of configuration options,  
hooks, and other ways to modify it's behavior. Plus it integrates into  
unlimited variations of backend infrastructures, that also influences  
the product's behavior.
And finally, this isn't something we really have influence on, on the  
basis of the licenses we use. This had to be discussed in a forum  
explicitly dealing with Open Source licenses and their interpretation.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/



More information about the horde mailing list