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

Tue Oct 30 11:37:09 UTC 2012

Le 26/10/2012 16:40, Jan Schneider a écrit :
> 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.
> 

I have no authority, but I completely agree with both the comments of
Stuart and the synthesis of Jan.

For my own and for action I would propose :
___________________________________________
1- Open a discussion with as aim to list the content we could wish to
add at the licenses. For this, I have made and listed here some simple
proposals and the steps :
    	- Define what we could wish
	- Define which one and how to add a parameter (add in software) , with
his syntax, which would be  added to the version number when changes
and/limitations are done.
	- Draw up a simple text (fifteen lines) as summary of recommendations
to distributors (any type) about use of name of HORDE (complements as
"built on", "built with", "restricted installation", "with add-on") and
description of the normalization of version number use (extension of my
proposal... ?)

2- Execution
    1- Add the text to the license joined to the product and eventually
somewhere else with the title "recommendation and wishes of HORDE team"
about the implementation of the product.
    2- At same time add the parameters for version number with open text
for the comments of the author of the implementation
    3- After a while, time for reactions, begin lobbying, using the
preceding steps done, to GNU/GPL (aims : discussion of a text, vote the
addition of this text as optional complement of GNU/GPL, text , at
first, limited to "recommendations" in the application of the license)

Is it too heavy ?

Best regards

Trebly (nickname on net for Bernard TREMBLAY, on lists use of Bernard or
Trebly)