Replacing no-derivs artwork from scratch

[AriaSalvatrice]

Right now, "unless the module is really essential, CC-ND is not allowed".

It would be good if we could instead replace all no-derivs graphics with new ones, created entirely from scratch, but conforming to the same metrics and semantics.

A few questions to consider:

• Is anyone working on this already? (So if I make anything I can coordinate to avoid clashing with their aesthetic)
• Which assets should be replaced?
• Are there some specific design guidelines, a Cardinal color palette, or simply aesthetic preferences to keep in mind?
• Assuming assets are replaced by the book - create an entirely new file that matches the metrics of the original artwork - are there any legal or moral issues to consider?
• Can it be argued that the code part of the widget library or the core modules are covered by no-derivs, or by trade dress moral rights?

[falkTX]

I wrote that rule because I expect very few contributions and know I am never going to do it myself.

No one I know is working on this, so feel free to start. Now some answers:

• Which assets should be replaced?

The CC-ND ones, afaik it is only Core and Fundamental panels that have this restriction.

• Are there some specific design guidelines, a Cardinal color palette, or simply aesthetic preferences to keep in mind?

Nothing is really defined at all, though I like the idea of them being color-inverted of the originals. At least in regards to the color palette.

• Assuming assets are replaced by the book - create an entirely new file that matches the metrics of the original artwork - are there any legal or moral issues to consider?

Yes, recreating the file is not something I would find acceptable. It goes into grey territory, as it is basically a copy of something else, even if done manually / from scratch.

But I find it hard to say how it should look like. At least for the audio module, the meters are nice to have, same for L/R jack pairs. Since this is always used in a single device environment (the host) the whole thing about picking/selecting a soundcard can go away.

• Can it be argued that the code part of the widget library or the core modules are covered by no-derivs, or by trade dress moral rights?

No, code is GPLv3+. You cannot apply such restrictions to GPL code, it would stop being GPL and become its own custom license.

[AriaSalvatrice]

I believe that creating faceplates with unmistakably different aesthetics to the same metrics is possible. However, forking the modules to create a new layout is also an option, but it entails more maintenance, should the core modules change later.

But a replacement component library would required to match the exact same metrics: modules creators have designed against it. And it should be noted that the component library directly names real-life counterparts (e.g., Davies1900hKnob, Rogan3PBlue) while also matching their real-life metrics.

[falkTX]

Great news, the Core panels already have a CC-ND-free variant over at https://github.com/Rcomian/Rack/, see https://github.com/Rcomian/Rack/issues/1 for details. So I am thinking of using those files. I dislike the new glossy look of the v2 panels, this allows us to keep the old design.

[falkTX]

Wait, I am stupid. These new unbranded graphics are still CC-ND. might as well do nothing then :rage:

[Rcomian]

I have serious concerns about the whole idea of "replacing graphics". Technically, the current vcv team seems focused the svg's themselves, but I'm not sure the law is. And when Andrew sells rack to oracle for a billion dollars, it's the law that counts.

The "design" of the module includes a lot more than just the svg, it's the workflow, it's the chosen controls and their positioning. I don't believe it's Andrew's intent to enforce those items, but the designer did also place those controls. And they're defined in code, not the svg. So to me, just replacing the svg still has potential to be considered a derivative work. We'd need to redesign the whole panel to be safe, and then because that includes code, keeping up to date with upstream is an extra problem.

I really don't like the trademarked CC-ND artwork in vcv rack. I got hold of the unbranded versions from Andrew for that reason, although he kept the ND lock and added an NC lock on them too.

Freerack was my attempt to provide a cleanroom approach to build other forks from. But if you're wanting to modify those base graphics - it doesn't help much.

[falkTX]

I am not modifying the original SVG files though, plus the code is GPLv3+ not CC-ND. You cannot place such restrictions on top of GPL code, it goes completely against its existence.

I know it is a grey area, but it is the best we can have at the moment. If we only partially show the panels as to hide the logo, does that count as derivative too? If one modifies the screen tinting or color balance, is that derivative? Cardinal is perhaps different since it intentionally modifies the rendering of CC-ND based artwork, though this is a can of worms if we start outlawing such practices. In case you are not aware, the library used to render svgs in Rack, nanosvg, lacks a lot of official SVG features (such as text). Some SVGs will not render correctly if made in certain ways. As I see it, the way Cardinal does things is akin to a broken svg parser. If the SVG reading code parses and renders the file incorrectly, is that derivative?

It just seems to me like we cannot place the 2 together, the artwork and code, in technical terms.

Cardinal never actually produces derivative works as a file. It is not picking CC-ND files, transforming them, and generating new files. Due to limitations in nanosvg, it actually cannot do this, it only reads, it doesn't write SVGs. CC-ND states in its summary:

NoDerivatives — If you remix, transform, or build upon the material, you may not distribute the modified material.

Cardinal does not distribute such modified material.

[Rcomian]

Yeah, the code is GPLv3, my point isn't that we can't modify it, it's that i feel a lawyer might try to argue that we need to in order to constitute a new design. Also IANAL and I haven't spoken to one about this. However, if we're dealing with evil companies that have lots of money and motivation to squash little people, I'm thinking worse cases of what they'll try, not even necessarily what will work.

