On 01/04/2012 02:13 AM, Duncan wrote:
James Tyrer posted on Wed, 04 Jan 2012 00:18:35 -0700 as excerpted:
I finally managed to build all of KDE-4.8 but had some problems with the
C# bindings.
FWIW, part of the issue there might be that a lot of devs won't touch
mono/c# with a 3 meter pole, due to where it came from. KDE isn't gnome,
and it's rather ironic that the one of the same people that founded gnome
due to license issues kde had at that time, has been so much the leader
in pushing the mono technology that MS has yet to clearly and irrevocably
free from patent claims and the like and apparently has no intention of
doing so, into gnome.
The FSF is too fanatical. If the source code is published and
distributable, then that should be enough. They made a serious error
when they started GNOME rather than supporting KDE.
While I see your point that people don't like this because it is M$,
there is a somewhat inverse point that is also valid. If M$ created C#
to have some sort of monopoly (I presume that that is where the name
'mono' came from) then the Mono project certainly removes that advantage.
The IP issues have previously been decided by the PTO and/or the Courts.
A programing language can not be patented; it can not even be
copyrighted. The last significant case, IIRC, was when Intel claimed
that the mnemonics for 8086 assembler were copyrighted -- they lost.
I am a bit disappointed by this as this would also apply to my
programing language (PL/Fiv). It was designed specifically with
compiling a consideration and to run on a virtual machine that could be
implemented in hardware. Yes, I thought of it when I was in college and
that was before Java. However, it is possible that the methods used by
the compiler could be patented if they are new and non-obvious --
different from a conventional compiler (which I see as rather
inefficient and wasteful)
So, the one issue that remains unsettled -- and this is a general issue
with M$ -- is their claims made in their EULAs that limit who can use
something that is freely distributable. I would bet on the snowball
here (a snowball's chance in hell).
But regardless of the political issues, there's little or nothing in
mainline kde sc that requires those bindings and unless you REALLY want
one of the fringe apps that might happen to require them, I'd say just
let them be. For most, at least most of those who'd choose to build it
themselves, it's simply a component or two that nothing uses, so not
installing it simply means not having to worry about updating it with
every kde update they do, and that many less unused or extremely lightly
used installed components to worry about the potential of someone finding
a security hole to exploit.
This is also true, but the only relevant issue here was that I had
appointed myself to a position and wrote a tutorial for compiling KDE,
so if it it exists, I need to know how to compile it.
I don't know what the future for that is since someone deleted (not
updated which would have been fine) but simply removed my tutorial. The
information regarding the dependencies for (B)LFS building of KDE are
now in the wrong place, but they are there and probably need to be updated.
So, again, people wanting to build KDE from source are directed to the
TechBase where the "instructions" are nebulous and vague -- as well as
being written with the presumption that people will want to build TRUNK.
It appears that the authors responsible do not know what a tutorial is
and don't seem to understand that vague suggestions are not going to
help people to build KDE (as it is not that simple).
I really need the answers to some questions to write another editorial
and this information simply doesn't seem to be available.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
