Chris B wrote:
> "Sabrina Kilian" <ykg### [at] vtedu> wrote in message 
> news:456b36c3@news.povray.org...
>> Chris B wrote:
>>> I therefore think we're probably down to picking from the list of 
>>> available
>>> Creative Commons licenses/certificates. Would anyone care to agree or
>>> disagree with that?
>> BSD and MIT licenses might also be an option, since they refer to source
>> code, which SDL is, and binary form, which the final images would be. I
>> didn't read them in their entirety, but I didn't see any references to
>> 'program' or 'executable' in there.
>>
> 
> These both seem good and short and I like the disclaimer, but they do seem 
> to me still to be oriented towards application code. They both speak of 
> software and although we could potentially draw parallels between software 
> and SDL and between binaries and generated images, it does seem a bit like 
> shoving a round peg in a square hole.
> To me the Creative Commons vocabulary, such as 'work' and 'derivative work' 
> seem to better fit what we create.
> 
>> www.opensource.org/licenses has several others that might work,
>> depending on their wording. The Academic Free License looks wordy but
>> seemed general enough to be used for everything.
> 
> There do seem to be quite a few  different licenses there to choose from. 
> Would anyone like to do some homework on those?

I've been trying to read one every few days, just to see what they read
like. So far, not much of a plot and no memorable characters.
> 
>> It seems like we are working backwards, going from established and known
>> licenses and taking out the parts we don't need. Let's start from the
>> ground and work up.
>>
> 
> Good point. I think this list gives us an excellent way to compare the 
> credentials of different licenses. I've tried to map the Creative Commons 
> licenses against this list and the Creative Commons Attribution Share-Alike 
> license seems to me to map pretty closely to what you've proposed.
> 
>> So, the issues I can think of are copyright, re-distribution of the
>> include, giving credit, commercial use, and re-distributing it under
>> another license.
>>
>> I don't think we can get rid of copyright. The person who writes each
>> snippet of code would still have the right to give it away, sell it, do
>> what ever they want with their piece of code.
> 
> Agreed. The original author would still have considerable rights, though 
> they could not subsequently sell it under any 'exclusive' distribution 
> agreement.
> I think this leads into an issue that Nemesis has eluded to, that the 
> release that we get the author to 'sign' when contributing the work under 
> the terms of this license would have to be in perpetuity, otherwise they 
> could change their minds later and cause no end of grief for people who had 
> developed derivative works.
> 

Define exclusive[1]. If it is exclusive from this point on, as in the
original author can not release the item again, then yes they could.

I also think there is a way around 'signing' anything. Look at the GPL
for example. If you modify a piece of code and release it back, it too
is GPL. Same works for CC- attribution and share-alike if it is a
derived work. The other way is to just ask them to put the text of the
license in the file they submit, or something like "This file is
licensed under SuchAndSuch, text found www.somewhere.com" No complicated
signing.

>> I also think that the
>> license should enforce the copyright notice in any re-packaged forms of
>> the include. It's a license for use, not a contract for sale of the items.
>>
> 
> This seems mostly consistent with the clause in the CC Attribution 
> Share-Alike license that "lets others remix, tweak, and build upon your work 
> even for commercial reasons, as long as they credit you and license their 
> new creations under the identical terms."
> I assume this would mean they could modify your include with the same 
> license on that include, but potentially a different license on other pieces 
> of their own work that they distribute it with. I don't think this would 
> stop them selling their work, which could include your work.

"license their new creations under the identical terms." I'd say that is
pretty clear that derivative works have to be under the same CC
Attribution Share-Alike. It can be released commercially, but the way I
read it all of it would have to be under the same license.

I don't think that the Collective Works clause would fit cleanly with
this. Collective Works "means a work, such as a periodical issue,
anthology or encyclopedia, in which the Work in its entirety in
unmodified form, along with a number of other contributions,
constituting separate and independent works in themselves, are assembled
into a collective whole." If a scene is made, and any piece of it relies
on something in the include, this license would force the entire scene
into the same license.

This is the same thing that would come up if we could use GPL for this.



