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-Bit/.Net_Data_Provider_GA/ingres-9.2.0-143-v21-com-win-x86-DotNet.zip/http
[1]
http://groups.google.com/group/dblinq/browse_frm/thread/9ca9e51b7516a4e/e9251f6f53206a17?lnk=gst&q=GPL#e9251f6f53206a17
[2]
http://www.oracle.com/technology/software/htdocs/distlic.html?url=/technology/software/tech/windows/odpnet/utilsoft.html
--
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.
