> Can a programmer distribute this product (povray)
> with a seperate project that explains it uses povray to generate pictures
> (like logo) and not make money off it?
> Is it legal?
>
> JohnnyL

Basically, yes.

All that is required is a statement that POV is in your distribution (at 
install)
and that POV is free, and available from www.povray.org

There is no requirement that your software be free.

Post a reply to this message

"JohnnyL" <lut### [at] operamailcom> wrote in message 
news:web.457b747521612df63b3f2090@news.povray.org...
> Can a programmer distribute this product (povray)
> with a seperate project that explains it uses povray to generate pictures
> (like logo) and not make money off it?
> Is it legal?
>
> JohnnyL
>

Hi Johnny,

The license covering the distribution of POV-Ray softare is at 
http://www.povray.org/distribution-license.html.
I think you'd need to read clause 3 to answer your question.
Unless your plans come under any of the specific terms of that clause (e.g. 
3.1c - educational institutions), then I believe you would need to get 
written permission.

Regards,
Chris B.

Post a reply to this message

JohnnyL wrote:
> Can a programmer distribute this product (povray)
> with a seperate project that explains it uses povray to generate pictures
> (like logo) and not make money off it?
> Is it legal?

Unless POV-Ray is just an optional inclosure to your product (see 
distribution license 4.1.d.i-ii) you need to obtain a written permission 
by the POV-Team.  You can use the email address given in the license 
text to make such an inquiry.

The purpose of these regulation is to ensure the users of such a product 
are prominently made aware that POV-Ray is included with the product, 
provides parts of its functionality and is available for free.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 15 Oct. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

In article <elgnme$uu5$1@chho.imagico.de>, chr### [at] gmxde says...
> JohnnyL wrote:
> > Can a programmer distribute this product (povray)
> > with a seperate project that explains it uses povray to generate pictur
es
> > (like logo) and not make money off it?
> > Is it legal?
> 
> Unless POV-Ray is just an optional inclosure to your product (see 
> distribution license 4.1.d.i-ii) you need to obtain a written permission
 
> by the POV-Team.  You can use the email address given in the license 
> text to make such an inquiry.
> 
> The purpose of these regulation is to ensure the users of such a product
 
> are prominently made aware that POV-Ray is included with the product, 
> provides parts of its functionality and is available for free.
> 
> Christoph
> 
This one does bug me a tad. If you completely redid POV-Ray to make it 
an includable library, which had its "own" render window that "must" be 
used as the installed component, "can't" be hidden by the developer and 
which, as part of its initialization, automatically displayed a test 
render and a scrollable disclaimer, including a statement that this is 
not an original, etc., etc., would that "cover" the requirement?

The limitations of the current implementation make integration iffy, use 
frustrating and the results less than exciting. Its probably actually 
easier, if you know the math, to code a look alike product, than use 
POV-Ray as part of any sort of package, optional or not. And its 
certainly not too helpful in cases where removing it "would" break the 
product. Then again, trying to use Moray with "anything" other than POV-
Ray would break that too. Its only "how" they integrate that is the 
issue and how easily some change in the interface that "does" exist can 
break it that effects the rules. And, given how easy it was to break 
compatibility between Moray and the latest POV-Ray version, this is 
hardly a crowning achievement of POV-Ray development. lol

I mean, why "can't" you adjust the design for a specific task, making 
clear that this is "not" the original, as long as it still does what is 
needed to comply with all the notices. Is it only the presumption that 
any closer integration *can't* comply? All that's needed is something in 
the dialog function that makes it "ignore" or "reset" any attempt to 
change its "visible" property, until "after" a certain amount of time 
has passed or someone has scrolled through the disclaimers and clicked 
"OK". Same result as having it 100% external and throwing yet another 
application window over the top of everything when it starts. And again, 
if the point is to prevent people making POV-Ray a "dependent" part of 
their own application that is manditory, Moray is already basically 
breaking that rule as would any GUI modeler that only exports to and 
uses POV-Ray as its target renderer.

Point is, does the anti-library issue make sense, if sufficient 
requirements exist, to make sure that the "rest" is adhered to? Last 
time I sort of asked this the answer was an unsatisfactory, "No you 
can't do that because it 'would' somehow break the disclaimer 
requirements..." I don't get why that "must" be true at all. Non-
conformity is non-conformity, regardless of if some clown creates a 
library version then doesn't show any of that or they code some hacks 
into their own application like to do it:

run "povray"
a= findwindow "povray"
setwindowposition "a",nonvisible & minimized

They are still breaking the rules, no matter "how" they hide it. Why is 
hiding the whole thing with a hack "less" egregious than making it more 
integratable and failing to include a way to show the needed information 
in their own application? The argument against library design is just 
one of, "Its easier for someone to cheat.", not one of, "This way people 
can't cheat.", so I just don't get why its more of a problem. Hell, if 
anything, I could create the above hack in five minutes and have it 
working, compared to the days it would take to do what a lot of people 
would like to be able to.

Anyway. Hope you really think about what I am saying here and don't just 
come back with the usual, "You just can't do it 'period'.", argument. :p

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott schrieb:
> 
> This one does bug me a tad. If you completely redid POV-Ray to make it 
> an includable library, which had its "own" render window that "must" be 
> used as the installed component, "can't" be hidden by the developer and 
> which, as part of its initialization, automatically displayed a test 
> render and a scrollable disclaimer, including a statement that this is 
> not an original, etc., etc., would that "cover" the requirement?

I don't really see your point here.  The POV-Ray license requires a 
custom version to be a fully functional version of POV-Ray.  The reason 
for this is to prevent anyone from crippling POV-Ray to just perform a 
certain limited task.  The user who gets a custom version of POV-Ray 
should always be able to do everything possible with the official 
version as well.  For the same reason the license does not allow to 
disguise the fact that POV-Ray is used in a program system.

As far as practical problems of using POV-Ray in combination with other 
programs is concerned - you seem to be very focussed on the GUI versions 
of POV-Ray.  The license no way requires a distributed POV-Ray 
executable to have a GUI and in the Unix frontend the GUI/render window 
has always been optional.

-- Christoph

Post a reply to this message

In article <457e602e$1@news.povray.org>, chr### [at] gmxde says...
> Patrick Elliott schrieb:
> > 
> > This one does bug me a tad. If you completely redid POV-Ray to make it
 
> > an includable library, which had its "own" render window that "must" be
 
> > used as the installed component, "can't" be hidden by the developer and
 
> > which, as part of its initialization, automatically displayed a test 
> > render and a scrollable disclaimer, including a statement that this is
 
> > not an original, etc., etc., would that "cover" the requirement?
> 
> I don't really see your point here.  The POV-Ray license requires a 
> custom version to be a fully functional version of POV-Ray.  The reason
 
> for this is to prevent anyone from crippling POV-Ray to just perform a 
> certain limited task.  The user who gets a custom version of POV-Ray 
> should always be able to do everything possible with the official 
> version as well.  For the same reason the license does not allow to 
> disguise the fact that POV-Ray is used in a program system.
> 
> As far as practical problems of using POV-Ray in combination with other
 
> programs is concerned - you seem to be very focussed on the GUI versions
 
> of POV-Ray.  The license no way requires a distributed POV-Ray 
> executable to have a GUI and in the Unix frontend the GUI/render window
 
> has always been optional.
> 
Well, there was some level of confusion at one point when either I or 
someone else mentioned it. So.. If someone made an ActiveX enabled one, 
which can run stand alone or as a library, then as long as some method, 
like I mentioned, is employed to make sure people know its POV-Ray, then 
that is OK?

In other words, if it functioned exactly as it does now under Windows, 
but you could also call it with:

a = createobject("application.povray")
b = a.renderwindow
b.parent = me.frame
b.render ("myscene.pov")

Then, and this is where I am suggesting the means of compliance, you 
code the interface so that:

1. "renderwindow" cannot be resized smaller than needed to display the 
required licencing elements.

2. "renderwindow" connot be "hidden" until after those are displayed.

3. "a.render" will not operate at all, unless you have at least one 
instance of "renderwindow" in operation.

4. Possibly set of the initial license info display as something you 
have to do an "decline" or "accept" type thing on, so they have to at 
least look at it.