> 
>> I also think the library as a whole should encourage giving credit to
>> the include and the author of the piece that is used, but I don't think
>> it needs to be a term in the license. It might be easier to use an
>> established license, but most of them enforce some display of copyright
>> being kept with the include file.
>>
> 
> The CC Attribution Share-Alike seems to cover that where they say they 
> should 'credit you'
> 
>> Now, re-distributing the entire include seems the easy part. Anyone who
>> downloads a copy should at least be able to pass it on under the same
>> terms they license they received it. I think they should also be able to
>> redistribute part of the include as well, since that would make
>> publishing scene code. I don't think it is necessary for this include to
>> force people using it to put any scene using it under the same license,
>> like the GPL would.
>>
> 
> From reading the CC Attribution Share-Alike, this seems to me to be covered 
> by the clause for Collective Works. I think that cutting and pasting into 
> another file would mean that the new file would have to come under the same 
> license (being a derivative work), but the original include or the 
> derivative work could be distributed as part of a group of files where the 
> other files come under different licensing terms.
> 

I disagree. It would take a lawyer to decide if making a function call
would fall into Collective or Derivative Works. The difference might
come down to how much of the scene it takes up. We could also just
re-define Collective Works to make using the library less tricky.

>> Stuff like the BSD and Creative Commons Attribution licenses would allow
>> them to then re-license it under any other license as well. That would
>> solve any problem with commercial use, since all someone would have to
>> do is re-license the library to them self under terms that would allow
>> it. If Pixar thinks we can make a better glass of water then they can, I
>> say we let them use it.
>>
>> What I don't like about the very open licenses is that ability to take
>> the entire library and bury it in another program without even a mention
>> of it being used. This gets back into the problem of distributing the
>> code vs distributing the final work, but I would prefer to see this
>> license keep the include free. I like the terms of the LGPL for this,
>> but I'm not sure it could be tuned to non-executable use.
>>
> 
> I think that the CC Attribution Share-Alike Clause 4c covers this quite well 
> by requiring derivative works, which presumably includes graphics generated 
> using your objects,  to include 'a credit identifying the use of the Work in 
> the Derivative Work (e.g., "French translation of the Work by Original 
> Author," or "Screenplay based on original Work by Original Author")' that 
> appears "where any other comparable authorship credit appears and in a 
> manner at least as prominent as such other comparable authorship credit".
> 
>> Finally, I did some more digging into GNU licenses and found the GFDL,
>> Free Document License. It would take more reading but it might be
>> possible to use something like that, similar to published computer
>> books. "The text (and whole library) is licensed under GFDL, and code
>> snippets (individual items or functions) are free to use in other
>> programs without attribution."  I haven't had time to really read it
>> yet, so that might not be possible, but now I'm going to check some
>> O'Reilly books to see how they word code licenses.
> 
> The next closest is the Creative Commons Attribution License which is a more 
> liberal license that just requires credit to be given for the work (and 
> derivative works where reasonable), but allows subsequent redistribution 
> under stricter licensing conditions. I don't think that the stricter license 
> could subsequently stop people using the copy from povray.org, but could 
> potentially prevent people from reusing some of the works derived from it.
> 
> Would anyone like to summarise how an alternative license maps to these 
> proposed requirements.
> 
> Regards,
> Chris B.
> 
> 

And we could end up with a lot of copies of the library under many
different licenses. Someone later could submit a piece of GPL code to
another archive of it, and anything added to the second one could not
move back into the main archive.

So, what do we want to see it licensed as? Ignore the legal terms for a
while, and let's figure out what we want it to be. Then we can figure
out which license will work.

[1]Legalese seems to have to define every word, I work under the
assumption that even something like 'a' could be defined to be an
elephant if the contract is drawn correctly.

Post a reply to this message

Hello again,

"Sabrina Kilian" <ykg### [at] vtedu> wrote in message 
news:456dfd09$1@news.povray.org...
>
> So, what do we want to see it licensed as? Ignore the legal terms for a
> while, and let's figure out what we want it to be. Then we can figure
> out which license will work.
>

Well I'm in favour of a very liberal license, so personally I'd be ok with 
the terms in the CC Attribution license or even the CC Public Domain 
Dedication (though, with the latter, as I understand it, each work would 
then need dedicating, which could be tedious for contributors). If we agreed 
to a more stringent license that afforded more protection to authors then I 
can always apply the more liberal terms to copies on my own web sites, so 
I'm not strongly opposed to a slightly more strict license either.

I think it's really picking a level that we feel won't deter potential 
contributors but that also won't stop the community from modifying and 
redistributing contributions, particularly back through this collection. 
Personally I'd prefer that they could modify and redistribute in other ways 
too (e.g. for profit), simply because I feel that people are more likely to 
invest their time in something where there's a prospect that they'll be free 
to use it in more or less any way they like in the future (but I can't prove 
that).

Regards,
Chris B.

Post a reply to this message

I'm really not particularly knowledgeable at the Creative Commons licenses,
being much more into open-source software licenses, particularly the GPL
and LGPL.  But from what i heard about CC they don't really seem to base
their licenses in copyright laws, instead trying to replace those with
something new.  While GPLed and LGPLed works are very much protected by
copyright law -- using it to effectively give the same rights to other
people -- it seems CC licenses are intended to replace copyright licenses.
I don't know how much protection authors take from their works under CC.
I'll have to take a look on it further... as of now, i'd go for a LGPL
license.

Sabrina, i don't think it'd be much of a problem if items from the
collection are licensed differently elsewhere, as long as we stick to what
we create here and other includes in the library only rely on stuff already
in there.  I mean, it doesn't matter that there is IronPython, Jython and
the likes:  the standard is CPython by the original author...

Chris B, you got me right.  If an author contributes work to the collection,
the license should provide a mechanism to ensure the contributed work is
there perpetually for use by anyone under the same rights it was originally
licensed.  Should the author change his mind, he can license further
modifications under other licenses and stop contributing it to povray if he
will, but can't deny others from using and modifying the original work in
the povray library.  He has to abide by the terms of the license and that's
why it should have such provision.

GPL licenses are famous for this fierce "freedom insurance"... :)

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> I think it's really picking a level that we feel won't deter potential
> contributors but that also won't stop the community from modifying and
> redistributing contributions, particularly back through this collection.

