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

Tue Oct 30 12:41:22 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.
> 
> 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)

I'm just curious; what's is the benefit here? I don't see how this would positively affect Horde. Vice versa, it will only add unneeded complexity and burden dealing with software implementation as a service. Which, one could argue, always was one of the main Horde moving drivers.

As others already pointed out, GPL license doesn't cover the level at which software as a service should be implemented. What is "crippled version of Horde" anyway? The version which doesn't send email? But it's completely for service provider to fix these kind of bugs. And if they don't want to do it - fine. Just choose another service.

One also could argue that this negatively affect Horde name. But as Jan pointed out, it's not a trademark or anything legally described. Moreover most users are conscientious at service level anyway these days.

>From where I stand, I don't see a problem at all.

-- 
   Vilius