On Mon, 2012-01-23 at 10:21 -0600, Tony Asleson wrote: > On 01/21/2012 08:57 AM, James Bottomley wrote: > > It's also a bit insular ... the first thing you usually ask in open > > source is what can I steal^Wborrow from other projects and how do I > > recruit others to do the work for me. > > The project site is a little sparse on details about what we have looked > at and considered. Ric Wheeler covered some of this during his > presentation in Prague, but I will place more information on the project > web site. That would be good for those who didn't go to that presentation ... > > The first question is probably: is there anything we can liberate > > from the Oracle storage API fisasco to help with this. > > The Oracle storage connect library was evaluated and subsequently > rejected for the following reasons: > > 1. The Oracle storage connect library is dual licensed, GPL and a > proprietary Oracle license which allows proprietary use. This allows > hardware vendors the ability to write proprietary plug-ins. The design > of the library has the library user and plug-in executing in the same > address space. Based on the information presented on plug-ins > (http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins) this design > goes against the requirements of GPL license compliance. Proprietary > plug-ins could be in compliance if they are implemented to execute in a > separate process. This is actually wrong thinking. Almost every Open Source project has an incompatible licence. The way we work around this (once we've determined there's something worth stealing) is to ask the project owner for a compatible grant (in this case, some pieces under LGPL). That's how we share driver code between Linux and BSD for instance. If Oracle is intent on pursuing an open core business model for this and says "no" to the request, then you can say they're incompatible ... did anyone ask them? > 2. At the time the Oracle storage connect library was being evaluated we > were unable to obtain a plug-in from a few different vendors. Without > plug-ins the value of any library becomes greatly diminished. Why? You have no plug ins for your project currently ... that doesn't really diminish the value of it as an emerging project. It sounds like you evaluated the Oracle project from an all or nothing standpoint rather than a what can we learn/steal standpoint. One of the big things we could co-opt from oracle looks to be vendor buy in (they seem to be investing more in marketing than actual engineering). Vendors hate being confused or making choices, so one easy way to bring them on board might be API compatibility with the Oracle project. > > The second might be what would it take to get vendors interested in > > doing the array plugin glue. > > By providing: > * Permissive license (LGPL) > * Easy to use out of process plug-in support to allow proprietary > plug-ins (IPC is abstracted) > * Language agnostic plug-in support (initial support is C and python) > > We are hoping we can get hardware vendors interested in providing their > own plug-ins. If anyone has additional ideas, we would certainly like > to discuss them. So no actual vendors have provided any input yet? James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