But a derivative work does not have to be a modification of an existing file. If I drew a module on a piece of paper, referencing the core modules as I did so, legally, my work could be considered derivative of the original work.

I also think that Cardinal's current approach is fascinating. And totally a grey area. Using the straight approved vcv unbranded graphics was intended to not be a grey area. I don't think Cardinal is creating a derivative work here. But I feel it's more interesting in how that plays out.

I'm not suggesting Cardinal is doing anything wrong. Or that Cardinal should adopt FreeRack's svg's. I'm pointing out that I feel that the task of replacing the repository graphics for the Core modules could be more of a grey area (and more work) than is obvious at first glance. Cardinal's rendering approach is probably the most likely to work if we're going to start with CC-ND files and want them to look different.

Anyway for me the process was to be:

• First approach, get unbranded graphics so that at least forks can avoid trademark infringement. This means forks are then unambiguously legal, although they can't change the svg's of the core modules.
• Next (probably never), redesign the core module svg's, this will allow forks to change how these look, add their own logo's, design elements, themes, etc. This leaves the derivative work ambiguity, however.
• Next (almost certainly never), redesign the core modules entirely, including UI elements, control placement, etc. This would squash the final lawyer loophole of looking at "derivative works" for the module design as a whole, rather than just the CC file.

[falkTX]

Yeah, the code is GPLv3, my point isn't that we can't modify it, it's that i feel a lawyer might try to argue that we need to in order to constitute a new design

You can't apply design rules to code though, code is code and the license is pretty clear being GPLv3+.

However, if we're dealing with evil companies that have lots of money and motivation to squash little people, I'm thinking worse cases of what they'll try, not even necessarily what will work.

Worst they can do is the project gets a C&D and disappears. Great optics for VCV :+1:

But a derivative work does not have to be a modification of an existing file. If I drew a module on a piece of paper, referencing the core modules as I did so, legally, my work could be considered derivative of the original work.

I can see how that thinking goes, but you are still within your rights to do so. You just cannot then distribute such work, but there is no issue keeping it to yourself. Do you think the very act of copying CC-ND artwork, no matter the medium or target, is a license violation?

I'm not suggesting Cardinal is doing anything wrong. Or that Cardinal should adopt FreeRack's svg's. I'm pointing out that I feel that the task of replacing the repository graphics for the Core modules could be more of a grey area (and more work) than is obvious at first glance. Cardinal's rendering approach is probably the most likely to work if we're going to start with CC-ND files and want them to look different.

Thanks, your comments are appreciated.

I would totally use the FreeRack graphics if CC-ND was to be removed, because I want it to have dark background. As-is, even if I was to place FreeRack Core components in Cardinal, I would still have to modify them like the originals in order to get dark mode. So the FreeRack files are still a problem, might as well use the originals then.

Anyway for me the process was to be:

* First approach, get unbranded graphics so that at least forks can avoid trademark infringement. This means forks are then unambiguously legal, although they can't change the svg's of the core modules.

While it is good to have unbranded graphics, not sure if it matters in the end. Cardinal does not host those source code files, they are referenced from the original repo. So we always end up with them in the cloned source code in the end.

On the other 2 final notes, @AriaSalvatrice already mentioned being interested on redesigning the Core panels from scratch. If that is done only Fundamental remains as CC-ND afaik

[falkTX]

After talking with some people responsible to packaging and dealing with license issues in several linux distros, it has come to my attention that CC-ND is quite fine, the problem is actually CC-NC. But still, I was assured there was a spot in contrib/multiverse like repos where it is not part of the main section of linux repositories, but a bit outside because of extra restrictions on the software (that is, the non-commercial clauses). Distributions do not have an issue with CC-ND actually, and it is not uncommon. As I was informed, they are quite okay for use in logos or a product/trademark design. Forks are meant to replace those logos, which is understandable.

For Cardinal, I have been replacing all the Rack code modules with custom ones, which are more optimized for plugin use and (in my opinion) will be simpler to use. I have received feedback that the many MIDI CC to CV, MIDI to CV, MIDI Gate to CV, MIDI CV to CC etc were all very confusing. Cardinal will have a single module for each task - 1 MIDI (to CV), 1 MIDI CC, 1 MIDI Gate and 1 MIDI Map - with each one providing both to-cv and from-cv conversions. This approach also makes it so that the Cardinal "Core" modules are distinct from VCV ones, thus the visual design cant be considered derivative. I did copy a bunch of code though, but that is mostly so that these modules work in a similar fashion and thus are compatible with the original Rack.

So, with this said, I am going to close this one as wont-fix. I added a few more details about module restrictions on the README, see https://github.com/DISTRHO/Cardinal#module-restrictions

The CC-ND that we have are for files that we do not change, or if we do (in runtime like Bidoo) it is done with permission from the author. It is only Fundamental that is a little bit of a problem right now. I have contacted Andrew to ask permission for the runtime dark mode (among other things) but I have yet to receive a response. In theory the runtime dark mode is legal, but I am not a lawyer so I dont know for sure. Will wait until start of next week to receive a response from Andrew, if I get nothing by Monday I will start to make some plans on Fundamental.

PS: Fundamental is not part of the Cardinal build right now, nor is any module that is slightly problematic. I removed those until it was 100% confirmed we could use them, slowly adding them back when so.