>From what I have been able to piece together from the archives of prior discussions on this topic, it appears that one cannot write a proprietary vfs module, correct?
If that is true, how far does the non-proprietary nature need to extend? For instance, would it be allowed to write a vfs module which talks to Oracle to get the data which backs the filesystem rather than an actual filesystem? Even if it involves linking against Oracle's proprietary OCI library for calls into the database? Quoting from a message from the archives which I found in my searches (http://lists.samba.org/archive/samba-technical/2002-February/019881.html): "For example, a vfs plugin that links to Oracle as a backend would be GPL, but Oracle itself would not come under the GPL. This is because Oracle is a program that is of itself functional without Samba." Say I work for a company, and I wish to write a vfs driver which interfaces with the company's proprietary product. What would be a reasonably efficient mechanism to do this while not violating any license terms for samba? Would this be writing a GPL vfs module which calls into the company's proprietary libraries? This would seem to be the case if writing an Oracle vfs client is allowed, since the only mechanism for calling into Oracle from C is, AFAIK, via OCI, which is a proprietary library (either directly or indirectly, such as through ODBC). Another clarification which I believe would be beneficial to the community would be, do vfs modules have to be GPL and only GPL, or could they be instead some other OSI-approved license? Thanks for any clarification you can provide, and I hope I don't trigger some sort of licensing holy war on the list ;) -- "Experience has proved that some people indeed know everything." -- Russell Baker -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
