Re: [Hardhats] VA To Invest Billions in Open Source Transition

[Nancy Anthracite]

The restrictions on combining products with open source licensed software generally
apply to redistribution, not the end user. Look to Linux as an example.

Sent via my Samsung Galaxy Prevail from Boost Mobile

Mike Dupont <jamesmi...@googlemail.com> wrote:

>>>This means, for example, that any hospital that implements a GPL version of VistA will be unable to purchase any commercial add-ons or enhancements to the platform.
>redhat, otrs and many others sell commercial add ons and enhancements
>to gpl products, I dont think your logic is fool proof here.
>
>mike
>
>
>On Mon, May 21, 2012 at 7:00 PM, Roger A. Maduro <rama...@gmail.com> wrote:
>> Guys,
>>
>> Just finished an article on the VA's participation at the Open Source
>> Think Tank conference, which took place in Napa, CA, April 12-14. This
>> is one of the leading open source conferences. Half of the three days
>> of the conference were focused on helping the VA work through the
>> development its open source strategy. Very exciting conference. I also
>> took the time to put a much broader picture together of VistA and the
>> VA Model of care. A lot of details in the article.
>>
>> VA To Invest Billions in Open Source Transition
>> http://openhealthnews.com/hotnews/va-invest-billions-open-source-transition
>>
>> Roger
>>
>>
>> -------------------------------------------
>> Roger A Maduro
>> Publisher and Editor-in-Chief
>> Open Health News
>> 117 Davis Avenue SW
>> Leesburg, VA 20175
>> (571) 252-9815
>> rama...@openhealthnews.com
>> www.openhealthnews.com
>>
>> --
>> http://groups.google.com/group/Hardhats
>> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
>
>
>--
>James Michael DuPont
>Member of Free Libre Open Source Software Kosova http://flossk.org
>Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
>Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
>
>--
>http://groups.google.com/group/Hardhats
>To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Ralph Johnson]

I'm a CS professor who teaches software engineering at the U of
Illinois and I lecture on copyrights each year and have studied the
matter quite a bit.

The GPL only applies if you give your software away in some matter.
If you take open source software, produce a server with it, but never
give away either source or binary, then it does not apply to you.
But if you sell either source or binary to other people then you are
required to give away source code for free to anybody who asks.

The GPL only applies to you if you modify GPL code, not if you run it.
But what if you link to it? GPL advocates claim that the GPL applies
if you distribute binaries that contain the GPL code even if all you
did was to link with a GPL library. They have created another license,
the library version of the GPL, that allows linking without making
your software be under the license. Some people say that the GPL is
not enforceable in this way, especially if you did not do the linking.
What if there is both a GPL and a non-GPL version of a library. When
you distribute an app with your code, you never include the GPL
library, but someone who bought your code did link it with the GPL
version and then sold it. Does this automatically infect your code?
Some people say yes, some say no, and the courts have not decided.
If you ask your lawyer, he or she will probably say that it is up to
the courts to decide.

What if you write a patch file and sell that to people who use it in
their own build process to make a binary that they sell or give away?
Again, some people say this makes your software come under the GPL and
others say it does not. However, concensus tends to fall more on the
line that this does make your code come under the GPL. Most people do
not think that your code will become infected by the GPL if somebody
else links it.

Linux is not a good example because programs do not come under the GPL
just because they are run under Linux. Only modifications to the
kernel are considered to come under the GPL. This includes device
drivers, and there have been cases where companies didn't write a
device driver for Linux because they didn't want to give away some
secret of how to communicate with it. Not many, and the cases I know
about were all old, before Linux got to be so popular.

Of course, many of the programs that come with Linux are also under
the GPL But not all. Apache and the X window system both have their
own license, for example.

I'm big fan of Smalltalk. Smalltalk is like Vista in the way
software components are distributed, which is patches. There is no
separate compiled library format. There is one GPL version of
Smalltalk. Even the other open source versions of Smalltalk are wary
of it. They won't take any code from it because they don't want to
become infected with the GPL virus. The Smalltalk community has
decided that it is OK for a GPL version of Smalltalk to take in code
from other systems, but not for the other systems to take in code from
a GPL system. (I know people outside the Smalltalk community who
disagree with this; as I said, in the long run it is up to the
courts). It seems to me that Vista is similar and the same things
will apply. People will tend to shy away from GPL code and the GPL
versions of Vista will become isolated. The version that wins out
will have a license like Apache, BSD, or MIT. It is inevitable.

So, people who don't like the GPL don't need to get excited about it.
Those who love the GPL should realize they are fighting a battle that
they will probably lose in the end. But we all die in the end, and
most of us fight it as long as we can. I admire people who fight to
the end in a cause they think is important, even if the chance of
success is small.

-Ralph Johnson

[Mike Dupont]

well we just have to make clear what this is all about and not be general.
if you make a program that stands alone, you can license it how you
like, even if it "uses" gpl code or functions.
if your program is derived from another program that is a different issue.
I dont see how the license of the core system will affect any
applications written for it.
please lets get to the details,
thanks,
mike

[Ralph Johnson]

On Tue, May 22, 2012 at 7:58 AM, Mike Dupont
<jamesmi...@googlemail.com> wrote:
> if you make a program that stands alone, you can license it how you
> like, even if it "uses" gpl code or functions.
> if your program is derived from another program that is a different issue.

It depends on what you mean by "uses". If you include one line of GPL
code then there are many people who say that your program falls under
the GPL. It is easy to make a program that runs on Linux but stands
alone from Linux, because it can run under Unix as well. And I
suppose a program that runs on any version of Vista can be said to
stand alone from GPL Vista. However, it can also be said that any
program that runs on Vista is an extension of it, that it is derived
from Vista. That is because the way you run a program on Vista is to
add code to Vista, to patch it. So, unless there are non-GPL versions
of Vista that your program can run on, there is significant danger in
other people claiming that it falls under the GPL. Then the courts
might have to decide who is right.

I've been using emacs almost since day 1, at least over 27 years. And
I have used gcc for a long time, too. linux not so heavily. I have
nothing against the GPL, but I am a programmer and an academic, so it
is well suited to me. I've noticed that a lot of companies are afraid
of it. I've also noticed that a lot of other licenses can give you
the same community action that was the purpose of the GPL. People
are just as likely to share with Apache software as in FSF software.
The license is less important than the culture of the community.

It is easy to say that those who are against the GPL are just
practicing FUD, but there isn't the same feelings about the other
licenses. Because of that, I would never pick the GPL for a new
project.

-Ralph Johnson

[David Whitten]

The license wars come up on a regular basis, and don't usually convince someone who is already decided.  I'm not attempting to convince those who already persuaded, but to

explain the view that I take.

In terms of VistA, it was created as a virtual operating system to run medical applications.  The VistA Kernel was named that, because it was the operating system kernel, much like there is a Linux kernel.  Running applications on Linux does not mean that they must take the Linux license as their own.    Writing code in MUMPS does not require the applications to take on the license of MUMPS. Writing code in VistA does not require the applications to take on the license of VistA. Practically speaking, VistA as a whole, as a work of the government and as such, is in the public domain.

Since MUMPS doesn't "link" programs in the way that "C" or some other programming languages do, we as a community of MUMPS users have a responsibility to explain how some of the provisions of the GPL-like licenses apply to our programming environment.

In my opinion, use of system calls in programs written in Linux is no different than using published APIs for Kernel (which includes FileMan). I have heard no arguments saying that every program written in Linux must have the Linux license and ownership, nor have I heard any arguments that every program written in MS Windows must be under Microsoft's ownership and license.

I do know that our VistA/Hardhats community is going to have real problems if we don't work together. I do know that if people think they can take from the community and not give back to it, that we will never reach the goal of wide usage of VistA and all of its proven benefits for health of people being treated in healthcare systems using VistA.

On Tue, May 22, 2012 at 7:58 AM, Mike Dupont <jamesmi...@googlemail.com> wrote:

[Mike Dupont]

Uses, I mean use, reference, call.
There is no restriction on usage of gpled code.

the only small issue is of linking, when on some systems, you will
link gpled code into your executable and create a derived work.

On Tue, May 22, 2012 at 5:15 PM, Ralph Johnson <joh...@cs.uiuc.edu> wrote:
> On Tue, May 22, 2012 at 7:58 AM, Mike  Dupont
> <jamesmi...@googlemail.com> wrote:
>> if you make a program that stands alone, you can license it how you
>> like, even if it "uses" gpl code or functions.
>> if your program is derived from another program that is a different issue.
>
> It depends on what you mean by "uses".  If you include one line of GPL
> code then there are many people who say that your program falls under
> the GPL.  It is easy to make a program that runs on Linux but stands
> alone from Linux, because it can run under Unix as well.  And I
> suppose a program that runs on any version of Vista can be said to
> stand alone from GPL Vista.


> However, it can also be said that any
> program that runs on Vista is an extension of it, that it is derived
> from Vista.

No i dont agree with that at all. I can create a program that stands
alone and sell it to you.
you would install vista and install my program, but I would never have
to distribute or copy the gpled code.

> That is because the way you run a program on Vista is to
> add code to Vista, to patch it.

that is a technical detail, the user patches it not the distributor.

> So, unless there are non-GPL versions
> of Vista that your program can run on, there is significant danger in
> other people claiming that it falls under the GPL.  Then the courts
> might have to decide who is right.

again i dont agree.

>
> I've been using emacs almost since day 1, at least over 27 years.  And
> I have used gcc for a long time, too.  linux not so heavily.  I have
> nothing against the GPL, but I am a programmer and an academic, so it
> is well suited to me.  I've noticed that a lot of companies are afraid
> of it.  I've also noticed that a lot of other licenses can give you
> the same community action that was the purpose of the GPL.   People
> are just as likely to share with Apache software as in FSF software.
> The license is less important than the culture of the community.

this is getting to big, lets stick to the details.

>
> It is easy to say that those who are against the GPL are just
> practicing FUD, but there isn't the same feelings about the other
> licenses.  Because of that, I would never pick the GPL for a new
> project.

lets not get emotional about this at all please, copyright is not
about emotion but about copying.

[Mike Dupont]

On Tue, May 22, 2012 at 5:25 PM, David Whitten <whi...@worldvista.org> wrote:
> Since MUMPS doesn't "link" programs in the way that "C" or some other
> programming languages do, we as a community of MUMPS users have a
> responsibility to explain how some of the provisions of the GPL-like
> licenses apply to our programming environment.

ok, lets think about this. you have a gpled program and you load new
data into it.
that is what perl or bash does as well, even the compiler loads the
program into memory, but emits a new program.

gt/m does for example emit .o files which can only be used by the
kernel, I have looked at some of it, it does not seem to include
source code of the main system, but even if it does, it does not
matter. If i have mumps code, I can run it on gtm no matter what
license it has.

>
> In my opinion, use of system calls in programs written in Linux is no
> different than using published APIs for Kernel (which includes FileMan). I
> have heard no arguments saying that every program written in Linux must have
> the Linux license and ownership, nor have I heard any arguments that every
> program written in MS Windows must be under Microsoft's ownership and
> license.

there are no copyright on function descriptions, header files and
function names.

>
> I do know that our VistA/Hardhats community is going to have real problems
> if we don't work together. I do know that if people think they can take from
> the community and not give back to it, that we will never reach the goal of
> wide usage of VistA and all of its proven benefits for health of people
> being treated in healthcare systems using VistA.

