First: I'm so glad people are talking about this. Also, this is a long
message. Sorry.

I myself have tried to license the files I posted here in the newsgroups
with a CC-Attribution or a CC-Attribution-ShareAlike license, because, as
was mentioned above (by Chris?) the CC licenses were the only ones I found
referring to "works" as if they were pieces of art. Also, not being
particularly versed in legalese (nor wanting to spend the time to get
versed), the CC licenses seemed to me the easiest to understand.

Personally, I wouldn't care if somebody sold a poster on Zazzle that
*contained* an object/texture/macro that I included in this library, but if
the scene was *only* that object, or a trivial change of it, or was exactly
a demo scene included with the object, I would be a bit miffed. On the
other hand, I don't think I would be miffed enough to do anything about it,
so if the licence allowed that, I think it would be OK. I'll call this
Unmodified Zazzle-Gank.

I don't think we should use the GPL for this library because it's viral
nature would, I think, discourage more than encourage participation
(although I would like to see it for POV-Ray itself... is that the current
plan for 4.0?). From what I understand (which isn't much) the LGPL would
work fine too. I see SDL as easily definable code and the resulting images
as binary output.

my summary:

GPL http://www.gnu.org/licenses/gpl.html
  advantages: good, freedom-style viral license encouraging community
  disadvantages: hard to read, geared toward code (only?), probably would
discourage use by the widest audience, every change must be dated &
attributed for the code to be released again (maybe an advantage?), "The
GPL requires all copies to carry an appropriate copyright notice"

The current POV license doesn't really cover this kind of repository. It's
awfully specific: scenes in /SCENES (except /SCENES/INCDEMO) are under
complete control of the author unless explicitly noted otherwise.

LGPL http://www.gnu.org/licenses/lgpl.html
  advantages: good, freedom-style license encouraging community
  disadvantages: hard to read, applies to code (only?), may(?) permit
Unmodified Zazzle-Gank

CC-Attribution http://creativecommons.org/licenses/by/2.5/
  advantages: readable, applies to "works" rather than referencing code
  disadvantages: *requires* attribution IF the author says so (which may
discourage wide use)

CC-Attribution-SA http://creativecommons.org/licenses/by-sa/2.5/
  advantages: readable, applies to "works" rather than just code, encourages
community
  disadvantages: *requires* attribution as above, requires derivative works
to be released under same license(like GPL).

There used to be a CC license (I think SA 1.0?) which didn't require
attribution, but I can't find it now. I think it's deprecated.

BSD http://www.opensource.org/licenses/bsd-license.php
  advantages: simple, short, permissive
  disadvantages: requires copyright notice, may allow Unmodified Zazzle-Gank

Public Domain
  advantages: most permissive of all
  disadvantages: probably doesn't apply worldwide, almost certainly allows
Unmodified Zazzle-Gank

There's a crapload of other licenses at
http://www.opensource.org/site_index.php

Since I'm pretty fuzzy about all this, please feel free to correct me.
Looking at all this legal crap makes my brain cringe. Personally I would
favor a CC-Attribution license. It's permissive, and the only disadvantage
is the requirement for credit if the author so wishes, which I think is
pretty easy. Most of the other licenses require some kind of credit anyway.

I don't think we ought to write a new license just for this, but IANAL.

-Stefan

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> From my
> point of view, for an include to become part of the 'standard' repository,
> the use of the include must be free of restrictions, in much the same way as
> the current official includes are.

you mean, like as in "no attribution required" and "no viral source code
disclose required"?

You know, i'm kinda having this feeling that people will not be submitting
overly complex models or textures by fear of someone using it barely
modified and selling a poster at Zazzle.  But you know what?  That's ok.

That's ok because the purpose of the collection isn't to have the best of
the best of what povray is capable of.  Its purpose, as i see it, is to
have a minimally decent *and* useful include file library for povray from
the get-go.

Right now, povray include files have abstract things like math.inc or
functions.inc for the mathematically inclined who love fractals or just
want to quickly render a shape-perfect witch hat or pillow.  There's also
rune's make_grass and... oh, that's about it.  Pretty slim if you ask me.
Then, there are a few sample scenes which, while perhaps impressive some 10
years ago, do not show what povray can do very well.

Really, i hope this effort don't get people overstressed into trying to put
everything into the collection or wary of contributing anything.  Let's not
rely much on code donation -- which would help a lot i admit -- but instead
focus on collaborativelly thinking about what useful objects, textures and
macros would please most povray users and put them there!  It doesn't need
to be an overly detailed fridge, chairs from the 19th century Victorian era
or an incredibly detailed and greebled Star Wars Battleship.  Let's instead
focus on covering the basics and get it truly useful.

Besides, i don't know how some poor fellow will make any money off ripping
povray standard objects if anyone can render it and have the same idea...
it's much like photocopying the Mona Lisa and wanting to sell at
Sotheby's...

> NB I'd also suggest that, as a standard, all includes from the repository
> have a test in them like the following:
>
>   #ifndef (Attributed_Includes_OK)
>     #error "This include file requires attribution"
>   #end

This is a simple and effective idea to deal with it! :)

