Re: [Config4gnu-developer] why not GPL?

[Justin Y. <ju...@sk...>]

On Wed, 12 Nov 2003 10:53:54 +0100 (CET)
p.c...@ar... wrote:

> And the main question now is:
> Should proprietary commercial applications for system administration
> be allowed to manage configurations through CFG or should they have to
> figure that out for themselves, with the money they charge.
>
> Maybe just think of Distribution specific Tools like the Yast
> Configuration Tools from newly aquired "Novel @ SuSE". Such special
> Tools are not free, and undermine the free development of a widely
> used configuration system.

Well, here's my only remaining issue with that.  A commercial app isn't going to benefit much by using CFG to read in its configuration, so I don't think thats much of a big deal either way in that regard.  As for front ends, I believe that CFG's frontends should be GPL'd, because they're not libraries, nor are they things that commercial apps should depend on, link against, etc.  

The only thing I think we might want to avoid is a vendor making CFG support their app by creating the proper meta-data for it and maybe a parser.  It would be "bad" if they then made their own non-free GUI that used CFG to manipulate that data.  

HOWEVER, they would have by default added support for their app in ALL of CFG's GUIs.  This is *very significant*, and would give CFG much more use.  If a vendor was able to use CFG to both read their config in their actual app and via some customized GUI, then fine, because by definition if they can do it so can all other apps and GUIs.  *IN FACT*, it would make it possible for people to use CFG to 1) convert/use their config for that non-free app as config for an open source app, and 2) provide a very structured interface into their config for various other uses (automated scripts, installs, etc.).  

I think that failing to encourage vendors to use CFG is a critical error.  What I would suggest is keeping CFG's core under the LGPL, making the UI's (command line, web, graphical, etc.) GPL, and finding some creative way to force vendors to distribute their meta-data files.  
The trick is how to do this without scaring them off.  One idea I've had before is to create a central repository where CFG can go when someone says "I want to configure Samba 3.56.2a".  CFG would go to this central website and automagically install the necessary meta-data, load it, and voila, it is now supported.  This would greatly vendors/authors to put their stuff on the central repository.

There are still some issues if the vendors think that their meta-data is some secret or whatever.  Does anyone have any ideas on how to get around this or find some middle ground so the meta-data is published in some way but vendors are happy?
 
Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com