Well i dont know the history of this discussion, but we need to remove
all the emotion here and get to the facts. I have spend years studying
copyright and licenses, and I can tell you that there are some unclear
issues to take care of here.

The biggest problem I see with gtm is that it has assembler code, we
should work on removing that direct assembler generation and assembly
files and use some higher level functions, there are many tools
available now aday.

mike

[Ralph Johnson]

On Tue, May 22, 2012 at 10:27 AM, Mike Dupont
<jamesmi...@googlemail.com> wrote:

> lets not get emotional about this at all please, copyright is not
> about emotion but about copying.

But this IS about emotion. Copyright doesn't make me emotional, but
it does that to many people. Technical decisions can have emotional
impact. It is important to consider their impact when making the
decisions.

-Ralph Johnson

[Mike Dupont]

On Tue, May 22, 2012 at 5:32 PM, Mike Dupont
<jamesmi...@googlemail.com> wrote:
> there are no copyright on function descriptions, header files and
> function names.

there is no copyright protection on the function names and the parameter lists :

http://www.theregister.co.uk/2011/03/29/google_android_and_the_linux_headers/
http://electronics.stackexchange.com/questions/12368/avoiding-copyright-violations-when-writing-header-files
http://linux.slashdot.org/story/11/03/20/1529238/rms-on-header-files-and-derivative-works

facts are not copyrightable http://en.wikipedia.org/wiki/Feist_v._Rural

[Mike Dupont]

I have heard a bunch of emotional arguments here that dont have
anything to do with how the gpl or any copyleft license work.
Let address the question of law here first and then you can continue
with emotional debate where I dont want to be involved in.

The question here for me is, in terms of copyright, does the license
of a kernel or server program affect applications that run on it,
and it does not. As long as the application does not copy files from
the server it is fine. Your creative works will never be infected with
"gpl viruses' if you dont copy any into your code.

lets take an example, you worked for 10 years on creating some program
and you sell it. you want to port it to a gpled gt/m. maybe they have
to change some lines of code, but as long as they dont copy lines of
code from gt/m it is still the same program. You dont give up any
rights just by running a program. The gpl specifies that you are free
to use it for any purpose, that means running your own program.

there are many examples of plugins and addons that have different licenses.

as I said, you only need to worry about changes to the gt/m itself but
not how the programs interact in memory. copyright is only really
invoked when you distribute the product and you are free to distribute
gt/m yourself and then free to sell your product that runs on it
separately.

this is the same issue with for example selling a linux server and
then installing your custom software on it.

mike

[Bhaskar, K.S]

I do not wish to comment on VistA licensing, but as the manager of GT.M, I will comment on GT.M.  In one set of words or another, I have gone on record to make a statement such as that below in public forums (search engines are your friend; the words may vary, since I try to state the point in plain English) a number of times since GT.M on x86 Linunx was first released as free / open source software in 2000 with GPL v2 (the current license is AGPL v3).

We do not consider running an application on GT.M to create a derivative work.  We do not consider bundling or aggregating for distribution (under a URL, on a CD, etc.) of GT.M with application code written to run on GT.M to create a derivative work.  If you modify GT.M source code to create and distribute a derivative work, we expect your modifications to GT.M  to comply with the license for GT.M.  Distributing GT.M and your application code in separate directories or folders, suffices to separate GT.M itself from application code written to run on GT.M.

If the above is not sufficiently clear, please do ask for clarification.  Thank you very much.

Regards
-- Bhaskar

K.S. Bhaskar
Development Director
Fidelity Information Services, Inc.
2 West Liberty Boulevard, Suite 300
Malvern, PA 19355, USA
+1 (484) 324-8608
ks.bh...@fisglobal.com
http://fis-gtm.com
http://fis-pip.com
http://fis-profile.com

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[David Whitten]

I don't think anyone has made an argument that GT.M's license has anything

to do with the license of code written in MUMPS to be used on a GT.M implementation.

Mentioning GT.M below is broadening this discussion unilaterally. I don't think you want to dilute the discussion about VistA code to bring up GT.M code issues.

VistA Kernel is a virtual operating system kernel written in MUMPS.

Each package of VistA Kernel can be clearly mapped into a subsystem in any other operating system. For example, the OS file-system maps into FileMan, the process scheduler maps into TaskMan, the OS-shell maps into MenuMan, the termcap file maps into the Terminal Type File, etc.

I don't think VistA Kernel's license has anything to do with the license of any application which runs on VistA Kernel. The application will consist of the code written in MUMPS or defined in VistA data-structures to be used on the VistA Kernel implementation, and should be considered as an independent entity with its own license. 

[Mike Dupont]

ok, I have not looked at vista at all, I have only looked at gt/m.

On Tue, May 22, 2012 at 4:20 PM, David Whitten <whi...@worldvista.org> wrote:
> I don't think anyone has made an argument that GT.M's license has anything
> to do with the license of code written in MUMPS to be used on a GT.M
> implementation.
>
> Mentioning GT.M below is broadening this discussion unilaterally. I don't
> think you want to dilute the discussion about VistA code to bring up GT.M
> code issues.
>
> VistA Kernel is a virtual operating system kernel written in MUMPS.
> Each package of VistA Kernel can be clearly mapped into a subsystem in any
> other operating system. For example, the OS file-system maps into FileMan,
> the process scheduler maps into TaskMan, the OS-shell maps into MenuMan, the
> termcap file maps into the Terminal Type File, etc.
>
> I don't think VistA Kernel's license has anything to do with the license of
> any application which runs on VistA Kernel. The application will consist of
> the code written in MUMPS or defined in VistA data-structures to be used on
> the VistA Kernel implementation, and should be considered as an independent
> entity with its own license.

ok great, so my arguments still hold to modules that you write that
are used in an os kernel. You would be able to sell and license source
code that goes into a kernel as well.

i need to reread this thread to see the question, but I still dont see
why the license of a kernel would affect how an independant part of
that system is licensed.

[Mike Dupont]

Ok, after readreading, I found a soft spot.

On Tue, May 22, 2012 at 3:15 PM, Ralph Johnson <joh...@cs.uiuc.edu> wrote:
>  And I
> suppose a program that runs on any version of Vista can be said to
> stand alone from GPL Vista.  However, it can also be said that any
> program that runs on Vista is an extension of it, that it is derived
> from Vista.  That is because the way you run a program on Vista is to
> add code to Vista, to patch it.

So, lets break this down.
Your customer downloads the gpl vista, then he goes to you, and buys a
program from you that you wrote, and patches his vista and runs it.
Where does the gpl come into play? only when they download vista. Your
program or patch does not have to be derived from the gpl vista, even
if you write it to fit against a specific version of vista.

Even if you need a set of names or constants or whatever to use it,
the names of those cannot be copyrighted, you cannot force the license
upon someone just because they use your names.

I hope that this is clear and I am willing to discuss it until we get
to the bottom of it.

mike

[Michael ONeill]

Mike,

Thanks for breaking this down. If it were possible to run everything according to a model where VistA is an operating system with applications running on top of it, in the same way that applications run on top of Linux, then the Linux licensing analogy would apply: the license of the operating system and of the applications are unrelated. 

But this is not the case for many VistA applications. They are implemented such that they are more tightly coupled with the VistA core; coupled in a way that would require the whole to be placed under the GPL if the core were under GPL. 

A GPL core would prevent non-GPL participation in applications that require close integration. That would remove from consideration too many valuable contributions to VistA.

This is the main reason why OSEHRA chose the Apache 2.0 license. 

Mike O'Neill

VA Innovation Initiative (VAi2)

OSEHRA

[Mike Dupont]

On Tue, May 22, 2012 at 8:01 PM, Michael ONeill <mdon...@me.com> wrote:
> But this is not the case for many VistA applications. They are implemented
> such that they are more tightly coupled with the VistA core; coupled in a
> way that would require the whole to be placed under the GPL if the core were
> under GPL.

Does this coupling require that lines of code are copied from the core
into the app?
What is being copied? how much code are we talking about.

And when does coupling create a derived work? Just because you use an
API or some functions does not mean you are making a derived work.

In fact, just because they are coupled has nothing to do with the
distribution. We could make an program a linker that couples the app
to the core according to some rules.

please provide concrete details and we can find solutions for them.

[Nancy Anthracite]

One thing that I would like to point out is that Apache with its Apache
license has a strong and well funded community, but it also is supported by
businesses where Apache is not their main business. It is but a tool that they
use and it crosses many businesses who are willing to contribute to that tool.

VistA is not in very wide use outside of the VA at this time and the community
of those passionate about it is relatively small. For those of thus trying to
build a community around VistA with new code licensed with a strong copy left
license, VistA is the CORE of what we do. Thus, assuring that work done by
members of the community is contributed back to all the other members of the
community is vital to us. We are also trying to support the have-nots world
wide and they are not in a position to purchase software. They need costs to
be kept low.

In particular, our volunteers, and even those who are compensated for their
work, do not want to see someone try to sell them an improved version of
whatever it is they contributed free of charge.

We have been watching Jignesh create yet another closed version of VistA over
the last year or so, and he is not the only one who will be doing it by any
means, so this is clearly not yet a community that is all committed to work
together like the Apache community may. I don't think you can make the
argument that the sheer size of the community will lead to cooperation, not
yet at least.

So WorldVistA will be seeking out users who are committed to that vision of
sharing and community and help seal the deal with a strong copy left license.

--
Nancy Anthracite

[Mike Dupont]

That is great to hear. I really think that a sharealike license can work.
Of course some big corps would like to have an "open" version so that
they can put it in expensive locked down products.
That works for microsoft and adobe in the 90s, it is the basis of the
unix culture etc.

That is not always bad, but if you want to get *people* to contribute
then that is a good protection for them. I just want to make sure that
no one is going to throw around fuzzy terms here and push for one
license without a rational discussion. We need to make sure that all
issues are discussed openly and I really have seen no reason for one
license over the other on technical terms. My personal preference is
share-alike for the reason that I think that sharing is important, but
my we are not even close to a decision right now because there are no
strong rational arguments yet presented.

Another argument would be to put the work under the public domain
because it is basically a project payed for by the people and it
should belong to the people.

The argument against that is that it reduces the ownership of the
community and if you look at a project like wikipedia , you will find
a dedicated community.

I am personally interested in gt/m because of fosm.org using it, I see
it has some interesting features and it might be interesting for the
future.

There are very many young people out there who dont know what to do, I
am sure some can be convinced to learn about vista and mumps and gt/m,
but there is a long road ahead for that. Having a license that gives
people a part of the pie, the promise that we will share back with
them is also a good way to build trust and increase openness.

For me personally I am missing all types of information and details
even about gt/m, the code is really old school c, and I have not seen
code like that in a long time, if ever.

We have to see the point that mumps/gtm/vista is its own little world,
and opening that up will be difficult. It is hard to bring new people
in because the barriers of convention, documentation and just
concepts.

There is alot of work to be done to get the gt/m system up to the
level such as the gnu tools in terms of code. It will be hard for
people from the free software/open source world to get used to the
code and to adopt it. I am willing to invest some more time on this,
but also I want to make sure that my work will not just be taken with
nothing being given back.

