I have the freedom to dual-license a portion of (A) with the AGPL as well, so as to create a self-contained AGPL component/script/plugin which can read (B)'s data files, and manipulate them for use by (A).
My question, then, is: What degree of separation must/ought I maintain between my core program (A), and the (B)-to-(A) converter/importer?
I realize that nobody here is a lawyer (or if you are, you can't give me legal advice anyway), so I'm looking more for guidelines. What is "clearly okay", what is "clearly not okay", and what lies in the middle?
Models I've considered:
A completely stand-alone data converter. Users visit a URL, or run a local executable, which takes (B)'s input format, and spits out a file that can be read by (A).
I host a converter on a separate server, which (A) knows how to talk to. A user provides a data file from (B) to (A), and (A) hands it off to the convertor, which responds with data (A) understands.
I write a conversion plugin, which a user may install into (A), and then upload data files from (B) for the plugin to convert to (A)'s native format on demand.
I write a library which converts from (B) to (A), and I load it in a separate tag, from a separate server, in my app. If successfully loaded, (A) exposes the option to the user to import data files from (B). If not successfully loaded, that functionality remains hidden.
Same as #4, but the script is hosted on the same server.
I expect (1) should be perfectly permissable, as there's no question that (A) is an independent program from the converter, running on a completely different machine (or at least hosted on a different machine) than (A).
The coupling gets tighter as I move down the list. Is there any point where a line is clearly crossed? Or even in #4, is (A) sufficiently decoupled, and non-dependant on the conversion plugin to be within the spirit of the AGPL?