Project accepting several type of licenses for art

[Cacatoes]

Been itched by this question lately,

We commonly find software projects (purely code) which use different bricks, libraries, which are licensed differently, and sometimes the whole is turned into GPL since it's a license which makes it necessary to convert others (BSD, public domain) into GPL. (see: http://www.gnu.org/licenses/gpl-faq.htm ... mCopyright & http://www.gnu.org/licenses/gpl-faq.htm ... ainWithGPL & http://www.gnu.org/licenses/gpl-faq.htm ... Compatible & http://www.gnu.org/licenses/gpl-faq.htm ... ggregation )

Distinction between aggregation and "mixing" may be easy with artwork. It's easy to know if you take 2 textures and make one of it, then you mixed them. Quite the same with sound. And some "whole song" probably is a mix, except if you've got some "digital orchestration format" (.midi, tracker format...) which keeps these sounds separate, or more generally if you get some "algorithmic layer" in-between.

Strategy-wise, I've been a bit curious of why people only select one license for their projects. One license reflects one opinion. One project may end up being distributed under its most restrictive license.

I see different kind of layer amongst licenses:
- Waivers like CC0 and public domain
- Minimal licenses such as BSD/MIT
- Copyleft licenses such as CC-BY-SA

Some of my worry was, when some project enforces one license, the contributor's wish may happen to be neglected. For expl, most contributors for a GPL project will release their stuff under GPL (because of no preference, and mostly because being not-that-much educated with legal stuff). Personally, I've rather been releasing my works under some less restrictive license. But then the source tree has either to specify it, or ignore it (agregate, or convert back to the more restrictive license)
Only one license means: less administrative/sorting burden, but some loss of the original author's intent.
So why couldn't projects organize themselves around multiple licenses ? (I'm not saying: all licenses, but at least one license from each "license layer")
-> Contributors' wish would be respected more closely
-> Would mean easier to get more art/assets, since we wouldn't have to stick to a single license, but could gather stuff from a few selected licenses

Logic would be to recognize plurality since the start, and adopt the agregative way of doing. Small projects don't necessarily need several licenses, while bigger (probably more specifically: games ...) could take profit from it.
For instance, take "Debian" project, it's an aggregation of several projects/licenses, while all of them are free. The only required effort would be to make classification clear, like one directory per license. That would also allow people who are eventually not satisfied by a specific license to reimplement it inside their favorite license set so it has an equivalant.
I've probably missed a few of the points I wanted to make while writing this, but the main ideas are here.
My main points were:
- sticking more with people's own preferences, and
- ability to use more artwork, since all of the produced things had the intent to be reused elsewhere, which sometimes happens not to be the case even when it's free (!)

[qubodup]

The easiest way for artists to preserve original intent is to upload their art under the license of their choice on http://OpenGameArt.org . This has the benefit of being easier to find. FOSS game repos are kind of a insider hint right now.

Permitting different licenses can lead to discussions and confusion. Deciding what set of licenses is acceptable takes time too. Some leads are willing to take that time, others are not. Many leads want to minimize time spent on license discussions.

There are multi-license projects, however. I don't know many but NAEV is one example https://github.com/bobbens/naev/blob/ma ... RK_LICENSE .

Some developers think that GPL is superior or prohibits non-GPL-compatible art - see OpenArena.