Really what i see as the most needed thing is a swig/interface
wrapping system or a gobject introspection system for gt/m to be able
to easily call out to existing c code. The existing system is just too
difficult to use, with a clean interface system we can also define
boundries between modules and licenses. It should be possible to also
make better wrapper for mumps to allow it to be used from python, perl
etc more easily. these are steps that will really make things easier
to use.

So really I think the most important thing is to work on that, a way
to document the interfaces of the code that are there and to be able
to generate wrappers and interfaces around those interfaces for new
code to be written and existing libs to be used.

thanks,

mike

mike

[K.S. Bhaskar]

(The following is just my own personal view and does not necessarily represent that of anyone else.)

The nature of M applications is that they are not really as tightly coupled as one might think.  At least on GT.M, every process is dynamically linked.  The first time a process does a DO ABC^DEF or $$ABC^DEF(), a GT.M process dynamically links module DEF.  So, let me work with the view that dynamic linking suffices to separate code with incompatible licenses.*  Then module DEF and module XYZ can have completely different licenses, and still be part of the same VistA process.  If entity P provides module DEF under a FOSS license, regardless of how permissive it is, and entity Q provides module XYZ under a proprietary license, dynamic linking at the process level in effect firewalls the licenses of DEF and XYZ.

Now, if entity P provides module DEF under a FOSS license, and entity Q wishes to modify the code of DEF with its proprietary enhancements, then license interaction needs to be considered, but not if they provide their code as separate modules.  In this case, entity Q could provide their changes as deltas to the code provided by entity P.  I acknowledge that is is one of those gray areas in license interaction that has not been fully decided with legal precedent.

Data interaction is similar to code interaction with one wrinkle.  If entity Q wishes to provide their proprietary data and loads it in a separate global variable, that global variable can reside in a completely different database file which firewalls the licenses.  If entity Q wishes to provide its data in a global variable that also contains data from entity P, it can provide its data as an overlay of deltas, just as with source code.  The wrinkle is that Q may want to change the data dictionary to map its changes and there is only one data dictionary.

VistA's history with distributed development and the use of namespaces actually makes it more likely that entity Q and entity P will create separate modules DEF and XYZ.  So my personal view remains that VistA licensing is obscured by smoke that blocks light.

Regards

-- Bhaskar

* While I am not a lawyer (and everyone thanks God for that, including me), my personal view is that dynamic linking firewalls licenses, at least in the United States.  While I am not aware of legal precedents, if it get to court, I strongly feel that this view will prevail.  But it suits people all round to treat it as a gray area.

>> To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com
>
>
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

--
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

--
http://groups.google.com/group/Hardhats

To unsubscribe, send email to Hardhats+unsubscribe@googlegroups.com

[Mike Dupont]

yes dynamic linking should do the trick,if you want to ship object code.
if you license your app in source, the customer can, without problem
also link it all together statically, just the vendor cannot sell a
statically linked binary that mixes with gpl.

On Tue, May 22, 2012 at 9:26 PM, K.S. Bhaskar <ksbh...@gmail.com> wrote:
> dynamic linking suffices to separate code with incompatible licenses.

[K.S. Bhaskar]

VistA is distributed with full source code, as are most M applications.

Regards

-- Bhaskar

[Mike Dupont]

as I tried to say before, if the customers are loading third party
modules themselves, there are no license issues at all. GPL only
affects vendors if they want to distributed mixed code between
licenses. If a vendor sells only a file that is standalone,
independent of the runtime behavior, and that standalone file does not
contain copies of other code, then there will be no restrictions on
the vendor.

so, it does not matter i think for a system like gt/m and vista,
vendors will be free to sell expensive software and the community will
be free to share code with each other with no limitation if the vista
source is under GPL .

Now with AGPL the issue might get more complex, I will have to think
about that.

mike

> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Michael ONeill]

The connections between VistA packages are much deeper than communication via an API. They essentially belong to the same application, sharing variables and data directly. Data owned by one package is updated directly by other packages. And I'm sure that the true developers on the list can give you better examples. 

There is no way that VistA packages are going to be decoupled in any of the ways you mention. Don't get me wrong - I wish this wasn't true! But it is the way that VistA was designed others on the list have stated far more elegantly than I can the benefits of this tight integration.

Mike

[Mike Dupont]

OK, I think I see the problem. Currently there are apps that use vista
code are maybe just extended versions of it. if they change the
license to gpl then it would cause problems?

lets say that you can deliver a patch to vista that contains no code
from vista that installs your app, you can sell that to your customer.
I think that should not be a problem as long as you dont distribute
the GPLEd code.

[Mike Dupont]

see this thread :
https://groups.google.com/group/gnu.misc.discuss/browse_frm/thread/bda81493bb28ba98?hl=en&pli=1

"Your customers will have to apply the patch themselves. "
"In additions, your customers will not be able to distribute the
patched kernel themselves either"

that applies i think to a hospital that is using your application.
mike


On Tue, May 22, 2012 at 10:05 PM, Mike Dupont

[Chris Farley]

All data manipulation is done by calling a FileMan API. You can't just
install a patch on GT.M and have it do much of anything to VistA data
without also having the VistA code - that is problematic. Creating a new
file, with pointers to existing GPL files also seems that it would cause
complications. One of the biggest factors that I see is that all routines
are stored in the same exact file.

None of this is going to be settled until someone tries to enforce the
license. Then it will be up to a Judge that has limited understanding of
technology or worse, a "jury of our peers" that knows even less.

My personal opinion is that regardless what the community does, in the end,
the slickest lawyer is who will be right.

Christopher B. Farley
HIT Consultant

[Michael ONeill]

Bhaskar,

Thanks for laying out your thoughts in such a structured way! 

Would we not be making life unnecessarily difficult for developers and for users if we forced them to follow some of the guidelines you laid out, though?

If a requirement to provide code via base modules and separate deltas isn't problem enough, what happens when the application demands common data, and it isn't desirable or possible to use separate globals and separate files? 

While we may be able to construct technical ways to handle each situation, to the extent that our solutions are difficult for users and developers, they dampen participation. That's contrary to building a bigger, more inclusive community.

Thanks,

Mike

>> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
>
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

--
http://groups.google.com/group/Hardhats

To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Michael ONeill]

Yes, changing the license to GPL would be a problem.

Not being able to distribute GPL code is sometimes a problem, too: suppose you are in the business of selling software and services to your customers, who expect a complete solution from you.

For many (maybe even all) cases we can imagine, there might be a way to work around the fact that some code is under GPL. You've described some some methods. Bhaskar described some, too. 

