In Memoriam: Tai'lahr
OpenUru.org, along with the rest of the Mystonline community, is mourning the loss of Tai'lahr on October 16th, 2019.
Rest in Peace, friend.
Difference between revisions of "User talk:Trekluver/sandbox"
Line 9: | Line 9: | ||
:As far as the PRP's go, maybe my wording was off. I realize everything you mentioned, which is exactly why it needs to be two separate licenses. Otherwise, what you create is the potential for Cyan to say they own any and all derivatives, rather than just the files that belong to them. The raw data files and textures will be the most difficult thing to convince Cyan to license. We need to discuss how to do this better during the meeting and, when we start to license, really get the input of Branan and Hoikas. (Their knowledge in this field will be highly valuable.). --[[User:Trekluver|Trekluver]] 13:29, 25 July 2012 (MDT) | :As far as the PRP's go, maybe my wording was off. I realize everything you mentioned, which is exactly why it needs to be two separate licenses. Otherwise, what you create is the potential for Cyan to say they own any and all derivatives, rather than just the files that belong to them. The raw data files and textures will be the most difficult thing to convince Cyan to license. We need to discuss how to do this better during the meeting and, when we start to license, really get the input of Branan and Hoikas. (Their knowledge in this field will be highly valuable.). --[[User:Trekluver|Trekluver]] 13:29, 25 July 2012 (MDT) | ||
− | :: I'm not suggesting anything at all about changing files names: What I was trying to get at was that your draft is written to specifically address the sfx files at the exclusion of others file types, and you go so far as to propose naming the files covered by the license. My point was that there has been a lot of work done to translate the textual content in Uru (e.g. the journals, etc.) and that needs to go into some of the other (existing) files in the dat folder, aside from any issues of people wanting to devlop new ages, etc. So focussing on sfx files is just too limiting. Also naming the files is potentially a "bad thing" - Let's say Cyan initially licenses a small sub-set of file to "see how things go" and later opts to release a larger (or different) set, then if the files are named within the license you'll effectively be in the position of re-licensing and that can get messy, depending upon circumstances. | + | :: I'm not suggesting anything at all about changing files names: What I was trying to get at was that your draft is written to specifically address the sfx files at the exclusion of others file types, and you go so far as to propose naming the files covered by the license. My point was that there has been a lot of work done to translate the textual content in Uru (e.g. the journals, etc.) and that needs to go into some of the other (existing) files in the dat folder, aside from any issues of people wanting to devlop new ages, etc. So focussing on sfx files is just too limiting. Also naming the files is potentially a "bad thing" - Let's say Cyan initially licenses a small sub-set of file to "see how things go" and later opts to release a larger (or different) set, then if the files are named within the license you'll effectively be in the position of re-licensing and that can get messy, depending upon circumstances. --[[User:Mac Fife|Mac Fife]] (I forgot to sign this when I added it) |
::: Just FYI: My biggest problem with any newly- or custom-authored license is that it would have to be read and analysed by Cyan Legal and then cycled an unknown number of times until everyone is satisfied, possibly delaying completion forever and ever. It is my opinion that any license must already be publicly established, well-known, understood, accepted and respected. And that license should not be modified in its original content, but have exceptions and additions attached as an addendum or "codicil." Only in this way can anyone understand its terms at a glance and minimize reasonable time to completion. [[User:JWPlatt|JWPlatt]] 10:42, 11 September 2012 (MDT) | ::: Just FYI: My biggest problem with any newly- or custom-authored license is that it would have to be read and analysed by Cyan Legal and then cycled an unknown number of times until everyone is satisfied, possibly delaying completion forever and ever. It is my opinion that any license must already be publicly established, well-known, understood, accepted and respected. And that license should not be modified in its original content, but have exceptions and additions attached as an addendum or "codicil." Only in this way can anyone understand its terms at a glance and minimize reasonable time to completion. [[User:JWPlatt|JWPlatt]] 10:42, 11 September 2012 (MDT) |
Latest revision as of 14:51, 17 September 2012
Sub-section numbering
Some sub-section numbering has gone wonky (mixed alpha and numerical numbering) as a result of pasting the original HTML formatted text into the wiki markup and not taking out some of the imported "bullets". --Mac Fife 15:01, 19 July 2012 (MDT)
- Yea, I was aware of it but haven't had the chance to go through and fix it. I figured that since it's my sandbox page, it's not that big of a deal until I have the time. :) --Trekluver 13:29, 25 July 2012 (MDT)
Premise of basing license on SFX files
This offers no help to e.g. the Uru Localization folks who want to change/extend the text! Also, I think you're missing the point about PRPs: While a license to distribute the PRPs (and the SFX files) is necessary for a shard to be self-sufficient (i.e. not dependant on copy data from a MOULa install) you need to remember that the PRPs are a compiled product and not the source files (which are 3ds Max files by and large). So, a license to distribute the existing game content on shard is actually covering a different set of files compared to license that allows modification of the sources, although the former can be produced from the latter. Textures are probably the most valuable things to age creators aiming for a consistent D'ni look in their work (and they're probably the most jealously guarded of Cyan's assets). --Mac Fife 15:01, 19 July 2012 (MDT)
- While that was just a mockup (I'm far from done with the draft. ;) ) I'm not entirely sure what you're referring to. The file names, or the license terms? As far as the SFX file names go, we can't change those because it would require far to many exception changes for shard operators and become unnecessarily complicated. And as far as the license terms go, when it's done it will basically be a revokable version of a CC license that someone has to sign up for from Cyan (At least where this version is concerned. We'll talk more about the specifics in our meeting.).
- As far as the PRP's go, maybe my wording was off. I realize everything you mentioned, which is exactly why it needs to be two separate licenses. Otherwise, what you create is the potential for Cyan to say they own any and all derivatives, rather than just the files that belong to them. The raw data files and textures will be the most difficult thing to convince Cyan to license. We need to discuss how to do this better during the meeting and, when we start to license, really get the input of Branan and Hoikas. (Their knowledge in this field will be highly valuable.). --Trekluver 13:29, 25 July 2012 (MDT)
- I'm not suggesting anything at all about changing files names: What I was trying to get at was that your draft is written to specifically address the sfx files at the exclusion of others file types, and you go so far as to propose naming the files covered by the license. My point was that there has been a lot of work done to translate the textual content in Uru (e.g. the journals, etc.) and that needs to go into some of the other (existing) files in the dat folder, aside from any issues of people wanting to devlop new ages, etc. So focussing on sfx files is just too limiting. Also naming the files is potentially a "bad thing" - Let's say Cyan initially licenses a small sub-set of file to "see how things go" and later opts to release a larger (or different) set, then if the files are named within the license you'll effectively be in the position of re-licensing and that can get messy, depending upon circumstances. --Mac Fife (I forgot to sign this when I added it)
- Just FYI: My biggest problem with any newly- or custom-authored license is that it would have to be read and analysed by Cyan Legal and then cycled an unknown number of times until everyone is satisfied, possibly delaying completion forever and ever. It is my opinion that any license must already be publicly established, well-known, understood, accepted and respected. And that license should not be modified in its original content, but have exceptions and additions attached as an addendum or "codicil." Only in this way can anyone understand its terms at a glance and minimize reasonable time to completion. JWPlatt 10:42, 11 September 2012 (MDT)