See, the idea is to both comply with the requirements, but also 
integrate the engine closely enough with what is going to use it that it 
is nearly invisible. Currently the only method to do that tends to be a 
tad flaky and became broken between versions. The idea is to provide an 
alternate wrapper, that provides complience, less obtrusive operation 
and better integration.

I would also, for my use, consider an additional optional "sandbox.ini" 
file, which would let you disable certain features, like radiosity, 
which might create excessive render times if used, so that, for my use, 
the engine **seems** to be limited to faster operations that allow 
closer to real time operation. I.e., scenes that take a minute or less 
to generate, not 30 minutes to 30 days, etc. However, editing the 
sandbox or even deleting it would "re-enable" anything disabled. Using 
it in "stand alone" mode would simply ignore the sandbox settings.

Point is, finding a way to comply with the requirements without breaking 
the rendering engine (and the rules) or recoding it, while "still" 
getting what you want out of it for the specific task you need it for.

The last few times anyone even suggested some sort of closer integration 
the answer wasn't, "If you make sure they know what it is and it does 
everything it normally would.", it was, "No you absolutely cannot." I 
want to know how flexible the rules really are and if you can comply, 
how ever convoluted the solution, without throwing the whole thing out 
as totally unworkable and starting from scratch. What I propose above 
would "seem" to me to make sense. I want to know if it does to the 
people that coded it.

NOTE: In case you are wondering, the idea is to, maybe, allow small 
scene files, dependent on local libraries of some pre-made stuff, to be 
sent by text based games, so that some level of 3D stills or simple 
animations would be possible. This mandates a sandbox that can 
"disable" things which, while nice for real renders, are time hogs 
otherwise. It also mandates some level of usable integration, which is 
barely possible when it works with the current method and not entirely 
practical for some uses. At the least it has serious issues with initial 
startup of the engine, which causes different problems depending on 
which starts first, as well as issues with multiple copies, either of 
the engine or of applications trying to talk to it. The existing method 
to solve it only partly addresses the issue imho, while real instancing 
of it as an object solves most of the problems, except the memory issue 
that then crops up.. But, its possible to allow one "stand alone" 
instance and one "object" instance or other permutations too, just not 
with it as it stands.

Mind you, I am buried in doing some other things at the moment, so the 
issue is mostly mute, for right now, but eventually I am going to have 
to either find out "if" the idea of viable or start trying to figure out 
how the heck to code one myself, should I start working on it again in 
the future. lol

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott schrieb:
> 
> Well, there was some level of confusion at one point when either I or 
> someone else mentioned it. So.. If someone made an ActiveX enabled one, 
> which can run stand alone or as a library, then as long as some method, 
> like I mentioned, is employed to make sure people know its POV-Ray, then 
> that is OK?

The source license is absolutely clear that it is not allowed to link 
POV-Ray (or parts of it) to another program (linking referring to the 
programming meaning of having another program directly call functions 
from the POV-Ray code).  You are free to extend the existing means of 
POV-Ray to communicate with other programs though as long as these 
extensions don't contradict the intent of the license.

> In other words, if it functioned exactly as it does now under Windows, 
> but you could also call it with:
> 
> a = createobject("application.povray")
> b = a.renderwindow
> b.parent = me.frame
> b.render ("myscene.pov")

I don't know the programming language this is written in but it pretty 
much looks like this functionality (i.e. starting a render and 
displaying the results) is supported by existing communication means of 
all official POV-Ray versions.  And if you for some reason don't like 
the existing means of doing this you can modify them to better suit your 
needs (you could for example add a feature to have the render results 
sent via some network protocol *).

I didn't really understand the rest of your posting (the 'sandbox' stuff 
etc.) - it seems to me you are talking about limitations of the POV-Ray 
rendering engine and not about the License.

*) note this is neither a legal advise not an official statement of the 
POV-Team, just my personal interpretation based on the fact that this is 
already possible indirectly via operating system mechanisms or separate 
tools.

-- Christoph

Post a reply to this message

In article <45810709@news.povray.org>, chr### [at] gmxde says...
> Patrick Elliott schrieb:
> > In other words, if it functioned exactly as it does now under Windows,
 