But any time that the method is awkward (like telling a customer to get the core of VistA from one place and an enhancement somewhere else, or telling them that they'll have to apply patches themselves, or telling a developer to maintain separate databases, for license reasons, of what should be the same data, etc.) there are going to be people who can't or won't participate. 

If we want to grow the VistA community, why make things more difficult for developers, users, and service providers? A permissive license removes these challenges. 

And as plenty of open source communities have shown, a permissive license rarely keeps anyone from contributing back enhancements that they make to the core platform.

Mike

[Mike Dupont]

On Tue, May 22, 2012 at 10:17 PM, Chris Farley <cfarl...@comcast.net> wrote:
>  You can't just
> install a patch on GT.M and have it do much of anything to VistA data
> without also having the VistA code - that is problematic.

OK, lets look at this. You are the vendor you want to *use* this
fileman and not to change it, just using it means that you expect it
to be there in a certain version, and you test it on your copy of that
version. the customer would install your program that uses that and it
is linked all together on the client machine. this is all within the
scope of the gpl. It would protect the fileman implementation and if
you wanted to change the code of fileman, then of course it would be a
more complex issue.

I am also wary of lawyers, I am not a lawyer. this is not legal advice :D,
but I think we should be able to debug this issue together.

mike

[Mike Dupont]

On Tue, May 22, 2012 at 10:48 PM, Michael ONeill <mdon...@me.com> wrote:
> But any time that the method is awkward (like telling a customer to get the
> core of VistA from one place and an enhancement somewhere else, or telling
> them that they'll have to apply patches themselves, or telling a developer
> to maintain separate databases, for license reasons, of what should be the
> same data, etc.) there are going to be people who can't or won't
> participate.
>
> If we want to grow the VistA community, why make things more difficult for
> developers, users, and service providers? A permissive license removes these
> challenges.

Now these are good arguments for having a permissive license, and I
understand the now better issue as well.

I hope that we can all see that it should be technically possible to
use GPL or some sharealike license for vista, even if it might make it
a bit difficult for some commercial vendors. That could be a problem.

Now, I am basing my discussion on the idea of people patching the
linux kernel themselves. but the situation for vista would be
different.

If you are dealing with a client directly and they are not going to
distribute the code, then you should not have a problem anyway. I dont
think you have your software on the web for download either. If you
are under contract from a client then they could allow you to deliver
them a patched system and you would agree with them that the modules
are under different licenses. I dont think it would change the way you
work, except that your customer would run the risk of not being able
to upgrade. That is why having clean patches would be good. The
purpose of the GPL is to allow for the customer to have the freedom to
continue without a vendor or to get a different vendor. I dont know
the terms of your software license, but in any case the customer would
have the code.

Now, The work to create clean interface would pay off. It should be
possible to put the work into cleaning up the system to make it
attractive. But, I dont know vista and would have to look into it
more. I am willing to look at some example code and try and grok it
if you want to point me to some examples.

I have learned something from this discussion and hope that you have
also benefited from it.

[Mike Dupont]

On Tue, May 22, 2012 at 11:27 PM, Mike Dupont
<jamesmi...@googlemail.com> wrote:
> and I
> understand the now better issue as well.

and now I understand the issue better as well.

[Michael ONeill]

Hi Nancy,

That's not such a convincing case for copyleft. 

The Apache Foundation is not a single open source project. There are around 100 different projects. For most of those communities that particular project is the core of what they do. And there are companies built on those open source products - for sure, that open source software is core to what those companies do. Take a look at Hadoop, an open source Apache Foundation project, and Cloudera, a company that makes a business providing Hadoop, bundled with software and services, to its customers. 

So the idea that the Apache license works only for products that aren't core to anyone's business doesn't make any sense.

But I do agree with you that those projects are often funded by a group of commercial companies who are willing to support the open source effort because it's important to their business. A permissive license allows them to build those businesses; a copyleft license, for many of them, doesn't. 

If we'd like to enable more people to build businesses by bundling software and services with open source VistA, which would give us a community of companies willing to support the open source VistA work, why would we hamstring those businesses with a copyleft license? 

Talk to the people in the Apache community, and the people like Red Hat and Canonical in the Linux community. The fact that they use permissive licenses just isn't the barrier you think it is when it comes to people contributing back their enhancements. 

How does a copyleft license help the have-nots? They can get the source code at no cost whether the license is GPL, Apache 2.0, or whether the code is public domain. But is source code really what helps them? Or is the availability of support and services what they really need? How do we enable more people and companies to provide that support? 

Has anyone on this mailing list ever had someone try to sell them an improved version of software that they wrote? Is that really the concern? I would think that anyone trying to make a living that way would be out of business very quickly. There just isn't a lot of value in selling pure code. There is a lot of value in selling services and support, in providing customers with turnkey solutions, etc. But just plain software - not so much.

I wonder if you're referring to people who write a proprietary package and sell it. That is very different from taking someone else's code, modifying it, and trying to sell it. Proprietary packages only get sold when there are customers who find real value in them. And if what is being sold is just code (and not support and services), then in a healthy community where there are many companies participating, it's unlikely that just having code will stay an advantage worth paying for for very long. And the type of license doesn't change that - except for one thing: the wrong license can keep people out of the market, which means that users lose out on choices.

So I'm just not seeing the value of the copyleft license for VistA. If what we want is a growing community, with more users, more service providers, and more developers - and this is definitely what both VA and OSEHRA want - then a copyleft license works against us by discouraging participation. 

Mike

[Ralph Johnson]

On Tue, May 22, 2012 at 5:13 PM, Mike Dupont
<jamesmi...@googlemail.com> wrote:
> see this thread :
> https://groups.google.com/group/gnu.misc.discuss/browse_frm/thread/bda81493bb28ba98?hl=en&pli=1
>
> "Your customers will have to apply the patch themselves.  "
> "In additions, your customers will not be able to distribute the
> patched kernel themselves either"
>
> that applies i think to a hospital that is using your application.
> mike
>

Read down that thread to the reply by Alfred Szmidt. He says that if
the patch is a derivative work, it must be licensed under the GPL. A
good lawyer would say that a patch must have been a derivative work;
you couldn't have written it without studying the original, and so it
was derived from the original. I'm not sure I believe that, but if I
were starting a company then I would worry about a judge agreeing with
him.

-Ralph Johnson

[Nancy Anthracite]

Frankly, I can't see OSEHRA having only a GPL or AGPL license because it would
be politically untenable. OSEHRA would be tolerated by the legislative bodies
otherwise. WorldVistA and some others in the community know from experience
how powerful the anti-open source lobbyists are on "The Hill". As I recall,
it took quite a bit of effort to even bring OSEHRA into existence because the
words "Open Source" are in the name of it. It will have to be "business
friendly" to survive. However, you could consider having dual licensing on
the part of OSEHRA.

But whatever OSEHRA decides about licenses, it does not mean that WorldVistA
has to change it philosophy, nor Medsphere for that matter, to contribute
significantly to the advancement of VistA and to help advance OSEHRA. It may
be inconvenient, but the end user can take advantage of the enhancements made
under a GPL or AGPL license and can benefit from the work done by the
WorldVistA community.

I think that OSEHRA has already worked out a means of providing copy left code
by having a separate repository for it and it plans to certify it just like it
does closed source code to be used with the OSEHRA version of VistA. Users can
go pick up copies of that code as conveniently as they can go buy a closed
source package. A nonalignment of the open source licenses between OSEHRA and
WorldVistA is not unmanageable.

We are already right in there working with OSEHRA, contributing on Hardhats,
providing community meetings that everyone, even those that have proprietary
products, can attend and benefit from. We will also become members of OSEHRA
if the wording of the membership agreement is changed. Yet WorldVistA EHR
users and contributors are also relying on being able to contribute to the
community and to have their contributions enhanced and returned without fail,
and they are relying on others in the community of WorldVistA EHR users doing
the same, and that is exactly what is happening.

We all know that the percentage of the code that is in WorldVistA EHR that is
not the VA public domain code is currently miniscule, but the philosophy is
there and the passion and belief in what we are doing is there and for those
for whom that works, we will be here to provide continued support.

--
Nancy Anthracite

[Mike Dupont]

>you couldn't have written it without studying the original, and so it
> was derived from the original.

Alfred is a great guy, and I respect him, but often he goes overboard.

I think that derived works are not defined as such, they are defined
if you contain a copy of the original. A patch does not. Calling a
function is fair use as the name of the function is not protected.
http://en.wikipedia.org/wiki/Derivative_work

You are only distributing a patch.
http://library.findlaw.com/2003/Jun/16/132811.html

The fact that the patch will not work without the source code is not
making it derivate, but some say that it might not.
http://www.linuxjournal.com/article/6366

It all depends on what your patch does and if it could be turned int a
running program. Ideally you would have a standalone modules that
works somehow, or could work in an incubator/test frame. That type of
test frame or api should be available under a permissive license for
people to use. Then you can test your code against it and it stands
alone.

I really still think that copyleft would be doable.

Now to get to this licensing issue again, I dont know the current
situation, but lets assume that you build a product on vista

Currently the http://en.wikipedia.org/wiki/VistA is public domain,
"""The VistA system is public domain software, available through the
Freedom Of Information Act directly from the VA website[15] or through
a growing network of distributors."""
and anyone can create a commercial product from it.
So if a new release is under the gpl and contains the same fileman
interface there should be no problem at all.

I dont see what the big issue here is now at all, based on the public
domain code you can create any number of licenses from that. There
would be no issue of copyleft at all for programs because they could
be plugins for the old vista code. You would only be restricted from
copying code from an incompatible license, but not from using it.

So, I would say it is not a problem to use any license you like, as
long as it would work with the public domain version it could be
combined with any other version without license change. The user can
mix and match licenses all they want, the vendor will need to refrain
from mixing licenses, but the should be able to use them.

Even if the gpled version produced a new interface, someone could
create code that uses that interface as long as they dont distribute
it as a derived work.

mike

[Mike Dupont]

On Wed, May 23, 2012 at 3:55 AM, Nancy Anthracite
<nanth...@earthlink.net> wrote:
> Frankly, I can't see OSEHRA having only a GPL or AGPL license because it would
> be politically untenable. OSEHRA would be tolerated by the legislative bodies
> otherwise.  WorldVistA and some others in the community know from experience
> how powerful the anti-open source lobbyists are on "The Hill".  As I recall,
> it took quite a bit of effort to even bring OSEHRA into existence because the
> words "Open Source" are in the name of it.  It will have to be "business
> friendly" to survive.  However, you could consider having dual licensing on
> the part of OSEHRA.

Those are also good arguments, but the ones being presented before
were ones related to the copyleft/sharealike.
I dont want to go into politics here, but If GPL was not business
friendly why does Redhat make so much money selling the stuff?

mike

[Nancy Anthracite]

Try convincing Microsoft or Epic how business friendly it is. :-)

--
Nancy Anthracite

[Mike Dupont]

On Wed, May 23, 2012 at 1:16 AM, Michael ONeill <mdon...@me.com> wrote:
> So I'm just not seeing the value of the copyleft license for VistA. If what
> we want is a growing community, with more users, more service providers, and
> more developers - and this is definitely what both VA and OSEHRA want - then
> a copyleft license works against us by discouraging participation.

Look, after seeing that existing code is all public domain I would
disagree. PD is the most permissive license you have, you dont even
need to give attribution. If a company has all that code available to
them to get started then I dont see why the new code under the GPL
would harm them.

The arguments that it is too technically difficult to create a
standalone package are just wrong. If the software is so badly
constructed that it is impossible to create a module, then that should
be the thing we are working on, and i might be tempted to do so.

[Mike Dupont]

I dont know who epic is, but I know that microsoft is in the GPL
business as well, selling suse licenses and also collecting patent
royalties from each android phone.

Of course we can find companies that live by selling proprietary
software and who benefit from public domain and weak open source
licenses. But that is not the issue here.
I think if google or microsoft came in to create your vista system,
you would not be using mumps, but python or visual basic. :D

I want to limit the discussion to the technical limitations of using
the gpl/sharealike/copyleft and we can leave the rest out for now.

mike

On Wed, May 23, 2012 at 5:43 AM, Nancy Anthracite

<nanth...@earthlink.net> wrote:
> Try convincing Microsoft or Epic how business friendly it is.  :-)
>
> --
> Nancy Anthracite
>
> On Wednesday, May 23, 2012, Mike Dupont wrote:
>> On Wed, May 23, 2012 at 3:55 AM, Nancy Anthracite
>>
>> <nanth...@earthlink.net> wrote:
>> > Frankly, I can't see OSEHRA having only a GPL or AGPL license because it
>> > would be politically untenable. OSEHRA would be tolerated by the
>> > legislative bodies otherwise.  WorldVistA and some others in the
>> > community know from experience how powerful the anti-open source
>> > lobbyists are on "The Hill".  As I recall, it took quite a bit of effort
>> > to even bring OSEHRA into existence because the words "Open Source" are
>> > in the name of it.  It will have to be "business friendly" to survive.
>> >  However, you could consider having dual licensing on the part of
>> > OSEHRA.
>>
>> Those are also good arguments, but the ones being presented before
>> were ones related to the copyleft/sharealike.
>> I dont want to go into politics here, but If GPL was not business
>> friendly why does Redhat make so much money selling the stuff?
>>
>> mike
>

[Chris]

Where do I begin? The original article authored by Mr. Maduro was really interesting; in contrast to the last WorldVistA meeting in Sacramento it appears DSS has significantly changed their tone regarding what is being coined as “open source.”

The article made an excellent point; highlighting the reality that the VA is undertaking “the largest open source effort by any government agency in the world today.” Amen. We shouldn’t discount the efforts being made with rhetoric about what we think are dumb decisions – heck half the time we don’t have the full picture to truly understand what the canvas is really trying to show. Ie – the Rorschach test. What do you see?

A lot of the comments got me thinking…

I heard the word Apache thrown around a lot… did you know Apache has its root from the public domain project NCSA HTTPd? When Apache was first incubated it didn’t have a license that required enhancements be contributed back.

How was the term open source coined? Look back to the Netscape days colliding with the freedom software movement. Back then free, as is in freedom, software was the thing. Netscape was released as free (as in freedom) software; yes the source code was available and it didn’t require reciprocal contribution. However your common end users who installed the Internet browser viewed free as in cost. Netscape didn’t like the term free software for the exact misconception free – as in cost. Now – for arguments sake - say the bottom line is the business of Netscape! How would you convince a potential buyer or shareholder(s) to purchase your FREE software? You can’t – or at least Netscape didn’t. Coining the word open source and providing their definition was one solution. Numerous months later the now “open source” Netscape would be acquired for, what was valued at that time, $4.2 billion.

The definition of open source is in the midst of evolution – especially now that it has entered the political arena.

Look at what open source means to this author…

I tried Googling for popular AGPL projects… umm… yeah… I’m actually shocked.

Throughout all of this discussion is my bottom line – keep software free as in freedom or free speech; not as in free beer. If you need a copyright to protect that freedom then so be it but don't fear freedom by attempting to control it. I know we’re debating licensing and debate is a healthy component of an engaged community but don’t let it be the resounding big fat elephant in the room. Compromise from all parties would be greatly appreciated.

Today – Rob Tweed presented a great overview of EWD in the OSEHRA AWG meeting. The previous week Medsphere presented. I’d like to see WorldVistA discuss what they represent and how they want to align resources with the new community that is forming.

[Michael ONeill]

Hi Nancy,
OSEHRA's license choice is based on what we think will build the most robust community because that will expand the opportunity for VistA and related software. That's good for health outcomes for Veterans, directly, in that enabling more people - developers, users, and service providers - to participate allows VA to move faster in enhancing VistA in ways that clinicians want. And it's good for Veterans indirectly in that the more we can foster the adoption of open source VistA-based EHRs in the private sector, the more we will see enhancements that will also be available to VA.

Choosing a business-friendly license isn't political. It's 100% aimed at improving our ability to advance open source VistA software.

