Todd Berman wrote:
Yes. However, the risk for a BSD licenced software is that the
freedom of the developers is at risk if a company forks off a closed
version and adds proprietary bits to it, and tries to extinguish the
old standard. It has happened enough times with MS windows
applications taking BSD licenced stuff.
And this was a WONDERFUL thing in *MANY* instances. Why do you think the
TCP/IP stack is such a solved issue on modern operating systems? Because
they all use the BSD TCP/IP stack, and they inter-operate flawlessly.
Yay for people using similar code making my world a better place.
Yes, but TCP/IP wasn't always there. Remember netbeui, IPX? TCP/IP won
despite attempts to usurp it. It could have lost too. It won the Stack
Wars in the end because it was open, freely useable and was lucky the
Empire... I mean, Bill Gates wasn't paying attention to the internet
at the time - the source was strong with TCP/IP Luke ... I mean, Todd.
It is logical for a company to do the embrace-extend-extinguish thing
if they can. It increases shareholder value. MS explicitly stated the
principle (well, ok, to be accurate they missed out the word
"extinguish") in the Halloween documents (note to rest: a leaked set
of documents outlining MS policy towards the threat of open source).
It is a prevalent risk in BSD style licences.
Nonetheless, it is a consequence. Vendor lock-in is much *much* harder
to enforce with GPL because you cannot close the code if you
distribute the software to others.
Incorrect.
OK, so this is where we disagree. Let's look at your example:
In fact, In health-care, I would argue that vendor lock-in is just as
easy with the GPL as it is with BSD.
Lets say you write this great wonderful amazing VistA module that solves
every problem ever seen or heard of. It makes this software basically
'finished' (Yes, I know, Impossible, but this is a hypothetical). So you
decide, being the good Samaritan that you are, that you will release
this wonderful module under the GPL.
My company, lets say SAIC ford grins, takes your GPL code, and then adds
all kinds of more wonderful stuff. Now, under the GPL when I distribute
a binary, I must distribute source.
But what happens if I don't ever distribute a binary? Then I have found
one of the many truck-sized loopholes in the GPL.
I can now take your wonderful code, and my amazing code, and sell it to
hospitals as an appliance. No binary, just a box they can't access with
my software on it. It can even be on-site, I can easily ship a computer
and a person to set it up, and send someone out whenever there is a
problem with it.
I am unsure of what you are saying. You could sell a black box that is
binary-only, source only, or script only, but the GPL requires the
source be given for an executeable. There have been cases of GPL code
violations for flashromware in appliances that have been straightened
out by the FSF in a non-confrontational way (they prefer to do things
low-key) (http://lwn.net/Articles/35712/). If the user wants to access
the source she can have it with GPL code.
Accessing an EMR webservice that is running on GPLware and located
with you rather than the hospital, that would be another matter. That
code has not been *distributed* to the user. So the user has no right
to ask for the code.
I regard that "loophole" as a feature rather than a bug, because that
sort of thing is pretty clearcut. Yes, I doubt it was thought of at
the time the GPL was created (in pre-web times). It will certainly be
addressed explicitly in GPL 3.
But I don't think there is going to be any hospital IT manager who
allows the installation an EMR that uses a proprietary webservice
possessed and controlled by a third party. Any such a manager would
truly deserve the Dilbert Prize for Pointy-Haired Boss Doofusdom,
unless there is a "release the source in case the company dies" type
of arrangement in the contract.
Now. I am not saying a BSD style license solves this. And sure, SAIC
could just as easily take your BSD code and do the same. But to act as
if the GPL 'solves' this problem is very naive.
Actually, like I have shown, GPL stops it (except currently for the
webservice case), while BSD allows it.
When was the last time you got a real emacs configuration to load under
xemacs or vice-versa?
That would actually be a heresy for me, since I am a follower of the
One True Text Editor, vi. But I will address your point based on my
understanding of the problem.
They are both lisp, they are very similar, and
they have had years and years to become compat. Yet they aren't even
close.
By interoperable I meant emacs plugging into the xemacs structure,
which was what prompted a fork in emacs. I understand one fork got
used for xemacs, the other version went off in its own direction. By
compatible I mean file compatibility (like I said earlier, that is not
to be confused with interoperable). Compatibility is not really an
issue in emacs, since it is a text editor. Oh, ok, maybe the mail
formats and other bits in the emacs extensions are incompatible (I
don't know), but since the standards are open it is not going to be a
showstopper, and no doubt there will be convertors for everything.
After all, emacs people are the original bearded unix guru prototypes,
who do six impossible things with lisp wizardry before breakfast.
So my contention is that the emacses are all compatible. Just not
interoperable.
[Todd:]
As well as this, library lock-in can be just as dangerous.
The LGPL exists for a reason, and is very successfully used in many
places, and the LGPL allows for commercial software to be built using
it, which would for all practical intents and purposes cause this
mythical 'vendor lock-in' that you speak of.
You are saying that if the rest of the code is vendor locked-in, then
you will have lock-in with LGPL. That is not a LGPL issue - it is a
rest-of-the-code issue. It also does illustrate that the stronger GPL
makes more sense for people who want to avoid vendor lock-in.
No. I am saying that many LGPL libraries are used by companies that
provide software that strives *NOT* to force vendor lock-in. Look at
StarOffice/OpenOffice. Or AbiWord. Or Gnumeric. Or Criawips (I know,
beta, but it does exist). There are hundreds of examples of LGPL
libraries used in this fashion. Yet the LGPL allows commercial
applications to use it. Just like BSD. So why the disconnect? I thought
commercial == vendor lock-in according to your previous arguments?
An excellent point. Yes, the LGPL has that failing. The GPL doesn't.
That's why the L at the front stands for "Lesser". LGPL was created to
allow developers an alternative to vendors who felt the GPL was too
restrictive. Rather than have users lose access to their code
entirely, the LGPL is a licence option developers can consider.
A good account of its meaning and consequences in plain english is at
http://teem.sourceforge.net/lgpl.html
The LGPL is better than BSD because LGPL derivations are guaranteed to
stay unlocked and can still evolve, but it is worse than GPL, because
vendor lock-in via the rest-of-the-code becomes easy, and evolution of
LGPL would tend to be slower as a result of that. So like I said
earlier, it is a rest-of-the-code-issue rather than an LGPL issue.
That is why the stronger GPL makes more sense in the long term.
Yes. An opensource licence just lubricates the wheels of the
development cycle, but it cannot power it.
Agreed. That is why an Open Development Model is whats important, not
the license it is available under. Community driven development is the
win, not the GPL, or MIT X11, or MPL, or CPL or CDDL, or any other
license option you could choose or create.
Wellllll... the open development model is what drives it, and the
drive comes from the open nature of the code, which encourages people
to chip in. The open nature of the code depends on the licence. GPL
style licences make such development work evolve faster in the long
term because it protects the openness of the code. This is an
intrinsic part of their GPL-style (protective-style) licences compared
with the other licences.
So it seems clear to me that if you want an open code to develop well
in the long term, the GPL or similar protective licence is the wisest
choice of open licence.
regards
PJ
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