Post a reply to this message

Charles C wrote:
> Christoph Hormann <chr### [at] gmxde> wrote:
>> The central question this all leads to is if a rendered image is a
>> derived work of the scene (and all include files) it is generated from.
>>     I think (but IANAL) that for this it would be necessary that some
>> aspect of the scene/include files that is subject to copyright (usually
>> this requires a minimum level of originality and individuality) to be
>> still present in the rendered image.  How exactly this is defined
>> differs between Copyright laws - see
>> http://en.wikipedia.org/wiki/Threshold_of_originality
> 
> I hope this isn't too off topic... But speaking about copyright law, there's
> another angle which'll affect this library and it's licensing, and that's
> whether a contributer has the right to distribute models which are derived
> from real-world objects which in turn may or may not have applicable
> copyrights.  E.g. furniture, cars, buildings, houses, just about anything
> real that's man-made in the last century or whatever.   Can somebody please
> tell me it's ok to make a 3d model of a real table and then share it? :-)
> 
> Charles
> 
> 
> 

My understanding is you can, as long as the item you are copying does
not have it's image trademarked, copyrighted, or patented. I doubt you
will find that your dining room table is a trademarked design, but a
piece of designer art furniture might be. In that case, change an angle
or leave off a leg or a screw. Just remember that nearly everything can
be trademarked now days. Harley Davidson (motorcycle company) tried to
trademark the sound their engines make.

For anything else, photography law might help. You don't need[1] a model
release for anything that an average person would not be able to connect
to the thing you are photographing.

[1] Legal values of 'need' only. For the price of a sheet of paper and a
pen it's easy enough to get one.

Post a reply to this message

Chris Cason schrieb:
> You have a good point.
> 
> My position is that it is simply not reasonable for anyone who uses an
> 'official' include file to have to credit the author(s) of the include. I'd
> categorize an 'official' include file as anything that is provided with
> POV-Ray for the purpose (or officially endorsed as such).
> 
> Previously I have mentioned the possibility of having two repositories; the
> 'standard' one, and the 'ad-hoc' one (or some similar description). From my
> point of view, for an include to become part of the 'standard' repository,
> the use of the include must be free of restrictions, in much the same way as
> the current official includes are.

I think that is a good idea but note there aren't any regulations for 
the official include files concerning distribution of modified versions 
(except of course the regulations for distributing unofficial modified 
versions of the whole package).  Any separately distributed file should 
have clear terms for this.

-- Christoph

Post a reply to this message

I am currently at work, thus I have no much time to make a long post. I sum
up the guidelines of my opinion:

Preamble: The spirit of POV (and especially POV team and major contributors)
is "all for free"

EITHER: Contributors, once 'elected' to appear in the repository, should
comply to a de-facto "all for free" rule/copyright/license, like all
built-in or shipped-with stuff that comes with the distribution. Otherwise
it is no contribution, it is commerce. However, I find normal that people
whose work is published in the repository, after having followed the
contribution and developement process and election rules, should be
credited in some way. In this way, 'official' contributors's work is
considered as being part of the POV product (in a wide sense), like
standard includes do.

OR: People who want fame or sell their work have many means to do so (Zazzle
for instance), where all copyright/license aspects are well defined.

   Bruno.

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> schreef in bericht 
news:456f1a51$1@news.povray.org...

> I'm sure we can do this too. I think a lot of people will be keen to 
> donate stuff as a small way of saying thanks to the POV-Team for the great 
> work they do.