OSEHRA has chosen the Apache 2.0 license. Of course that doesn't force WorldVistA or anyone else to change philosophy. And because OSEHRA's choice isn't religious or political, it can change if the nature of the community changes. Right now, I don't see that changing, for all of the reasons I've been mentioning in my other posts. If maintaining multiple licenses is good for the community, OSEHRA will do it. Right now it's not much of an issue. As the community grows, maybe that changes.

I'd like to see as much collaboration as possible between all of the people and companies that are currently involved with VistA in any way, and I'd like to see new players get involved. That's what OSEHRA is about. I think it's good to talk about issues like licensing so that they don't become a reason that we prevents the very collaboration we all want to see.

Mike

[Michael ONeill]

Mike,
Here's how GPL harms them:

The codebase starts as public domain. One developer adds to the codebase and puts his contribution under GPL. VistA is not modular in a way that allows that contribution to be isolated - future enhancements to that codebase will need to be under GPL. Too many companies are not interested in participating in GPL software. Users lose out on enhancements those companies could bring to the table.

It's not theoretical. VA uses VistA software developed by DSS. If VistA becomes a GPL codebase and DSS declines to write software for it, VA loses out on the software that DSS brings to market.

Arguments that it shouldn't be so hard to create standalone package are great - I agree 100% and both VA and OSEHRA are working to change this. Please join in this effort!

I do not disagree with any of the technical solutions that have been mentioned here, that allow GPL to mix with other licenses - I am not saying that they can't work, technically. I am saying that they are impractical for the market we want to develop. If we want to make VistA a system that is easy to develop with, easy for users to adopt, easy for service providers to integrate, test, package, sell, maintain, support, and enhance, GPL and the gymnastics it requires is an inhibitor. Every time we draw up an example of how we might use GPL in ways that are inconvenient for developers, users, and service providers we are proving that point.

In the end, we can debate this forever among ourselves. I'm already starting to repeat myself. What matters is the results we get in the community we're trying to build. There is too much feedback on how GPL gets in the way for us to ignore it or for us to counter with answers that are inconvenient but technically correct.

Mike

[Nancy Anthracite]

Microsoft and Epic are important for the politics of it, not the remainder,
but I am happy to limit the discussion. Make no mistake that when it comes to
VistA, politics are important, including for WorldVistA. Legislation around
EHRs and the politics of it dictate a lot of what we do. Meaningful Use is a
relatively benign example. The potential is there for FDA regulation and that
could be far from benign and OSEHRA's continued existence can depend upon
politics. The very existence of VistA is thanks to politics beginning about 30
years ago.

[Nancy Anthracite]

I think WorldVistA already has accepted that OSEHRA will not have a GPL
license, unless perhaps it will dual license, but it is not stopping us from
collaborating or contributing and we intend to continue to do so.

One concern I have is that we are not seeing the participation of the VA
developers and users with OSEHRA and I don't see OSEHRA going very far if that
does not happen. As far as I am concerned, open collaboration between all of
the parties involved is the holy grail. I am thrilled that we are now able to
talk with the developers twice a year at the VistA Community Meetings, but
that hardly reaches the level of collaboration that I envisioned, and I don't
think it reaches what you envision either. I hope we will be hearing about
some progress toward that collaboration becoming a reality at the VistA
Community Meeting.

In addition, open collaboration with the entities that the VA contracts with
and could be in the mix. The Ray Group work on code refactoring seems to be
an effort to put a toe in the water in that direction. The Ray Group will be
presenting at the VistA Community Meeting and I am looking forward to seeing
that collaboration succeed as a model for what there can be in the future.

--
Nancy Anthracite

On Wednesday, May 23, 2012, Michael ONeill wrote:
> Hi Nancy,

[Nancy Anthracite]

If you would like to see a very nice example of how new modules can be added
to VistA, take a look a the work done for the C0C package and VistACom using
EWD, and more will be happening along those lines at the VistA Community
Meeting. Tony Shannon from the UK will be presenting his work first thing at
the conference and then interested community members and Rob Tweed will be
connecting that work up to VistA with EWD during the conference to make it
mobile and web enabled for VistA, hopefully to be seen by all before noon on
Wednesday.

-
Nancy Anthracite

[Nancy Anthracite]

WorldVistA has made very good use of some GPL software called Djigzo. That
code is available under another license as a package that can be included in
proprietary software and cannot be modified for a hefty price. It helps to
support Martijn Brinker's open source work.

Perhaps those who are feeling that they are being denied use of GPL software
can make similar arrangements with the developers of the GPL software.

--
Nancy Anthracite

[Michael ONeill]

Nancy,

Thanks, but as I said, it's not that we can't design a solution for each problem that GPL creates. We probably can. My point is why keep doing this? Why keep developing work-arounds that are awkward and that discourage people from participating? Why not remove the source of the problems so that we can stop focusing on workarounds and focus all of our time and energy on the software and the users? Why not do everything we can to grow the community?

I would much rather have VistA experts working on VistA than on licensing.

I would much rather have new companies join the community without hesitation than have them stay away because their lawyers won't let them touch GPL. 

Mike

[Michael ONeill]

Yes, this is terrific work. It's a great example of how developers can produce meaningful applications without having to get into the core of VistA. As much as many of us like to focus on the work within the VistA core, and as important as that is, so many applications can be written by using an API like MDWS, or the calls that AViVA is developing, or a platform like EWD. The more we can support this activity, the more we are enabling developers and users. 

Will the AGPL license be a problem? Yes, I think it will. I think we will end up having all of the discussions we just went through concerning GPL and VistA, but with AGPL and EWD. Hopefully I am wrong.

Mike

[Mike Dupont]

OK, thank you all for explaining the positions and I think I
understand the issues much better now. I will continue to work on the
gt/m core as I have time, that is the commitment that I can make right
now.

On Wed, May 23, 2012 at 11:17 AM, Michael ONeill <mdon...@me.com> wrote:
> Arguments that it shouldn't be so hard to create standalone package are great - I agree 100% and both VA and OSEHRA are working to change this. Please join in this effort!

[Nancy Anthracite]

If we can see large collaborations being coordinated by OSEHRA with VA and
contract and open source developers and users and other interested parties all
working together on open source Apache licensed software, I can see an
evolution to a community where the open source version from OSEHRA with an
Apache 2 license will be equivalent to having a GPL license because no one
will bother running off and not contributing back. We are not anywhere close
to there yet. We will have to agree to disagree and do the extra work to
continue to have a productive relationship nonetheless.

[Roger A. Maduro]

There are many ways that open source communities protect their code
and their projects. Licensing is just one of them. Others include
trademarks, copyrights, and certification, for example. The Apache
Foundation, for example, is very aggressive at protecting it's
trademark. It's one of the key ways that it has protected the Apache
Web Server (the #1 web server in the world), as well as the 100 plus
other projects that they support. No commercial entity can say Apache
in any of their materials unless the Apache Foundation has given
approval. They have sued companies over this and to my knowledge all
cases were settled before going to court. So if you see any product
out there that carries the Apache label, or the label for any other
project, then that product is consistent with the guidelines and
requirements of the Apache Project. I believe OSEHRA is going to play
that role. VistA is in fact a registered trademark of the VA (and the
VA was ready to sue Microsoft for trademark infringement when the
White House ordered them to back off). The VA/OSEHRA would have the
right to sue anyone that uses the trademark VistA in a way that is not
consistent with it's guidelines. Thus a commercial could take the
VistA code and make it proprietary. But they will never be able to
claim that it was VistA or that it was certified.

Roger

On Wed, May 23, 2012 at 8:37 AM, Nancy Anthracite

> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
Roger A. Maduro
rama...@gmail.com

[Nancy Anthracite]

Fortunately, these are applications that are fairly straight forward for end
users to install and so far, they will probably work on any version of VistA.

--
Nancy Anthracite

[rtweed]

Mike

I'm not wedded particularly to AGPL for EWD - I adopted it as an
appropriate license on advice from people like Bhaskar. If an
alternative license is more acceptable for use by, eg, the VA, I'm
more than happy to discuss, I do not want licensing to be any barrier
to people using EWD. As you, yourself, have noted: I make my revenue
through support, consultancy and training, and EWD is essentially a
means to an end for me to obtain and retain that revenue stream. The
more people who use it, the better :-)

Rob

On May 23, 4:22 pm, Michael ONeill <mdone...@me.com> wrote:
> Yes, this is terrific work. It's a great example of how developers can produce meaningful applications without having to get into the core of VistA. As much as many of us like to focus on the work within the VistA core, and as important as that is, so many applications can be written by using an API like MDWS, or the calls that AViVA is developing, or a platform like EWD. The more we can support this activity, the more we are enabling developers and users.
>
> Will the AGPL license be a problem? Yes, I think it will. I think we will end up having all of the discussions we just went through concerning GPL and VistA, but with AGPL and EWD. Hopefully I am wrong.
>
> Mike
>

> On May 23, 2012, at 08:03 AM, Nancy Anthracite <nanthrac...@earthlink.net> wrote:
>
> If you would like to see a very nice example of how new modules can be added
> to VistA, take a look a the work done for the C0C package and VistACom using
> EWD, and more will be happening along those lines at the VistA Community
> Meeting. Tony Shannon from the UK will be presenting his work first thing at
> the conference and then interested community members and Rob Tweed will be
> connecting that work up to VistA with EWD during the conference to make it
> mobile and web enabled for VistA, hopefully to be seen by all before noon on
> Wednesday.
>
> -
> Nancy Anthracite
>
>
>
>
>
>
>
>
>
> On Wednesday, May 23, 2012, Mike Dupont wrote:

> > On Wed, May 23, 2012 at 1:16 AM, Michael ONeill <mdone...@me.com> wrote:
> > > So I'm just not seeing the value of the copyleft license for VistA. If
> > > what we want is a growing community, with more users, more service
> > > providers, and more developers - and this is definitely what both VA and
> > > OSEHRA want - then a copyleft license works against us by discouraging
> > > participation.
>
> > Look, after seeing that existing code is all public domain I would
> > disagree. PD is the most permissive license you have, you dont even
> > need to give attribution. If a company has all that code available to
> > them to get started then I dont see why the new code under the GPL
> > would harm them.
>
> > The arguments that it is too technically difficult to create a
> > standalone package are just wrong. If the software is so badly
> > constructed that it is impossible to create a module, then that should
> > be the thing we are working on, and i might be tempted to do so.
>
> > mike
>

> --http://groups.google.com/group/Hardhats

[Carol Monahan]

Nancy:

Since hosting the Licensing session at last year's VISTA Expo & Symposium, I have continued researching licenses, and learning more about community stakeholder's reasoning and legal arguments.

Here's my current understanding, and my conclusion:

1) Our commercial stakeholders (i.e. DSS) have had strong legal advice not to sell their proprietary packages into GPL environments. It does not matter if those are "end user" environments, since, for VISTA, any end user can become a development site - open source allows for that and indeed encourages it. Their real problem about the GPL comes down to the interpretation of the two words "Entire Work". The inclusion of those two words in the GPL's "copyleft" terms makes them fear for the integrity of their claim on their proprietary code.

2) Our non-profit and volunteer stakeholders want some recourse if a "Bad Actor" corporation comes along and scoops up their open-source code, locking it up into a closed-source, proprietary product. Having no recourse at all (e.g. Apache licensing) is not acceptable for these authors/developers.

