I noticed in another topic you mentioned the renaming of AudibleInstruments,
and this made me wonder if there are some lessons to be learning here (by us)) about licensing when porting modules.
so, as a dev, it may be useful to know what the ground rules are here…
if for example, I decide to fork/port something from vcv to mm.
ofc, Im familiar with open source licensing (MIT/GPL3 etc)
but im concerned theres some ‘devil in the details’ here.
(though perhaps Im not so up on the artwork side for panels)
so, specifically…
so, can I ask why this was done? as its pretty confusing for users.
(and, ofc, Im sure there is a good reason !)
I know that MI do not like/allow 3rd parties to use their names.
is vcv also ‘protecting’ AudibleInstruments ?
I know there was some ‘fuss’ over the panel artwork when someone ported vcv over to iOS… is this all related?
note: ofc, artwork can be protected , so ‘fuss’ is perhaps trivialising.
however, it seemed nit picking to say it was covered by GPL, but not the panel.
(frankly, it felt like there were other reasons for this fuss… this was just used as a leverage point)
anyway… it has made me wonder, if we need to ‘tread carefully’ in this area.
(*) also arguably, its not allowed with GPL3, as the svg IS part of the package, GPL3 doesn’t really allow for separate of parts
Nothing special, just normal courtesy of contacting the author of the work and seeing what they think. Sometimes the license is not clear where exactly the line is drawn, and it’s good to know what they would like to see happen with the new project: example: do they prefer you keep a separate fork or want to integrate changes upstream? Just basic consideration for another person’s work, even if the license technically allows for use without reaching out.
That basically sums it up. I heard about that “fuss” (I don’t know all the details), and I just wanted to steer a wide path clear of any kind of issues like that. So I made a choice to use our own names and artwork. I talk to Emilie first and followed her recommendations, and have been in conversation with Andrew (mostly about other MetaModule things), but the choice to do AI=>CI was my own, just to avoid any potential of toe-stepping or bad feelings. Also, practically speaking, we had to re-do the artwork anyways to make legible PNGs on the small screen. So changing the names just sealed the whole deal. I also intended to move the basis of our port to the original MI module code, but it didn’t happen in time for v1.0. So using the AI names in that case wouldn’t have made much sense.
I would hope that it’s not too confusing/frustrating for users after making a few patches with the CI modules. The layouts and control/jack names are (mostly) the same, so sight recognition and “muscle-memory” (if that exists for virtualized modules?) should still be helpful. Once we add tags and search/filter for modules, it should be no issue at all (I still type “Plaits” in the VCV module browser, so even if MM called it “Macro Oscillator 2” it wouldn’t change anything for me – but maybe I’m not in the majority here?)
A conversation with the author should make it clear if this is “great! go for it!” situation or not.
Cool , yeah …
It’s an interesting one … I think we all have different ideas about the benefits / motivations/ role of open source … and that affects our approach.
Nothing new … it’s why we have so many license type , some of which are only subtly different.
anyways yeah, I view open source devs as a community. In that sense, courtesy is important.
I’m not sure if other issues having to do with the VCV implementations came up, but with physical modules, a lot of the fuss was: if cloned modules used the same names, there was the possibility that some people would think they were “official” MI products. Using different names made it clear that they were made by other companies.
no that was not really an issue, Emilie was clear about this very early on, well before VCV existed , Johannes & I discussed this when we ported some mi modules to Axoloti - Emilie was happy as long as we didn’t use brand names or imply it was supported by MI.
(at that time, Emile was happy with names like Elmts… but refined the guidelines later, adding examples of what was ok)
the ‘fuss’ was that whilst the source code was open source (in vcv /mi), Andrew said the panel art was not (it used a different license) , and hence why miRack could not put the vcv mi modules onto the App Store.
not saying Andrew was wrong, rather just it muddied the waters a bit.
e.g. imagine an open source synth not being able to forked/released as it has UI elements that were not ‘distributable’.
(you can argue its different, but its certainly makes the waters murky)
anyways… was just interested if there were other lessons learns, as 4ms has ported quite a few modules, so perhaps other devs had concerns/requests.