This thread has got the least attention from the others.  My guess is that
people either don't mind copyrights or mind too much to even consider
sharing their works under suspiciously named licenses with lots of boredom
legalese...

> Personally I'd prefer that they could modify and redistribute in other ways
> too (e.g. for profit), simply because I feel that people are more likely to
> invest their time in something where there's a prospect that they'll be free
> to use it in more or less any way they like in the future (but I can't prove
> that).

Just as a last complement, let me clarify this:  the free in "free software"
is freedom, not gratis.  There are big companies making money off
open-source software.

The LGPL is less intransigent than the GPL in that it allows LGPL libraries
-- like povray includes -- to be used by even proprietary closed-source
software without requiring such software to be licensed under the same
terms or disclosing the sources.  The only requirement is that if you
redistribute a *modified* LGPL code, you distribute the modification as
well.

So, if someone used a povray include under the LGPL, they wouldn't need to
distribute the source for the rendered image.  If they used it and changed
the include file itself a bit, they still wouldn't need to distribute their
scene file, only the modification to the original LGPLed include file.  Of
course, what is to be considered modification in the context of povray is
open to debate:  is simply scaling an include file provided object a
modification from the original?  I'd say not, but maybe someone could say
otherwise...

Point is:  if people want to sell their work and not disclose the creative
process they've taken, fine.  LGPLed include files wouldn't hamper it.

Post a reply to this message

My comments:

Creative Commons sounds useful and could be a way to go. I haven't looked at
what implications it has in detail though.

GPL would be out since anyone using a GPL'd include in their scene could
potentially then have to release their entire scene under the GPL. Whatever
license is chosen must not have the effect of coercing associated works into
the same license. LGPL might be a possibility.

For include files we basically (it seems to me) have several broad categories:

  a) Purely declarative includes, such as colors.inc;
  b) Functional (but still declarative) includes, such as for example
     a macro that given a location and time returns the position of the sun;
  c) 'Artistic' includes; by this I mean an include file that provides some
     sort of object, or a texture/material/etc. Basically something that we
     would categorize as more the work of an artist than a programmer.
and
  d) Combinations of the above - e.g. a tree growing include could be a
     combination of (b) and (c) above.

The reason I make this distinction is that traditionally art and code have
been considered different things and generally have different licences. In
POV-Ray, the two tend to merge since SDL is a co-ordinated blend of both art
and function.

It may be that there is no one existing license (other than POV's own) that
fits all our needs. However 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.

-- Chris Cason

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> The reason I make this distinction is that traditionally art and code have
> been considered different things and generally have different licences. In
> POV-Ray, the two tend to merge since SDL is a co-ordinated blend of both art
> and function.

yes and there lies its beauty. :)

> However in a pinch we could probably say that any POV
> source file is considered program code since SDL is what we parse,

actually, povray source includes code and data like any other programming
languages.  And data is content really external to code itself, like sounds
or images or, in this case, descriptions of images.  Source code in SDL --
with full control flow structures and even macros implementing clever and
complex algorithms and all -- is there just to make such artistic
descriptions possible.

So, yes, i'd say your distinction is spot-on and indeed mostly declarative
includes perhaps could be licensed with something like CC rather than
software oriented licenses...

