> > Which BTW is quite hard to maintain, and can't be incorporated
> > into a commercial tool because of the POV license.  

>I've had a quick look through the source, and
> it doesn't really look that hard to maintain

	If you don't think so, why don't you go and fix
	the bug reported on povray.general under
	"Re: POV-file that crashes POV-Ray".  It's a 
	nice tangled one, from what I can see.

> After all, any file format is inherently proprietary

	To different extents.  One advantage with XML
	is that a parser can read any XML file, not
	just a particular variant.

> So I'm not sure what the difference here would be. I'm can't see how the
> POV licensing agreement would prohibit you from creating all the POV
> tools you wanted? 

	The POV license is much more restrictive than GPL or
	the BSD license.  

> since the people who use
> modeller's couldn't care less what language POV really used.

	I think if the modellers suddenly had the choice of
	taking their data from Rhino to Autocad to POVray and
	then back to Rhino, without any conversion process,
	they might regard it as a nice feature.  

	I think it's weird to claim that users of modelling
	packages don't care what format their data is in.                     
 
> So why not make a commercial library to parse POV? That would solve your
> problem

	No, we are talking about a way that POV can be parsed
	_without_ a special POV parser.

> > This is the whole point of XML.  You define the tags that are relevant
> > to your problem domain, specify this to the XML parser, and the rest
> > is mainly automatic.
> 
> Again, how is this any different than the existing POV parser?

	Because the POV parser is hard coded to parse POV, while an
	XML parser can be configured to read any XML based format,
	without programming.

> they are
> quite willing to provide the parsing libraries for an honest price. 

	Doesn't solve the problem of tracking each new version
	of POV, or automating conversion of old files, or
	handling extensions in a transparent way.

> I'm not sure I'm much of a fan of highly explicit structures, since they
> can easily become limiting and loose substantial flexibility. 

	Not true with XML.

> But POV is first and formost a rendering application. 

	POV is ONLY a rendering application.  There are
	good reasons that it should be more flexible.
	
> I don't see how any professional user's are shut out from using 
> POV? 

	Because I can't use it as a library, POV has zero
	commercial interest to me.  I'd also want to bypass
	the parser and populate the 3D scene from a Inventor
	style scene graph, without using files.  I'm shut out.

> The licensing agreement is not much different that the GPL licenses for
> Linux etc. 

	Yes it is.

> And just for a bit of a teaser, I am looking very seriously at using
> the POV parser in just this way! It means the end product will have to
> be completely open source

	I don't see the point of doing this, just to get around the
	POV license.

> I just have a very high disregard for people who
> think every body else should do all the work, then they should be able
> to recompile it and pocket all the profits. 

	Perhaps five years ago I could imagine the scenario
	(before the Internet) where someone could take POV,
	recompile it, put it in a fancy box, and sell it at
	the shops.  

> Well, pardon me for being so dense, but I can't seem to find them.
> Perhaps you could put togeather a formal list in some kind of point
> form?

	The first post to this thread I thought was very detailed.
 
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message