OSS Waiver for Navy's DADMS
Kedzierski, Artur CIV NSWC Corona, PA13
on my second one. I mentioned the waiver back in December. However, the
particular waiver that I was working on was finished, I went on two week
vacation, and after that I forgot about it.
Anyway, I was trying to get associated to OSS software in DADMS (JacORB to be specific). There
was already an entry for it that stated:
USN Guidance: ** OPEN SOURCE ** 4/15/09 - CIOs must ensure that adequate and funded in-house support or third-party vendor support is in place for continued use of this freeware product.
I was going to list email-list / issue tracker as support with the commercial third party support
as a backup (budget available if we have to use it). However, that wasn't the support that they were
looking for.
"when you buy COTS you're not only buying the actual software but the support that goes with it. When you download open source it comes with no agreement for support. If a vulnerability for Office 2007 is identified we know they'll provide a patch; if there's a problem with JacORB we can probably assume someone will address the issue but that's not the same as having someone on the hook to provide support."
It sounds like when you want to use OSS, you have to purchase support from somewhere.
Now, I could just purchase $10,000/per seat support and not do the waiver. However,
what happens when I cannot purchase support for some OSS product. Let's say I want
to use Firefox on Windows (Red Hat license would cover Linux side). Firefox's website
doesn't even show commercial support (unless I missed it). I don't have anybody "on hook"
to provide the patches so the software is unsupported and I cannot use the software.
Is there any DoD memo/document that describes the definition of "support"? I would think
that "support" means somebody (e.g. Mozilla or Apache foundation) actively maintaining
the software and communicating with its users (e.g. taking bug reports, etc).
Any thoughts?
--
Artur Kedzierski
Miles Fidelman
> Has anybody done an OSS waiver for Navy's DADMS (FAM list)? I am working
> on my second one. I mentioned the waiver back in December. However, the
> particular waiver that I was working on was finished, I went on two week
> vacation, and after that I forgot about it.
>
> Anyway, I was trying to get associated to OSS software in DADMS (JacORB to be specific). There
> was already an entry for it that stated:
> USN Guidance: ** OPEN SOURCE ** 4/15/09 - CIOs must ensure that adequate and funded in-house support or third-party vendor support is in place for continued use of this freeware product.
>
> Is there any DoD memo/document that describes the definition of "support"? I would think
> that "support" means somebody (e.g. Mozilla or Apache foundation) actively maintaining
> the software and communicating with its users (e.g. taking bug reports, etc).
>
>
Well... the overall DoD policy for Open Source says:
".....must ensure that the plan for software support (e.g., commercial
or Government program office support) is adequate for mission need."
Seems like there are two different issues to address:
1. That patches and updates are being provided at a level comparable to
that provided for purchased commercial products (e.g., periodic new
releases, high-priority security patches). It certainly seems plausible
to argue that the Mozilla foundation "supports" Firefox at a level
comparable to Microsoft's support of MSIE. It might be a little harder
to argue that community support of Debian is equivalent to redhat's
support of enterprise linux. A somewhat broader argument is that the
basic level of support that comes with a commercial (or FOSS) product
does not include on-demand response equivalent to what you might get
from having an integrator under contract.
2. That there is someone who is actually monitoring new releases and
patches, and actually deploying them into the operational environment.
Of course this applies to both open source AND commercial software. You
might be able to argue that a funded sys admin (in house or contractor),
plus an active community, provides the equivalent of what you get with a
commercial product.
Just some random thoughts here.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
JCusick
We use a lot of OSS software where I'm located. Generally, we do it at
a OS distribution level.
> It sounds like when you want to use OSS, you have to purchase support from somewhere.
> Now, I could just purchase $10,000/per seat support and not do the waiver. However,
> what happens when I cannot purchase support for some OSS product. Let's say I want
> to use Firefox on Windows (Red Hat license would cover Linux side). Firefox's website
> doesn't even show commercial support (unless I missed it). I don't have anybody "on hook"
> to provide the patches so the software is unsupported and I cannot use the software.
due to the support requirement.
Essentially, as an employee of a company that contracts with the U.S.
Navy, I am the "roving" Linux Sys Admin here, supporting various Sys
Admins across the base on an "as needed" basis (not to mention
Solaris, etc)
When setting up CentOS5, for example, I set it up to automatically
install security updates from CentOS. Any IAVA'a that come down are
handled by the individual labs, and if they have questions, they call
me. I help with mitigation write-ups when necessary or let them know
if/when the security updates become available. I have yet to see this
become an issue, and my area takes these very seriously.
I have little experience with DADMS however. With most of the installs
I've done DADMS has not been a direct issue for me except a few
installs of the cygwin environment on Windows.
The OS distros installed since my employment began have been CentOS5,
Scientific Linux, Fedora13 and Fedora14 and Ubuntu 10.04 LTS (Long
Term Support)
The operational position has been (the questions I'm asked by various
IAO's/IAM's), "Can you support this?" or "If we should have problems
is commercial support available, ***If Necessary?***" "IF NECESSARY"
seems to be the operative phrase here, but we are somewhat unique as a
base, lots of research, development, testing and evaluation, so the
relatively sophisticated user's/developer's requests are met wherever
and whenever possible.
According to the JacORB site:
-----------------------------------------
"We provide free, best-effort support via our mailing lists and our
bug tracking system. Many issues can be resolved this way, but if you
need a guaranteed level of support, or an urgent fix for a specific
problem, commercial options are available. The following companies and
individuals offer professional services for JacORB."
Commercial support & development
Object Computing, Inc. (OCI)
PrismTech
Remedy
Members of the JacORB core team are available for contract work to
resolve issues or implement new features. Please enquire at
devel...@jacorb.com.
-----------------
So, it seems to me that this does have commercial support, if
justification is needed
As an aside, now that HBSS requirements are being rolled out and since
HBSS supports most linux distros, a lot of IAO's/IAM's concerns have
been alleviated somewhat.
The few times I've been involved with DADMS (I do not have a DADMS
account at this time - and I really do not want one :-) - so I go
though the Lab I'm working with) we generally look to see if the
package has already been entered somewhere, and if not, keep it as
generic as possible in order to "piggyback" on a previous entry. For
example the *entire* cygwin distribution is entered now as the
cygwin.dll distribution number, 1.7. We have been told not to worry
about each individual library, dependency, etc but instead paperwork
justification highlights the particular application we need. For
example, the cygwin distro is justified because of the XWin system and
the necessity to securely forward X apps through ssh from various HPC
sites at two particular Labs. Labs love it because it has saved them a
small fortune in Hummingbird license renewals. Although some
individuals use Openssh (part of the cygwin distro) for connection,
the majority use the combo putty/kerberos package downloaded from the
DoD HPC site, which I have to assume are already in DADMS.
If there is any specific information that I can help you with I can
ask the individual in my area that handles this. She was able to get
the Fedora 14 distro through very quickly. For example, less than a
week after we had our first request, I got the go-ahead.
Regards,
John C
Kedzierski, Artur CIV NSWC Corona, PA13
Sorry for late reply. Can you check with if she did OSS waivers for
any new adds in DADMS? Every new add for OSS requires a waiver. If she
did a new add recently, she must done a waiver too.
I wish there were an official document that describes "plan of support for OSS". My
IAO believes that such plan requires a purchase of support. We do cross platform software
development (Linux/Windows) so we use quite a bit of OSS (Boost, zlib, hdf5, Fox, Eclipse,
CMake, TortoiseSVN). Purchasing support for each of these would put us way over
budget. I can see people shutting down our Linux support because "OSS is too expensive".
--
Artur Kedzierski
Naval Surface Warfare Center Corona Division, PA13
-----------------------------------------
Commercial support & development
-----------------
Regards,
John C
--
You received this message because you are subscribed to the "Military Open Source Software" Google Group.
To post to this group, send email to mil...@googlegroups.com
To unsubscribe from this group, send email to mil-oss+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mil-oss?hl=en
michael.c...@gmail.com
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
John, Sorry for late reply. Can you check with if she did OSS waivers for any new adds in DADMS? Every new add for OSS requires a waiver. If she did a new add recently, she must done a waiver too. I wish there were an official document that describes "plan of support for OSS". My IAO believes that such plan requires a purchase of support. We do cross platform software development (Linux/Windows) so we use quite a bit of OSS (Boost, zlib, hdf5, Fox, Eclipse, CMake, TortoiseSVN). Purchasing support for each of these would put us way over budget. I can see people shutting down our Linux support because "OSS is too expensive". -- Artur Kedzierski Naval Surface Warfare Center Corona Division, PA13 -----Original Message----- From: mil...@googlegroups.com [mailto:mil...@googlegroups.com] On Behalf Of JCusick Sent: Friday, April 01, 2011 7:00 To: Military Open Source Software Subject: [mil-oss] Re: OSS Waiver for Navy's DADMS On Mar 30, 6:06 pm, "Kedzierski, Artur CIV NSWC Corona, PA13" <artur.kedzier...@navy.mil> wrote: > Has anybody done an OSS waiver for Navy's DADMS (FAM list)? We use a lot of OSS software where I'm located. Generally, we do it at a OS distribution level. > It sounds like when you want to use OSS, you have to purchase support from somewhere. > Now, I could just purchase $10,000/per seat support and not do the waiver. However, > what happens when I cannot purchase support for some OSS product. Let's say I want > to use Firefox on Windows (Red Hat license would cover Linux side). Firefox's website > doesn't even show commercial support (unless I missed it). I don't have anybody "on hook" > to provide the patches so the software is unsupported and I cannot use the software. In fact, I strongly suspect that the only reason my position exists is due to the support requirement. Essentially, as an employee of a company that contracts with the U.S. Navy, I am the "roving" Linux Sys Admin here, supporting various Sys Admins across the base on an "as needed" basis (not to mention Solaris, etc) When setting up CentOS5, for example, I set it up to automatically install security updates from CentOS. Any IAVA'a that come down are handled by the individual labs, and if they have questions, they call me. I help with mitigation write-ups when necessary or let them know if/when the security updates become available. I have yet to see this become an issue, and my area takes these very seriously. I have little experience with DADMS however. With most of the installs I've done DADMS has not been a direct issue for me except a few installs of the cygwin environment on Windows. The OS distros installed since my employment began have been CentOS5, Scientific Linux, Fedora13 and Fedora14 and Ubuntu 10.04 LTS (Long Term Support) The operational position has been (the questions I'm asked by various IAO's/IAM's), "Can you support this?" or "If we should have problems is commercial support available, ***If Necessary?***" "IF NECESSARY" seems to be the operative phrase here, but we are somewhat unique as a base, lots of research, development, testing and evaluation, so the relatively sophisticated user's/developer's requests are met wherever and whenever possible. According to the JacORB site:
Tina
Tina
Kedzierski, Artur CIV NSWC Corona, PA13
the DoD documents mandating it. I see it as support for application (IA issues resolved,
application actively maintained, etc.) while others see it as support for end-user, i.e.
technical support (ability to call even when the person on the other end is a dummy
following scripts on the screen).
I like the matrix from "Open Software Solutions for the Government" document that somebody
posted here a few weeks back. I wish I could say that application X is supported because it
scores N points on that matrix (followed by a break-down of the score).
If there were ever a follow up memo for "Clarifying Guidance Regarding Open Source Software OSS)",
I would love to see the definition of "plan of support" in it.
Kit Plummer
There's support for OS-level OSS.
There's support for Server/Service-level OSS.
There's support for Framework-level OSS.
There's support for Library-level OSS.
There's support for Gov-funded apps that include OSS.
There's support for Gov-funded OSS (of any flavor).
The _reality_ is that OSS is COTS. The same diligence is required for
evaluating OSS, to include SLAs.
I honestly don't believe there's a govie org out that wants to be a
maintainer of adjudicated OSS projects. But, there's surely an
opportunity for a company to support a standard "pile" of
commonly-used projects, who may or may not lack a parent org that
already provides support.
The SLA itself is problematic, because most OSS projects have a
committer structure that would prevent optimal contributions from an
external source. This means that there's likely some kind of
branch/fork in the middle - which then has to be maintained
independently. Been there - it isn't as bad as it sounds. I do think
there's a need for this. There are many, many libraries and
frameworks that are being maintained in many forks that waste the
whole point of OSS in the first place because using contractors are
too scared, or incapable of working with the up-stream project.
I've always thought that a mil-specific support channel for
Apache-based projects would be a great opportunity. FuseSource has
this down for the commercial space (ActiveMQ, Camel, CFX, ServiceMix)
- and are working with a few gov agencies to provide consulting and
support, as an example.
Kit
On Tue, May 3, 2011 at 7:00 AM, Kedzierski, Artur CIV NSWC Corona,
Miles Fidelman
> Part a problem is lack of definition of "support" or "plan of support" for OSS in
> the DoD documents mandating it. I see it as support for application (IA issues resolved,
> application actively maintained, etc.) while others see it as support for end-user, i.e.
> technical support (ability to call even when the person on the other end is a dummy
> following scripts on the screen).
>
>
The 2009 OSS Policy Memo states:
"d. The use of any software without appropriate maintenance and
support presents an information assurance risk. Before approving the use
of software (including OSS), system/program managers, and ultimately
Designated Approving Authorities (DAAs), must ensure that the plan for
software support (e.g., commercial or Government program office support)
is adequate for mission need."
unless I'm reading this wrong, it applies to "any software" - OSS, COTS,
custom, ... - and leaves it to the DAA to decide what support is
"adequate for mission need"
seems to be pretty clear cut to me - each situation is different,
someone has to make the official call
Miles Fidelman
--
Miles Fidelman, Principal
Protocol Technologies Group, LLC
617-538-9249 - mfid...@protocoltechnologiesgroup.com
In theory, there is no difference between theory and practice.In
Kedzierski, Artur CIV NSWC Corona, PA13
be associated to a COTS, you fill out an application. If the COTS
is OSS, then you have submit an additional OSS waiver that contains
plan of support with 4 or 5 stamps of approvals. One if the stamps
is IAO's. My IAO's interpretation of support is having commercial support.
--
Artur Kedzierski
Naval Surface Warfare Center Corona Division, PA13
Miles Fidelman
--
Miles Fidelman
commercial support
Then again, there's commercial support and there's commercial support -
for a lot of commercial applications, support = "buy the next release."
Seems to me that one way to skin this cat is to look at the support
offered for a comparable COTS program, and propose an equivalent support
plan.