Conclusion: We need a copyleft license with cleaner definitions of what constitutes the "licensed work" and a "derivative work". Such a license won't have lawyers telling proprietary folks that they have to steer clear, and will protect the community from bad actors.

So far, the closest to this "dream license" I've found is Lawrence Rosen's OSL 3.0. It is clean, easy to read, and makes no claims over the "Entire Work". It claims license over the identified work of authorship, and works derived *from that work of authorship*. Using such a license would allow VA's contributions to remain identifiably Public Domain, allow non-profits and volunteers assurance of recourse if someone "steals" their code by incorrectly re-licensing it (there is even a compatible non-profit version of the OSL, giving greater liability disclaimers for non-commercial contributors), and allow proprietary code to be deployed in the environment without falling afoul of an "Entire Work" copyright claim.

I am not a lawyer, but I hope that we can examine the terms of the OSL (or any other non-GPL license that affords open-source carryon licensing), to see if we can accommodate both non-profits and commercial interests. 

I also have hopes that we can leverage an improved VISTA name- and number-spacing system to assist in identifying authorship history and licensing by module/package. 

-Carol Monahan

Director of Strategy

VISTA Expertise Network

[rga...@tampabay.rr.com]

MDWS is still in its infancy though, once we able able to do more writes to the VistA back-end it will be a more mature product.

EWD is a godsend and I sure hope VA adopts its use for rapid development.

> --

[Michael ONeill]

Hi Nancy,

Thank you - the productive relationship part is all-important. 

I'm hopeful that we will quickly get to the kind of community that you describe - where many people and companies participate and no one runs off without contributing back. There is definitely work to do - let's see how fast we all can get there.

Mike

PS - I'm grateful to the list participants for not kicking me off for propagating a non-technical discussion.

[Bhaskar, K.S]

Since EWD is cleanly separable from VistA - it's a separate layer with 100% separable routines and globals* - I don't quite see how the EWD license interacts with a VistA license, any more than the EWD license interacts with the licenses for other infrastructure, such as Linux, GT.M, Apache, sendmail, etc. etc. etc.  The only "benefit" to a non-FOSS license for EWD would be enable proprietary (non-FOSS) derivative works.

Regards
-- Bhaskar

* Last year, I released a virtual machine showing EWD and VistA cleanly separated.  You can run VistA with EWD and you can run exactly the same VistA without EWD.

-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Michael ONeill]

Not so separable. AGPL requires that source code be provided for applications connect to AGPL code over the network. It makes it harder, not easier, to develop cleanly separated applications.

Mike

--

[Bhaskar, K.S]

Mike --

If EWD is licensed under AGPL, that only refers to EWD source code, and making that available is not a concern of Rob's.  Since using EWD with VistA does not create a derivative work, the VistA code is cleanly separated from EWD code.

Let's set aside interaction with VIstA.  If running EWD with a FOSS license interacted with the license of other software it runs with, then we would have problems running a FOSS EWD with a proprietary M implementation on a proprietary OS.  A logical extension of the point of view you suggest would make it illegal to run proprietary software such as SAP or Oracle on a FOSS OS like Linux, or a FOSS application like emacs on a proprietary OS like Windows.  In other words, the world of IT would grind to a halt.  So, in this particular case, I must respectfully disagree with your opinion.

Regards
-- Bhaskar

[Michael ONeill]

Thanks, Bhaskar, I quickly got some feedback that I am guilty of propagating a misconception about AGPL. 

As you correctly pointed out, requiring any software that interacts with AGPL code to be under AGPL as well would just not work. 

The case that AGPL was designed to correct (vs. GPL) is the case of a GPL server application, where one might modify the code but not make those modifications available, making the service available over the network instead. AGPL says that you must make those modifications available as source code (so clients can see the modifications, for example) - essentially saying that providing the service is equivalent to distributing the derivative work. 

Mike

[Bhaskar, K.S]

On 05/22/2012 06:36 PM, Michael ONeill wrote:

Bhaskar,

Thanks for laying out your thoughts in such a structured way! 

Would we not be making life unnecessarily difficult for developers and for users if we forced them to follow some of the guidelines you laid out, though?

[KSB] Actually, no.  While this may have required effort twenty years ago, what I laid out is pretty trivial today.  Distributed version control systems do far,far more complicated magic than this.  So if entity P releases package XYZ under a FOSS license, and entity Q wishes to distribute an enhanced version of that package under a proprietary license, they would just maintain two different trees.  If entity Q wishes to release their enhanced version to their customer K, they would just provide that customer with the tree for the FOSS XYZ and the tree for their proprietary enhancements and a script for K to create the proprietary software.

Although the details would be different, the technical complexity would be no more than that of creating and applying KIDS packages.

Even for any FOSS code provided by Q to K, the only entity entitled to ask Q for the code is K.  FOSS licenses provide rights to the recipients of the FOSS code, and not to third parties.

If a requirement to provide code via base modules and separate deltas isn't problem enough, what happens when the application demands common data, and it isn't desirable or possible to use separate globals and separate files?

[KSB] As discussed the area where I see an interaction is in the data dictionary, and I would suggest that data dictionaries are like APIs (and yes, Google and Oracle are arguing in court about APIs).

But again, it's trivial for Q to adopt a distribution process / model that allows it keep its version of XYZ proprietary.

While we may be able to construct technical ways to handle each situation, to the extent that our solutions are difficult for users and developers, they dampen participation. That's contrary to building a bigger, more inclusive community.

[KSB] I'll stick with my KIDS analogy.  Anyone who can handle patching VistA, and patching an OS, can handle the technology.  Technology has gone far past these issues.

Regards
-- Bhaskar

Thanks,

Mike

On May 22, 2012, at 05:26 PM, "K.S. Bhaskar" <ksbh...@gmail.com> wrote:

(The following is just my own personal view and does not necessarily represent that of anyone else.)

The nature of M applications is that they are not really as tightly coupled as one might think.  At least on GT.M, every process is dynamically linked.  The first time a process does a DO ABC^DEF or $$ABC^DEF(), a GT.M process dynamically links module DEF.  So, let me work with the view that dynamic linking suffices to separate code with incompatible licenses.*  Then module DEF and module XYZ can have completely different licenses, and still be part of the same VistA process.  If entity P provides module DEF under a FOSS license, regardless of how permissive it is, and entity Q provides module XYZ under a proprietary license, dynamic linking at the process level in effect firewalls the licenses of DEF and XYZ.

Now, if entity P provides module DEF under a FOSS license, and entity Q wishes to modify the code of DEF with its proprietary enhancements, then license interaction needs to be considered, but not if they provide their code as separate modules.  In this case, entity Q could provide their changes as deltas to the code provided by entity P.  I acknowledge that is is one of those gray areas in license interaction that has not been fully decided with legal precedent.

Data interaction is similar to code interaction with one wrinkle.  If entity Q wishes to provide their proprietary data and loads it in a separate global variable, that global variable can reside in a completely different database file which firewalls the licenses.  If entity Q wishes to provide its data in a global variable that also contains data from entity P, it can provide its data as an overlay of deltas, just as with source code.  The wrinkle is that Q may want to change the data dictionary to map its changes and there is only one data dictionary.

VistA's history with distributed development and the use of namespaces actually makes it more likely that entity Q and entity P will create separate modules DEF and XYZ.  So my personal view remains that VistA licensing is obscured by smoke that blocks light.

Regards

-- Bhaskar

* While I am not a lawyer (and everyone thanks God for that, including me), my personal view is that dynamic linking firewalls licenses, at least in the United States.  While I am not aware of legal precedents, if it get to court, I strongly feel that this view will prevail.  But it suits people all round to treat it as a gray area.

On Tuesday, May 22, 2012 4:01:12 PM UTC-4, Mike ONeill wrote:

Mike,

Thanks for breaking this down. If it were possible to run everything according to a model where VistA is an operating system with applications running on top of it, in the same way that applications run on top of Linux, then the Linux licensing analogy would apply: the license of the operating system and of the applications are unrelated. 

But this is not the case for many VistA applications. They are implemented such that they are more tightly coupled with the VistA core; coupled in a way that would require the whole to be placed under the GPL if the core were under GPL. 

A GPL core would prevent non-GPL participation in applications that require close integration. That would remove from consideration too many valuable contributions to VistA.

This is the main reason why OSEHRA chose the Apache 2.0 license. 

Mike O'Neill

VA Innovation Initiative (VAi2)

OSEHRA

On May 22, 2012, at 12:40 PM, Mike Dupont <jamesmi...@googlemail.com> wrote:

ok, I have not looked at vista at all, I have only looked at gt/m.

On Tue, May 22, 2012 at 4:20 PM, David Whitten <whi...@worldvista.org> wrote:
> I don't think anyone has made an argument that GT.M's license has anything
> to do with the license of code written in MUMPS to be used on a GT.M
> implementation.
>
> Mentioning GT.M below is broadening this discussion unilaterally. I don't
> think you want to dilute the discussion about VistA code to bring up GT.M
> code issues.
>
> VistA Kernel is a virtual operating system kernel written in MUMPS.
> Each package of VistA Kernel can be clearly mapped into a subsystem in any
> other operating system. For example, the OS file-system maps into FileMan,
> the process scheduler maps into TaskMan, the OS-shell maps into MenuMan, the
> termcap file maps into the Terminal Type File, etc.
>
> I don't think VistA Kernel's license has anything to do with the license of
> any application which runs on VistA Kernel. The application will consist of
> the code written in MUMPS or defined in VistA data-structures to be used on
> the VistA Kernel implementation, and should be considered as an independent
> entity with its own license.

ok great, so my arguments still hold to modules that you write that
are used in an os kernel. You would be able to sell and license source
code that goes into a kernel as well.

i need to reread this thread to see the question, but I still dont see
why the license of a kernel would affect how an independant part of
that system is licensed.
>
>
> On Tue, May 22, 2012 at 10:45 AM, Mike Dupont
> <jamesmi...@googlemail.com> wrote:
>>
>> On Tue, May 22, 2012 at 5:37 PM, Ralph Johnson <joh...@cs.uiuc.edu>
>> wrote:
>> > On Tue, May 22, 2012 at 10:27 AM, Mike  Dupont
>> > <jamesmi...@googlemail.com> wrote:
>> >
>> >> lets not get emotional about this at all please, copyright is not
>> >> about emotion but about copying.
>> >
>> > But this IS about emotion.  Copyright doesn't make me emotional, but
>> > it does that to many people.  Technical decisions can have emotional
>> > impact.  It is important to consider their impact when making the
>> > decisions.
>>
>> I have heard a bunch of emotional arguments here that dont have
>> anything to do with how the gpl or any copyleft license work.
>> Let address the question of law here first and then you can continue
>> with emotional debate where I dont want to be involved in.
>>
>> The question here for me is, in terms of copyright, does the license
>> of a kernel or server program affect applications that run on it,
>> and it does not. As long as the application does not copy files from
>> the server it is fine. Your creative works will never be infected with
>> "gpl viruses' if you dont copy any into your code.
>>
>> lets take an example, you worked for 10 years on creating some program
>> and you sell it. you want to port it to a gpled gt/m. maybe they have
>> to change some lines of code, but as long as they dont copy lines of
>> code from gt/m it is still the same program.  You dont give up any
>> rights just by running a program.  The gpl specifies that you are free
>> to use it for any purpose, that means running your own program.
>>
>> there are many examples of plugins and addons that have different
>> licenses.
>>
>> as I said, you only need to worry about changes to the gt/m itself but
>> not how the programs interact in memory. copyright is only really
>> invoked when you distribute the product and you are free to distribute
>> gt/m yourself and then free to sell your product that runs on it
>> separately.
>>
>> this is the same issue with for example selling a linux server and
>> then installing your custom software on it.
>>
>> mike

