StrategyWiki talk:License

Discuss the StrategyWiki license on this page.

Licencing: CC-BY-SA instead of GFDL?

Hi,

May I inquire what was the reason to go with the GFDL as a licence instead of a Creative Commons licence such as cc-by-sa?

Thanks, Nyenyec 15:17, 21 April 2006 (PDT)

Well the biggest advantage is that content from other wiki sites (Wikibooks, [Gameinfo], etc.) can be copied here because we all share the same license. However I wasn't here at the time of the decision so the reasoning may be more complex for all I know. Garrett^Talk 17:11, 21 April 2006 (PDT)

GFDL is Wikipedia-compatible, and that was a huge factor. We wanted to remain compatible with the largest collection of open content game information, guides, etc. We want to promote a working relationship between the projects.

Initially I almost considered something of a proprietary dual license that I termed a "community license"--we would place the content under the GFDL and also give the StrategyWiki organization--which isn't even an entity yet--full rights to all submissions. That was intended so that we would have the option of changing to any new or better open media license of the community's choosing in the future without being locked into GFDL exclusively. Basically, all content would still be licensed under the GFDL, but there would also be the option of choosing another license later by community vote. I scrapped that idea because it was too complicated, and I feared it would make users apprehensive.

If and when we gain traction, however, we may be able to ask the community what they think of a relicense or dual license, or even this "community license" that I just talked about. Of course if we decide to do this, the application of it would NOT be retroactive unless we can find the permission of those authors who have submitted work. I would be fine with having all of my work relicensed, and several other StrategyWikians might as well. Others may not, however. Or we may not be able to find them all. Anything we couldn't relicense could be either tagged or rewritten.

We are in an early enough stage to shake things up, but we'd have to have a community consensus. After this Digg thing, I'd like to see what happens to the community. Will it grow stronger? Will we gain more help? Once I have a fuller view of this, we'll probably put this and other issues up for debate. --echelon ^talk 17:27, 21 April 2006 (PDT)

Urg.. I see why some people prefer CC-BY-SA to GFDL. And it's not a nice reality. If that article is true, then we might want to consider some dual-licensing and relicensing in the future. I know it's impossible to change anything we already have to CC-BY-SA, but in the future we might want to make future articles CC-BY-SA. I'd like to hear your opinions on this issue. --echelon ^talk 23:03, 13 May 2006 (PDT)

Yes that article captures the gist of it perfectly. I for one would certainly support changing to CC-BY-SA. In addition to the reasons they gave I think its simplicity makes it simple for the average user to understand, and perhaps making them more likely to feel confident about licensing their contributions. However if a change is to be made it must be done NOW. Re-labelling the site itself is the fiddly bit.

The per-guide implementation however is easy, and can be done via templates. Take a look at the bottom of my user page for an example. Unfortunately IE's hatred of CSS means it doesn't work for it; however this is just the code I had on-hand, there are definitely more compatible methods. Anyway, this means licenses can be added or overridden (a button can be placed over top of another just as easily as beside it) straight from a template.

Wikinews recently changed their copyright from PD to CC-BY, see their copyright page for more (and especially note the wording of their footer). That might give you some ideas. But, anyway, this is definitely a decision that must be made as quickly as possible to both minimise the workload and also the amount of content under the GFDL. Garrett^Talk 02:29, 14 May 2006 (PDT)

Having this discussion now should be an immediate priority for us. I can't believe I didn't consider the impact of doing nothing about this before. We need everyone who edits here to contribute their thoughts and opinions on this issue so we can make a wise choice. While I'd like to switch licenses now, whatever we do will have a large impact on our future. Picking a license that prohibits multi-licensing and isn't future-compatible will box us into a hole that we don't want to be in. First, let's look at the available options and weigh what each provides for us. We need a long-term solution that will work for many, many years. Perhaps beyond the scope of our own time here, to best accomodate whomever future contributors and users of this project may be.

If we can't decide on CC or BSD or something else, I also have another possible idea that I had thought about before. What about a "StrategyWiki License" that pertains specifically to the contents of this wiki? We would create this with the future in mind, so that we could predict and adapt to any future legal issues that may arise. Therefore, the first thing we would state is that people can "at their choice, use this version or any later version" of the license. Sort of like the GPL, this gives us future-compatibility. Secondly, we could draw up the terms of the license to be as dual-licensing friendly as we want to be and as copyleft as we want to be. After reading about CC-BY-SA, I feel it is much more open and far less restrictive than the GFDL. Moreover, the most important advantage a custom license would give this project is that the project can adapt--with a custom license, we could retroactively apply important changes to anything licensed under a StrategyWiki license. Older content wouldn't be stuck in the past forever. (So long as that is part of the provisions for contributing.) Older revisions would still be under the license version they were initially published under, but the project as a whole would be under the latest version of the license--this is what I mean by "future expandability".

Now, there are three problems that come to mind with this (and you may be able to think of more). The first, and greatest, is that the license could evolve into something bad. Who is to prevent this from happening? We could say that the license would be democratic, but there is always a small fear inside me that it could be pulled into the depths of something that takes away usage rights of the public and grants it to some all-powerful group. Think the FSF, who ask all contributors to waive their rights to copyright on all contributed code. Bad, bad, bad! I could only see an FSF scenario becoming more restrictive, more GFDLish. Then again, IIRC, I believe it was the Debian project that manages to do fairly well in licensing? The only goal I am aiming for is to ensure StrategyWiki content is always going to be relevent, useful, and free to use with as little restriction as possible. Is a custom license too bad for its own good? Is it overkill?

The second disadvantage is that a custom license is unknown. New contributors to our project may see our license, but without the familiarity of Creative Commons, GFDL, or BSD, they won't have a clue whether our license is actually authentic and can be trusted. Or what it states without reading it all themselves.

The third and final disadvantage of a custom license is that it has to hold up, legally. Who would write it? I'm not a lawyer. Could we just copy from the CC-BY-SA and delete/change what we don't like about it? Or add things we feel are missing? Ths is yet one more question that needs to be answered.

While a custom license for this project would be a lot of work, I do feel that the advantage of forward-proofing contributions for change of license would be a significant gain that would save us large amounts of trouble in the future. Maybe we could simply state this in an ammendment to a copied Creative Commons license? What are you thoughts? --echelon ^talk 11:15, 14 May 2006 (PDT)

---

I have several comments but I will try to be concise:

• Creative Commons. I tend to dislike CC licenses because authors tend to choose the noncommercial (NC) variants. If we pick CC-BY-SA, then we do not have that problem.
• Attribution Withdrawl. The CC-BY-SA 2.5 licenses have an attribution withdrawl clause, which appears to agree with the recommendations in the debian-legal Summary of Creative Commons 2.0 Licenses. However, even though Debian thinks that it is okay, I personally dislike this clause:
  • If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any credit as required by clause 4(c), as requested. – clause 4(a) of CC-BY-SA 2.5 Legal Code
• Transparent copies. The GFDL requires everyone who distributes "more than 100" copies of a guide to provide a "Transparent" copy (in human-editable text such as the MediaWiki markup, not in generated PDF or Microsoft Word). The CC-BY-SA seems to lack that requirement, which is another reason why I normally prefer the GFDL. However, I only care that this wiki has a Transparent version. If we always use MediaWiki, I can Special:Export/Main Page and get the wiki markup, even if wiki is CC-BY-SA.
• Custom license. The text of the CC-BY-SA 2.5 is itself under in the public domain: "We do not assert a copyright in the text of our licenses. So yes, CC will let you edit the CC license to make a new license.
• Dual-licensing. It might make sense to declare that after date X, all contributions to StrategyWiki must be licensed under both the GFDL and CC-BY-SA. However, date X would have to after whenever we finish importing Wikibooks content.

My recommendation? Stay GFDL; or switch to a dual-license between GFDL and CC-BY-SA. --Kernigh 12:32, 14 May 2006 (PDT)

Hm. Well I'm undecided. I certainly don't like the idea of dual-licensing. Not only does this prevent importing pretty much any other wiki's material but it also could confuse potential contributors. As for the other possibilities, CC has some definite flaws as both you and the Debian people pointed out but it has the advantage of being both well-known and compatible. A custom license has downsides that may outweigh its upsides, but does allow any number of subtle license changes to be made to suit our needs. Garrett^Talk 20:18, 17 May 2006 (PDT)

This is a very sticky issue, and I don't expect us to solve it without more input. I've personally been thinking that we should try to go create a custom license as a direct copy of CC-BY-SA. The reason I don't want us to go with CC-BY-SA is that future versions of that license may turn into something we don't like. If we have our own, there's nothing to stop us from turning our license into anything short of the BSD license, should we ever feel that was the best course of action. (But of corse this is an example only, I don't think that would ever happen.)

The problems with this, however, are the same as I listed before--especially the part about users not knowing the terms of a custom license. I do think I may have come up with a simple solution, however. If we keep the differences between any given version of a custom license and any given role model open source license as small as possible, we could have an easy reference point to show users. Then it would be as simple as pointing out the minor and unique differences in our license. Or, let's say we don't do that. We could just as easily create our own succinct explanation. Anyhow, if we do wind up creating something, I want to run it by the OSI for approval.

Finally, since we're already trying to work on something that addresses the problems inherent in licensing wikis, why don't we work on a license that can be used by all wikis? There's no license I've seen that is really suitable for wikis at all, and there really needs to be one. We could call it "WikiLicense" or something. The major problems with the GFDL are that you must provide full changelogs, you can't easily include copyrighted texts or images, you can't easily multi-license, etc. The problems with Creative Commons is the whole "pick and choose" model. (If something is really "free" it must still be available for use in commercial purposes, whether you like it or not.) Imagine if all wikis used a single license and it made copying possible between all wikis. Wouldn't that be awesome? echelon 04:22, 19 May 2006 (PDT)