Absolutely true!!

Thomas

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:456ec2b6@news.povray.org...
> ... snip ...  in a pinch we could probably say that any POV
> source file is considered program code since SDL is what we parse, and as
> such a program-oriented license may be more suitable. But if so, not one 
> that
> refers exclusively to 'executables' since the includes aren't that.
>

The LGPL defines a 'library' as "a collection of software functions and/or 
data prepared so as to be conveniently linked with application programs 
(which use some of those functions and data) to form executables.". They 
also use the term 'executable' elsewhere when referring to things containing 
the library.

Does anyone know whether the use of the term 'executables' in this context 
would give us any issues if we used this license?

Regards,
Chris B.

Post a reply to this message

in news:456f0e52$1@news.povray.org Gilles Tran wrote:

> When I was looking for a license to distribute my SDL code some years
> ago, and after reviewing the various licenses available, I finally
> chose the Creative Commons "By Attribution" license. 

I have a strong preference for that one, as I find all the others limiting 
somehow.

Ingo

Post a reply to this message

I'll attempt to summarise the discussions from this 'licensing' thread so 
far and to draw some conclusions. It seems to me that we're moving towards a 
general consensus on the main issues, so if we can address any remaining 
concerns then we should hopefully be able to draw this part of the 
discussion to a close pretty soon. Please feel free to comment if you think 
I've got stuff wrong or if you just disagree with it.

The Plan.
---------
The intention is to have an area on povray.org where a collection of 
objects, textures and include files, contributed by the POV-Ray community 
can be held so that anyone can download and use them in their scenes. The 
area will be split into two main parts with (1) an 'ad-hoc' area for new 
submissions and (2) a 'standard' area where contributions adhere to certain 
standards and to a common licensing structure.

Before any author/copyright owner can submit a contribution they must 
confirm either (A) - that they authorise distribution under the common 
license, or (B) that they have included a clear definition of their own 
licensing terms in the work and a standard 'attribution-trap' in their SDL 
to make sure people can't use it without knowing that it has strings 
attached. Only work submitted using (A) - a common license - is eligible for 
consideration for promotion into area (2) - the 'standard' area.

The License
------------
The terms for the common license should be as liberal as possible. The main 
purpose being that the POV-Ray community can then freely enhance these 
contributions over the years without having to get permission from previous 
contributors who may now be uncontactable. It seems that we will probably 
need separate provisions for licensing the source and for licensing the 
resulting generated images.

The main candidate for a common license to cover the submitted Scene 
Description Language files and things like height field files and input data 
files, seems to be the LGPL (Lesser General Purpose License). This 
introduces the concept of a 'library' which is defined as "a collection of 
software functions and/or data prepared so as to be conveniently linked with 
application programs (which use some of those functions and data) to form 
executables.". This permits the library to be redistributed in original or 
modified form under the same terms. Paragraph 7 includes the statement "You 
may place library facilities that are a work based on the Library 
side-by-side in a single library together with other library facilities not 
covered by this License, and distribute such a combined library", which 
seems to me to be consistent with what has been discussed.

The text of the LGPL does seem complicated to me and includes statements 
that I don't fully understand the significance of, but the general spirit of 
the license seems in line with our intentions. Is there anyone out there 
with sufficient legal knowledge to advise on the detail of the LGPL and 
whether we're likely to run into any difficulties if we used it for SDL, 
height fields, data files etc?

The LGPL does not seem to me to explicitly cover images generated using the 
library. I think the discussions in the thread implied that we want images 
to become the property of the person using the files, as I believe is the 
case with files distributed under the includes directory of POV-Ray. I think 
we need to be explicit about generated images, otherwise I think it leaves 
the use of the files unclear. Maybe we could actually use the POV-Ray 
license for this by simply stating that generated images come under those 
same terms.

A potential alternative to the LGPL is the Creative Commons Attribution 
license which seems to be oriented more towards the artistic community. It 
allows modification and redistribution without forcing others to distribute 
derivative works under the same terms, but does include the provision that 
credit needs to be given to the author. The general feeling seemed to be 
that giving credit should not be an absolute requirement of the license. The 
LGPL seems to be the one favoured by most contributors to this thread.

Has anyone come across any other licenses that you believe would cover the 
requirements we've discussed any better than either of these?