>>
>> --
>> James Michael DuPont
>> Member of Free Libre Open Source Software Kosova http://flossk.org
>> Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
>> Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
>>

>> --
>> http://groups.google.com/group/Hardhats
>> To unsubscribe, send email to Hardhats+u...@googlegroups.com
>
>
> --
> http://groups.google.com/group/Hardhats
> To unsubscribe, send email to Hardhats+u...@googlegroups.com



--

James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

[Luis Ibanez]

First of all,

I want to congratulate and thank all the contributors to this
interesting conversation. This is one of the most civilized
software licensing discussions that I have ever witnessed.   :-)


I want to pick from Carol's nice mention of the Licensing
session last year at VISTA Expo, since I think that this was
a "Moment of Zen" on what a Software License really means
to any Community.


The core of the matter is:

  "A prosperous Community needs to define a set of rules
   and guidelines that define what are acceptable and what
   are unacceptable behaviors for Community members."


These rules and guidelines constitute the:

                          "Culture of the Community"

This Culture is the real force behind the identity and power
of the Community. It is what makes us feel part of a group
of people with whom we share ideals, and a group to which
we belong. That sense of belonging is the real power of the
Community.


A prosperous, and innovative community is the Goal.

If we build a healthy Community, software will just follow.


In the case of an Open Source Community,
the expected behaviors must lead to:

      * Willful and generous Cooperation
      * Desire for improving our common resources
      * Spontaneous innovation and
      * Low barriers of entry for participation


How such behavioral rules are promoted and enforced
is a related but rather secondary matter.


Licensing, is one of such potential mechanisms for
enforcing compliance with expected behaviors and
for punishing deviations from them, but this is not all
what licensing does.


Licensing fulfills two main goals:

A)  Clarifies the permissions that recipients of the
      software have to exercise the exclusive rights
      of copyright, patents and trademarks that are
      held by other parties.

B)  State the conditions under which such permissions
      in (A) are granted to the recipients of the software.


A generous, permissive licensing makes (A) as wide and
complete as possible, and keeps (B) and small and light
as possible.

The permissions in (A) are the "invitation" to others to join
and participate in the Community without fear or concern
of infringing existing copyright, patent and trademark laws.

The terms in (B) are the dangerous zone where Licenses
may undo the kindness of the invitation that (A) makes to
become a community member, and instead become a
system of authoritarian Government that discourages
participation. Part (B) tends to start evolving as a collection
of "Thou Shall Not..." rules.

It is an curious aspect of human nature that when we get the
opportunity to write rules for others to live by, we become very
creative, very quickly, and we err on the side of overreaching
and start dictating in fine detail how others must live and act.

All the concern with over-legislating other's behaviors via
Licensing is a bit misplaced. This is because  the apparent
strength of part (B) of Licenses can rapidly be dispelled when
one realizes that this is only useful if we are actually willing to
go around suing the rule-breakers and bringing them to court.


Here is where we have to ask the honest question:

    Are we here to work together building an EHR that
    saves lives, improves outcomes and reduces costs
    for people all over the world ?

    Or do we want to spend our limited time and meager
    resources in legal fees prosecuting rule-breakers ?


This point has been made to me by highly estimated licensing
experts such as Richard Fontana, (Open Source Licensing
Counsel at Red Hat), and Alan Ruttemberg (formerly with the
Creative Commons).


Their enlightening point has been:

                  "Community Culture is much more
                     effective than a Legal System"


In fact,
a Community Culture is akin to a system of Common Law.

At some point, any legal system, has to rely on actual
voluntary compliance by the community members, and
that compliance is easily regulated by the peer-pressure
of all the surrounding community members, and by self
conviction of every member.

It will always be the case that a few members will not abide
by the Community rules, and therefore what we have to do
is to create a system that simply make them irrelevant.

The good news is that such system already exists, it has
always been there, and it is dictated by the fundamental
Economics and the natural complexity of software
development.


Under this light,
let's come back to the central point of this thread:

      "The Reciprocity Condition of the GPL License"

and the fact that such Reciprocity condition does not exist
in the Apache 2.0 License that OSEHRA has adopted.


The Reciprocity condition is part of that section (B) of
what a license does, where rules are added to dictate
the expected behaviors that community members must
abide to, in order to be allowed to enjoy the permissions
given by part (A).


In plain English the Reciprocity rule says:

             "You should give back to the Commons"


We can split hairs on whether it refers only to "derivative
works", "static vs dynamic" linking, and whether it applies
to the "entire work" and so on... but the core of the matter
is that this is about enforcing that: 


        "As well-behaved members of the Community
         we must give back our improvements to the
         Common pool or resources for the benefit of all"


Several undesirable situations arise when Community
members break this rule, and they appropriate, or are
perceived to appropriate, pieces of our Common pool
of resources. For example, they make improvements
and keep them to themselves, or they take improvements
made by others and profit form them without sharing the
resulting wealth back with the community.