I see following ways of spreading knowledge and acceptance of different asset licenses:
* If you can write concise, simple texts about licenses, edit http://freegamedev.net/wiki/Art_licensing_guide . For example I feel that many leads/devs don't know how to give credit or state what license is being used, guidelines or templates could be of help.
* If you are a web dev or designer, you can try to join the OpenGameArt admin/webdesign team and think of/implement ways of making licenses clear to people who download assets (for example we could use a text file which gets generated for each node so giving credit is automated.

[Julius]

Normally more permissive licenses are no problem at all, e.g. a GPL project will always accept BSD or CC0 artwork and will have no problem mentioning in the readme that files xyz are actually not only available under the GPL but the more permissive licenses too.
So I don't quite get your issue... obviously less permissive licenses (like non-commercial options or non-derivative etc.) are not legally compatible and for many good reasons disapproved off.

[Cacatoes]

1) My intent was to get feedbacks about eventual issues you would see with a project using several different and eventually incompatible licenses for art.
2) Most FOSS game project identify themselves as using a single license for art, and don't keep otherly licensed files in parallel, so I was wondering if it wasn't some blind habit which had few good reason to be.
3) Some project still are embarassed about choosing license, so I tried to point out accepting several may help with license wars, and would help projects to get assets from a wider range of external sources.
4) And finally, have some clues about how projects organize themselves (file structure) when they use several licenses.

So, yeah, maybe my question was pointless, but if it is, it's weird we end up recommanding one specific license like put_your_favorite_license_here for both people who seek help with "what license should I choose for my project" (applies to FGD) and for contributors inside an existing project (applies to any project).
There may be a subtle difference between the exigence of "use my own license", and "please, use some license which is at least as free as CC-BY-SA / GPL".
There is also the "please, use some GPL-compatible license" phrasing, but that means you still can't use CC.

Am I still unclear ?

[Julius]

IMHO I feel that accepting several (potentially even incompatible) licenses would be a huge step backwards.
In fact it took a quite heavy lobbying effort in the past (partially by me personally) to come to the point where we are now: e.g. at least have the major open-source project recognize the need for a single (hopefully copy-left) and compatible license.

It is the single most important and defining feature of open-source (and even more so FOSS) games that licensing is clear and that reuse is possible (hopefully in the copyleft sense)... any concessions to petty ideas of some artists that are just too full of themselves (I am an artist my self primarily btw ) will just result in problems down the road (see f.e. the Blood Fronter disaster).

Let them stay with non-free modding projects that are dead even before they get released as the game they are based on is long dead... but from my experience they couldn't case less as they are mostly in for portfolio development to get a paid job anyways (nothing inherently wrong with that, but FOSS game are more than that).

[Cacatoes]

I'd like you to relate a bit more on that lobbying effort (what a term, ehe, but no worry I could as well pretend doing propaganda ).
So you're into the "one license to rule them all". This is "weird". Historically, I can understand why some people were reluctant to custom-made licenses, copying main ones but changing a few things, like adding their own whims to it while missing what the license was all about.
But now, licenses are fairly established, some people are more educated about their use and meaning, software has vastly adopted some, and people probably assumed the fact they have to find the license that suits them amongst a limited set rather than reinventing the wheel.
Personally, I was rather glad lately to see new license approaches, and was kinda pleased to find licenses such as CC0 emerging. And I don't feel conservative enough so these kind of movement (new approaches) stops.

Parenthesis:
I've been rather quick with the "sure of themselves artists" part on the other topic. There are people who come here with their own approach. There are often "details" we can automatically decrypt as "unwanted", and strongly disaproving them makes us in our turn "sure of ourselves free software intolerant fanatics" or alike. This critic doesn't come from nowhere and has to be considered, even if we believe we were at least right regarding the "what license to choose" problem. It's basically the problem about how to explain someone he's doing wrong, and with that you have to consider you may be doing wrong too. I've rarely assumed the license advisor role, but I assume it happens many time here, and it can lead to some rejection, which I consider to be a fail. Though not a that big fail if part of the ideas made their way.
)

Back to topic, here are a few questions:

- how do you explain success of Debian ? (multiple licenses inside)
- do you think a project like NAEV will fail due to it using several licenses ?
- what can you do with people who don't like the license of your choice, but could have been glad to contribute otherwise ? (probably an uncommon case, but I can myself easily fall into that one)
- and why couldn't these otherly-licensed assets conserve their license in parallel ?

Not free enough ? Too free ? Tolerance ? Will that lead to a project failure ?
There are probably loads of criterias for a project failure. (it wasn't exactly my first worry when starting this topic)

[Julius]

Honestly... I am kind of tired of these license discussions, and I also have the feeling we are not fully understanding each other...
Case in point is that you mention the Debian project which is THE prime example of being extremely anal about sticking to one license. Sure they accept compatible and more permissive licenses also, but solely because those can be re-licensed as the one license the entire project runs under.
The same is the case for all other projects (gaming or not) that have chosen a single license.

My personal take on all this license non-sense:
Ideally there would be no such thing as automatic copyright (but rather some sort of right close to patent-law). But the realist in me knowns that copyright in it's current form is to stay and that thus a common and compatible (preferably copy-left) license to allow free sharing of code and assets is the best outcome we can hope for. Thus I don't mind people using the CC0 for example (as it checks-off as compatible and permissive) but asking people to share under the same terms (aka copy-left) is the best way to promote this idea, prevents the most forms of misuse, and is a good compromise for those that are more (but not overly) protective of their "intellectual property".

[Cacatoes]

but solely because those can be re-licensed as the one license the entire project runs under.

Do you have evidence for that ?

Not a single word about that precise license in http://www.debian.org/intro/about#what nor here http://www.debian.org/social_contract ; however I know about http://wiki.debian.org/DFSGLicenses which seem to show some kind of plurality for licenses.

I may try to discuss your second point about CC0 and copyleft, that is, if you don't mind to be bored with further license discussions.

[Julius]

Not a proof per se, as in "take this quote by Debian representative XYZ", but my understanding of the DFSG is that is basically paraphrases the idea that everything included in Debian has to be GPL compatible.
I am not sure what you are implying though... I am not aware of any project that says you have to use CC-by-SA for example... rather they say you have to use a license compatible to the CC-by-SA (e.g. more or equally permissive), which in turn means that they can re-license the entire work (which includes your work) as cc-by-sa. The latter is mainly done for convenience as it is much easier to deal with a single license that a list of several ones. And obviously licenses less permissive than the CC-by-SA are not considered beneficial to the project and thus rejected.

Regarding my second point... I quite lengthy discussed this on OGA some time ago in the comment section of a post by Bart:
http://opengameart.org/content/art-copyright-and-value (same username)

[Cacatoes]

So, we start from "relicensed into one license", then now "gpl-compatible", how will we end ?

In my previous post I stated GPL-compatible wasn't really the criteria, since Creative Commons also are accepted, and you should know well CC aren't compatibles with GPL.
On the contrary, Debian defines something which is closer to "ethics", and which indeed shares some properties GPL has. That's not surprising, Stallman probably had a huge influence on license matters at this time, and formulation of the principles he formulated for GPL can be tracked back into DFSG.

As I mentionned in my previous posts, my attention was in particular towards the wording. "License work into GPL", "relicense it", "GPL compatible licenses", "sharing same principles", don't mean the same thing. So, beware here not to give your own interpretation of DFSG too quick, specially when the text we refer to has been written with care and strictly chosen words.

I am not aware of any project that says you have to use CC-by-SA for example

Really ?

Found in a second: viewtopic.php?f=22&t=2316

Target:
Free/Open-Source (Art will be licensed under the Creative Commons BY-NC-SA License)

Does it say CC-BY-NC-SA compatible ? No, it says: Art WILL be licensed under THE ...
I agree it doesn't explicitely prohibits CC-BY-SA or CC-BY or MIT-licensed art, but it doesn't say "CC-BY-NC-SA" compatible licenses, and I heavily suspect this project, like many others, didn't think that much about "okay, it's fine if contributors release their work under other licenses".
You mean this is implicit ? I mean this omission is the proof other ways weren't really thought about.
At least, this is misleading: some contributor will think s/he has no choice but to use that license.
At worse, this is stubborn: the lead thinks material HAS TO be published under that license, none else.
In practice, that translates to otherly licensed files not being present in the source tree, restricting the whole project production to "one unique way to think", rather than making part of this production available for use in slightly otherly licensed projects. Looks like selfish way of doing is it ?

Other aspects of effects I can mention:
- it doesn't help with collaboration between projects but also between individual who don't exactly share the same view of licensing
- it doesn't help these projects since maintaining a single license tree makes people will only borrow from compatible sets, not with ones which share the same spirit, and will eventually relicense some "very free" license into some "just free" license simply to comply with the tree.
- as I said, people will mainly think they *have to* produce their stuff under some particular license, when they could have chosen other ones if they had been informed better. Which is kinda like "hey, I think that about licenses, here, now you think just like me, w00t !"

Bonus article taken from a news website: http://www.moviemaker.com/articles/prin ... usch_2972/ ; oh, original is old shit, but french translation was just recently published.

[amuzen]

1) My intent was to get feedbacks about eventual issues you would see with a project using several different and eventually incompatible licenses for art.
2) Most FOSS game project identify themselves as using a single license for art, and don't keep otherly licensed files in parallel, so I was wondering if it wasn't some blind habit which had few good reason to be.
3) Some project still are embarassed about choosing license, so I tried to point out accepting several may help with license wars, and would help projects to get assets from a wider range of external sources.
4) And finally, have some clues about how projects organize themselves (file structure) when they use several licenses.

The way how I see this issue is that approving of incompatible art licenses has both advantages and disadvantages, and it depends on the situation whether it'll be beneficial or harmful to you. The advantage is that you might be able to find more art, and the disadvantage that mixing two files of your project may trigger a license violation.

If you intend to only use external art with hardly any modifications, incompatible licenses are fine. If you need custom art but there's no need to base it on other files, it's still fine. If there's so much art under incompatible licenses that it'll save lots of time and effort, it could be a good idea. Likewise, if you don't have other developers or all of you are license savvy, you can probably handle the complications even if you need to mix files.

On the other hand, if pretty much all the external art you need are compatible with one license, it doesn't hurt much to simplify your licensing terms. If external art tends to always require modifications, for example because you try to achieve a consistent style, being unable to mix files can get rather annoying. If you have to create the most of the art yourself, there's little point to use incompatible licenses. Lastly, if you have contributors who aren't license savvy, having multiple incompatible licenses would likely be too much for them to handle.

From the bookkeeping point of view, there isn't much difference between one or multiple licenses if the set of licenses includes something like CC-BY that requires attribution. In that case, you need to have some kind of author/asset list regardless. If you store the attributions to a text file as a {file, author} pair, you could just as well add the license there too. At least remembering the PD/CC0 status of files can be useful because attribution can get unwieldy if, for example, you use multiple source images to texture paint a skin for a 3D model.

[Julius]

-------quote="Cacatoes"--------
So, we start from "relicensed into one license", then now "gpl-compatible", how will we end ?

In my previous post I stated GPL-compatible wasn't really the criteria, since Creative Commons also are accepted, and you should know well CC aren't compatibles with GPL.
On the contrary, Debian defines something which is closer to "ethics", and which indeed shares some properties GPL has. That's not surprising, Stallman probably had a huge influence on license matters at this time, and formulation of the principles he formulated for GPL can be tracked back into DFSG.
----------

Well the DFSG is obviously geared towards GPL compatibility... they simply choose to write it more vague to not get into discussions about "really free" (MIT/BSD) and Free (as in coply-left/GPL) which was a big issue at the time and has luckily settled down a bit by now (I feel you might be still affected by it a bit though ).
Regarding CC-by-SA and GPL compatibility... it's not as clear as you make it sound. Back in the day the CC-by-SA 2.5 was thought to be completely incompatible with the GPL and thus strictly refused by the Debian foundation (which is a case in point toward what I said earlier), but with CC-by-SA 3.0 they included a bit of the unclear license term with the intend to make the CC-by-SA compatible with the GPL (but funnily enough not vise versa). This cause a HUGE debate in the Debian foundation weather or not they could include the CC-by-SA as an accepted license now, which ended with an acception by a tiny margin which is still not uncontested to this day.

-------quote="Cacatoes"----------
As I mentionned in my previous posts, my attention was in particular towards the wording. "License work into GPL", "relicense it", "GPL compatible licenses", "sharing same principles", don't mean the same thing. So, beware here not to give your own interpretation of DFSG too quick, specially when the text we refer to has been written with care and strictly chosen words.
---------------

My point is that licenses should be compatible and thus allow for re-licensing of bigger projects as a whole as anything else is simply a license nightmare. In praxis this usually means GPL compatible.

------quote="Cacatoes"---------
Does it say CC-BY-NC-SA compatible ? No, it says: Art WILL be licensed under THE ...
I agree it doesn't explicitely prohibits CC-BY-SA or CC-BY or MIT-licensed art, but it doesn't say "CC-BY-NC-SA" compatible licenses, and I heavily suspect this project, like many others, didn't think that much about "okay, it's fine if contributors release their work under other licenses".
You mean this is implicit ? I mean this omission is the proof other ways weren't really thought about.
At least, this is misleading: some contributor will think s/he has no choice but to use that license.
At worse, this is stubborn: the lead thinks material HAS TO be published under that license, none else.
In practice, that translates to otherly licensed files not being present in the source tree, restricting the whole project production to "one unique way to think", rather than making part of this production available for use in slightly otherly licensed projects. Looks like selfish way of doing is it ?
----------

Well I can't speak for the project lead (and since he choose the NC option which I consider extremely harmful to free sharing, I don't want to defend him), but I think you are interpreting too much in this simple wording. For sure they will also accept other more permissive and compatible licenses (and thus it is as you said "implicit").
And it makes sense from a project management point of view to distribute a project as one package under one license... you can still mention the original individual licenses in the source repository... but in praxis you don't really need to do that either as simply ripping of art from another project is usually considered a bad habit, so you will have to get into contact with the original author anyways and he can tell you under which license terms he is willing to distribute his or her stuff (or even relicense it). Alternatively the artists can upload they artworks independently on a website like OGA where the precise individual license in clearly stated.


-----quote="Cacatoes"------
Other aspects of effects I can mention:
- it doesn't help with collaboration between projects but also between individual who don't exactly share the same view of licensing
- it doesn't help these projects since maintaining a single license tree makes people will only borrow from compatible sets, not with ones which share the same spirit, and will eventually relicense some "very free" license into some "just free" license simply to comply with the tree.
- as I said, people will mainly think they *have to* produce their stuff under some particular license, when they could have chosen other ones if they had been informed better. Which is kinda like "hey, I think that about licenses, here, now you think just like me, w00t !"

Bonus article taken from a news website: http://www.moviemaker.com/articles/prin ... usch_2972/ ; oh, original is old shit, but french translation was just recently published.
----------------------------------

I think what it boils down to is that you are from the BSD/MIT group that doesn't consider copyleft as truely free and thus are frustrated when non-copyleft artwork is simply re-stamped as copyleft artwork. But honestly... that is how coplyleft is intended to work, so to say it's precise purpose. You can of course disagree with that "free-er than free" idea, but the past has shown its effectiveness and for practical purposes it hardly has an disadvantage over license like MIT/BSD (or even CC0 for that matter).

P.S.: real quotes didn't work with more than four internal quotes... sorry for the difficult to read text.

[mdwh]

Not sure I fully understand the issue but...

When I use 3rd party media, I tend to distribute it under its original licence, simply to save me the legal worries of working out what is and isn't compatible when it comes to relicensing.

But if I was having someone create or submit something for me, I can see the advantages of specifying a particular licence, to keep everything simple and being able to release the project under a single licence (or say, one licence for binary, and another for the media). Releasing your artwork under one licence doesn't prohibit you from releasing it under other licences too (unless you've assigned your copyright over) - but that's up to you to do that, and is better done by hosting the art separately I feel.

[Cacatoes]

I was going to answer all this, and even wrote some offline answer, but I'm unsure if this is necessary. I'll do if I feel it's right.
I agree & disagree but still I appreciate inputs you wrote