I wrote:
Open source is usually one of two licence styles. BSD style and GPL style.

Todd Berman wrote:
But for sure, there are for more styles of licenses than those 2.


Absolutely. http://en.wikipedia.org/wiki/List_of_software_licenses

I am not saying licences are either BSD or GPL. I am saying they
usually are one of these two *styles*. Sorry about my lack of clarity.
Maybe I should have used the terms non-protective and protective licences, like in
http://www.groklaw.net/article.php?story=20031231092027900:

  "Open source licenses may be broadly categorized into the following
  types: (1) those that apply no restrictions on the distribution of
  derivative works (we will call these Non-Protective Licenses because
  they do not protect the code from being used in non-Open Source
  applications); and (2) those that do apply such restrictions (we
  will call these Protective Licenses because they ensure that the
  code will always remain open/free)."


More explicitly, I am saying that all open source licences have
features that tend to put them in one style or the other. Licences
that tend to let a developer usurp and close the code and lock in the
user are BSD style, while licences that do not are GPL style.

(In object-oriented-speak, I am saying the open source licences
inherit polymorphically from the abstract classes that are BSD style
or GPL style. The definition of the two abstract classes is a bit
nebulous though).


The other thing that BSD code allows you to do that you are missing is
it actually allowed greater *developer* freedom.

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.

The list of promising open-source projects that have been doomed because
of using a license like GPL is long and notable, in fact, many of the
well known projects available exist because of this. As well as all of
the insanity you get with stuff like readline vs libedit, etc.

Most software development projects fail. Think of it as darwin in
action. It makes the GPL stuff that survives much stronger, especially
since good bits can be taken out of failed stuff and reused.

As far as public domain and BSD style licensing being the same, I
disagree, lawyers disagree, the OSI disagrees. I'm not saying you are
wrong,

BSD and public domain obviously differ. What I am saying is that they
have the same style of failure - the risk of the software being
usurped, closed off, and used to bludgeon the original version out of
the running. I am, for example, worrying about the new paediatric modules etc being an instance of an attempt to embrace-extend-extinguish.

The GPL style has one basic restriction - a restriction that somewhat paradoxically *increases* freedom for the user in the longer time scale. The restriction being that if the user decides to distribute the program further, the source code must be made available further too. The consequence of this requirement is that the code can be developed further by the user, and that you can not ever be locked in by the vendor.


Again, vendor lock-in is not implicitly or explicitly solved via a GPL
style license.

Nonetheles, 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.

You can still be locked into a vendor who distributes software under the
GPL if no one else distributes functionally equivalent and/or
interoperable software.

Yes. But if the software is at all popular, a fork will spring up. On
the other hand, forking from a closed source distribution derived and
extended from a BSD style licence is much harder.

The GPL absolutely does allow for someone else to come along, fork an
application and continue a long with it, however, that is a high cost
result, and *forcing* a fork by choosing a license does not actually
promote any form of interoperability. You have to look no further than
the various emacs history pages to see this sort of issue re: emacs,
xemacs, etc.


Yes, GPL style code forks, a design may change, but fit code survives and you always have access to whichever code you want. Diversity is good, gives choice, and is self-limiting.

More importantly, the foundations of interoperability are open standards, formats. These foundations allow compatibility (not the same as interoperability) to be better in open source. Close off the source, and create your own standards and formats, and we go into embrace-extend-extinguish territory and we have less interoperability.

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.

Because of this, a lot of people, including me, regard GPL as the only sensible code licence in the long term for medical purposes.

I can't say that I am one, I am of the opinion that both licenses have
their uses in various situations, including healthcare. Choosing a
license could easily be the single most important decision a project
ever makes. To cover all possibilities with a all-encompassing statement
is not good under any circumstances.

I agree with you all-encompassingly on that.

It seems to me that the idea behind the certified support release of VISTA-office is to roll out the system in a supported way, so that incompetent people do not install it and botch it up. In sue-happy America, that is something the VISTA-office people and Medicare would have to worry about.



If VOE is released under nearly any license that it would actually be
released on, CMS will never be held liable. Thats what "No Warranty" and
"as-is" mean.

A doctor gives no warranty, and can only do his best. But
malpractice insurance has still gone nuddly over that last few years because doctors are sued. It is often not reasonable, but people are often not reasonable. Why should CMS not be sued by an unreasonable person?

I think the way forward for the VISTA-office people is to require an indemnity from anyone who wants to install it on their own without support from a certified vendor.

This is implicitly given due to any rational licensing terms.

Sorry, I meant in writing, with a signature. Given the way people sue, I would suggest that a shrinkwrap agreement or an implied agreement is too weak. I can imagine plenty of scenarios for a person to be instigated by a lawyer into sueing CMS. Lawyers sadly often do not sue for justice, but for money.

The other key thing to keep in mind is that a piece of software and code
released under and "opensource" license is useless. What is useful is a
open development model and community driven efforts. Without those, you
have a giant hunk of unmaintained code that stagnates and bitrots. It
does no one any good other than educational.


Yes. An opensource licence just lubricates the wheels of the
development cycle, but it cannot power it.

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

Reply via email to