Community members who generously contributed to the
Common Pool of Resources, feel treated like "suckers"
(yes that's an Economics term) when they perceived that
they have been taken advantage of.

and, in the words of Elinor Ostrom
(Nobel Laureate in Economics 2009):

                   "Nobody wants to be a Sucker"


It has been rightfully pointed out in this conversation that
we shouldn't become too emotional when talking about
Licensing, but it is also true that at the bottom, the reasons
why we participate in a Community are both Rational and
Emotional. It is our human nature that we are first motivated
by emotion, and then we are steered by reason.

So, here is the answer to the conundrum:

     "The idea that anyone can possibly appropriate
       software that is maintained by a vibrant Community,
       is a temporary illusion."


and therefore, when we perceive that a person or an
organization is trying to "appropriate" of a piece of
software that is currently maintained by an active
Community,  instead of anger, and instead of feeling
treated like suckers, we should feel sympathy and
compassion for them, and smile kindly to their
naiveness.

They are "One guy trying to steal an Aircraft-Carrier".
One can only smile at such attempt...


As it has been pointed out many time in the VistA
community, software is never a finished product,
but a Living Complex Organism.

VistA, (and any EHR) is a Very Large and complex
organism. Taking care of such organism requires
a lot of work, a lot of knowledge, a lot of expertise,
a lot of experimentation, that has to be done on a
continuous daily basis by a lot of people working
together.


The fundamental Economics of software development
are such that in order to properly maintain a project
we need one developer for every 1,000 lines of code.

And as Rob Tweed presented at the VEN meeting, once
the first version of code is written in one year, it still takes
13 years of subsequent use and maintenance to get all
the bugs out of it.

Most efforts of software development are actually
underpowered beyond proportion, and that's one of
the main reason that leads to about 70% of software
projects never reaching deployment.

To properly take care of VistA, we need an vibrant
Community of 5,000 to 6,000 active developers, and
they must be surrounded by about twice that number
of active clinical collaborators, for a total of a 20,000
members community. Of course not all of them work
full time on it. Some of them will be very active, while
others will do one thing, and only once. It follows a
power-log distribution of effort.

Any actor that comes along with less than 20,000
strong community, with the Evil plan of appropriating
the software...well... has a harmless and actually
laughable Evil plan.

Granted, some of the contributions that we are
discussing here are of smaller size, maybe a
couple hundred thousand lines of code, and yet
in that case, it applies the rule, that the appropriator
will have to come with a couple hundred developers
who have expertise in the system, to properly
maintain it after they take over it. In general, such
take over it is just a poor business decision.



Why at OSEHRA we consider that we do not need
a Reciprocity clause in the License ?

   Because anyone who develops improvements
   to the software and do not put them back in the
   Common Pool of resources to be shared with
   the Community, is not simply "appropriating"
   that small piece of code improvement....

   It is also taking on his shoulders the *Loan*
   payments that comes with the future maintenance
   of that piece of code, that now nobody is going to
   help them maintain, and it is also taking on the
   heavy economic burden to have to merge its
   changes with the hundreds of changes that are
   being generated on a daily basis by the active
   Community.
      
   Basic Economics take care of those who
   defect from the rules of Collaboration in
   Open Source communities. It takes just a
   couple of years, and a couple of releases
   of the main active project, for these defectors
   to realize that maintaining software is A LOT
   more expensive than writing software, and
   that what they now hold is a very expensive
   mortgage for which they have to keep making
   regular payments.

   There is no need to take defectors to court.
   You just wait and see them falling into their
   dead-end roads where they gave up the
   help provided by the labor of thousands of
   contributors.



The key to the Economic model of Open Source
is to understand that the daily contributions of
thousands of developers do have a large monetary
value, and that this value is only realized as long as
you maintain the software in the Common pool of
resources. If you withdraw, you lose. If you fork
the value stops flowing to you.

Every time that one takes a piece from the Common
pool of resources, and attempts to appropriate it, one
is also giving up on the help from thousands of players
who were helping take care of it, and among whom we
were distributing the cost of maintaining the code.


At this point, it is not even about being Nice...

Any smart, rational, self-interested actor with find
that it is in its best interest to continue playing in the
Common Pool of resources, because what is being
shared is not really the software, but the labor, and
expertise that is required to keep the software alive
and functional on a daily basis.

Nearsighted Self-Interest, leads to Appropriation.
Enlightened Self-Interest, leads to Collaboration.


What we need as a Community is not a License that
use Reciprocal terms in their (B) part. What we need
is a MASSIVE amount of collaboration from a diverse
group of people combining clinical expertise, with
engineering expertise. What we need is an active
Community that safely and frequently introduces
innovation in the software held in the Common Pool
of Resources.  The License we need is the one with
the largest (A) part, and the smallest (B) part. One
License that invites all to play along, without bringing
any extra rules that cause discussions among the
Community members, whether they are nurses,
doctors, pharmacists, students, engineers,
corporations, government agencies or universities.



In the early days of the Linux Kernel
they were making daily releases.

Today they do:

"Regular 2-3 month releases deliver stable updates
 to Linux users, each with significant new features,
 added device support, and improved performance.
 The rate of change in the kernel is high and increasing,
 with over 10,000 patches going into each recent kernel
 release. These releases each contain the work of over
 1000 developers representing around 200 corporations."

http://www.linuxfoundation.org/publications/whowriteslinux.pdf


At that massive level of participation,
at that rapid pace of innovation,
it is just bad business not to Collaborate.


That is where we have to get.

We must grow the size of the VistA Community to 20,000
active members combining clinical and engineering members,
thousands of young students, mentored by hundreds of hardhats
and VA developers. Combine academic institutions with for-profit
corporations aligned with the goal of making a high quality, low
cost EHR available for all to use.

How will the for-profits will generate revenue ?
from providing support, maintenance services, training,
extensions, customizations, and adaptations of the software
to the ever-changing landscape of healthcare.

How is this all going to be paid if the software is going to be
distributed for free ?   It will be paid from the savings that a
high quality, low cost EHR will produce on the 16% of GDP
that the country spends today in healthcare, particularly from
the costs savings of hospitals and insurers.


At this point, the key to success is to bring on board thousands
of twenty-something developers to learn M, and learn VistA
under the mentorship of the hardhats and VA developers, and
then unleash their creativity to bring rapid innovation into the
system.


As we bring these thousands of new members on board,
we must ensure that we educate them on this basic
Culture of the Community:


             "You should give back to the Commons"


not because we are going to sue you if you don't...

but because, that is what we do, that is who we are,
it is good software engineering, it is a good clinical
practice, and that is how the power of Open Source
is realized and how we can actually deliver on building
and maintaining a high quality, low cost EHR for all.



      Luis



-------------------------------------------------------------------------

[Chris]

1. Ever thought about writing a book about building open source communities? (I'd buy it.)
   
2. Have any recommended readings?

[JohnLeo Zimmer]

superb summary, I think.

jl.z 

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

--
Not sent from anyone's Ipad

[Mike Dupont]

I agree, very impressive! I like the loan idea!
thanks,
mike

[Nancy Anthracite]

I won't deny you your vision, Luis, or say that it is not a good one, but
OSEHRA is very far from that point now. There are tremendous risks for
OSEHRA that may well prevent it from getting there. There is no guarantee
that OSEHRA will persist beyond November, there is close to no user or
developer participation from the largest community of VistA experts, and there
is a very large threat that a whole lot of closed source software will be
imposed on the project by the iEHR which is clearly not singing the open
source tune from almost everything I have seen.

That does not mean that I, personally, will not continue to help out in
getting OSEHRA to where you envision it should be where there are common
goals with mine, but should OSEHRA fall by the wayside or head in a direction
where I can't agree to travel, I will continue to pursue what I think is
right.

--
Nancy Anthracite

> *"Regular 2-3 month releases deliver stable updates

> to Linux users, each with significant new features,
> added device support, and improved performance.
> The rate of change in the kernel is high and increasing,
> with over 10,000 patches going into each recent kernel
> release. These releases each contain the work of over
> 1000 developers representing around 200 corporations."

> *
> http://www.*linux*foundation.org/publications/*whowriteslinux*.pdf<http://w
> ww.linuxfoundation.org/publications/whowriteslinux.pdf>

[C. Monahan]

I would add that, although "taking" VISTA would be like one guy stealing an aircraft carrier, and "good actors" would not attempt it, there's money to be made, making it entirely likely that someone will try it. And though we know they're likely to "fail", they can externalize their costs, so where is the risk for them? It won't be the company that "takes" VISTA that suffers, it will be hospitals and clinics who buy their product. When there are benefits, and someone else will bear the costs, there is a real motivation for "bad actors".

Right now, government incentives make it critical that hospitals large and small, rich and poor, adopt a full EHR. Unfortunately, the vast majority have only seen advertisements from the big companies telling them that open-source is risky, and created/maintained by people in basements. They think they have to buy something proprietary.

Add to this the ready availability of code for a vast EHR which can reach meaningful use certification with a measurable amount of labor. 

Thought experiment: a company comes along, uses the public domain code, and then just uses all the Apache-licensed non-VA open-source code we're talking about putting out there in order to get to a certified status. They call their closed source product "ReadyEHR". It's proprietary, and they sell it to hospitals for tens of millions a pop (the going rate). No, they won't be contributing back to the community, but since they anticipate being able to continue getting public-domain/permissive-license updates from VA/OSEHRA, they won't care. They figure they can keep the thing spinning along - at least long enough to sell it to more hospitals. Then, perhaps, they decide that maintenance is indeed too onerous, so they go out of business, taking their profits with them. Who gets left holding the bag? The hospitals.

Really, the first and foremost concern shouldn't be that software developers see their babies getting sold, it's that their babies will get sold as part of a bill of goods that will ultimately cost hospitals, and by extension patients, and by further extension taxpayers, a whole lot of money. . . when a reciprocal license would at least make our potential "ReadyEHR" guys liable for damages (and therefore less likely to do it in the first place), and even allow hospitals who get snookered by a scam like that the opportunity to get back on track without having to start all over with a fresh EHR (since they could demonstrate that what they were sold is actually open-source, allowing them to rejoin). 

There is so much money floating around in the commercial EHR field, and so many increasingly panicked potential customers - I don't think it's unreasonable to take modest precautions.

-Carol

[Mike Dupont]

Excellent point.

On Fri, May 25, 2012 at 5:09 PM, C. Monahan <vista...@gmail.com> wrote:
> Really, the first and foremost concern shouldn't be that software developers
> see their babies getting sold, it's that their babies will get sold as part
> of a bill of goods that will ultimately cost hospitals, and by extension
> patients, and by further extension taxpayers, a whole lot of money. . . when
> a reciprocal license would at least make our potential "ReadyEHR" guys
> liable for damages (and therefore less likely to do it in the first place),
> and even allow hospitals who get snookered by a scam like that the
> opportunity to get back on track without having to start all over with a
> fresh EHR (since they could demonstrate that what they were sold is actually
> open-source, allowing them to rejoin).

[Luis Ibanez]

On Thu, May 24, 2012 at 8:58 PM, Chris <chris....@gmail.com> wrote:

1. Ever thought about writing a book about building open source communities? (I'd buy it.)
   
2. Have any recommended readings?

---------------------------------------------------------

I can wholeheartedly recommend:

On the topic of Building Communities:

     Peter Block

     "Community: The Structure of Belonging"

    Berrett-Koehler Publishers, 2008

http://books.google.com/books/about/Community.html?id=3sEukiSw0fwC

http://www.peterblock.com/ 

http://www.youtube.com/watch?v=jZxbx7ke7wg

 

Peter Block delivers plenty of counter-intuitive wisdom on

how to build powerful communities. His insights come from

urban communities and apply word-by-word to Open Source

communities. At its core, it is about focusing on our gifts

instead of our deficiencies, focusing on our possibilities,

and letting go of our preoccupation with problem-solving.

----

On the front of Economics of Commons and how communities

have developed for hundreds of years self-governance that 

are more effective than property systems and central 

government intervention:

Elinor Ostrom

(Nobel Laureate in Economics 2009)

"Governing the Commons:

The evolution of Institutions for Collective Action"

Cambridge University Press

http://books.google.com/books/about/Governing_the_Commons.html?id=4xg6oUobMz4C

On the Economics analysis of why and how 

Collaborative Communities trump Hierarchical 

institutional management:

Yochai Benkler

"The Penguin and the Leviatan:

How Cooperation Triumphs over Self-Interest"

Crown Business, 2011

http://books.google.com/books/about/The_Penguin_and_the_Leviathan.html?id=IHHd-XU8JDgC

On the Socio-Economics of where the resources

are coming from, and why volunteers will dedicate

time and efforts to a collaborative endeavor:

Clay Shirky

"Cognitive Surplus: 

Creativity and Generosity in a Connected Age"

Penguin Press, 2010

http://books.google.com/books/about/Cognitive_Surplus.html?id=PjeTO822t_4C

On the mathematical modeling of how collaboration

emerges and can be sustained in the presence of

self-interest, and how a small group of cooperating

actors can take-over a world of defectors:

Alex Axelrod

"The Evolution of Cooperation"

Basic Books, Revised edition 2006

http://books.google.com/books/about/The_Evolution_of_Cooperation.html?id=KFf2HXzVO58C

On the more specific front of Community building

for Open Source projects, with some more emphasis

on tools and practices:

Jono Bacon

"The Art of Community:

Building the New Age of Participation"

O'Reilly, 2009

http://books.google.com/books/about/The_Art_of_Community.html?id=DtZmvezJTIgC

---

Peter Block's book is a fascinating place to start, 

it is a very eye-opening perspective on how and 

why we work together to build powerful possibilities.

    Luis

[Joseph Dal Molin]

"Robert" Axelrod
"The Evolution of Cooperation"

Robert's book, Harnessing Complexity which followed "Evolution" uses the
Linux community as a case study. Axelrod goes beyond mathematical
modeling and simulation of collaboration. He examines a range of
examples of collaboration and identifies several simple, practical
guiding principles for building collaborative ecosystems. I have been
recommending this book for ten years and still think Axelrod's work
provides one of the best blueprints for establishing open source
communities.

Joseph Dal Molin
President, E-cology Corp.
Tel: +1.416.232.1206
Skype: dalmolin

On 12-05-26 10:26 PM, Luis Ibanez wrote:
> On Thu, May 24, 2012 at 8:58 PM, Chris <chris....@gmail.com

> <mailto:chris....@gmail.com>> wrote:
>
> 1. Ever thought about writing a book about building open source

> communities? (I'd buy it.)

> 2. Have any recommended readings?

> <http://books.google.com/books/about/The_Penguin_and_the_Leviathan.html?id=IHHd-XU8JDgC>m/books/about/The_Penguin_and_the_Leviathan.html?id=IHHd-XU8JDgC

[Clyde Smith]

Usually there's only one listener on a VA system, helps to manage licensing slots.  It does help though in HL7 v1.6 to have a separate listener for maybe each application (lab, pharmacy, etc.) as there's no way to temporarily suspend HL7 activity without bringing down the listener.

You mention that your reference lab interface is working flawlessly.  Would you care to share some of trials and tribulations in getting this to function?

________________________________

[Wolfgang Giere]

Am 25.05.2012 17:09, schrieb C. Monahan:
> Right now, government incentives make it critical that hospitals large
> and small, rich and poor, adopt a full EHR. Unfortunately, the vast
> majority have only seen advertisements from the big companies telling
> them that open-source is risky, and created/maintained by people in
> basements. They think they have to buy something proprietary.

I am confused. On the one hand I studied the "Report to Congressional
Defense Comittee on DoD Enterprise Architecture to Guide the Transition
... " and found almost no intention to promote Opem Source. VA seems to
have lost control. The paper reminds me of the former triumph of "the
COBOL Mafia", the centralists with emphasis on requirement formulation.
On the other hand I read the enthousiastic reports about the Open
Source conference and the planned investments of VA and OSEHRA,
including "agile development", rapid prototyping. Apparently Baker
supports Foia VistA. What is the reality? What is WorldVistA expecting?

Wolfgang Giere

[Thurber, Joe]

Reference lab setup went pretty much by the LEDI manual. LabCorp is an excellent partner and was very responsive and helpful. We did run into a few snags, but nothing serious.

A good bit of our troubles related to users, lab, and locations being mixed up in a variety of VistA domains and institutions. Our one lab is serving multiple divisions in VistA. Users must be in the same domain and institution as the lab. The user's default division should be a part of the same institution as the lab. Each person that accessions must be in a Division (the default for that user) that is part of the system default institution which in turn is in the default domain. Also I had to modify the lab files to put the lab site in the correct institution.

Have you started your implementation of LEDI yet?

One other note, it seems that the National VA LAB CODE had to be on each test that is to be shipped. After adding this, the samples were added to the shipping manifest...

--
http://groups.google.com/group/Hardhats
To unsubscribe, send email to Hardhats+u...@googlegroups.com

________________________________

Email correspondence to and from this address is subject to the North Carolina Public Records Law and may be disclosed to third parties by an authorized State official. Unauthorized disclosure of juvenile, health, legally privileged, or otherwise confidential information, including confidential information relating to an ongoing State procurement effort, is prohibited by law. If you have received this e-mail in error, please notify the sender immediately and delete all records of this e-mail.