Hi Jon, I can't help you with the non-Ingres libs and licenses I'm afraid. And I'm not necessarily a fan of the Ingres login-to-download policy either...
The Ingres Stereo Provider is a spin off of the original provider and can be downloaded here: http://sourceforge.net/projects/ingresstereo/ It is released under GPL. Regards, Thomas On Jan 4, 8:02 pm, Jonathan Pryor <[email protected]> wrote: > On Mon, 2010-01-04 at 09:07 -0800, Thomas Glaser wrote: > > Some of the .DLL's in the lib folder should probably be in the > > binary .zip as well. For instance Ingres access won't work without the > > actual .NET Data provider Ingres.Stereo.dll. > > > Currently you've packaged those libs only in the source .zip. > > Can you elaborate on which ones should be packaged? Additionally, what > the license for those "redistributable" libraries is? > > For example, of these files in lib: > > * FirebirdSql.Data.FirebirdClient.dll: Presumably the "Firebird > ADO.NET Data Provider" from firebirdsql.org, but what version? > Also, I don't fully understand which license their downloads are > under -- Initial Developers Public License? InterBase Public > License? -- and what restrictions they have. (If it's not BSD, > MIT, or GPL, I don't want to tax my brain reading it.) > * Ingres.Stereo.dll: I can't even find where to download this file > from, so I *really* don't know what license this was released > under. More annoying, if I go to ingres.com and navigate to the > download page for the .NET Data Provider drivers (e.g. [0]), I'm > prompted with a login/password dialog box. Not cool. > * Mono.Data.Sqlite.dll: MIT/X11, but what version? Plus, if > you're using Mono.Data.Sqlite, you're probably using Mono, which > includes Mono.Data.Sqlite *anyway*, so why would we need to > distribute it? > * Mono.Security.dll: A dependency on Npgsql.dll. > * MySql.Data.dll: GPL, leading to a "wonderful" discussion on this > list several months ago [1]. Yes, it should be possible to > distribute GPL'd software with non-GPL'd software "side-by-side" > without causing problems (e.g. a Linux distro), but I don't need > another 30 message long discussion about GPL requirements. > * Npgsql.dll: At least it's MIT/X11, but what version is this? > * nunit.core.dll, nunit.core.interfaces.dll, nunit.framework.dll, > nunit-gui-runner.dll: Needed for unit tests, not actual > assemblies, and thus shouldn't be distributed. > * Oracle.DataAccess.dll: I'm not a lawyer, and don't care to > understand what the restrictions at [2] include. Plus, what > version is this? > * sqlite3.dll: Public domain, but what version? > * System.Data.SQLite.DLL: ditto. > > So, for a variety of reasons (questions about versions, licensing > concerns, etc.), DB vendor assemblies should NOT be distributed with > DbLinq. We stick to the standard ADO.NET interfaces for a reason: it > shouldn't matter what ADO.NET provider is used, as long as we can find > it, and we find it through a variety of mechanisms (e.g. via the > connection string's DbLinqProvider and DbLinqConnectionType parameters, > through the DbMetal.exe.config file). > > It should be up to the end developer to choose which ADO.NET provider > they want to use (in turn dependent upon the DB they're using), not > DbLinq (unless there's a *really* good reason to do otherwise). > > - Jon > > [0]http://esd.ingres.com/product/drivers/.Net_Data_Provider/Windows_32-B... > > [1]http://groups.google.com/group/dblinq/browse_frm/thread/9ca9e51b7516a... > > [2]http://www.oracle.com/technology/software/htdocs/distlic.html?url=/te... -- You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/dblinq?hl=en.
