FreeTDS
by James K. Lowden
https://www.redhat.com/archives/fedora-extras-list/2005-September/msg0116...
A decision was made back in 2005 not to include FreeTDS in Fedora Extras.
The decision's reasoning rested on faulty logic. I am not an RH user or
developer; I'm the FreeTDS maintainer. I would like to clear up the
misunderstanding today and request FreeTDS be included in some way in the
Fedora distribution.
The above cited message suggests FreeTDS is under a legal cloud. The
facts are:
1. The TDS protocol has been public information for many years.
2. Microsoft's patent 5,974,416, mentioned above, does not apply.
3. Microsoft and Sybase are well aware of FreeTDS and have never
suggested any kind of infringement exists.
4. FreeTDS serves the business interests of both vendors.
Sybase's document
(http://www.sybase.com/content/1040983/Sybase-tds38-102306.pdf
) is freely downloadable. It is marked "confidential", true, but it has
continuously been published on their website for several years, so any
confidentiality is surely now minimal. The mere fact that something is so
marked, in any case, has no legal import. Nothing else in the document
suggests its use is in any way restricted.
The assertion that FreeTDS violates the LGPL license that governs its use
is incorrect. The TDS protocol is not covered by any patent.
http://patft.uspto.gov/netacgi/nph-Parser?u=%2Fnetahtml%2Fsrchnum.htm&Sec...
Microsoft's patent 5,974,416 does not mention and does not describe TDS.
It issued in 1999, 15 years after Sybase invented TDS, perhaps five years
after Microsoft licensed it from Sybase, and two years after FreeTDS was
first released. Yes, the patent has words like "tabular" and "data" and
"stream" in it. No, TDS does not have any of an "Advanced Data TableGram
(ADTG) format", a "HandlerOptions section", or a "Descriptors section".
There is no "Descriptors section [that] comprises a 16-byte unique
identifier." In short, the patent describes something similar to TDS that
the inexpert reader might be led to believe is the same thing, but which
in fact specifically avoids language that describes TDS. This should come
as no surprise: Sybase surely would object to having its protocol patented
by Microsoft. One might even suggest the USPTO would object, too.
The assertion in a reply
"There are 4 versions of TDS: 4.2, 5.0, 7.0, and 8.0. MS bought TDS 4.2
from Sybase. Only Sybase uses 5.0, and only MS uses 7.0 and 8.0."
is true but unimportant. These flavors of the protocol are much more
similar than different. Only a small part of FreeTDS distinguishes
between them. The features Microsoft added are limited to a few new
datatypes, the use of UCS2 encoding for metadata, and some minor
annoyances. No one would plausibly claim that TDS 7.0 represents an
invention of any kind, much less a protocol distinct from its predecessors
in any but the most technical way.
The FreeTDS project has been contacted by parties at Microsoft from time
to time. Discussion at one point led to how Microsoft might support the
project in some way. If patent violations were at issue -- which clearly
they can't be -- surely those who opened the discussion with us would have
been warned off. In the end, though, nothing came of it; they would
have required a nondisclosure agreement no one on the project was
interested in signing. (IMO the LGPL was the real stumbling block.)
http://technet.microsoft.com/en-us/library/bb497057.aspx
Finally, a Google search for "freetds site:microsoft.com" quickly shows
that Microsoft actively supports FreeTDS to a surprising degree. Microsoft
makes no Unix drivers of any kind. I do not think I have to explain how
Microsoft benefits from the existence of a free driver connecting
Apache/PHP sites (to cite just one example) to their database product.
The facts are all on one side: the documentation, the patent language, the
age and history of TDS, and the vendors' behavior and interests all tell
us that TDS is completely, absolutely unencumbered. It cannot be patented
or copyrighted, and it is obviously not a trade secret. It doesn't even
stand vaguely *accused* of violating patents. FreeTDS is, simply, free
software. I wish the Fedora project would accept and treat it
accordingly.
Thank you for your time.
Regards,
--jkl
P.S. I hope this is the right forum, now that fedora-extras-list is
closed.
16 years, 10 months
OCaml find-requires and find-provides
by Richard W.M. Jones
Here are some working find-requires and find-provides scripts for OCaml.
The produce dependencies according to what I wrote about here:
https://www.redhat.com/archives/fedora-packaging/2007-May/msg00105.html
(Ignore the earlier versions of the same scripts attached to that email).
To use them is simply a matter of adding the following lines to a spec file:
%define _use_internal_dependency_generator 0
%define __find_requires /usr/lib/rpm/ocaml-find-requires.sh
%define __find_provides /usr/lib/rpm/ocaml-find-provides.sh
Also attached is a patch to the ocaml.spec file to install these.
I've got working specs/SRPMs for ocaml-findlib, ocaml-extlib, ocaml-pcre
and ocaml-calendar, which I'm going to put into BZ shortly as review
requests.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones
Toshio Kuratomi wrote:
> On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote:
>> Nigel Jones wrote:
>> > Hi everyone,
>> >
>> > While putting in a couple of packages for Extras Review I've stumbled
>> > into a couple of issues regarding how Ocaml links libraries and how the
>> > Fedora Packaging Guidelines are set.
>> >
>> > My packages in question are:
>> > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804)
>> > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805)
>> > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815)
>> >
>> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set
>> > of dynamic libraries, and another set for development etc), sadly when
>> > other packages like freetennis build, they staticly link to libraries
>> > such as camlimages/ocamlSDL.
>> >
>> > I found it semi-suspect when I built freetennis, and hence why I asked
>> > on bugzilla when I posted the three packages for review, however I did
>> > some more questioning today and after a quick IRC discussion in #ocaml
>> > was told:
>> >
>> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries
>> > right?
>> > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes.
>> > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading.
>> > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for
>> > dynamic loading as static loading.
>> >
>> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk
>> > (as well as the main ocaml package) store .a, .cma and .cmxa files in
>> > /usr/lib/ocaml (and subfolders).
>> >
>> > As I'm only new to Fedora packaging, could someone please advise on
>> > where I should from here on the matter and what the position of FESCO is
>> > on Ocaml static libraries, and where I should go from here.
>> >
>> > Thanks,
>> >
>> > Nigel Jones
>>
>> I'm just wondering if anyone has any thoughts on this issue.
>>
>> I've talked to some more people in #ocaml (Freenode), who suggested that
>> I try a patch by the name of 'scaml' which is a year or two old (and
>> although can be manually applied to the ocaml source, it does not work
>> (problems with assembly which I've not comfortable meddling with).
>>
>> We'd actually need to downgrade to 3.07 which was removed from Fedora in
>> Feb 05 to get the patch working to satisfy the need for dynamic loading
>> which I'm sure would upset a few people.
>>
>> Upstream already have a bug opened stating that they need to fix the
>> issue but they have never updated it, or assigned it to anyone.
>>
>> So my main question is "where to from here?"
>
> I think, if the ocaml compiler doesn't support dynamic libraries, static
> linking would be acceptable. This doesn't mean that we shouldn't press
> upstream to add dynamic linking (and convert all our packages when that
> becomes available) just an acknowledgment that fixing the limitation has
> to be done upstream (it could be done by someone within Fedora but the
> fix needs to go upstream).
>
> This is similar to allowing C libraries in even if they only build
> statically.
>
> If I'm not understanding precisely what the limitation is, feel free to
> clarify.
There are two issues here: (a) Having OCaml binaries link dynamically
instead of statically to OCaml libraries. (b) Writing a dynamic library
in OCaml, and having it used by programs written in other languages,
particularly C.
I suspect it's unlikely that upstream will do (a), ever. There's a
technical issue. OCaml really doesn't have a concept of an ABI. It
does a kind of whole-program optimisation where even changes to the
internal implementation of a library can affect the resulting binary.
Moreover even if you "fixed" that, any change whatsoever to the
library's signature or the version of compiler it was built with (even
bugfix releases which have the same version number) will make the
library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cb...
Another issue which Xavier doesn't mention is the ability to fix a
security bug in a shared library, and not require all dependent
applications be recompiled. Well, there aren't many (any?) widely used
OCaml libraries, and there aren't a lot of binaries which would need to
be recompiled either. But it could be a problem for OCaml world
domination plans.
As for (b), the ability to write libraries in a sane language and have
them called through a C API: This almost works. Well, it works well on
i386, but there are some problems on x86-64. I'm looking forward to
having this. It needs some tools to make it work well - it would be
nice to have the C header files and the complex Makefile fragments to
get it to work generated automatically.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
Upcoming FESCo Election
by Brian Pepple
Hi All!
It's that time of year again. Everyone that wants to be in the next
FESCo needs to nominate him/herself for it by June 12, 2007 0:00 UTC;
that self-nomination should contain some information's like "Mission
Statement, Past work summary and Future plans".
Please place your nomination on this page in the wiki:
http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations
The actual election will start on Thursday, June 14, 2007 0:01 UTC and
will last until Sunday, June 24, 2007 23:59 UTC. The results will be
posted to the fedora-devel list. The first meeting of the "new" FESCo
will be on Thursday, July 05, 2007 on #fedora-meeting at 17:00 UTC. A
new chair will be elected there by the new members.
For more information regarding the election, please refer to this:
http://fedoraproject.org/wiki/Extras/Policy/FESCoElections
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
16 years, 10 months
First impressions of a system update with yum
by Matthias Saou
Hi,
Here are my very first impressions of a system update from FC6 to F7
using yum. Note that I haven't "insisted" yet, but it's not looking
good.
First thought : Try "yum update" after updating fedora-release (and
fedora-release-notes which it requires).
No go, because some F7 updates are required to fix my system's upgrade
path (in this case it's audacious-plugins which is newer in FC6 and
requires an older version of curl).
Second thought : I'll break down the transaction in smaller bits, which
can only be a good thing. So "yum install kernel yum".
No go, it stops about rpm-libs and rpm-devel still needing the FC6 rpm.
Possibly a multiarch problem since it appears I have i386 rpm-libs and
rpm-devel installed for some reason.
Third thought : Try an even smaller transaction. "yum install kernel"
No go, because it would update the x86_64 ncurses, which then conflicts
with the older i386 ncurses. Possibly the same problem as the previous
transaction.
Current thought : do a "yum remove glibc.i686" to get rid of all 32bit
packages before trying anything else. But this scares me a little,
since last time I did this, many applications stopped working
(segfaults inside gconv libs) until I upgraded all x86_64 glibc
packages. Might work here since the F7 update will do so...
Other current thought : To hell with it, format "/" and reinstall from
DVD...
Last current thought : This used to be much easier. I'm not an
unexperienced user, and it's annoying for me, which is not a good sign.
Oh, and I hate multilib, and most of all that one-arch-only proprietary
flash plugin.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.20-1.2952.fc6
Load : 0.21 0.25 0.42
16 years, 10 months
Explaining the new suspend quirks functionality in F7
by Richard Hughes
New in Fedora 7 we have the new pm-utils and hal-info dmi based matching
of suspend quirks. We are doing finer matching to the laptop make and
model, to make suspend (and more importantly resume) work for more
people.
What this means:
* Some machines that suspended in FC6 might not work in F7
* Lots of machines that did not suspend in FC6 might work in F7
So, if you have to edit a file or add stuff to grub to get suspend
working in F7, that's a bug. This stuff should just work on the majority
or laptops.
To help, and to try and make clearer all this new stuff, I've written a
few pages here:
http://people.freedesktop.org/~hughsient/temp/quirk/quirk-intro.html
This is not the permanent location, nor are these documents finished -
I'm hoping to add more and more content to them over the next few days.
So please point out new ideas, typos or maybe just general questions,
and I'll try to answer then on these pages as best I can.
Feedback welcome,
Richard Hughes
16 years, 10 months
revisor in f7
by Deependra Singh Shekhawat
Hi
Will there be revisor for F7. I don't see it in the rawhide.
Thanks
--
Enjoy Life !
16 years, 10 months
An idea for RPM -> License Agreement support
by Mohd Izhar Firdaus Ismail
I'm not sure if i missed it .. anyway .. here goes
it would be useful to Third Parties if RPM have the ability to ask for
License Agreement before installing their package. I'm not a lawyer
but I believe this is useful in legal related stuff when distributing
softwares. I have seen a few RPM that are stored .bin just for the
sake of license agreement (Sun Java is the easiest example) and with
RPM having (optional) license agreement before installation , this
would reduce their worries bout licensing when packaging app for
Linux.
and ... Linux newbies can avoid the terminal more (I know this sounds
silly, the moment somebody says open terminal and run "chmod +x
file.bin", certain users freaks out , double clicking RPM is easier to
explain ).
any comments?
--
-----------------------------------------------
regards
Hikaru
-----------------------------------------------
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
天野晃 「あまの ひかる」
mohd.izhar.firdaus(a)gmail.com
-----------------------------------------------
kagesenshi.87(a)gmail.com
Blog: http://kagesenshi.blogspot.com
http://fedoraproject.org/wiki/MohdIzharFirdaus
-----------------------------------------------
16 years, 11 months
