search

rikai / OpenYourMouth

Open Source Recipes from the Jupiter Broadcasting community
GNU General Public License v2.0
156 stars 79 forks source link

Licensing: GPL vs. CC ShareAlike #53

Closed ninjaaron closed 9 years ago

ninjaaron commented 9 years ago

It might be too late to make this change, but a code license like the GPL doesn't make much sense with artistic/cultural works like recipes, since it refers to a lot of technical things like source code, compiling, executing, software, etc. The CC ShareAlike would be the equivalent license for written (and other) works. It's free and it's viral.

foss-scribe commented 9 years ago

I second proposal that if it's possible to change. Recipes are technical docs, just like user guides, manuals and application help files. CC would be a better choice.

ubuntuaddicted commented 9 years ago

I love how this project is already so active. Chris just announced this in a show like hours ago (at least when I heard about for the first time). I notice how people are already using it and your comment about which license would make more sense being CC versus GPL. This is great!

g33kdad commented 9 years ago

Here's my "me too". CC makes much more sense, IMHO.

odysseywestra commented 9 years ago

I would agree too that CC liscense would make more sense than a GPL liscense.

ninjaaron commented 9 years ago

You could also use something like the GFDL, which is for documentation. It would be something to act quickly on though, if at all, because you would technically need to get permission from all of the contributors to change the license. I doubt anyone actually cares, but it's good to cover your assets.

bencord0 commented 9 years ago

Does the GPL vs CC argument change if there's actually come code in this project? c.f. pull #66

pcwizz commented 9 years ago

I think GFDL (https://www.gnu.org/copyleft/fdl.html) is a much more suitable license for this project. I think by definition recipes are documentation, so a documentation license is preferred.

CC Share Alike is a much more permissive license, hence it is much simpler, but gpl compatible license. It is a very general license though, as it is intended for everything from podcasts to novels, so while we would no longer be using a code license inappropriately it's not the most suitable license.

We could argue that recipes are sets of instructions, therefore they are programs. It is probable not far from the truth to say that you could write an interpreter to perform the recipes, but I do not believe this is the projects intent, so this justification of a code license is flawed.

To answer bencord0 I do not believe this repository is an appropriate place to store code. It is a repository of recipes not an application. There is of course the compilation of things like gh-pages were we could choose to present a nice interface to the repository, that could result in no JavaScript.

While I would expect the JavaScript would be trivial and therefore a nil issue, however if the JavaScript was not trivial I would be in favour of licensing the JavaScript as software (under the gpl), and licensing the content and recipes as documentation (under GFDL).

rikai commented 9 years ago

I don't think that the choice of license is that inappropriate. I mean, opencola, a product that was sold, used the GPL as well, and if it's good enough for Cory Doctorow, its good enough for me. :palm_tree:

TheEndIsNear commented 9 years ago

I still like the sound of making this Beerware licensed

KennyStier commented 9 years ago

Well because Markdown is considered "code", I think that the GPL is suitable for this project. Although I see no reason why the GPLv3 shouldn't be used.

rikai commented 9 years ago

I, personally, dislike v3 and see no benefit to using it on this project.

rikai commented 9 years ago

Right then, don't see much of a real need to change, so sticking with the GPLv2