Menu
▾
▴
#53 ODF import from HW4.x
Hi,
It would be nice if GO could at least import HW4.x odf files. As these are simple XML, it shouldn't be that hard... Even better would be if GO could then write such imports as a base .organ file form which further development would be possible.
Benefits are that fewer experts are needed to convert unencrypted HW-sample sets to GO.
Discussion
After reading "As these are simple XML, it shouldn't be that hard.", I'm really tempted to reply: "As its so easy, why don't you just write I XSLT to transform the XML into a ODF?".
There is no public documentation of the HW format.
As far as I know, there are at least 3 different HW file versions (HW4.1 might have introduced a new version). Being able to get a compressed and a uncompressed HW file of each version would allow to write converter between both formats. The uncompressed form allows guessing, what a subset of options is for and might help deriving a mapping from the older HW format to newer HW format. There still remain options, which will need further explanations.
The GO internals are different from the HW internals so you can't 1:1 map between both formats (eg. HW seems to create sampled tremulants with alternative ranks, while GO adds all samples into one pipe).
A output of a HW to GO convert has the drawback, that the organ file would be a derived work of the HW file. Sharing, changing ... would require aproval of the HW sampleset creator.
https://github.com/e9925248/grandorgue-odf
Not to mention that the HW v2, 3, 4 etc ODF formats are proprietary and that we do not have permission from Milan Digital Audio to parse them (and we won't get permission either!). MDA have threatened prosecution of other applications that did import HW files. In my opinion we should also get rid of HW1 backward compatibility as GrandOrgue has now moved far beyond that origin.
—
Sent from Mailbox
Last edit: Martin Koegler 2015-01-19
We've already more or less prepared for leaving the old .organ format anyway with the new panel 2.0 format. It would only be necessary to transform the warnings into errors and it's no longer possible to load a HW1 file in GO. Also, a current GO compliant .organ file already is not possible to import into HW either like the old format could (I think, as I cannot verify it myself).
As I've done a few conversions of un-encrypted HW samplesets I can say that the XML is not that obvious to decode in a text editor. Certain things could be read, like for instance the coordinates for graphics, only after a lot of detective work and ID number matching.
In my opinion it's actually easier to build an independant version of the sampleset, using the available files as a source together with some common sense, than to try to decode the XML. What we really need for GO is a tool for .organ file creation that's both complete and possible to use without knowing all the details of the odf format.
Kind regards
Lars P
I don't spot any risk from importing any unencrypted HW file format.
Same for a HW to ODF converter.
A converter might tempt users to create a legal risks for them, as they might need the permission of the sample set creator for doing a conversion and, as the result is a derived work of the sampleset, they need the permission of the sampleset creator for modification/redistribution.
Any person, who has a contract with MDA (eg. to the get HW XML reference, ..), might be persecuted, if the contract contains a clause, which forbid such actions. All persons without such a contract are safe.
The only risk for reading encrypted formats are DMCA and similar copy protection paragraphs in other countries. If you make sure, that reading the encrypted format is not a format covered by these paragraphs, you should be safe.
So I don't see any reason to drop the remaing HW1 support.
PS: I would be interested in the MDA "claims".
I didn't try to start a HW/GO war.
Facing reality as a GO user, there are a lot of HW-compatible sample sets I can buy and only a few GO compatible sample sets. Most of the latter tend to be of lower quality than their HW-equivalents. There are users capable converting one format to the other, but they are rare. One German GO-site proclaimed converting "all" unencrypted HW-ODF's from a certain sample set creator to GO's .organ format. That was two years ago...
So as an end user, one can only buy HW-sample sets, which are useless for GO.
I'm not asking to create a flawless import feature that can read sample set builders minds, just a feature to create a smart starting point (and preferably a working one) from where a non-expert user can go from.
From a user perspective, I'm not interested in technical details. As a developer, I know that XML is extremely easy to read. I don't know anything about the technical inside of GO, so I can't assess the impact of converting one format to the other. I leave that up to you.
Claiming to have created a "derived work" by reparsing an ODF file sounds flat out ridiculous to me. It would be like suing an art buyer for reframing his legally bought painting… If MS thought like that, they could sue the whole planet for parsing their propriety formatted MS-office documents by non-MS software. I don't know any copyright system, including the US', that will backup such a claim.
From the creators perspective - the sample set builder - there would be no gain in suing for this reason, for they would be able to target a wider audience without a single drop of sweat. You don't shoot a chicken which lays golden eggs when the eggs are yours anyway.
It would be a completely different matter if you would resell complete sample sets as GO-compatible without prior permission from the original creator. But I don't think anyone with respect for copyright would want to pursue that.
The issue with XML is, that it might be easy to parse, but you have to interpret the parsed data - that is the complicated part. Compare it to trying to understand a foreign language, where you know the letters, but you don't have got any dictionary/grammar book.
Your MS example doesn't fit.
The situation would be like if I convert a MS office document to a LibreOffice document. Neither Microsoft nor LibreOffice can claim any copyright in this case. But as the original office document contains a copyrighted work, the converted document still contains the same work. So the copyright of the original author is still valid for the content in the converted document, which means, that the original license still applies.
As most commercial samplesets will very, very likely forbid redistribution, redistribution of a (possibly modified) converted ODF will be forbidden too.
MDA consider the HW ODF as part of their definition of "Software" that
is governed under their license when installing Hauptwerk. So, in
addition to the copyright of the original sample set producer, we have
to consider the license of MDA.
Also remember that there are different types of "Proprietary"
formats... some are "Open" and others are "Closed". In the Wikpedia
article on Proprietary formats, MS Word is listed as "Controversial".
The HWv2 and above ODF formats are closed proprietary formats that are
under license agreements by anyone who installs one.
2.2.
Limitations On License. Except as expressly authorized above, You
and/or any person(s) acting with or for You may not:
(a) directly or indirectly sell, lease, rent, license, sub-license,
redistribute, lend, give, transfer or otherwise distribute or use the
Software without written consent from Milan Digital Audio;
(b) modify, translate, or create derivative works from the Software,
assign or otherwise transfer rights to the Software or use the
Software for timesharing or service bureau purposes;
(c) reverse engineer, de-compile, disassemble or otherwise attempt to
discover the source code or underlying ideas or algorithms of the
Software or any subsequent version thereof or any part thereof;
(d) attempt to modify any file or folder installed as part of the
Software, except using functionality provided for the purpose within
the Software, or when specifically advised to do so within the
Documentation, or when specifically advised to do so by Milan Digital
Audio. (In particular, we reserve the right not to provide support if
you have attempted to edit any of Hauptwerk’s settings files directly,
or to edit, move or rename any of Hauptwerk’s files or folders
manually, unless we advised you to do so);
(e) use any license file, dongle, or other registration information or
software or hardware, that was not supplied to You by Milan Digital
Audio or its resellers or distributors, and for which written consent
for use was not given to you from Milan Digital Audio, for
registration of the Software, or use any means whatsoever to attempt
to enable the functionality of a Registered copy of the Software,
other than by paying for and registering it with Milan Digital Audio
or its resellers or distributors, and using the registered copy in
accordance with this Agreement;
(f) install and run the Software from a net work server, or run the
Software on more than one computer simultaneously, unless You acquire
a license for each simultaneous user of the Software;
(g) use any part of the Software or any media or other materials
supplied with the Software for any purpose other than that for which
it was supplied within the Software, without written consent from
Milan Digital Audio, unless such use is allowed by a separate
agreement. In particular, audio samples and other media supplied as
part of the Software may not be us ed with any other program unless
separately licensed.
3.2.
Intellectual Property Rights. The Software, the structure,
organization and code embodied in the Software are the valuable and
confidential trade secrets of Milan Digital Audio and are protected by
intellectual property laws and treaties. You agree to take all
reasonable measures to protect Milan Digital Audio's intellectual
property rights and to abide by all applicable laws
The only avenue open to GrandOrgue users is to write a request to the
sample set producers asking for a GrandOrgue version, and if that
cannot be supplied, then asking for permission to create a GrandOrgue
version of that sample set. If permission is given, then requests can
be made to the development team and advanced users for help in
creating the GrandOrgue .organ file for that sample set.
Kind regards,
GG
Last edit: Martin Koegler 2015-01-19
Graham, you are quoting from the HW license agreement?
In that case, any non-HW user is safe, as only HW users (and maybe other MDA customers too) have accepted that contract.
From the GO project perspective, I'm not scared, if MDA would start threating its own customer base.
You both seem to be missing the point here... Legally you can probably do this, but the HW community is going to look at GrandOrgue as if it were truely illegal. It is already viewed as suspect because of the "HW 1 Clone" status. Many organists are religious, and the moral high ground should be the path of choice for our user base.
Yes, this is from the HW license. ALL Hauptwerk sample set producers have had to agree to this in order to get the HW organ ID number from MDA, plus an even more controlling non-disclosure agreement if they have downloaded the CODM manual or requested the ODF manual.
IF you add HW4 import capabilities to GrandOrgue I can see MDA requesting that all major sample set producers add a clause to their licenses that specifically excludes use with GrandOrgue. They already will not post links to any site that mentions GrandOrgue, and delete any discussion that mentions GrandOruge on their user forum.
If you really want to pursue this, my suggestion would be to create a separate open source project that does the conversion of the HW4 sample set to GrandOrgue format. The problem with non-disclosure agreements is that I cannot tell you much about the possibility of other organ samplers being tested and being released soon. So there may be other formats to convert from / convert to.
I, personally, will not support the adding of a Hauptwerk Import function in GrandOrgue. I will also continue pushing for a new file format that is not based on HW1 .organ compatibility.
Kind regards,
GrahamG
—
Sent from Mailbox
Last edit: Martin Koegler 2015-01-19
@Graham,
I'm afraid you are mistaken.
First, you mix up the default .organ format of GO with an HW-import facility. Those are two separate things. I was suggesting the latter.
Second, you have no moral high ground when you openly support illegal activities. Both in the US and in the EU there are very stringent competition acts which forbid agreements to exclude competition in order to gain or maintain a monopoly. If proof can be found of the agreements you presume, Milan and the sample set makers are in for very serious legal trouble.
Lets be very clear about this. I have nothing against a well thought out commercial product as HW. If it fits me, I will buy it. Also it is IMO understandable how the reality of "HW-only" sample sets emerged. Up until now, there simply was no market for GO sample sets. The result however is that there is very little serious stuff you can buy for GO but old HW1 16 bit sets. If the world stays as it is, all you can do right now is either create a new GO-ODF yourself, or create your own sample sets. Both are not "consumer" acts, but "builder" acts. Not every consumer can be a builder, either by lack of skills, equipment, time and/or accessible organs.
If you want to change this reality, you have a few paths you can take.
Convince sample set makers of the market share they can gain with GO-compatible ODF's
They will have to invest in this, and as FOSS has a smell of "don't pay, won't pay", you have a few hurdles to take. There are for example already a few GO-ODF's for free. Why invest when "they" will do it for free anyway?
Create a commercial GO-only sample set maker and prove you can survive.
Any volunteers? Seriously, this will take years.
Offer a facility to use HW targeting sample sets unmodified with GO.
The advantage is for both the GO-user and the sample set makers. It will also unlock the GO-market for sample set makers. After that, HW and GO can happily coexist. If you feel better by buying a commercial HW license, that please do. If you are bound to linux, can't afford a license, have moral objections against spending offerings for anything other than charity, and/or want the freedom to experiment any way you see fit, you can use GO. The choice will be yours to make.
I opt for the last. Then afterward, you can develop unique and to-be-loved functionality for GO, which will trigger sample set makers to support GO out of the box. When the market becomes clearly visible and accessible, they will invest.
I rest this case. It is up to you all now.
Just my 2c.
Kind regards,
Pieter
Last edit: Pieter J. Kersten 2015-01-14
I'm not mixing up the default .organ format of GO with an HW-import
facility. The default .organ file and configuration IS HWv1 FORMAT.
That is what MyOrgan used as it was a HWv1 clone... GO has simply
added to it over the years. To put it bluntly, .organ files are
proprietary to Milan Digital Audio, even though it has become an open
format added to by the GO developers. Anyone can load a HWv1 sample
set into GrandOrgue. I would love to see the format completely change
and for a GrandOrgue sample configuration (organ definition file,
whatever) file to be named something different. So the default
load/open of GrandOrgue is a HWv1-import facility.
"Both in the US and in the EU there are very stringent competition
acts which forbid agreements to exclude competition in order to gain
or maintain a monopoly. If proof can be found of the agreements you
presume, Milan and the sample set makers are in for very serious legal
trouble."
So are you saying that creating a closed proprietary configuration
file, and requiring users to agree to not use it except with the
software program that it is used with, is illegal and immoral?
This requirement by MDA does not preclude using the target files of
the configuration (the wave and image files) in something else. It
just places the ODF off limits for any other use than with Hauptwerk.
As far as I am aware, software companies do this all the time with
data and configuration formats.
Sample set creators do then also add to the restriction stating that
their samples can only be used in Hauptwerk. Again, sample set
producers on other sampler platforms (NI Kontakt, PLAY, etc.) do this
all the time. Are they doing something illegal and immoral?
The right to protect your property (recordings and intellectual
property) is what these license restrictions do. They do not hinder
anyone from competing, so long as the competition create their own
samples and configuration files. But taking someones samples and
configuration files and using them where a license agreement prohibits
that use, surely this breaks both legal and moral standards?
If anyone brings an HWv4 import feature into GO I will remove all my
GO sample sets and encourage anyone else working with GO to do the
same. We should be working on making something unique and better than
HW (which we are, as we have convolution reverb options before HW
has). GO should not continue be seen as a HW clone.
Last edit: Martin Koegler 2015-01-19
I'm inclined to agree with Graham on this matter. I do think that MDA and it's software is a hornets nest we should not mess with. Nor do I see a great need for importing/converting their format inside of GrandOrgue. When I did a few conversions of samplesets from Sonus Paradis I even asked Jiri (as the original sampleset creator) first just to be sure before sharing the new files with the public.
For the underlying issue about attracting sampleset producers and users I do think that we need better tools for GO sampleset production (odf construction) than currently is avaliable. If making the ODF is no big issue, I think that we'd increase the chanses of attracting more users and producers. If great tools exist any user can buy the (un-encrypted) sampleset and create any organ he likes to play in GrandOrgue from the files, not just the version the producer imagined.
I think that GrandOrgue is a wonderful, unique software! Thus I also agree with Graham that it would be nice to pass into the new panel 2.0 format with a parsing of an .orgue file as standard instead of .organ. It would make sense to still keep an import feature without all the log warnings for the old .organ format, it would certainly also make some users happy to still be able to load old samplesets without the log window clogging up...As far as I know, a current GO odf, correctly made without any warnings, is not possible to import into MDA's software, so in fact we don't share the same format anymore anyway.
Kind regards
Lars P
Sorry for the delay on this: I posted by replying, but it never reached this discussion.
On 14-01-15 at 11:45 Graham Goode wrote:
You missed my point. The default format is not the issue here. Please start another feature request and argument for it there.
This is plainly wrong. The HW1-4 ODF format is in IP-terms part of "public available material", as it is part of the "free sample sample sets". There is no IP-system in the world that can defend it against reading and/or parsing. End of story. I cannot state it more clearly.
That is the other feature request.
No. I did not. You mentioned NDA's between Milan and the sample set makers to exclude competition. That would be illegal both in the US and in the EU.
You claimed "moral high ground" in obeying the asymmetrically enforced license agreement from Milan. I don't concur. Most nations neither. Most of them have strong protection mechanisms against this "obey or die" licenses for consumers. MS, Apple and Google have all found their Waterloo in this matter within the EU. Milan will be no different.
Furthermore, claims/licenses, law and morality are all very separate things. Mixing them all together creates extremely slippery and swampy territory. Please stick with law/license. That is complex enough as it is. Lets save discussions on morality for a long night over a glass of good wine.
It tries to do so. But "talking legal" and being legal is not the same thing. A lot of claims will not survive court. This one will not.
And they can only succeed if their format is "normally" inaccessible for inspection and exclusively used for internal workings. (internal DB-structures can be seen as this, or cache-formats). They will fail if it is either easily accessible, publicly documented and/or part of public available external data sets. The ODF format is both freely accessible, part of external data sets and at least partly documented.
Illegal: literary yes, as it cannot be backed up by law. Immoral: it depends on ones ideas of morality. As the negative connotation goes as in doing something punishable by law: it depends on the local laws. Some countries make acts like this punishable, some don't.
See the DVD analogy for this. If Sony and Phillips started working together on DVD's, Sony creating content on DVD's, Phillips creating DVD-players (they did), neither of them could enforce the combo to be purchased/used as a tandem and/or "closing" the DVD-format for this combo. We have all seen the lawsuits in the 90's , both on the format, the encryption techniques used and on the targeting of standalone players - none of them succeeded.
From the buyers perspective, he legally obtained a DVD containing IP protected material, with the right to reproduce it as audio/video. Courts all over the world considered it to be both legal and moral to break the restrictions of the DVD consortium, rendering those as illegal.
To put it simply from a technical perspective: a DVD is a "carrier" or interchange format. It is not considered to be part of the IP-protected material on it. You need it to access the IP-protected material you are legally allowed to use. The same reasoning applies to the HW-ODF's.
Make no mistake, both the sample set and either HW or GO must be obtained legally. If those criteria are met, you have the right to use the HW sample set for GO. You also have the right to share in public how you did this, whereby the ODF created for GO can be part of the publication.
There is nothing legal either Milan or the sample set makers can do to prevent this, but spreading FUD. They can create technical hurdles, but at least in the US and the EU it is legal to break those for use within the aforementioned context and to publish about it.
Whose property is protected here? You sold your property, remember? So the legal ownership was transferred to the buyer.
In general it is considered immoral and illegal to enforce how someone must use his own property. In a digital world, there are restrictions to prevent turning buyers into sellers or publishers but the general principle stays as it is.
So, on the very safe and careful side of the law: if the license allows using it for a certain purpose, it cannot enforce how to use it to obtain this purpose. Again, see the DVD analogy.
Furthermore, if you freely distribute your IP-protected property, it can only be protected against inclusion in derived works and false IP-ownership. It can no longer be protected against "consuming" aka reading/parsing.
Milan's FUD has overtaken you. I'm sorry to see that. Please don't panic. And it would be a very bad idea to join them in spreading their FUD.
Also consider the consequences. When the GO community creates a "legal" island without any commercial sample set maker (you stripped all compatibility), you effectively take GO from the market. Only the current free sample sets (once reformatted) will remain. That will create additional hurdles to take for both current and future sample set creators.
From an IP point of view - and I'm not trying to offend you, just stating facts - you cannot really pull the plug on your own public available sample sets. They are out in the open. As long as they are offered unmodified up and until the moment you "pull the plug" by changing your license or removing them from your server, anyone can continue doing so under the original license without offending any IP-law. They are there to stay.
I concur. However, you cannot change the way others see GO. You can only try.
Both projects and others (e.g. jOrgan) pursue to be the best virtual pipe organ. GO could only raise above clone status if it starts leading the pack by doing things both different and better than others as seen from a functional user perspective. Technical differences are only relevant for this status if the user perceived overall quality starts exceeding that of the others (easy of use, stability, (audio/midi) hardware compatibility, extra and wanted features, etc., etc.)
Lets start with catching up on commercial available sample sets.
Copyright law got a protection for "copyright protection systems" a few years ago. The wording is such, that it could even include trivial stuff, which I would never dare to call "encryption".
You have to rule out (eg. for your DVD use cases), that your not facing such a system, as the protection of these system has precedence over other rights.
Some HW encryption is snake-oil - the question, if GO can load these, depends on these paragraphs.
Sharing a ODF created for a HW set could be problematic. You need to make sure, that you are not creating a derived work of the HW XML - that means, that you don't copy copyrightable data from the HW XML. The systematic wav filenames as well as the stop names are in my option to trivial to be copyrighted, so I don't expect any issue from non GUI ODFs. On the other hand, the output of a HWtoGO converter would very likely a derived work of the HW XML.
Ad 1: Which copyright law? From which nation? Ànd if a "copyright system" prevents using it in an alternate way to achieve the contractually agreed upon purpose by the legitimate user, it can never take precedence.
Ad 2: You make the same mistake here as Graham. The "original work" stays untouched. The GO-ODF wont work without acquiring the original sample set. You will still have to buy it. When you do, it will give you the legal right to use it. When playing with GO after conversion, the HW-ODF will not be used. This renders the ODF as a mean of access and puts it outside the IP-protected work.
If you want to prevent lawsuits -- although you probably will win them all, they can cost you -- you can simply make GO capable of "playing" HW-samplesets right out of the box. In this case there will be no discussion over "derived works" or anything else. This is e.g. the road Oracle took with their FOSS VirtualBox hypervisor - it can "play" VMWare virtual appliances without any conversion. Oracle and VMWare are both US based competitors.
Add 1:
DMCA in the US. EU copyright directive chapter III, article 6.
Just look at the whole DRM topic and the related court decisions.
Add 2:
I'm talking about the copyright situation of the GO ODF.
If you convert a text document into a form/media, the original author of the text keeps his copyright. You might also need the permission of the author for that as well as for further modifications/redistribution.
If you are just copying part, at some point, at some point your work will be considered a derived work.
So depending on how a GO ODF is created and what information from the HW set is used, it CAN become a derived work of the sampleset - in that case, you need the permission of the sampleset creator for everything.
Perhaps you should read this: (EU Copyright directive 2009, article 15)
One can create a GrandOrgue organ definition without ever having to look at an Hauptwerk ODF, so this copyright directive simply does not apply.
—
Last edit: Martin Koegler 2015-01-19
Finally, yes!
But of course this presumes taking the HW-ODF as a means of access, not as part of a IP-protected item. If you presume the latter, this clause does apply.
Both cases, you are in the clear, at least in the EU.
The HW ODF is off limits, as it is protected by HW license and copy rights.
The sample set data, on the other hand, is available to GrandOrgue so long as permission has been granted. For instance, if Jiri has a HW sample set, and agrees that a GrandOrgue sample set can be created, the we can use all the non-HW protected information (the wave files and images) and create a configuration file for GrandOrgue to load them. We don't need anything from the HW ODF to do this.
—
Sent from Mailbox
Last edit: Martin Koegler 2015-01-19
No, it is not. Even if it was part of the HW program - it is not - it is allowed to adapt it for use in other programs for the purpose of cooperation. Prerequisite for this is that the user doing it is legally allowed to use both programs, as I explained before.
So, best case scenario - you don't need a HW-ODF - it is allowed.
Worst case scenario - you need the HW-ODF and it is considered to be part of the IP protecting HW itself - it is still allowed.
Pieter, it is clear that your definitions and my definitions are not equal. Endless arguing about protections and legalities are not going to help. Regardless of this, GrandOrgue won't be getting a HW import function so I suggest that we leave this discussion and pursue other things.
—
Last edit: Martin Koegler 2015-01-19
Well, they are not my definitions, but those as used in EU law, which in its nature is related to US law. It is a pity to see you dug into your own definitions. EU law and your interpretation of it clearly do not match. If the result of this would be an isolation of GO from the rest if the VPO communities, I pity the GO users. Perhaps you can persuade the sample set makers to create custom GO-ODF's, but my guess is this will take years.
I'm surprised though that you simply tell us "we won't do this". Do you decide for the community as a whole? Or have others a say on their own? This is an OS project, right?
Graham's statement about the HW ODF (off the limits) is incorrect.
Lars HW samplesets have been licensed under the CC BY-SA - so there is no issue with analysing/converting his HW ODF (the converted result need to be CC BY-SA).
The SP license does not contain any MDA related clauses, so only SP controls, what can be done with their HW ODF.
From the legal point of view, a HW importer for unencrypted sampleset is OK and I would not oppose including it, if certain conditions are met.
From the pratical point of view, my conlusion is, that there will not be any HW importer for the next time. Remember my first post about your "easy xml" statement.
HW is a undocumented format, so somebody (without any HW sampleset reference) has to discover, what the various codes mean. HW and GO ODF are different, so there can't be 1:1 mapping. Therefore for the first time, a external HWtoGO converter is better, as the missing parts can be added/corrected by hand.
PS: Graham, you have added full quotes of all previous posts to each of your answers. I have deleted them, as this thread already contains them, so that it is more readable.
Last edit: Martin Koegler 2015-01-19
Intellectual Property, or IP, is a complex matter. Mixing perspectives complicates correct decision making. A lot. Although there is truth in all that is said, it adds IMO up to the wrong conclusions.
Lets explore this a bit further.
There are four parties involved in this matter.
Milan DA as the creator of HW. They are a US based company. HW is in IP-terms a "unique work" and protected by US copyright laws. Their license is of the "shrink wrap" kind: "when you break this seal, you agree with the license inside". That means that there is no mutual agreed upon license as defined by most IP-systems; it is asymmetrically enforced. Most IP-systems allow "blackboxed" reverse engineering. Milan can "enforce" not to reverse engineer their work, but even the US laws allow it.
The sample set creator. Although there is some fuzziness about what the "real" unique work would be - the organ, the church, the recording, the sample set - and thus who the legal owner might be, one can assume that they can be protected by IP as well. Which copyright laws apply differs from one sample set maker to the other.
The consumer. They can be anywhere. As there is no international agreed upon IP system, the local, read national, copyright laws from the consumers nation apply. They can differ a lot from the creators/sellers copyright system. Any claim from a seller can only apply when the local copyright system agrees on the terms of their license. Mostly only a few parts of it remain.
The GO-community. As it operates under public license with international coverage, there is little debate on how IP works here.
Now lets see what happens when a consumer buys HW, a sample set and then retrofits it for use in GO.
He sends money to Milan. Milan sends him a HW-key and the license. There is no sample set yet, only the one included in HW. If there are matches between the license and the local IP-system, they can only apply to HW itself.
He buys a sample set from Milan. Now Milan can extend their license to include the sample set. If it applies to the consumer or not depends again on the local IP-related laws.
He buys a sample set from another firm. They can apply their own license. If it applies to the consumer, depends again on the local IP-system. Milan however, has nothing to say about it, as they are not the legal IP-owner. This is where the MS-Office analogy kicks in.
He retrofits a legally purchased sample set for usage in GO. No matter the original license, this is a legal act in most IP-systems, as the consumer legally obtained the right to use it. Here you can use the analogy of a purchased DVD: whether you use a Samsung player, a Phillips or a PC to play it, the seller has no say. Even if the seller explicitly demands a physical device, if you digitize it, store is on a SSD and stream it on your local LAN, the seller has no say.
He resells the retrofitted sample set to one other party. This is considered a legal act in most IP-systems, as long as all original traces of the sample set are destroyed after reselling. The new buyer obtains the identical rights of the first buyer. There is very little a sample set creator can do about this.
He resells HW to one other party. This again is considered to be a legal act as long as HW is destroyed by the original buyer. If Milan agrees on this? I doubt it. But a consumer with balls might sue Milan for it and most probably will win their case. Practical though, as HW needs a license file which is installation dependent, they can block further usage of HW, making the resell worthless.
He resells or redistributes the retrofitted sample set unlimited. Now all copyright systems I know of kick in, full whistles blowing. It is considered an illegal act.
There are a few more complex situation. When the GO-community creates ways to convert a HW sample set to GO-format, it is like publishing the DVD-codecs in order to play them on your PC, as was once done. However, as we have all seen, all law suits against this act failed so far. There is very little to fear for the GO community. GO would not be selling or reselling legally IP stuff. It only has created a new method of reading and using legally obtained IP-stuff.
When a community chooses to share GO-ODF's for free, the analogy would be like sharing FOSS to play a specific DVD. The IP-owner could try to sue, with little chance of success BTW, but they would shoot themselves in the foot by scaring away a whole new market of new customers. Because, in the end, the only way to legally obtain a sample set, is by obtaining it from the legal IP-owner, which is the seller of the HW-samplesets. There is no gain for them in suing.
There is of course the chance of a "divide and conquer" action from Milan, which could scare sample set creators away from new customers. If this will or will not happen, is not a matter of IP but of marketing tactics. No matter what we might think of that, it will not be our decision to make. We can only watch.
And there of course the increasing number of encrypted sample sets, which will only work with HW. Then there would be no point in converting to GO, as the consumer needs to own HW in the first place to be able to use it.
Bottom line: It is IMO IP-wise perfectly safe to create a import feature for HW-sample sets.