GPL license and European 90/EC/250 Copyright Law
Posted 23 Oct 2001 at 00:51 UTC by lkcl
In creating a dynamically loaded, self-contained library, released under
the GPL license, with an interface (header file) that was available from
a BSD licensed package, I believe that any insistence by any individual
that this makes the BSD program, which is responsibly for dynamically
loading the library, is in breach of the European Community's
"Interoperability" rights as laid out in 90/EC/250, and that such
insistence is unlawful.
The program is FreeDCE. It made its way from the Open Software
Foundation, originally as DCE 1.1 - the Reference Implementation of
DCE/RPC. The OSF/1 , under which FreeDCE is released, is officially
classified as a BSD-style, Open Source License.
The module is ntlmsspauth.so. It originated from several authors, who
released that code under a GPL license. I created the header-file for
ntlmsspauth from a FreeDCE example header file. The header file
contains function definitions for the FreeDCE "Authentication API".
This is therefore defined, under 90/EC/250 as an "Interface". Also
defined as an "Interface" is the single function, rpc__module_init().
FreeDCE's job is to look into all dynamic libraries under its "wing", to
load the function symbol "rpc__module_init", then to call that
function. the module _itself_, from inside rpc__module_init(), does
In the case of ntlmsspauth.so's rpc__module_init() function, it
registers a specific group of functions (that make up and conform to the
FreeDCE "Authentication API") into a global table which can be used from
anywhere within FreeDCE.
there are those people who would insist as follows:
"Well, you have GPL code in one directory, and BSD code in another, and
the GPL code is a module, and the BSD code is a program, so it's a
no-brainer, you stupid idiot: you *have* to release all the BSD code
under the GPL".
now, clearly, given that the amount of GPL code is 12,000 lines and the
amount of BSD code is twenty times that amount, coming in at 250,000
lines, naturally i am a little disinclined to look favourably upon such
I am interested to hear any opinions or confirmation regarding this
particular issue, as I believe it may have possible ramifications for
the GPL and other Open Source Licenses, should at any time a court case
regarding a well-known open source program in a monopoly position of
power (such as samba), ever take place.
and before you start wondering why i mention samba as being in a
monopoly position of power, i'll answer it now.
samba dominates ports 139, please see RFC1001.txt, Appendix B-1, model
number 1. this totally makes it impossible for anyone to implement
_other_ NetBIOS services on the same host / ip address. fortunately, we
don't give a monkey's about port 139 any more, we have port 445 instead,
so that example is becoming less important. let's move on to IPC$,
then, shall we?
over SMB IPC$ is something called NamedPipes. NamedPipes are what
Microsoft chose to allow DCE/RPC to be used. _unfortunately_, samba
currently includes (and i know this because i was the one that
implemented it that way), its own implementation of DCE/RPC over SMB
IPC$. and the implementation is very basic, and LOCKS OUT OTHER
SERVICES AND PROGRAMS FROM BEING ABLE TO RUN OVER SMB IPC$.
if you are not familiar with samba as i am, and are more at home with a
fictitious parallel example that may help illustrate this issue more
clearly to you, imagine for a minute that this is the linux kernel we're
discussing, not samba.
imagine how outraged people would be if the linux kernel developers
decided that only programs authorised _by the linux kernel developers_
could run under linux.
so, if you should ever think that the scenario i outline, where a
GPL-based program could not possibly end up in a court of law, please
discussion welcomed here: your opinions valued.
There are two versions of the BSD license. One with an advertising
clause and one without. If the library is under the version without the
advertising clause, the license is GPL compatible and you need not
change anything. However, I would very strongly suggest that anyone who
wants to change the BSD license on the library to proprietary not
include the GPL component, because there probably would be a license
conflict in that case.
If the BSD license you are using has the advertising clause, try to get
it removed. It is not GPL compatible. Rather than being forced to change
your program to GPL licensing, you would simply not be allowed to use
the GPL component at all.
You have some misconceptions about the GPL, derived works, and I think
EU law, I'll answer them in other
You don't lay out enough of the EU law and your interpretation for me to
say conclusively that your interpretation is wrong, but I strongly
suspect your interpretation is wrong. Consider this from the
standpoint of a similar proprietary library. Suppose a popular
program "A" uses proprietary library "B" under license and ships it as a
DLL, and thus most people have library "B" on their systems. The API of
library "B" is available in a published book that you can buy in a
technical bookstore. The developers of program "C" don't have a license,
but they know that most people have a copy of library "B" installed on
their system, because program "A" is so popular. So the developers of
program "C" write
and distribute a program that uses library "B", even though
they don't have a license for "B". The developers of "B"
sue the developers of "C" to force them to pay for a commercial license.
Are you saying that the EU compatibility law would find for "C" rather
than "B"? If so, please demonstrate how you come to that conclusion
quoting chapter and verse of the EU law in sufficient detail that we can
check your interpretation.
Linking a proprietary program to a BSD library that is linked, even
dynamic linked, to a GPL program is probably a license conflict. In this
case it doesn't matter that the BSD library is there, just consider
proprietary and GPL together. In your place I'd write out the GPL
component, if your goal is to support proprietary use.
In considering a license conflict between two works, the relative size
of the works to each other makes little difference. However, you are not
in general going to find yourself forced to change the licensing of
any work to match the GPL. You will be forced to remove the
infringement by removing the GPL component from your program.
Nothing in Samba prohibits the system administrator from removing it and
providing another daemon to operate on port 139. The Samba source code
is disclosed, making it very simple for someone to determine all of its
APIs and replace it. The APIs are also subject of a published standard.
The Samba license does in fact permit the software to be modified, so
that you may add additional services directly to Samba.
I think you are trying to connect this with the Microsoft anti-trust
case and their "co-mingling" of the web browser with the OS. But
remember that they didn't publish their source code and APIs, and it was
very difficult to remove the browser from the rest of the OS and still
have something that worked afterward, and it was very difficult to
modify their code - there was no source and permission to
In the U.S., there is exactly one court case regarding whether linking
to a dynamic library creates a derivative work: Nintendo vs. Goloob
Games. It's worth looking over if you are an attorney, but it is not
definitive. I don't know of any similar E.U. case.
There is a note attached to the Linux license explicitly waving any
restriction on programs that use Linux only through the system-call
interface. There is another note permitting proprietary modules, but
only some kinds of module (it's in Linus' chapter of "Open Sources",
O'Reilly press). So, Linus considered this enough of a concern that he
was explicit about it. He specificaly says that some kinds of
proprietary module are not OK. This is exactly what you think
would outrage people, very similar to your own use of DLLs, and Linus'
restriction on some forms of proprietary module has been in place for
years without outrage.
i've been advised that the GPL actually conveys additional copyright,
and is not actually a license, per se. for anyone interested in
studying this issue, you might wish to take this fact into account.
hi there bruce, gosh, okay, where to begin :) thanks for responding: i
think what i might do is give more clarification of points, and leave
the rest for debate.
You don't lay out enough of the EU law and your interpretation for me to
say conclusively that your interpretation is wrong,
but I strongly suspect your interpretation is wrong.
Consider this from the standpoint of a similar proprietary library.
Suppose a popular program "A" uses proprietary library "B"
under license and ships it as a DLL, and thus most people have
library "B" on their systems. The API of library "B" is
available in a published book that you can buy in a technical bookstore.
The developers of program "C" don't have a license, but
they know that most people have a copy of library "B" installed on
their system, because program "A" is so popular. So the
developers of program "C" write and distribute a program that uses
library "B", even though they don't have a license for
"B". The developers of "B" sue the developers of "C" to force them to
for a commercial license.
Are you saying that the EU compatibility law would find
for "C" rather than "B"? If so, please demonstrate how you come to
that conclusion quoting chapter and verse of the EU law in
sufficient detail that we can check your interpretation.
[okay. this is to help stop me getting headaches: let program "A" ==
outlook. let library "B" == MAPI. let program
"C" == pegasus mail. the API for MAPI is available in the MSDN. this
makes it "the developers of outlook and MAPI can sue pegasus mail to
force them to pay for a commercial license". okay, now i understand.]
well the developers of "C" might actually get sued for not having
software license before they even _get_ to the courts over the issue of
using library "B". okay,
i've re-read your scenario above: that they _can_ get the API for
library "B" by purchasing a technical book. but they never purchased a
license for library "B". assuming that they can do the work _without_
access to "B" and that the API for "B" is sufficient to do this, and
that they are _really_ skilled developers who never have to test
anything (!), then:
under EU law, then the answer to your question is that yes, under
90/EC/250 Copyright law, "B"'s access-point (API) is defined as an
the court case would be in favour of "C", as "Interfaces"
are specifically excluded from Copyright protection
the document i am working from is http://europa.eu.int/eur-lex/en/lif/dat/1991/en_391L0250.html.
the specific whereas clause, which is an *exception* to the "Directives"
listed below it, is:
Whereas the parts of the program which provide for such interconnection
and interaction between elements of software and hardware are generally
i presume that this covers "software-software" as well as
"software-hardware" and "hardware-hardware" because 90/EC/250 relates to
"programs" and therefore covers programs in hardware as much as programs
if you consider this insufficient, examine the two whereas clauses above
(quoted in advogato article 354) they are pretty similar.
okay. let program "A" = FreeDCE. let library "B" = FreeDCEAuthAPI.
let program "C" == ntlmsspauth.so.... :)
Linking a proprietary program to a BSD library that is
linked, even dynamic linked, to a GPL program is probably a license
conflict. In this case it doesn't matter that the BSD
library is there, just consider proprietary and GPL together. In your
I'd write out the GPL component, if your goal is to
support proprietary use.
to clarify. "The Program" is FreeDCE. It was (is) available under the
OSF/1 BSD-like license. it is a run-time library set and environment,
- an IDL compiler, dceidl
- an IDL NDR library, and if you don't link to this library you have
20,000 loc of code to write or your program is useless
- an endpoint mapper daemon, known as rpcd.
- support libraries and infrastructure, all of which now are dynamically
these support libraries are not dynamically linked, they are dynamically
using dlopen(). the "Interfaces" for these support libraries are
well-defined - by the OSF, in FreeDCE, and they include such things as
Transport Access (TCP, UDP, IPX/SPX, DecNET, NT NamedPipes, HTTP) and
Security Mechanisms (Krb5; NTLMSSP; GSS-API; PKI).
[given that this is an IDL compiler and run-time environment, i would be
interested to hear from people as to whether they consider a compiler's
output from an IDL compiler to be proprietary if the IDL compiler is
Open Source, but that's another matter :)]
anyway, moving on.
using this OSF/1 BSD-licensed runtime library and environment, we
compile our "test" application (for the sake of argument, let us suppose
that "test" is proprietary).
the program "test" is compiled with the BSD-licensed IDL compiler. it
is linked to the BSD-licensed IDL Library and to the BSD-licensed
_at no time_ does the GPL library get "dynamically linked" to the
_at run-time_, the BSD-licensed runtime library "dynamically loads" the
GPL component "libntlmsspauth.so" with dlopen(), obtains with dlsym()
and calls its "rpc__module_init()" function which initialises the
"Interface" inside the runtime library such that the runtime library may
access the capabilities of "libntlmsspauth.so" via the well-defined
(BSD-licensed) FreeDCE Authentication "Interface".
are you saying that, because the BSD-licensed runtime library
"dynamically loads" and then calls one SINGLE function and one SINGLE
FUNCTION ONLY in "libntlmsspauth.so", that the BSD-licensed runtime
library must be released under the GPL, and therefore the program "test"
is therefore linking with a GPL program and therefore the program "test"
must also be released under the GPL?
Nothing in Samba prohibits the system administrator from removing it and
providing another daemon to operate on port
yes, unfortunately, there _is_ a prohibition: between five to twenty
man-years of development work (depending on what level you wish to
provide, you could possibly get away with the minimum of five man-years
of work, but you'd soon wish that you hadn't).
The Samba source code is disclosed, making it very
simple for someone to determine all of its APIs and replace it.
ah, no it doesn't.
the technical level of expertise and experience required to comprehend
the samba codebase unfortunately makes it, i am sorry to say, pretty
much irrelevant that it's open source, leading me to compare the samba
project to a proprietary project that _happens_ to be released under an
open source license - and with good reason.
i would say that the ramp-up time to understanding the 350,000 lines of
code in Samba makes it, without any outside assistance or understanding,
approximately six months to one year before you might feel comfortable
enough to make useful contributions to the samba codebase in one
there are approximately *fifteen to twenty* APIs inside of samba, at
varying technical levels: NetBIOS (wins, datagram, session, network
neighbourhood); SMB (print, file and IPC$), NamedPipes (LANMAN, samr,
lsa, netlogon, svcctl, srvsvc, spoolss) and that's _without_ even going
into implementation details regarding such issues as the SMB "vfs" layer
or the interactions between each of these layers and APIs.
this is why i have been advocating the "TNG" development approach to
Samba, because it is abundantly and very bluntly obvious that this is
one area that the open source community is failing to deliver.
excellent as the Samba project is, it's still in a monopoly position:
microsoft's strategic business policy of making life difficult and
complicated has made sure of that.
APIs are also subject of a published standard.
as i mention above, the ramp-up time to understanding those APIs are
simply abominable. each of them can be measured in man-years. and i
had to be the idiot that first determined and then developed some of
those apis (ahh, pooor me. poor _stupid_ me, more like!).
license does in fact permit the software to be modified, so that you
may add additional services directly to Samba.
ah. now we come to the crux of it [and we get slightly off-topic]
so, i may modify and add additional services directly to Samba. so i
must now say to people, "if you want these additional services, you must
first get the source, then you must apply this patch, then you must
compile it, ..." to which the ordinary person is going to say, "well,
all i want is 'A Samba', and 'A Service', why do i have to go to all
that trouble?" and the more discerning person is going to say, "how much
has this patch been tested?".
in other words, by the samba project running exclusively on port 139 and
thence IPC$ (over which Windows NT NamedPipes may be emulated) and being
uncooperative in not providing full documentation and not providing
reasonably APIs with which to interoperate, they are in a position of
monopoly power for technical reasons _as well_ as through being the
only available Open Source project of its kind.
I think you are trying to connect this with the Microsoft
anti-trust case and their "co-mingling" of the web browser with the
no, i'm not.
But remember that they didn't publish their source
code and APIs, and it was very difficult to remove the browser from
the rest of the OS and still have something that worked
afterward, and it was very difficult to modify their code - there was
no source and permission to modify.
i have to say that, imo, the browser / OS issue is peanuts compared to
NT 4.0 and 2000 Domains, DCE/RPC and now ".net" interoperability, and
it's an issue that i am EXTREMELY cross with the U.S. Dept of Justice
Monopolies and Mergers about.
i just hope that the EU's monopoly case against microsoft doesn't make
the same mistake.
a long answer to a short response, i'm afraid. if this was HTTP, i
really wouldn't bother with this at all, believe me! HTTP is nice and
simple and you can implement a simple client or server straight from the
RFC and pretty much expect it to work with a few bug-fixes.
SMB and DCE/RPC you haven't a cat in _hell's_ chance of doing that,
which is why there is only one popular Open Source SMB implementation
and there _isn't_ a popular DCE/RPC Open Source implementation.
unfortunately, the issue of samba restricting what programs can run -
and it _does_ restrict what DCE/RPC programs can be run, because of its
dominance and inability to cooperate, unmodified, of port 139 and of
IPC$ over port 139, has not been even considered in samba.
GPL compliance, posted 23 Oct 2001 at 12:15 UTC by mslicker »
Check with the FSF if you want to be absolutely certain. Just from my
understanding though, if you want distribute Samba as free software,
there is nothing in the GPL preventing you from doing that. The new BSD
and the GPL are compatible free software licences. If you want to
distribute as proprietary software, then the GPL states that this work
must be reasonably independent from the GPL parts, and you must
distribute the GPL parts seperately. I'm not familer enough with the
project to say if this is the case.
The implications for programs that use Samba is a bit more tricky. These
programs if released in a GPL incompatible way, must be reasonably
independent of the GPL parts of Samba.
The main key in this is determining reasonable independence. I think the
GPL is purposely vauge about this, to avoid all the technical issues
about linking code in various ways. I think the intention is to be fair
with respect to what is a derivative work.
OK, I looked at the EU law cited. It is mainly a permission to reverse
engineer software for purposes of compatibility. In the case of MAPI, it
would allow you to reverse engineer the APIs of the MAPI DLL and the
over-wire protocol of it uses, but it would not give you a free
license to use the MAPI DLL. If the producer of the MAPI DLL sued you
for using their API and protocol, the law would protect you. If they
sued you for using their DLL directly, it would not.
I'm not an
attorney, feel free to consult one for verification of this.
I think your argument of Samba as a monopoly still fails. If they were
doing something to unfairly and artificially maintain that monopoly,
like hiding interfaces and other details of their software, you would
have a point. But the only thing that gives them a monopoly, according
to your argument, is that there is a number of years work necessary to
duplicate their program, and that the software internals are difficult
to learn without a lot of work. Monopoly protection simply doesn't cover
the fact that you have to work or that the other party has a
time-to-market advantage. Those things are fair and expected aspects of
Consider that program "test" is proprietary. It uses FreeDCE, a dynamic
library under a BSD-like license. FreeDCE uses a GPL module. All three
elements are effectively parts of the same program - they reside in the
same address space, and the program counter is in each of them at
different times to execute the flow of control of the program. So, it
really does not make sense to say that the GPL module is not ever linked
to the test program. The BSD-licensed element between them is not a
condom that protects proprietary programs from the obligations of the
The GPL prohibits you from using GPL software as part of proprietary
software, as in the above example. I think you are confusing yourself by
thinking that the GPL would require you to change the license of the
other code. The GPL would require you to simply not use the GPL
component at all.
thanks, posted 25 Oct 2001 at 07:42 UTC by lkcl »
bruce, mark, thanks for taking time to address this: i think things are
clear-cut, and importantly, clear-cut now _to me_ :)
i'll take a look at the new GPL, as given that the existing GPL says
"you may release under this or later version", if the new GPL has better
BSD compatibility, that may be the way to solve this issue.
don!, posted 25 Oct 2001 at 07:49 UTC by lkcl »
mark, sorry, i thought you'd said there was a new version of gpl, no you
say implications are that components must be separated. ah well. no
solution to problem. solution is therefore, as recommended, a madatory
rewrite of at least 12,000 lines of code, because of licensing issues.
Bruce, it seems to me that you might be confusing usage rights with
copyrights. In particular, when you say:
The GPL prohibits you from using GPL software as part of
proprietary software, as in the above example.
...it would appear that you're incorrect. The GPL simply prevents you
from _distributing_ the GPLed code in such a situation. It specifically
doesn't say anything about what you're allowed to _use_ the program for.
If the user chooses to link your proprietary program to a GPLed program
later, it would seem to be fine; the user has obtained a proprietary
program under a valid license, and may now do what he/she wants.
Alternatively, in the A/B/C outlook/MAPI/pegasus case, just because
pegasus can talk to a MAPI dll doesn't mean the pegasus developers need
a license for it. When the user buys pegasus, if they already have a
licensed copy of MAPI then they can use it for whatever they want -
including pegasus. Since the pegasus developers have never touched the
MAPI dll, how can they be sued for using it?
To think of it another way: what if the pegasus developers link their
application to a "null MAPI" dll, with all the same function calls but
all of them just stubs? Then the end user can replace the stub MAPI
with the real one, and it'll work. How can that allow pegasus to be sued?
DMCA and UCITA notwithstanding, of course.
By the way, I'm not a lawyer either.
well, i have to say that i am just extremely unimpressed. microsoft has
been using dce/rpc technology since it was first introduced in windows
NT 3.1, well over ten years ago, now.
since then, they have continued to widen the gap further and further, to
the extent that it is now _such_ well-established technology that new
microsoft employees haven't even heard of it, have no idea what it is,
and there is noone left to explain it to them because they have all
retired as millionaires.
so they play _exactly_ the same strategies all over again - read the
halloween documents - except with fresh, new people, and fresh, new
and the open source community is left behind with their droppings,
taking no initiative because there's no room for the open source
community behind such a fast development rate that microsoft can
these GPL and BSD incompatibilities are going to continue to punish open
source developers and so-called "free" projects until someone somewhere
starts to get it.
Perhaps you could expand on how Microsoft is ahead of us.
Speaking as a user, the difference between free software and Microsoft
software, is like night and day. Using Microsoft software was like being
at war with your computer. Applications fighting you, the system and
applications strategically crippled, random system attacks (crashes).
Now that I use Debian, I can happily say my system has ceased fire.
I'm not very demanding user though. For users who are into the whole
Microsoft get up, you need complete file system support to make the
transition painless. That is, supporting all microsoft document formats,
media, ect. That is the main thing the user wants is file system
That is exactly where I would stop copying Microsoft. Microsoft's model
of software is completely different from free software, or at least how
free software should be built. It is a development model forced upon
them by their choice of business model. This development model consists of:
- a system of binary components
- a closed platform
- closed source
In this system, binary compatability is maintained throughout all
previous versions of system. This is a tremendous disadvantage compared
to free software. This means the software can't change, it can only be
added to. This is the same problem Intel has with its chips. The result
is increasing system complexety, bugs, and bloat. Meanwhile free
software can evolve, it can change with the changing use of computers.
What I think free software needs to do, and this stems out of my diary
entries, is it needs to focus on building a system. Right now we use a very
similar model to Microsoft, we are esentially taking our greastest
advantage and throwing it out the window. What I mean by building a
system, is that kernel developers should not be sepererate from library
developers, and library developers should not be seperate from
application developers. There should be one uniform solution space which
keeps evolving around the needs of the highest level, applications.
Therefore, when you are an application developer you are automatically a
library developer and a kernel developer, because all these barriers and
obstacles are eliminated, and you can focus directly on the solution to your
problem. I firmly believe if we had a focused effort on building a
system, we could be leaps and bounds ahead of Microsoft, and our community
grow closer in the process.
I agree that licence issues are a pain. Free software developers should
not have to deal with these, however I feel the GPL has had a very
progressive effect over all.
Samba and port 139, posted 26 Oct 2001 at 00:38 UTC by alan »
Quite frankly if you think it takes 5-25 man years of work to write a
tool to parse the packets to put both SAMBA and DCE based software on
the same port you have a problem.
I wouldn't mind betting you can find several consultants who will
happily bill you say four man years work and make a very tidy profit in
For that matter you can ifconfig a second address bind dce to one and
samba to another.
hi there alan,
i would _love_ to be one of those consultants paid for four years of
work to write a new open source SMB server. and i have the advantage of
knowing this protocol - the draft rfc JUST for the file-serving
component is two hundred and fifty pages long - pretty well.
i realise that these are fairly extreme man-year numbers and you do not
have to believe a word i say. that is _exactly_ the attitude i had six
years ago that got _me_ into this line of work in the first place
["heck, this stuff can't be difficult: _i_ could do better than
if you know anything about NetBIOS you will be aware that it is a
proxied transport [a bit like the proposed "TCP over HTTP" i heard
about, a few months ago. gawd, i hope that never happens :)].
ports 137 to 139 are the NBT version - NetBIOS over TCP [137 is like
dynamic-dns and is in some ways a little bit like ARP; 138 is the
datagram service and is like UDP; 139 is the session service and is like
your idea of adding an extra ip address has merit, and is in fact often
recommended to and by advanced administrators, especially when running
different versions of samba on the same host.
the only thing is that unique NetBIOS names are fixed to one ip address.
so whilst it is a nice idea, and in fact is often recommended [to have
multiple ip addresses on the same box], you must create a unique NetBIOS
name per each ip.
think of it like this. with the proposed "TCP over HTTP", what would
happen if that was implemented in user-space? would you recommend to
people, should critical TCP-based services become proxied over TCP that
people add an extra ip address, and run a new HTTP server over that?
food for thought.
hi there mslicker,
i have written a number of times in various locations describing how
microsoft is so far ahead, and it is far further ahead than even eric s.
raymond hints at in the halloween documents. their "strategic business
practice" of developing technologies that put them ahead by
approximately one and a half to two years of the game is LAYERED upon
the previous development.
i am focussing on the core technology - DCE/RPC - because without this
it is impossible to play catch-up.
regarding being a linux user, i am happy with linux because, like you, i
cannot deal with the frustration and time wasted by an OS or an
application that crashes thirty times a day. more to the point, other
people _around_ me can't deal with what happens to me when i am forced
to deal with such contemptible software. i try to make jokes out of it,
but that just makes people nervous.
however, most of the people who deal with computers on a day-to-day
basis are not like you or me, they are _forced_ to use Windows. hate it
or not, they know no better and no different. they are either paid to
sit in front of the Machine regardless of whether it works or not, and
when they get home, all their friends and all their helplines they can
reach go glassy-eyed when anything but the magic word "Windows" is
we are in the technological minority elite, boyzngirlz. there may be
some nice mailing lists and projects out there to keep us occupied
full-time, and this results in us not being able to see wood for trees.
we are in the middle of our own little world that has no relation to the
_rest_ of the computing world, we are _that_ far advanced and therefore
microsoft's policy of creating technological polarisation therefore wins
BY DEFAULT! i've been in a lecture theatre where the question was
asked, "why do you want to _bother_ catching up with microsoft: we [the
linux developers and users] are perfectly happy with what we have" and
it received an ovation!
the answer is, therefore, to help give _the other_ people [non linux
developers and users] some degree of choice which we already have and
take for granted.
p.s. i crashed StarOffice the other day, i just _loved_ the little
dialog box that said "you _may_ be able to recover your work if you
restart StarOffice" :) :)
parsing packets, posted 27 Oct 2001 at 16:32 UTC by lkcl »
hi there alan, i just re-read your statement "tool to parse packets".
okay, we're unfortunately not just talking about a tool to parse
packets. parsing packets is easy and can be done in a number of
different ways, and i have personally implemented at least six different
packet-parsing systems over the last five years.
we're talking about the support infrastructure _behind_ that _as well_
as the packet parsing, and it comes to approximately... one million
lines of code.
that sort of investment in code development you are guaranteed to be
talking about man-decades.
Don't take my comment as a criticism of Samba. I hardly know the
techincal issues involved to make a valid criticism, and it seems like a
It was more of a general argument, and perhaps a very obvious argument,
targeted to some trends within free software. Essentialy you can't catch
up to someone by following in their footsteps, unless they are standing
And in the process of catching up who has defined your path? Do we
really want a free software .NET? Or do we want to take the internet in
a completely different direction, one that promotes freedoms and
openness? Can we do a lot better techincally if we look inward and find
our own strentghs, instead of blindly following Microsoft?
You are right about free software being elitest. Not in theory, but in
practice. I hope that eventually we break down the remaining barriers
for the wide-range acceptence of free software.