Other Stuff
-----------
Authors can add comments into their work to describe the extent of their 
contribution. Also, if the copyright for the original work remains with the 
author, then I don't see any reason why they can't also include a copyright 
notice in the comments (alongside the license statement). Anyone using the 
contribution would be free to decide the appropriateness of maintaining the 
list of credits within those SDL comments. If we ever end up with a 5 line 
contribution containing 200 lines of credits, then someone can do a tidy-up.

We discussed a concern that someone could publish and make money out of our 
work without making any significant changes to our contribution and without 
giving us any credit, but the general consensus seemed to be that, although 
we may get a bit miffed and be a bit grumpy with our friends and family for 
a few days, we'll otherwise live with that.

One question open in my mind (because IANAL), is, if the image generated 
becomes the property of the user, is there any danger that someone could 
incorporate our works in a way that could prevent others from using it. For 
example, could they use the image of a contributed object as part of a 
trademark, or in an advert that associates the object with a well-known 
product and thereby constrains people from using anything resembling their 
trademark or any image that might be associated with their brand?'

 Regards,
 Chris B.

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> The License
> ------------
> It seems that we will probably
> need separate provisions for licensing the source and for licensing the
> resulting generated images.

hmm?  Why is generated image licensing a concern?  Just to draw an example
from programming languages and environments:  most, if not all, compilers
do not place any limitations on what kind of license the generated
binaries/executables should be under.  It means you can use a compiler
licensed under the GPL, say, GCC, and still license the generated
executable for your source code under some proprietary license of your
choice.

If someone puts limits in generated content from source code, isn't it as
bad as limiting the source code itself?  I'm not really aware of such
limitations in open-source software...

> The main candidate for a common license to cover the submitted Scene
> Description Language files and things like height field files and input data
> files, seems to be the LGPL (Lesser General Purpose License).

Reading through the discussion i was under the impression a majority of
people were inclined to go with CC licenses.  Perhaps it should be a good
time to start a Poll thread for the subject?  I myself would go for the
LGPL but have no problem with CC licenses if they are chosen.

> This
> introduces the concept of a 'library' which is defined as "a collection of
> software functions and/or data prepared so as to be conveniently linked with
> application programs (which use some of those functions and data) to form
> executables.".

read:
"a collection of SDL #macros/functions and/or #declares prepared so as to be
conveniently included with scene files (which use some of those
macros/functions and declares) to generate images"

> The LGPL does not seem to me to explicitly cover images generated using the
> library.

We're talking about include files here, not complete, final scene files,
right?  The LGPL differs from the GPL in that it permits source code
licensed under it to be used by other sources *without* requiring them to
be licensed under the same license.  It means someone may license a .pov
scene file using such LGPL includes under whatever license that meets their
needs.  Images generated using the include files are the same as executables
generated using the library.

Now, since we're talking about include files, not final scenes, i'm not sure
why the concern of licensing of generated images from the sources:  aren't
we contributing stuff to the collection precisely for them to be used
abroad?  Limiting them in this way doesn't seem helpful.

> I think the discussions in the thread implied that we want images
> to become the property of the person using the files, as I believe is the
> case with files distributed under the includes directory of POV-Ray.

the LGPL covers that, as seen above:  generated images are licensed to the
main pov scene file author's will.

> A potential alternative to the LGPL is the Creative Commons Attribution
> license which seems to be oriented more towards the artistic community.

To me, it seems better suited for complete, final, individual pov scene
files, perhaps ones appearing in demo sections of the web collection or
something.  The need for crediting everyone that ever worked in any little
line of code does not lead well for agressive collaborative efforts...

> Other Stuff
> -----------
> We discussed a concern that someone could publish and make money out of our
> work without making any significant changes to our contribution and without
> giving us any credit, but the general consensus seemed to be that, although
> we may get a bit miffed and be a bit grumpy with our friends and family for
> a few days, we'll otherwise live with that.

as i said previously, i wonder how much money a guy can make with stuff
freely available and easily reproductible -- like rendering demo scenes
from the collection and selling at Zazzle -- when anyone can have the same
idea for the same scene.

It's a collaborative effort that should benefit everyone.  I won't benefit
if i'm the only one contributing, but if others do it as well i'm sold!...

Post a reply to this message