 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
This is an offshoot from the thread "povray standard include files" to
discuss licensing, copyright and release authorisations. The idea 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 (potentially with certain constraints,
as defined by a license).
I should start by saying that I'm not an expert in this field.
Warp explained that there's no fireproof way of explicitly placing work into
the public domain (or at least, none that works effectively under all legal
systems). Also, whether the originator of a piece of work explicitly claims
copyright or not, they still retain rights over that work, including rights
to decide who can reproduce the work and how. The copyright owner can give
rights to others through a license or a release.
If I understand correctly, a release is simply a statement that you've
genuinely got the right to license something and that you're willing to do
so. In this context it could be that, when you submit something for
distribution on the povray server that you state that you understand the
origins of the content, that you do have distribution rights and that you
are happy for that work to be distributed (in accordance with the terms of
distribution covering the collection). I therefore think the release will
probably be a standard piece of text that you can copy into a note
accompanying a submission to the collection.
I think that licensing is the thing that needs most discussion. One option
is for each person to define their own license and include information
within their submission about the terms of their license. Personally I think
this would be a minefield for people wishing to use the files and I don't
think it would really differentiate this collection from the many assorted
files available around the Internet.
I would rather see a standard license that would cover this entire
collection and I think the main candidates are:
o The POV-Ray license
o A Creative Commons License (see
http://creativecommons.org/about/licenses/meet-the-licenses)
o Creative Commons Public Domain Dedication
(http://creativecommons.org/licenses/publicdomain/)
o A custom license covering this collection
My view is that having an area on povray.org where all of the contributions
can be re-used without any preconditions (or with a very minimal agreed
standard set) would be good for POV-Ray and would make an important
differentiator for this collection over other object and include file sites.
This would also mean that the POV-Ray community could freely enhance these
contributions over the years without having to get permission from previous
contributors who may now be uncontactable. The downside is that it may
discourage some contributors from submitting their work.
Any thoughts/ideas welcome.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Let me begin by telling this is a very good follow up on the previous
discussion. :)
"Chris B" <c_b### [at] btconnect com nospam> wrote:
> I think that licensing is the thing that needs most discussion. One option
> is for each person to define their own license and include information
> within their submission about the terms of their license.
I believe this would be too cumbersome and eligible to many legal nitpicks.
> I would rather see a standard license that would cover this entire
> collection
me too!
> and I think the main candidates are:
> o The POV-Ray license
the problem with this one is: wouldn't we fall into the same problem we
have with povray license today, where people who previously contributed
code to povray itself are unreacheable and thus the license has to remain
the same until the planned 4.0 rewrite? I mean, if i submit a povray scene
which comes included with povray and is licensed under the current povray
license, will it be able to be included in next povray releases in case of
license change that reveals itself conflicting with the previous license?
Unless we explicitely stated that the scenes are licensed under current or
future povray licenses.
> o A Creative Commons License (see
> http://creativecommons.org/about/licenses/meet-the-licenses)
> o Creative Commons Public Domain Dedication
> (http://creativecommons.org/licenses/publicdomain/)
This could be nice, specially since they're stabilished liberal licenses
that exist well outside of povray's realm. I would also put the GPL or BSD
licenses under consideration. The BSD is the classical liberal license,
allowing the code to be used for any purposes, by anyone. The GPL is the
one conclaiming people modifying GPLed code to also distribute the
modifications IF redistributing the modified binary. In the case of povray
scenes, i guess if people modify a pov scene and distribute the modified
generated jpg or png, they should also distribute the modifications to the
source scene file. I don't know how compatible the GPL is to the povray
distribution so that eventual GPLed include files could be distributed with
it.
> o A custom license covering this collection
i'm really against Yet Another License For The Sake of It...
> My view is that having an area on povray.org where all of the contributions
> can be re-used without any preconditions (or with a very minimal agreed
> standard set) would be good for POV-Ray and would make an important
> differentiator for this collection over other object and include file sites.
> This would also mean that the POV-Ray community could freely enhance these
> contributions over the years without having to get permission from previous
> contributors who may now be uncontactable.
In other worlds, kind of the typical open-source project source repository.
This sounds really nice. And should sound nice to povray maintainers as
well, since code contributions for povray includes eventually getting into
the distribution itself would be maintained by the community themselves. :)
> The downside is that it may
> discourage some contributors from submitting their work.
I don't believe it would discourage people any more than today when no such
provision exists and it would even clarify legal issues so everyone would
benefit.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
nemesis wrote:
> "Chris B" <c_b### [at] btconnect com nospam> wrote:
>> I think that licensing is the thing that needs most discussion. One option
>> is for each person to define their own license and include information
>> within their submission about the terms of their license.
>
> I believe this would be too cumbersome and eligible to many legal nitpicks.
>
>> I would rather see a standard license that would cover this entire
>> collection
>
> me too!
me three
I have different opinions about how the includes and scenes might be
licensed. For clarity, I think of includes as collections of single
objects, textures, macros, lighting patterns, just about anything made
mostly of #declares and meant to be reused. Scenes would be the
individual artistic expression, possibly made up of items from the
include. Clear as mud, and probably open to legal nit-picking.
>> and I think the main candidates are:
>> o The POV-Ray license
>
> the problem with this one is: wouldn't we fall into the same problem we
> have with povray license today, where people who previously contributed
> code to povray itself are unreacheable and thus the license has to remain
> the same until the planned 4.0 rewrite? I mean, if i submit a povray scene
> which comes included with povray and is licensed under the current povray
> license, will it be able to be included in next povray releases in case of
> license change that reveals itself conflicting with the previous license?
> Unless we explicitely stated that the scenes are licensed under current or
> future povray licenses.
>
The way I read things, scenes are not licensed for re-use unless they
are in the incdemo folder. I don't know where to look to see what the
terms of donating a scene are.
While the includes could easily be added to POV-Ray, probably without
changing the license by just adding them into the INCLUDE folder, I
don't know that any scenes could be. Legalese isn't even my second
language, but the usage provisions seem to say that anything in
scenes/incdemo is free to reuse or distribute, while the other scenes
are not. There doesn't seem to be much middle ground available. Either
the new includes would have to be added to the normal package in the
proper folders, or the POV-Ray license would have to be changed /
rewritten to account for the packaged includes being distributed outside
of the normal package. That would fall into the Yet Another License
category.
>> o A Creative Commons License (see
>> http://creativecommons.org/about/licenses/meet-the-licenses)
>> o Creative Commons Public Domain Dedication
>> (http://creativecommons.org/licenses/publicdomain/)
>
> This could be nice, specially since they're stabilished liberal licenses
> that exist well outside of povray's realm. I would also put the GPL or BSD
> licenses under consideration. The BSD is the classical liberal license,
> allowing the code to be used for any purposes, by anyone. The GPL is the
> one conclaiming people modifying GPLed code to also distribute the
> modifications IF redistributing the modified binary. In the case of povray
> scenes, i guess if people modify a pov scene and distribute the modified
> generated jpg or png, they should also distribute the modifications to the
> source scene file. I don't know how compatible the GPL is to the povray
> distribution so that eventual GPLed include files could be distributed with
> it.
>
I think that 'distributing' would need to be clarified a little with
regard to images. Is hosting a jpg of a GPL scene distributing? Is
printing a hard copy of a scene, which is a derivative of a binary
representation, distributing if it is given to someone else?
I'd be more partial to an LGPL style license for any includes, over the
normal GPL, for reasons like the following. If someone creates a scene
using one of the proposed new includes, which could be anything from
vector transforms to colors to anything else, when would they need to
provide access to the source of the scene? If they hosted it online, or
ran off a hard copy that they sold, or had Zazzle sell copies of it? If
the scene is theirs, why would the include need to affect the license of
the final scene?
For scenes I think I would prefer stricter terms. I know I would be
annoyed to see my scenes turn up in someone else's Zazzle store unmodified.
>> o A custom license covering this collection
>
> i'm really against Yet Another License For The Sake of It...
Some derivative of the normal POV-Ray license, possibly co-licensed
under GPL or LGPL or anything else, would not quite be 'Yet Another
License' but might cover all of the bases. And it might allow for what
ever license change takes place with 4.0 or later.
>
>> My view is that having an area on povray.org where all of the contributions
>> can be re-used without any preconditions (or with a very minimal agreed
>> standard set) would be good for POV-Ray and would make an important
>> differentiator for this collection over other object and include file sites.
>> This would also mean that the POV-Ray community could freely enhance these
>> contributions over the years without having to get permission from previous
>> contributors who may now be uncontactable.
>
> In other worlds, kind of the typical open-source project source repository.
> This sounds really nice. And should sound nice to povray maintainers as
> well, since code contributions for povray includes eventually getting into
> the distribution itself would be maintained by the community themselves. :)
>
>> The downside is that it may
>> discourage some contributors from submitting their work.
>
> I don't believe it would discourage people any more than today when no such
> provision exists and it would even clarify legal issues so everyone would
> benefit.
>
>
>
Having a defined set of rules and requirements might encourage people to
reuse some code instead of reinventing it. As it stands right now, I
hesitate to go through the posted scene files looking for things similer
to anything I am working on. Since only a few that I've seen have
licenses in them, I would believe that all the rest are not licensable
and I wouldn't want to accidentally reuse some little trick or function
I happened to read. While I don't think most people here would fuss over
a simple texture on one rock in a scene, someone might and it's just
easier to reinvent everything.
And if the rules allow or require changes to get put back into the
repository, then we might even end up with better results since things
could be built up instead of reinvented.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
whoa! thanks for commenting, Sabrina. good to see women using povray as
well. Specially as intelligent and skillful as you seem to be. :)
Sabrina Kilian <ykg### [at] vt edu> wrote:
> For clarity, I think of includes as collections of single
> objects, textures, macros, lighting patterns, just about anything made
> mostly of #declares and meant to be reused. Scenes would be the
> individual artistic expression, possibly made up of items from the
> include. Clear as mud, and probably open to legal nit-picking.
That's a very good definition, i believe everyone will agree.
> I don't know where to look to see what the terms of donating a scene are.
I think that's what we're trying to accomplish here.
> Either the new includes would have to be added to the normal package in the
> proper folders, or the POV-Ray license would have to be changed /
> rewritten to account for the packaged includes being distributed outside
> of the normal package.
AFAIK, povray license is likely to change in coming versions, am i right? I
heard they're seeking to put it into an OSI-compliant license.
Anyway, i don't think this reworked include collection would go into the
standard include folder as the legal terms stand today.
> Is hosting a jpg of a GPL scene distributing?
I think if users are able to download and save an image to their PCs, it's
like software they can download and use. OTOH, has you ever seen a GPLed
web site or web service? I mean, yes, we can see the *generated* html
content, but not the actual PHP sources or something like that...
> Is
> printing a hard copy of a scene, which is a derivative of a binary
> representation, distributing if it is given to someone else?
I realize it was better in the good ol' days. Too much legal obfuscation
these days... I wish povray scenes could be licensed under a poetic
license or artistic license, like perl... ;)
> I'd be more partial to an LGPL style license for any includes, over the
> normal GPL, for reasons like the following. If someone creates a scene
> using one of the proposed new includes, which could be anything from
> vector transforms to colors to anything else, when would they need to
> provide access to the source of the scene? If they hosted it online, or
> ran off a hard copy that they sold, or had Zazzle sell copies of it? If
> the scene is theirs, why would the include need to affect the license of
> the final scene?
Very good point, much more well reasoned than mine (i was busy at work and
didn't give too much thought to details).
Indeed, the LGPL is much more well suited for library components. And it
still retains the GPL benefit of people changing the LGPLed work itself to
contribute back the changes. Note this doesn't affect people merely using
such works in a scene, they can indeed hide the sources without problems.
And if their scene use a slightly modified LGPLed work, the only
requirement is to publish the modifications to the GPLed work, not to the
whole scene!
> For scenes I think I would prefer stricter terms. I know I would be
> annoyed to see my scenes turn up in someone else's Zazzle store unmodified.
fair enough.
> Having a defined set of rules and requirements might encourage people to
> reuse some code instead of reinventing it. As it stands right now, I
> hesitate to go through the posted scene files looking for things similer
> to anything I am working on. Since only a few that I've seen have
> licenses in them, I would believe that all the rest are not licensable
> and I wouldn't want to accidentally reuse some little trick or function
> I happened to read. While I don't think most people here would fuss over
> a simple texture on one rock in a scene, someone might and it's just
> easier to reinvent everything.
well, if you ever need a potato texture or detailed brick wall texture and
happens to find some of my old scenes, feel free to use them! When such
collection area is up on povray.org, i'll republish with the chosen proper
license... :)
> And if the rules allow or require changes to get put back into the
> repository, then we might even end up with better results since things
> could be built up instead of reinvented.
Yes, but i've realized many people here are highly creative artistic minded
people who indeed enjoy creating things from scratch. Still, might be
useful for other people interested in composition rather than creation.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
To summarise the discussions so far on defining a license for an area on
povray.org to hold collections of objects etc.:
We seem to have 100% vote for adopting a single license for the whole
collection (3 out of 3).
Similarly all seem keen on making the collection as open to re-use as
possible.
It sounds like the POV-Ray license would not be able to cover this
collection without modification.
I'm not sure that the GPL or LGPL licenses are all that appropriate because
they contain a lot of terminology that is exclusively oriented towards
software/programs rather than works of a creative or artistic nature (no
offence to application developers intended). I think this was probably why
the Creative Commons Licenses came into being. The reproduction and
distribution of images and computerised descriptions of scenes can throw up
unique issues, such as, when is an image a reproduction and when is it a
representation of the original work? (i.e. is a thumbnail a copy or can it
reasonably be used in an index or search engine).
Unless we can enlist the help of a licensing Guru then rolling our own is
probably out of the question.
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?
To move on into some of the detail:
On the subject of scene files, I didn't necessarily see this as being a
place where finished scenes would go, although samples and example scene
files could accompany objects, textures, macros and include files to
illustrate their use. I would argue that there are other forums where fully
finished and refined scenes can be maintained including the IRTC and various
Internet galleries, POV-Ray rings etc.
If an image is rendered from a sample scene file and sold on Zazzle or to
the Tate Gallery, then I would propose that we have no more access to the
cash than the guys who made the pile of bricks that the Tate Gallery bought
for a wheelbarrow full of money a few years back. The money goes to the
artist who makes the sale. In any case, if very minor changes could get the
artist/charlatan out of trouble, then, would the addition of a corporate
logo to your pride and joy really make you feel any better?
The other issue raised by Sabrina and Nemesis is around whether users of the
collection should be required to contribute their work back to the
collection. My vote is that we don't impose such a restriction. Personally
I'd like to see a license that's about as close to public domain as we think
we can get. I'd prefer one that allows re-use for both commercial and
non-commercial purposes without needing to give credit to the original
authors. I'd also like people to be able to redistribute the files in
original or modified form. I think we should maybe suggest that giving
credit is polite, but not make it a licensing condition.
Am I out on my own now, or is anyone else thinking along the same lines?
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Chris B wrote:
> To summarise the discussions so far on defining a license for an area on
> povray.org to hold collections of objects etc.:
>
> We seem to have 100% vote for adopting a single license for the whole
> collection (3 out of 3).
> Similarly all seem keen on making the collection as open to re-use as
> possible.
>
> It sounds like the POV-Ray license would not be able to cover this
> collection without modification.
>
> I'm not sure that the GPL or LGPL licenses are all that appropriate because
> they contain a lot of terminology that is exclusively oriented towards
> software/programs rather than works of a creative or artistic nature (no
> offence to application developers intended). I think this was probably why
> the Creative Commons Licenses came into being. The reproduction and
> distribution of images and computerised descriptions of scenes can throw up
> unique issues, such as, when is an image a reproduction and when is it a
> representation of the original work? (i.e. is a thumbnail a copy or can it
> reasonably be used in an index or search engine).
>
> Unless we can enlist the help of a licensing Guru then rolling our own is
> probably out of the question.
>
> 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.
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.
>
> To move on into some of the detail:
>
> On the subject of scene files, I didn't necessarily see this as being a
> place where finished scenes would go, although samples and example scene
> files could accompany objects, textures, macros and include files to
> illustrate their use. I would argue that there are other forums where fully
> finished and refined scenes can be maintained including the IRTC and various
> Internet galleries, POV-Ray rings etc.
I separated my opinions since the POV-Ray license did the same, and
because I got lost trying to follow the discussion before this thread.
If we want to just avoid finished scenes for this discussion and focus
on a library of reusable items and demo scenes, great.
>
> If an image is rendered from a sample scene file and sold on Zazzle or to
> the Tate Gallery, then I would propose that we have no more access to the
> cash than the guys who made the pile of bricks that the Tate Gallery bought
> for a wheelbarrow full of money a few years back. The money goes to the
> artist who makes the sale. In any case, if very minor changes could get the
> artist/charlatan out of trouble, then, would the addition of a corporate
> logo to your pride and joy really make you feel any better?
Bricks do make a good analogy for the items in an include library. I
would be flattered to see my texture used in a nice picture on Zazzle,
but I would be annoyed to see my whole scene with someone else's name on
it. I was focusing that argument on finished scenes.
>
> The other issue raised by Sabrina and Nemesis is around whether users of the
> collection should be required to contribute their work back to the
> collection. My vote is that we don't impose such a restriction. Personally
> I'd like to see a license that's about as close to public domain as we think
> we can get. I'd prefer one that allows re-use for both commercial and
> non-commercial purposes without needing to give credit to the original
> authors. I'd also like people to be able to redistribute the files in
> original or modified form. I think we should maybe suggest that giving
> credit is polite, but not make it a licensing condition.
>
> Am I out on my own now, or is anyone else thinking along the same lines?
>
> Regards,
> Chris B.
>
>
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.
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. 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.
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.
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.
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.
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.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Sabrina Kilian <ykg### [at] vt edu> wrote:
> Chris B wrote:
> > We seem to have 100% vote for adopting a single license for the whole
> > collection (3 out of 3).
ah! the destiny of many in the hands of so few! come on, povvers! vote
now! :)
> > I'm not sure that the GPL or LGPL licenses are all that appropriate because
> > they contain a lot of terminology that is exclusively oriented towards
> > software/programs rather than works of a creative or artistic nature (no
> > offence to application developers intended).
yes, indeed.
> > 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?
I agree. In the previous thread, Gilles Tran also seemed to hint at CC, but
i won't put words into the mouths of others...
> > On the subject of scene files, I didn't necessarily see this as being a
> > place where finished scenes would go, although samples and example scene
> > files could accompany objects, textures, macros and include files to
> > illustrate their use.
Indeed. I started a thread to update povray standard include files, not
demo scenes or the like.
> > The other issue raised by Sabrina and Nemesis is around whether users of the
> > collection should be required to contribute their work back to the
> > collection. My vote is that we don't impose such a restriction.
point taken. I'm an admirer of the GPL way of doing collaborative work, but
can certainly see the benefits of more liberal schemes. If CC is to be it,
let's get ahead with it! :)
> 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.
That's right. But i hope there's some provision in the license under which
he (the contributor) published his work that restricts if he suddenly
changes his mind and begin requesting the contribution to be dropped from
povray or something. I mean, he has to abide by the terms under which he
originally licensed it. If later he begin to develop other version of the
file and publishes under another license, that's his right, but the
original should still be under the original license so as to be used by
povray.
> 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.
This sounds like BSD.
> 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.
not at all! The LGPL scheme would work much better. But i believe CC is
the way to go if not anyone more pronunciates about the subject...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Sabrina Kilian" <ykg### [at] vt edu> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"nemesis" <nam### [at] gmail com> wrote in message
news:web.456b65696ea74aa99d738cb0@news.povray.org...
>
>
>> 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.
>
> That's right. But i hope there's some provision in the license under
> which
> he (the contributor) published his work that restricts if he suddenly
> changes his mind and begin requesting the contribution to be dropped from
> povray or something. I mean, he has to abide by the terms under which he
> originally licensed it. If later he begin to develop other version of the
> file and publishes under another license, that's his right, but the
> original should still be under the original license so as to be used by
> povray.
>
If I understand you correctly, this would mean that the contributor would
need to agree to the license in perpetuity. ie. They would need to give away
the right to change their mind. Otherwise there could be consequences
affecting all derivative works covered by the original license. I think we'd
need to cover that in the release that the contributor 'signs' up to when
contributing the work.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Chris B wrote:
> If I understand you correctly, this would mean that the contributor would
> need to agree to the license in perpetuity.
The expression I see used in contracts in the USA is "grants to the
Client a non-exclusive, non-transferable, perpetual and royalty free
license for Client’s business use." Modified appropriately to address
whether you want it transferable, and the fact it isn't business use
we're talking about. Potentially adding "unlimited" or something, to
indicate the author is giving up all the extra "rights" that europe
gives to authors that the USA doesn't, like moral rights etc.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Chris B wrote:
> "Sabrina Kilian" <ykg### [at] vt edu> 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] vt edu> 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] btconnect com nospam> 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] deletethistoo povray org> 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] gmail com> schreef in bericht
news:web.456e1f276ea74aa9b1e716f90@news.povray.org...
>
> "Chris B" <c_b### [at] btconnect com nospam> 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] inter nlDOTnet> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"nemesis" <nam### [at] gmail com> a écrit dans le message de news:
web.456f05996ea74aa93976a8750@news.povray.org...
> 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...
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. It seemed the simplest, both for
me and for the users, particularly for things are both art and software. It
boils down to "you can do everything you want with my stuff as long as you
credit me (if I want to)", which is something that anyone can understand.
OTOH software-specific licenses like the LGPL are much more obscure for
non-programmers.
G.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Verm <pov### [at] thirteeen dynu com> wrote:
> Sometimes people genuinely forget where they originally got code from
> especially if they've heavily hacked it.
don't worry: lawyers will remind you! :)
ok, lame joke... next!
> 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.
Yes, specially having to list people who just modified a few lines of code
rather than created it. Mind you, this "give credit where credit is due"
provision doesn't exist in the GPL and LGPL licenses because they
understand it would bring such issues in collaborative works:
collaborative work means small contributions are as important as large and
giving credit to everyone is quite like giving credit to no one.
Credit listing in BSD and MIT licenses can grow insane, but at least, they
are hidden in C headers while such listing would indeed have to be compiled
by hand in a text file, say, credits.txt and be released together with the
rendered image. Of course, a script of sorts, perhaps interfacing with the
Version Control System in charge of the collection, could possibly track the
scene dependencies and generate credits.txt.
> Sorry not a very helpful post
actually, it brought another excellent point to the table. thank you!
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Among the people here who able to contribute and/or manage such a project,
are there some of them who are acustomed with collaborative development on
the Net?
In any case, apart from the licensing issue discussed here, collaboration
means rules, standards, defined process & organisation, and some reliable
'leaders'. How many of us/you/them are likely to be a POV artist/guru AND a
software developper? Coding scenes like we see most often here (and there)
in SDL is not developing (=requirements, specifying, documenting, coding,
testing, delivering, maintaining ...).
What I am sure of, is that POV is quite mature and there is lots of
POV-related stuff available that deserve special attention and that could
be made public in the community (after re-shaping and re-packaging). And I
guess we can find the 'resources' to achieve this.
Regards.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Verm wrote:
> Sometimes people genuinely forget where they originally got code from
> especially if they've heavily hacked it.
Would you like to see POV used to make a television commercial? Where
will you put the credits? :-)
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Verm" <pov### [at] thirteeen dynu com> wrote in message
news:456f09be$1@news.povray.org...
> 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".
>
Well I've read it a few times over the past few days and I've got to admit
that each time I read it it seems to say something slightly different, but
then it contains some pretty long sentences and the interpretation is highly
dependant upon the punctuation and capitalisation.
In section 4c of the Attribution Share-Alike legal code they say "You must
keep intact all copyright notices for the Work and provide, reasonable to
the medium or means You are utilizing ..." and, later in the section, after
talking about the credit identifying the use of a work in a derivative work
"Such credit may be implemented in any reasonable manner; provided, however,
that in the case of a Derivative Work or Collective Work, at a minimum such
credit will appear where any other comparable authorship credit appears and
in a manner at least as prominent as such other comparable authorship
credit."
It's the references to 'may' and 'reasonable' that make me think it's
probably a 'should' rather than a 'must'.
Because there is no full-stop between the 'reasonable to the medium or
means' and the place where they start talking about credit, I think it's
possible to argue that having a big piece of text saying "Verm made this
chair" in the middle of someones piece of art would be unreasonable to the
medium or means, whereas a little fast-moving title credit in a film where
your object featured fairly prominantly would be reasonable.
The same working is used in the CC Attribution Share-Alike and the CC
Attribution licenses for this.
>
> 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.
>
I agree. That's the level I'd like too.
>
> 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.
>
I think that's where we're struggling. But, given the difficulty of
interpreting legal texts, I think it would be challenging to write a new
license of our own, unless we've got a licensing specialist in our midst
who'd like to volunteer.
>
> 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.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Bruno Cabasson" <bru### [at] alcatelaleniaspace fr> wrote in message
news:web.456f13296ea74aa9f5fba6ef0@news.povray.org...
> Among the people here who able to contribute and/or manage such a project,
> are there some of them who are acustomed with collaborative development on
> the Net?
>
> In any case, apart from the licensing issue discussed here, collaboration
> means rules, standards, defined process & organisation, and some reliable
> 'leaders'. How many of us/you/them are likely to be a POV artist/guru AND
> a
> software developper? Coding scenes like we see most often here (and there)
> in SDL is not developing (=requirements, specifying, documenting, coding,
> testing, delivering, maintaining ...).
>
Yes indeed and we have other threads in this very newsgroup addressing those
exact issues. One for organisation/process and the other for
standards/rules.
>
> What I am sure of, is that POV is quite mature and there is lots of
> POV-related stuff available that deserve special attention and that could
> be made public in the community (after re-shaping and re-packaging). And I
> guess we can find the 'resources' to achieve this.
>
> Regards.
>
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.
I think this licensing discussion is key to making sure the community can
re-shape and re-package contributions so that this resource can evolve into
something more comprehensive in the future.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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.
Ultimately some authors may choose not to allow their scenes to become part
of the standard repository since they don't want to allow their work to be
used without attribution, and in that case that's their call.
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
So unless the user sets this in his/her scene file prior to pulling in any
includes, they will be alerted if they accidentally include a file that
requires them to attribute the author.
-- Chris
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
I'm no expert on licenses which is why I've stayed quiet so far on this
one... I'd be happy to vote though if somebody wanted to call for one.
Verm <pov### [at] thirteeen dynu com> wrote:
> 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.
I'm inclined to agree with this. It just sounds a whole lot simpler.
>
> 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.
Individual credit is nice, especially when the #includes more explicit in
what they make or what they do. But to my mind, crediting the "Library"
with a capital-L (whatever it ends up being named)with the individual
credit appearing in the individual files would be enough for me anyway. If
something I made were refered to as "the ____ from the [name_of_library]"
I'd be happy.
Charles
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christoph Hormann <chr### [at] gmx de> 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
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Charles C wrote:
> Christoph Hormann <chr### [at] gmx de> 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? :-)
Yes, as long as you don't copy/model any trademarks, you can model what
you like - for example it isn't ok to copy a car and it's badge. (I'm
fairly sure think it's ok to copy the car though )
It should be ok to model a boat as it seems ok to take a physical
moulding of a boat and use this to reproduce and sell replicas.
(Bonito Boats, Inc. v. Thunder Craft Boats, Inc. 489 U.S. 141 (1989))
Ok I admit it I got this via slashdot.org's thing about possible Patent
law reform :-)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
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] deletethistoo povray org> 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] gmx de> 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] btconnect com nospam> 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] deletethistoo povray org> 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] btconnect com nospam> 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
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"nemesis" <nam### [at] gmail com> wrote in message
news:web.4576d7696ea74aa93976a8750@news.povray.org...
> "Chris B" <c_b### [at] btconnect com nospam> 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?
>
Well. I may be wrong about this, but I thought that an image generated from
a 3D model was a derivation of the artistic work contained within the 3D
model. So my thinking was that if we don't explicitly grant permission to
use and modify the images that people wouldn't be licensed to do so.
>
> 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 agree that the intention is not to limit the use of images and that's what
I was trying to say.
My concern was that if we simply don't mention them in our licensing
statement that their use may be implicitly limited.
Does anyone have a definitive answer on this question?
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"nemesis" <nam### [at] gmail com> wrote in message
news:web.4576d7696ea74aa93976a8750@news.povray.org...
> "Chris B" <c_b### [at] btconnect com nospam> wrote:
>> The License
>> ------------
>
>> 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.
>
Maybe I phrased this a little innaccurately. It seemed to me that the
majority considered that requiring credit to be given (Attribution) was not
practical or necessary for the collection. This seems to rule out the CC
licenses, the least restrictive of which still requires attribution
(although there is some text that introduces the concept of 'reasonableness'
appropriate to the medium).
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Chris B" <c_b### [at] btconnect com nospam> a écrit dans le message de news:
4576e360$1@news.povray.org...
> Maybe I phrased this a little innaccurately. It seemed to me that the
> majority considered that requiring credit to be given (Attribution) was
> not practical or necessary for the collection. This seems to rule out the
> CC licenses, the least restrictive of which still requires attribution
> (although there is some text that introduces the concept of
> 'reasonableness' appropriate to the medium).
The conditions in the CC licenses can be waived if necessary, so I don't
think the credit is much an issue. I'm really under the impression that too
much importance is given to the credit issue anyway. I've worked on scenes
that used a lot of foreign material and credit was never a problem. We're
talking POV-Ray scenes made by mostly individual artists, not large-scale
F/OSS projects involving project teams and hundreds of dependencies.
I can only repeat what I've said in a previous post, which is that for
non-programmers (at least for me...) the LGPL and others are completely
abstruse and add some unecessary burden to the whole process. As someone who
could want to reuse some snippet of code and possibly redistribute it, the
CC-By is simple and clear enough. I can't say the same with a license that
requires digging in a lengthy document that's using both legal and developer
lingo (in a foreign language) to understand what one can and cannot do.
Example from the LGPL : "If a facility in the modified Library refers to a
function or a table of data to be supplied by an application program that
uses the facility, other than as an argument passed when the facility is
invoked, then you must make a good faith effort to ensure that, in the event
an application does not supply such function or table, the facility still
operates, and performs whatever part of its purpose remains meaningful."
It may makes sense for a developer, but for me it's Tagalog.
G.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Gilles Tran" <tra### [at] inapg fr> wrote in message
news:4576ed96$1@news.povray.org...
> "Chris B" <c_b### [at] btconnect com nospam> a écrit dans le message de
> news: 4576e360$1@news.povray.org...
>
>> Maybe I phrased this a little innaccurately. It seemed to me that the
>> majority considered that requiring credit to be given (Attribution) was
>> not practical or necessary for the collection. This seems to rule out the
>> CC licenses, the least restrictive of which still requires attribution
>> (although there is some text that introduces the concept of
>> 'reasonableness' appropriate to the medium).
>
> The conditions in the CC licenses can be waived if necessary, so I don't
> think the credit is much an issue.
I hadn't noticed before that the CC Attribution Deed does indeed say that
"Any of these conditions can be waived if you get permission from the
copyright holder".
However, the Legal Code for the CC Attribution license does state that "No
term or provision of this License shall be deemed waived and no breach
consented to unless such waiver or consent shall be in writing and signed by
the party to be charged with such waiver or consent." .
It also says "This License constitutes the entire agreement between the
parties with respect to the Work licensed here. There are no understandings,
agreements or representations with respect to the Work not specified here."
If there is a way to explicitly waive the attribution clause of the CC
Attribution license without having to manage signatures then this could be a
great way forward.
> I'm really under the impression that too much importance is given to the
> credit issue anyway. I've worked on scenes that used a lot of foreign
> material and credit was never a problem. We're talking POV-Ray scenes made
> by mostly individual artists, not large-scale F/OSS projects involving
> project teams and hundreds of dependencies.
>
Well, I think the only importance in the issue of credit is that we don't
want to place onerous and difficult to satisfy requirements on people
maintaining this collection in the future. So we're looking to find a way of
'not' mandating stuff, while trying to reduce the risk that anyone can
interfere with the freedoms that we're giving.
> I can only repeat what I've said in a previous post, which is that for
> non-programmers (at least for me...) the LGPL and others are completely
> abstruse and add some unecessary burden to the whole process. As someone
> who could want to reuse some snippet of code and possibly redistribute it,
> the CC-By is simple and clear enough. I can't say the same with a license
> that requires digging in a lengthy document that's using both legal and
> developer lingo (in a foreign language) to understand what one can and
> cannot do.
>
I agree. The LGPL terminology is difficult to interpret, particularly within
our intended context. The Legal Code for the CC Attribution license is also
quite heavy going, but seems easier to interpret within the more artistic
context that we need. One of the nice things about CC is that they have the
Deeds that put things in more straight forward terms.
Looking again at the CC site, there is also a CC LGPL license that I'd never
noticed before. If I understand correctly, this is the LGPL accompanied by a
CC human readable Deed. I don't know if this helps at all.
> G.
>
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Chris B wrote:
> 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.
>
>
(IANAL but I could play one on TV)
Considering how much work some companies put into keeping trademarks
from being diluted, I doubt that a corporate lawyer would use an
established object from a publicly available library that was
copyrighted by someone else.
No one sane would attempt to use some brand name can of soda from
another company as a trademark. They may have a license to use it, but
they do not have the copyright to it.
Worst case would be that someone contributes something that they later
sell to a company to use as their trademark. However, if all the license
stuff is in order, people using the library have a perpetual and
non-exclusive license to use that object.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Sabrina Kilian" <ykg### [at] vt edu> wrote in message
news:45772c0e$1@news.povray.org...
> Chris B wrote:
>> 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.
>>
>>
>
> (IANAL but I could play one on TV)
> Considering how much work some companies put into keeping trademarks
> from being diluted, I doubt that a corporate lawyer would use an
> established object from a publicly available library that was
> copyrighted by someone else.
>
> No one sane would attempt to use some brand name can of soda from
> another company as a trademark. They may have a license to use it, but
> they do not have the copyright to it.
>
> Worst case would be that someone contributes something that they later
> sell to a company to use as their trademark. However, if all the license
> stuff is in order, people using the library have a perpetual and
> non-exclusive license to use that object.
I guess you're right. I think maybe that reading all this legal gobbledegook
over the last couple of weeks has made me a little paranoid.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
nemesis schrieb:
>
> 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.
Please read what i wrote in:
Subject: Re: POV-Ray Includes - Licensing
Date: Thu, 30 Nov 2006 14:40:19 +0100
From: Christoph Hormann <chr### [at] gmx de>
Newsgroups: povray.general
For all discussed licenses (both software licenses and CC) this depends
on if the image can be regarded as derived works on the include files.
And as illustrated there are definitely cases where this is the case and
there are definitely cases where this isn't.
Concerning LGPL - you should keep in mind that this would allow anyone
to integrate the covered include files into different 3D packages (by
translating into a different language) and distribute them as a closed
product. This will be difficult in some cases (for example when
POV-Ray's procedural patterns are used) but will be fairly straight away
for example for a tree generator. I don't regard this possibility as
bad per se but everyone considering using such a license should keep
that in mind. Trying to avoid this would suggest using the CC-'share
alike' licenses. In some cases this will of course impose significant
unintended restrictions to the images using the file (see above).
-- Christoph
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Chris B" <c_b### [at] btconnect com nospam> wrote in message
news:4576c842$1@news.povray.org...
> 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.
>
There don't seem to have been any postings on this subject for a couple of
days. I'm not sure whether that means we've reached a concensus or whether
everyones just hacked off with the discussion.
I'll assume it means that we've reached a concensus unless:
1. anyone can suggest a clever way of waiving the 'Attribution' clause of
the Creative Commons Attribution license without requiring us to manage
waiver signatures, or
2. anyone has an alternative license that would better suit our needs,
It seems to me that we're down to using LGPL with a statement to clarify
that images generated using contributions to the collection become the
property of the user, even if they're pretty close/identical to what you get
when you just render the SDL provided.
I would suggest that we use the CC LGPL version, because it incorporates a
human readable deed.
Regards,
Chris B.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christoph Hormann <chr### [at] gmx de> wrote:
> > nemesis schrieb:
> > hmm? Why is generated image licensing a concern?
> Please read what i wrote in:
> Subject: Re: POV-Ray Includes - Licensing
> Date: Thu, 30 Nov 2006 14:40:19 +0100
> From: Christoph Hormann <chr### [at] gmx de>
> Newsgroups: povray.general
Yes, i've read about the threshold of originality. Well, i think if we dig
too much deep we're going nowhere. Source code licensing is as far as i'll
go.
> For all discussed licenses (both software licenses and CC) this depends
> on if the image can be regarded as derived works on the include files.
I really don't like this generated image licensing at all. What if someone
sees a cool povray image (not source) and recreates it in Blender and
renders it in yafray almost matching the original lighting, colors and
camera positioning and angles? Isn't that the same as a povray render of a
real world Volkwagen? If someone just releases the jpg how can we now if
they are ripping from a povray include file description of a 3D model or
have come up with something of their own?
This is why i think it's best for us to just keep on source code
licensing...
> Concerning LGPL - you should keep in mind that this would allow anyone
> to integrate the covered include files into different 3D packages (by
> translating into a different language) and distribute them as a closed
> product.
That's the purpose of the LGPL of course: to allow unrestricted *use* of
the libraries by anyone.
Still, isn't translating the include file -- say, the algorithm behind a
complex macro -- to another language a derived work itself? If so, the
community loses nothing from the company incorporating them, since they are
obligued by copyright law governing the LGPL license terms to give back the
source to the modification itself.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Chris B" <c_b### [at] btconnect com nospam> wrote:
> I'm not sure whether that means we've reached a concensus or whether
> everyones just hacked off with the discussion.
I'd vote for having a summary of the discussed licensing issues and options
for licenses and posting a poll about it in the povray website main page.
Like:
Read this thread [here] and choose a license for the povray include file
collection:
(a) - Creative Commons by attribution
(b) - LGPL
etc...
But then again, mindless vandals would make a lot of noise without
significantly contributing to the discussion...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |