OpenMPT logo and icon redesign (was: Some custom MPT icons I made)

[Saga Musix]

A general comment: We currently have many different icons used for different purposes: application icon, file association icon, website favicon. I do not think this is necessary or useful and would prefer to unify them and use a single icon design for all 3 use cases.

I agree in general, but I think for the file association icon, it would be nice to keep some of the current aspects (waveforms and pattern data) to communicate the file contents more clearly. In larger variants (32x32 and upwards) it might be okay to combine those with the potential new ModPlug icon though.

[manx]

A general comment: We currently have many different icons used for different purposes: application icon, file association icon, website favicon. I do not think this is necessary or useful and would prefer to unify them and use a single icon design for all 3 use cases.

I agree in general, but I think for the file association icon, it would be nice to keep some of the current aspects (waveforms and pattern data) to communicate the file contents more clearly. In larger variants (32x32 and upwards) it might be okay to combine those with the potential new ModPlug icon though.

I would not mind the pure application icon as file icon. However, i think most importantly is that I do not really like the current sheet-of-paper document style of the file icon. The document aspect of the icon is kind of redundant, wastes space and looks somewhat dated IMHO.

In general, having any kind of stylized pattern data in any icon would be great, if the result looks ok as a whole. However, i suspect that would interfere with a modern and clean and simple look, like in the direction of the current design suggestions.

[ellobo]

Just to re-state comments from the aforementioned private discussion. The logo I designed is obviously based on the MP in the current logo. My intentions were to modernize it and for it to be on par with logos from the biggest DAWs out there. Like Harbinger, I'm personally not a fan of having the plug in the logo itself as it doesn't quite match with the thickness of the letters. I also firmly believe that less is more. However, I could see the plug being a part of accompanying graphics that could be used with the logo. As for the application icon, I do think MiDoRi was heading in the right direction. I think the logo in a black box is the way to go.

[Saga Musix]

Yep, the black version would definitely be good for a logo / icon. It would also match the current website favicon.

[Alice (Midori)]

Damn, i'm usually not a big fan of modern flat design, but that new ellobo's icon and logotype look really gorgeous!
*thumbs up*
As for the idea of one image serving as both application and file association icons, I'm on the totally opposing side, pretty much hating that trend, ever since it became a standard practice in Windows with version 8 (the OS sets unaltered program's icon for associated extensions, as opposed to creating a new one, with paper background, and there's no user-friendly GUI anymore to set them to own liking, which is annoying, because i like to be able to distinguish a document from the associated program).
That said, I'm all for redesign of both (I might try my hand at doing the document icon sometime actually)

[Saga Musix]

Random thought for ellobo: Maybe the plug can be worked into one of the letters as negative space? Although it might be hard to recognize then.

I'm also not a fan of having the application icon being identical to the file icon, but I'm sure we can work that out somehow.

[ellobo]

Yea I'll work it into the look somehow. Thank you MiDoRi! I appreciate that. We can figure something out to distinguish the file icon from the application icon.

[manx]

I did not mean to say that application and file association icon need to be identical. I just meant to say that they do not necessarily need to be different.
I do consider file association icons that resemble a sheet-of-paper rather stupid though. There is IMHO no point in conveying the document metaphor visually in that case because it is always unambiguously clear from the context the icon is displayed in. Also, file icons are often displayed rather small, at which point the sheet-of-paper outline consumes valuable visual real estate in the icon. The icons can of course be slightly different, but not too much IMHO, because that would visually dis-associate the file from the program.

[manx]

As an application icon, I think using ellobo's design on a rounded black (or dark) square as MiDoRi did in the first version could look rather good.

MiDoRi's version with grey background and green sound wave does not look all that appealing to me. Maybe retry with a black/dark background and grey-ish or red-ish waveform? I guess something in that direction could work as a file icon (if we want that to be different). The waveform in the background could also work with ellobo's design of the "mp".

As for ellobo's wide logo design (with the "OpenMPT" text), I do not like the way the OpenMPT text looks. The "O" looks somewhat disconnected from the "p" (feels like some kind of kerning/spacing/whatever problem with the font).

In any case, I am not a graphic designer, and I will listen to you guys when you think something would be utterly stupid visually. I am merely trying to give useful input, not trying to direct (please stop me if I start doing that). I know from experience that it is important to have an actual designer (not implying professional, but someone who has experience with these kind of things) involved in any final call on a design.

[manx]

Also, ellobo and MiDoRi, are you fine with the licensing of any artwork that I suggested earlier?
Saga Musix, do you have any additional opinion on that?

[Saga Musix]

No, I think the options are both sensible, especially since they would also be compatible e.g. with putting them on Wikipedia or similar.

[ellobo]

You're right about the kerning. I would fix that before we go live with the design. Maybe a black circle would work as well for the icon. I'll try it out. As for the file icons, we could just fade the colors if you want to keep the same shape. Just a thought. I don't really have a strong opinion about it. I don't really have an opinion on the licensing either as long as I get credit for my designs and they won't be altered (after the final look has been approved by you guys).

[manx]

I don't really have an opinion on the licensing either as long as I get credit for my designs and they won't be altered (after the final look has been approved by you guys).

The BSD3 license (see the table at https://choosealicense.com/appendix/ as well as the license text at https://choosealicense.com/licenses/bsd-3-clause/) allows modifications (even without mentioning the modifications). It requires giving credit and prohibits showing endorsement by the original author for any derived works. The whole of OpenMPT (with the exception of external libraries that we use) is licensed under this license, and even though application of this license to artwork is somewhat difficult (I Am Not A Lawyer, though), I do not think we would want to license certain parts of OpenMPT not (at least also) under this license.

The CC-BY-4.0 license also allows modification, however it requires the modifications to be clearly mentioned. It also requires giving credit to the original author and also prohibits showing endorsement by the original author for any derived works.
See https://creativecommons.org/licenses/by/4.0/.

There is also a CC-BY-ND-4.0 license (https://creativecommons.org/licenses/by-nd/4.0/) which would prohibit all modification. However, given that BSD3 already allows it, I doubt that would be of much practical use.
Also, use on Wikipedia would be impossible (see https://commons.wikimedia.org/wiki/Commons:Licensing#Acceptable_licenses) under CC-BY-ND-4.0. I am not sure if BSD3 itself is disallowed on Wikimedia Commons. However, an explicitly allowed license would certainly be preferred. An acceptable CC license would make things way easier and clearer (which is precisely why I came up with the suggestion of dual-licensing the artwork in the first place).

CC-BY-SA-4.0 license (https://creativecommons.org/licenses/by-sa/4.0/) would require any modifications to be released also under the same CC-BY-SA-4.0 license. As far I am concerned, I think, dual-licensing under BSD3 and CC-BY-SA-4.0 could also work for OpenMPT artwork in practice, even though the spirit of CC-BY-SA-4.0 is more like the spirit of GPL-style licenses and less like the spirit of BSD-style licenses which OpenMPT uses. I would still highly prefer not to have this restriction on the secondary/other/dual-license for the artwork, as it makes the 2 licenses rather inconsistent in meaning and spirit.

In any case, consider the following:
If someone (for whatever reason) does some modification to OpenMPT and distributes it, he/she is certainly allowed to do so by the OpenMPT license. Even though we would like the name and branding to be changed in that case in order to avoid confusion, this is not required by the license itself. If the artwork license would prohibit any modification, anyone modifying OpenMPT would either need to stay with the exact same original artwork (and thus would be forced to give somewhat wrong impression) or to use completely new and unrelated artwork all together (which will force anyone who wants that to do more work). (Something similar (though not identical, something trademark related was also ivolved AFAIK, I will not try to go into legal details here, because I Am Not A Lawyer) to that happened for the Mozilla Firefox branding which made it impossible for the Debian Linux distribution to actually name their firefox browser "Firefox" and use the commonly used firefox logo. They had to invent a new name and logo).

I am aware of the fact that designers tend to want to never ever see any modifications to their work by others (I can even understand the reasons why), however that mindset kind of conflicts with the principles of open source software. I do not expect us to randomly change your design just because we feel like it; that would be highly unlikely to happen. However, I do not think we could accept contributions with this restriction written into the license, as that would make modifying and distributing OpenMPT harder. It would even prevent us from changing something as simple as the dimensions of the logo background, even if required for any particular use context. Also note that any specification or limition with respect to who can modify the design would also be unacceptable, because change in maintainership of open source software as well as forks or otherwise derived software could happen any time and are the foundation of how open source works.

If our license requirements conflict with what you are willing to license your work under, we would very sadly have to reject your contribution.

[Alice (Midori)]

As far as licensing is concerned, I'm absolutely ok with any copyleft-style license you want to use, (otherwise I wouldn't have even thought of contributing to an open project like OpenMPT, right? ) including ones that permit derivative works, but it would be nice to choose one that requires a mention of the original author (well, in fact my icon itself is a derivative work too, lol). BSD3 license seems to fit perfectly in this case.
Disclaimer: I'm not a lawyer either

[manx]

As far as licensing is concerned, i'm absoluitely ok with any copyleft-style license you want to use, including ones that permit derivative works,

Just to be clear here (and I think we should be absolutely clear with this stuff):
"Copyleft" is usually used as the term to describe licenses like GPL2, GPL3 and CC-BY-SA, which all explicitly request that modified or derived works are to be released under the same license as the original work. OpenMPT's BSD3 license as well as the suggested CC-BY license do do not require derived works to be released under the same terms and are thus not copyleft licenses. Both (as well as the just mentioned copyleft licenses) are of course considered free and open.

See https://en.wikipedia.org/wiki/Copyleft.

but it would be nice to choose one that requires a mention of the original author

All licenses so far discussed here require this.