> > but you could also call it with:
> > 
> > a = createobject("application.povray")
> > b = a.renderwindow
> > b.parent = me.frame
> > b.render ("myscene.pov")
> 
> I don't know the programming language this is written in but it pretty 
> much looks like this functionality (i.e. starting a render and 
> displaying the results) is supported by existing communication means of
 
> all official POV-Ray versions.  And if you for some reason don't like 
> the existing means of doing this you can modify them to better suit your
 
> needs (you could for example add a feature to have the render results 
> sent via some network protocol *).
> 
Well, its not "quite" the same. ActiveX has advantages that static 
methods don't. But, its nice to know this is allowed, though it gets a 
bit more complicated. Technically an ActiveX wraps the whole 
application, not just an extension loaded into it, which is what the 
current system does. Still, its nice to clear up how and if that was 
acceptable. Now, some others may have "intended" something like this, 
but described it wrong, thus creating confusion that led to them being 
told "No, you can't do that." Needless to say, this confused me a bit, 
since I didn't see how a more stable method (at least more stable on 
Windows) was a "bad" thing.

> I didn't really understand the rest of your posting (the 'sandbox' stuff
 
> etc.) - it seems to me you are talking about limitations of the POV-Ray
 
> rendering engine and not about the License.
> 
Well, in some ways it "is" about the license. The license says clearly 
that you can't provide an incomplete and partially functional version. 
This idea is intended to side step that.

Let me explain. A client application I use also uses Lua and a 
"sandbox". This is done to limit and safeguard the machine from code 
that "might" be dangerous. Since the scripts are created by the clients 
users and tied to a set of plugins, someone could add dangerous code to 
a plugin, which the other users would never know about, while thinking 
they got something that provides beneficial features. For example, the 
IO library functions. In Lua you can declare your own functions that 
override the "existing" ones, so the solution to preventing something 
from adding code like this:

io.run "del c:\windows"

is to place, in the "sandbox" a function like:

def function io.run {
}

When anyone tries to execute the io.run function in a script the 
"sandbox" version is called, which doesn't do anything.

Now, the idea for POV-Ray would be a bit different. Lets say I dont' 
want anyone using Isosufaces at all and I want to "restrict" the use of 
reflection with refraction, since those things tend to cause serious lag 
in scene generation. And maybe also limit mesh sizes to reduce render 
times. The sandbox.ini might look like:

[forbid]
isosurface
[limit]
mesh:10000
[restrict]
reflection:ior

When run normally the sandox it ignored entirely. When used from the 
activeX connection it would look at the sandbox and a scene that 
contained these would generate errors and refuse to produce the scene if 
you violated any of those rules. The engine and the normal environment 
would still be 100% functional, but limits could be placed on what could 
be done through the activeX connections.

The reason this is a licensing issue is that it technically allows you 
to provide an partially disabled version, within the limits of how you 
are using it, while *still* providing a complete version, when used as 
though it was just the stand alone version. Think of it like a more 
complex version of the render level commands, which let you decide what 
things the engine should "not" render, when doing test renders. Though, 
I suppose, since that already exists, this is just a more specific form 
of the same thing.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
>
> Well, its not "quite" the same. ActiveX has advantages that static 
> methods don't.

Well - since you don't give any concrete example here this is difficult 
to comment on.  Note however that apart from license issues any such 
non-portable approach would be

> [...]
> 
> The reason this is a licensing issue is that it technically allows you 
> to provide an partially disabled version, 

No, see 2.2-f of the source license:

"If that directive is not present, the Modified Version must work in the 
same way as the Licensed Version."

Any unofficial version should by default work exactly like the official one.

Now what you described is just an extension of the quality switch in 
POV-Ray.  Nothing prevents you from implementing this *inside POV-Ray* 
(if it is turned off by default).  You can also pre-process a scene with 
a separate program to disable certain parts.   But having an external 
hook to switch POV-Ray into an incompatible, crippled mode would violate 
the above part of the license as well as section 1.6:

"[...] Modification to these APIs or other officially supported 
communication mechanisms (or the addition of any new code or feature) 
for the purpose of avoidance (or to assist others to avoid) the intent 
of this or any other POV license is expressly prohibited."

Once central purpose of the POV-Ray source license is to avoid 
modifications of POV-Ray to impose limits to the users concerning their 
use of POV-Ray.

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 15 Oct. 2006)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

In article <em35ps$uuv$1@chho.imagico.de>, chr### [at] gmxde says...
> Patrick Elliott wrote:
> >
> > Well, its not "quite" the same. ActiveX has advantages that static 
> > methods don't.
> 
> Well - since you don't give any concrete example here this is difficult
 
> to comment on.  Note however that apart from license issues any such 
> non-portable approach would be
> 
> > [...]
> > 
> > The reason this is a licensing issue is that it technically allows you
 
> > to provide an partially disabled version, 
> 
> No, see 2.2-f of the source license:
> 
> "If that directive is not present, the Modified Version must work in the
 
> same way as the Licensed Version."
> 
> Any unofficial version should by default work exactly like the official o
ne.
> 
> Now what you described is just an extension of the quality switch in 
> POV-Ray.  Nothing prevents you from implementing this *inside POV-Ray* 
> (if it is turned off by default).  You can also pre-process a scene with
 
> a separate program to disable certain parts.   But having an external 
> hook to switch POV-Ray into an incompatible, crippled mode would violate
 
> the above part of the license as well as section 1.6:
> 
> "[...] Modification to these APIs or other officially supported 
> communication mechanisms (or the addition of any new code or feature) 
> for the purpose of avoidance (or to assist others to avoid) the intent 
> of this or any other POV license is expressly prohibited."
> 
> Once central purpose of the POV-Ray source license is to avoid 
> modifications of POV-Ray to impose limits to the users concerning their
 
> use of POV-Ray.
> 
Hmm. Well, its a bit of  gray line in this case. The purpose of 
implementing such a limit is to "hopefully" automatically apply limits 
that prevent parse times or render times that would exceed any 
reasonable time limit. If you are looking at a game that incorporates 
this as a rendering system, but you don't *absolutely* need "real time", 
which isn't practical, as in, 30 seconds to "at most" a minute thirty. 
Allowing things that in combination are "certain" to produce longer 
times is not a great idea. Mind you, one could simply leave it entirely 
open and let the scene maker deal with how to decrease the render and 
parse times.

In principle the sandbox is just another ini. Its one "specific" to the 
this implementation as a inlined rendering engine, but not "required" by 
the program in any other context. Ironically, your argument seems to 
imply that adding it as something that works in "all" contexts is more 
acceptable, since it becomes a "rendering setting", than when limited to 
one specific use?

Ok, how about this. Allow the sandbox to act like that, but instead make 
the ActiveX command have two forms:

pov.render ("myscene.ini") - Functions just like the "existing" 
interface.

or

pov.render ("myscene.ini", False) - Functions as above.
pov.render ("myscene.ini", True) - Uses the sandbox limits.

Its just extending the capabilities then, even in the interface, since 
the default behavior is "indistinguishable" from the normal one, right?

****

In principle, one option going to the issue with ActiveX vs. other 
methods, you can do with ActiveX one thing you "can't" with the existing 
method, even if it is platform independent. With ActiveX I could have 
open (presuming I didn't mind the lag and memory issues):

1. Regular copy, rendering a big file.
2. ActiveX instance that is generating an image with low render 
settings.
3. ActiveX instance that is generating a longer render time version of 
2, along with other queued images, with higher quality settings.

and, I don't have the "keep single instance because the program running 
both version 2 and 3 can't tell who they hell they are talking to. I 
understand that "is" an issue with the current system, which is why 
Moray requires you run it only in "single instance" version. There is no 
way for the OS, the program making the calls, etc. to "know" which one 
it is dealing with. ActiveX has one big advantage in that each instance 
is uniquely identified in the OS. And, just to be clear, while this may 
not "technically" be cross platform, there are implementations of things 
like Mono that "are" available under Linux and support the same sort of 
unique identification and instancing systems. While it may have been 
true in the past that there was no "better" option, this isn't exactly 
true now.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message