Actually, the GFDL does not require full changelogs; it only requires a "History" section acknowledging previous documents which you modified. This is why I created a NetHack/History page at Wikibooks, because I copied some text from one Wikibook to another Wikibook. Even the FSF does not include a full changelog with the prototypical GFDL'd document, the GNU Emacs Manual. There is an available ChangeLog, but at the bottom it gives a copyright not allowing modification. The ChangeLog is not an Invariant Section of the Emacs Manual (unlike the GPL, Manifesto, and Distrib info), so it is not part of the manual and the GFDL does not require that you keep the changelog with the manual. --Kernigh 11:46, 30 May 2006 (PDT)

Labelling old content?

This all sounds good. However the next big step is how to deal with guides already under the GFDL. It shouldn't be impossible to gradually replace GFDL content with fresh content under the new license, but there needs to be some way of handling things in the meantime. Garrett^Talk 16:24, 28 May 2006 (PDT)

Also, if this procedure looks to be logical enough it might be a good idea to import CC-by-SA guides as well (such as these) for seeding of future content. The biggest problem with both this and the GFDL material however is ensuring that content is truly done from scratch and not just pasted from the old license version. Garrett^Talk 16:31, 28 May 2006 (PDT)

We can have, for example, a New-Wiki-License guide that does only worlds 1 and 2 with a separate GFDL guide that does worlds 3 to 10. There is no need to link everything into one executable, as is necessary with free software. The annoying part would having editors understand the differences between the different licenses. --Kernigh 12:12, 30 May 2006 (PDT)

Or we could try the EmacsWiki approach: "This work is licensed to you under version 2 of the GNU General Public License. Alternatively, you may choose to receive this work under any other license that grants the right to use, copy, modify, and/or distribute the work, as long as that license imposes the restriction that derivative works have to grant the same rights and impose the same restriction. For example, you may choose to receive this work under the GNU Free Documentation License, the CreativeCommons ShareAlike License, the XEmacs manual license, or similar licenses." However, I am not sure whether or not that license is copyleft. --Kernigh 12:15, 30 May 2006 (PDT)

If you are going to change the license for the wiki, just put a note at the bottom of any page which uses the new license. For example, http://en.wikisource.org/wiki/Romeo_and_Juliet has a Public Domain notice at the bottom to let people know that it is not under the GFDL. Speaking of Public Domain, that's the license that I used for my wiki. Why not just use that? Gerard Foley 20:29, 1 June 2006 (PDT)

Relicense StrategyWiki Plan - This is important!

Time to relicense StrategyWiki--if we are ever to do it--is now. If we wait any longer, it may become a terribly difficult process. Ultimately, I have decided that I want to go with our own copyleft license, modeled *exactly* after the Creative Commons BY-SA. The reasons why we should do our own license is because I believe we can make ammendments later (with the help of a lawyer) that are relevant to our purposes and allow us to make certain requirements, uses, etc. that the CC doesn't. Here's are the goals I think we should have:

• I think our license should be as "free" as possible. The GFDL is very restrictive and will hinder a lot of people from using our content. Say someone wants to publish a collection of our guides--they'd have to include each page's entire revision history. (This is a rediculous requirement for our purposes!) The GFDL also has several quirks that make including screenshots and other images a murky matter. Multilicensing is also more difficult with GFDL than other licenses.
• We shouldn't be public domain: IGN, CNET, or conceivably anyone would take our content, modify it, and then prevent us from using their modifications, however useful they may be. This isn't to say that we wouldn't allow IGN, CNET, et al. to use our content--of course we'd like that! It'd be the sincerest form of flattery. We just want them to do so in a copyleft manner so that any improvements they make will still be open to anyone. (After all, they would be borrowing this content for free to begin with!)
• There are some instances where we will want select groups to include revision histories--Wikis, database projects, etc.--so that they will not be lost in the event StrategyWiki's server gets hit by a giant meteorite or something. The CC BY-SA won't allow us to do this, but with our own modifications to that license we can. Because wikis have the power and capability to store revision histories, we would want our license to state that they should do so whenever possible.
• There might be other stuff we want to add later on. Who knows what the future will bring. We should be ready to adapt, and using our own ammendable license will allow us to do so better than using any other license.

If we do this, our first license will be called StrategyWiki License 1.0, and the content will be exactly that of the latest Creative Commons BY-SA, except every reference to "Creative Commons" will be changed to "StrategyWiki".

To make understanding our license easy, we will provide a diff to the Creative Commons BY-SA and a short document explaining why we have a custom license and what it does.

Finally, before we do anything of this sort we will have to mark all old pages with a GFDL 1.2 marker icon to indicate that those pages (and subsequent edits) are licensed under the GFDL. We'll then ask all of our writers if they would be willing to relicense their submissions under the StrategyWiki License; we'll create a page for editors to sign their names if they are for doing so. For pages we are unable to convert from the GFDL, that is okay! We will rewrite them later, concentrating on new content for the time being.

So, have I made a reasonably good case to do this? What are your thoughts on this? Yea or Nay?