Post a reply to this message

Chris Cason schrieb:
> [...]
> 
> It may be that there is no one existing license (other than POV's own) that
> fits all our needs. However 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 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

A good example for a scene element where this is certainly the case is a 
hand modelled mesh, like for example a Poser figure.  An example where 
this most likely cannot be assumed is something like a random placement 
system for objects - the resulting random positions which are the only 
thing still visible in the image are certainly not copyrightable.  But 
in most cases the situation is less clear and will even differ between 
states and copyright laws.

To uniformly handle all types of include file a special license would be 
needed that regulates any use of a file no matter how exactly the law 
sees this use.  One option that would not require designing a new 
license would be to use an existing one intended for programs (like the 
GPL) and explicitly exclude images made using the files from the 
restrictions of the license.  This would essentially allow unlimited use 
for creating images (including commercial use) but would still impose 
the license conditions on any modifications and distribution of the 
include file itself.

-- Christoph

Post a reply to this message

"nemesis" <nam### [at] gmailcom> schreef in bericht 
news:web.456e1f276ea74aa9b1e716f90@news.povray.org...
>
> "Chris B" <c_b### [at] btconnectcomnospam> wrote:
>> I think it's really picking a level that we feel won't deter potential
>> contributors but that also won't stop the community from modifying and
>> redistributing contributions, particularly back through this collection.
>
> This thread has got the least attention from the others.  My guess is that
> people either don't mind copyrights or mind too much to even consider
> sharing their works under suspiciously named licenses with lots of boredom
> legalese...
>

There might be another reason, and that is that it is not really easy for 
non-native speakers to fully appreciate the ins and outs of the legal 
language in English. It is already hard enough in one's own idiom. I am 
pretty sure that a lot of people here are deeply interested, but (like me) 
they got lost pretty fast, and 'scarred' to go further. It is good to have 
some people able to sort through this, and personally I deeply appreciate 
your efforts, but I feel too that I am not really able to contribute 
something really except by mumbling voicelessly :-)
Keep up the good work!! I think it is very important for many of us (silent) 
onlookers!!

Thomas

Post a reply to this message

"Thomas de Groot" <t.d### [at] internlDOTnet> wrote:
> There might be another reason, and that is that it is not really easy for
> non-native speakers to fully appreciate the ins and outs of the legal
> language in English.

hmm, but you speak even portuguese! :)

but yes, good point.

I hope that at least silent onlookers vote for or against the few licenses
we're able to sort out after these discussions.  I don't know, some kind of
poll so that we can get a taste of what the vast silent majority are
thinking about... since this is intended to be a collaborative project, i
don't think it's fair to simply impose a license based on what 3 or 4
people think is better...

Post a reply to this message

Chris B wrote:
> This seems mostly consistent with the clause in the CC Attribution 
> Share-Alike license that "lets others remix, tweak, and build upon your work 
> even for commercial reasons, as long as they credit you and license their 
> new creations under the identical terms."
> I assume this would mean they could modify your include with the same 
> license on that include, but potentially a different license on other pieces 
> of their own work that they distribute it with. I don't think this would 
> stop them selling their work, which could include your work.
> 
>> I also think the library as a whole should encourage giving credit to
>> the include and the author of the piece that is used, but I don't think
>> it needs to be a term in the license. It might be easier to use an
>> established license, but most of them enforce some display of copyright
>> being kept with the include file.
>>
> 
> The CC Attribution Share-Alike seems to cover that where they say they 
> should 'credit you'

I believe it says they *must* credit you. There is a difference between 
"should" and "must".

I'd be wary of forcing people to give credit. I'd say people should be 
strongly encouraged to give credit but not legally obliged to.

Sometimes people genuinely forget where they originally got code from 
especially if they've heavily hacked it. Also it would get very long 
winded and tedious having to give credit for every author of every item 
in a busy scene if each item was taken from the proposed library and 
each item had been repeatedly modified by different people.

Ideally people should give credit yes, it's disrespectful to the 
original author not to, but I'd not want to force hobbyist POV hackers 
to have to keep track of the provenance of every single line of code.

I'm not at all sure how you'd find, or write, a license that strongly 
encourages people to give credit for any significant contributions 
without forcing acknowledgment of everyone who's ever touched even a 
single line of code of the least significant object.

Sorry not a very helpful post - it seems rather negative, but I do 
really like the idea of an object repository and somehow making it *the* 
official repository. I also agree it would need a common licence.

Post a reply to this message