Response to the Federal govt RFI

Wed Feb 18 13:55:08 UTC 2009

As an open source developer I'm always concerned when someone refers to open 
source software as free in the sense of "gratuit".    The advantage of open 
source lies much more in the free in the sense of "libre".     Libre implies 
the ability to adjust and customize the software product to suit the 
government needs exactly.    Libre implies that the government would have to 
pay local developers to do those customizations.    Libre implies a better 
product at a lower cost,  NOT an substitutable product for gratuit.

I was involved with Elections Canada in the past number of elections as an 
automation coordinator.    That software is a classic example of a vendor 
(IBM) solution not fitting the needs of the customer (EC),  but the customer 
not having the ability make any changes.     Unfortunately when we floated 
the possibility of the Canadian Government creating an open source project to 
generate the next generation of EC software,  we ran square up against what I 
would call the "need to have someone to sue should something go wrong" 
mentality.    The Canadian Government doesn't yet see themselves as a partner 
in a process which provides a service,  but rather they see themselves as a 
customer purchasing a product which is supposed to provide the service.   
This is a shame because if they could make that mindshift I'm convinced that 
our taxpayer $$$ could be more efficiently allocated in the software area.

In this era of multi billion $ stimulus packages aimed at creating jobs,  we 
should be emphasizing the immediate local Canadian job creation potential 
offered by customizable open source government software solutions.    We 
should be emphasizing the long term value and cost savings afforded by 
customizable open source software.    We should be giving the Canadian 
government examples where this collaborative custom software development 
model has worked,  with specific emphasis on taxpayer savings. 

bob

On February 18, 2009 01:48 am, Evan Leibovitch wrote:
> Hello all,
>
> As many of you know the Canadian government has produced a formal
> Request for Information (RFI) regarding "no cost software" (which
> lumps together FOSS as well as free-to-download proprietary).
>
> I haven't had the time to create a complete doc on behalf of
> TLUG or CLUE, but  I'm at least planning to put in a submission
> on my own behalf.
>
> I've attached a draft of what I've done so far. There are three
> questions of the 10 -- #4, #8 and #10 -- that I either don't fully
> understand or don't have an answer for. Any assistance or suggestions
> will be welcomed, and I'll be happy to credit on the document the
> name of anyone who helps.
>
> - Evan
>
>
>
> -------------------------------------------------------------
>
> Q1. In the Overview, the Crown provided a definition for No
> Charge Licensed Software. Is this an appropriate definition?
>
>
> No, it is not appropriate.
>
> The current definition encompasses two categories of software that share a
> single trait in common but are otherwise substantially different:
>
> Software that is free of cost for an individual to download but otherwise
> proprietary, usually shipped in binary-only form (to be referred to in the
> rest of this document as “free-proprietary software”)
>
> Software that upholds both senses of the the English word “free” -- not
> only free of cost (in French, gratuit) but also free of most limitations to
> use, copy or redistribute (in French, libre) – (to be referred to in the
> rest of this document as “open source software”)
>
> Indeed, confusion about the two uses of the word “free” have led to the
> common use of the term “Open Source” to describe software distributed with
> such freedoms. “Free Software”, a term used by proponents of such software,
> has often been confused with software that is free of cost. This confusion,
> we believe, is menifested in the Crown's improperly combining these two
> different kinds of software for the purpose of this RFI.
>
> How is “free-proprietary” software different from “open source” software?
>
> Many different software licences that qualify as “open source” according to
> guidelines of the Open Source Initiative (http://www.opensource.org) or
> “free software” according the the Free Software Foundation
> (http://www.fsf.org), they share significant common and basic traits:
>
> They do not limit re-distribution;
> They do not define inappropriate use nor put any limitations on use;
> They supply source code and allow anyone to make modifications for their
> own use; They allow and encourage (and in some licenses they require) that
> modifications are also distributed with these same charateristics
>
> Proprietary-free software generally lack some or all of the above
> characteristics; indeed, they are no different from the conventional
> packaged software except that under a certain circumstance it is
> downloadable at no cost. Generally, free versions of proprietary-free
> software are provided as promotions, preliminary versions, or as enabling
> tools or drivers to support other non-free software or hardware. The
> revenue model behind the production of proprietary-free software ultimately
> requires that revenue is derived from either the software or something that
> the software enables.
>
> Conversely, open source software is intended to be provided as a finished
> product, not intended to promote something else. Its revenue model
> generally avoids monetizing the software itself, instead providers derive
> revenue from ancillary services such as support, training and consulting
> which are not necessarily required for the operation of the software.
>
>
> Because of the differences in purpose and revenue model, often
> free-proprietary software has various limitations, not all of which may be
> known at the time of first use or until the license is read in detail:
>
> Certain features are “locked” unless a fee is paid or some action is taken
> The software is time-limited and will stop working after a certain period
> or on a certain date Free use may be restricted to personal or non-profit
> systems
> The software is a preliminary or “beta” version; the full release version
> must be paid for The software contains advertising which in some cases can
> be turned off by paying a fee1 Current version is free to download; future
> versions and upgrades will be charged for Proper use of the software
> requires registration (and loss of privacy) Messages “encouraging” users to
> send money are shown.
>
> In other words, what may appear to be “free” may instead be just a
> demonstration, or software disabled in such a manner as to encourage
> purchase of the full version. It is not a coincidence that the terms
> “nagware” and “crippleware” have been coined, most often to refer to
> free-proprietary software.
>
> By definition (of the common traits explained above), open source software
> is not susceptable to such limitations.
>
> There are occasional legitimate and helpful uses of free-proprietary
> software – hardware drivers and  evaluations, for example. However, such
> software is so substantially different in characteristics and motivation
> that it should not be “lumped in”  with open source software for the
> purpose of this RFI or any other future Crown request for goods, services
> or information.
>
>
> ----------------------------------------------------------------
> Q2. What are reasonable criteria that the Crown should consider
> in a decision process for acquiring No Charge Licensed Software?
> Are there circumstances in which the acquisition of No Charge
> Licensed Software would not be advisable?
>
>
> As stated above, we can demonstrate that free-proprietary software – while
> serving some useful purposes – is rarely useful in production environments.
> We are not aware of any legally acquired free-proprietary software that us
> useful for production environments without requiring an upgrade to a paid
> version. Conversely, we are of the position that open source software
> should be considered in any situation in which an open source alternative
> exists to conventional proprietary software. Open source alternatives will
> not always be the superior choice in regards to features and performance;
> however, the phenomenal flexibility and adaptability of open source
> software should also be a consideration in tenders and RFPs. We also
> suggest consideration of the following issues when developing policies and
> processes regarding the procurement of open source software: 1.The listed
> “source” or maintainer of a specific open source software package may not
> necessarily be indicative of – or aligned with – the best sources of
> knowledge and support for that package. A package should not be demoted if
> it is listed as having a foreign source, if high quality Canadian support
> organizations are prepared to support it. Likewise, a package may be seen
> to be “maintained” by a single individual, yet it may be surrounded by a
> substantial infrastructure of support, training and integration. 2.For the
> purposes of any tender or RFP, it is the supplier of support and
> integration services who must be primarily evaluated. Conventional “vendor”
> evaluations are of reduced value in the virtual, decentralized world of
> open source software development. Even in the case where an open source
> software package is seen to have a high-profile sponsor (such as Sun's
> involvement in OpenOffice.org and MySQL or Google's support of the Mozilla
> Project), procurement policies must primarily focus on the suitability and
> track record of the proposed local implementors. Because of the
> availability of source code, a contracted implementor of open source
> software is capable of providing support at a level far beyond that of
> proprietary software resellers. 3.The Crown must take into consideration
> that, because of the models supporting their development, open source
> software projects usually have negligible marketing talents and resources
> behind them. It is more important than usual to look beyond the gloss of
> vendor presentations to evaluate the quality of the service to be provided.
> Open source support companies usually have less marketing resources than
> similarly sized companies selling proprietary solutions. Open source
> support organizations break the conventional Value-Added Reseller (VAR)
> model because they are not reselling anything – and as such do not receive
> financial incentives and support from the software supplier. The Crown
> should make an extra effort when evaluating IT solutions based on open
> source software, not to confuse the quality of a solution with the gloss
> surrounding it.
>
>
> ----------------------------------------------------------------
>
> Q3. What factors other than price should be considered as part
> of an evaluation guideline for No Charge Licensed Software? Are
> there other factors beyond those outlined in Appendix A & B that
> the Crown should consider?
>
> As stated above, the personal background of the open source software
> developers must not be as much of a point of evaluation as it is for
> vendors of conventional proprietary software. However, it is legitimate to
> evaluate the stability or health of any open source project that is
> proposed for Crown use.
>
> The following criteria may assist in determining the long-term stability
> and health of open source software projects: 1.How long has the project
> existed?
> 2.How long has the current lead developer held that position?
> 3.Is there an incoporporated body supporting the organization? If so, who
> are its sponsors? 4.What is the size of the developer community?
> 5.When was its last release?
> 6.Do developers consider the current version stable? (Is the release
> version less than 1.0) 7.How often are updates released?
> 8.Is the software included in the repositories of major Linux
> distributions?
>
> Related criteria that may be asked of a service provider proposing  support
> for an open source project – that might not be asked of a proprietary
> software reseller may include: 1.How long has the provider supported the
> project?
> 2.Are any of the provider's staff on the projects development team?
> 3.Have staff contributed code, documentation reviews, bug reports or other
> resources? 4.Are they subscribed to the project's mailing list(s)?
>
> Requests for examples of existing uses and case studies are completely
> appropriate, as they should be for any software being considered.
>
>
> ------------------------------------------------------------
>
> Q4. How should existing Government Furnished Equipment,
> Services, Service Level Agreements and internal resources be
> considered when evaluating the usage of No Charge Licensed
> Software?
>
> We do not have a response to this question.
>
>
>
> --------------------------------------------------------------
>
> Q5. How practical is No Charge Licensed Software? Are there
> hidden costs that need to be considered as part of the process
> of evaluating the alternatives available?
>
> As listed above, we have serious concerns about the limitations, often
> hidden, within free-proprietary software. As well the Crown should consider
> what file formats and interfaces are being used, and receive a declaration
> related to any claims of patents or other intellectual property.
>
> Genuine open source software entails no hidden costs; indeed, it is indeed
> a matter of “what you see is what you get”. Any warrantees, if even
> possible, would need to be provided by the integrator as opposed to the
> software developer(s). The Crown needs to ensure that any proposed provider
> of solutions based on open source software clarify the availability and
> cost – as applicable – of Tutorial and Reference documentation.
>
> Services such as training, integration, installation, configuration and
> maintenance should be quoted by solution providers using open source
> software. Local providers may be responsible for sourcing services and
> materials such as courseware which may usually be provided by proprietary
> software vendors.
>
>
> ---------------------------------------------------------------------------
>------------------------------------------------------ Q6. What are the
> general financial, technical and security risks associated with acquiring
> and using No Charge Licensed Software?
>
> As listed above, we have serious concerns about the limitations, often
> hidden, within free-proprietary software. It is critical to evaluate the
> license of any software of this kind in advance of using it, even for
> evaluation purposes. Usually, free-proprietary software has little or no
> support, even less than the community of volunteers who routinely help
> users of open source software.
>
> For open source software, the risk evaluation should be similar to that for
> proprietary software. As recommended above, the stability of open source
> projects should be evaluated as well as that of the proposed solution
> providers, to compensate for the lack of a software “vendor” to evaluate.
>
>
> -----------------------------------------------------------
>
> Q7. How do Open Standards and interoperability factor into
> evaluation considerations?
>
> Because it is supplied with source code, any interfaces and formats used by
> open source software are by definition open themselves. As such open source
> software is most likely to use open standards (such as the ISO-standard
> OpenDocument format) than proprietary software that has an interest in
> “vendor lock-in”. Open source software developers have never asserted
> patents or other intellectual property claims on such formats and
> interfaces. As such, standards made with and by open source software will
> always remain open and available. Users of open source now will avoid the
> current situation in which old documents can no longer be read because they
> were created with proprietary formats by old proprietary software which is
> no longer available.
>
> Indeed, open source software has evolved in a world that has been dominated
> by proprietary software vendors; it had to be interoperable in order to
> even be accepted. Tools such as the Samba file-sharing infrastructure have
> been critical components of the acceptance of open source systems into the
> IT mainstream. Whenever possible open source software developers have
> strived to maintain compatibility with proprietary counterparts; however
> the reverse is not true. As a result, open source software tends to be
> easier to intergrate with other systems than proprietary tools. (As a
> simple example, most modern Linux and BSD based operating systems are
> capable of dual booting and mounting of Windows filesystems. The reverse is
> not true.)
>
>
> -------------------------------------------------------------
> Q8. How does the technology factor into the evaluation
> consideration, such as ability to maintain and evergreen?
>
> We do not have a response to this question.
>
>
> ---------------------------------------------------------------------------
>------------------------------ Q9. How does the Crown evaluate the
> flexibility of the licensing models for No Charge Licensed Software?
>
> As mentioned in the response to Q1, all licenses claimed to meet
> well-understood definitions of “open source” or “free software” have a
> number of common characteristics.
>
> A detailed contrast of the various approaches is beyond the scope of the
> RFI; however, it is reasonable to assert a number of criteria that should
> be evaluated, depending on the particular needs of the Crown:
>
> The main distinction between most licenses is in what rights or limitations
> exist when open source source software is modifed (that is, changed in
> source code as opposed to configured).
>
> Some licences provide no limitation, allowing a user to take the software,
> make modifications to it, and close the result as proprietary. Other
> licenses prohibit this, requiring any modifications to be as open as the
> original software.
>
> If the purpose of the Crown's procurement is as an end-user, and not as a
> re-distributor of open source software, than the distinctions above may not
> be significant. Most (but not all) open source software licenses freely
> allow modification and do not require modifications to be open of the
> software is not redistributed. The Crown is advised to ensure in its RFPs
> that the licenses provide the required rights, either to ensure the
> continued freedom of modifications, or to allow proprietary derivatives.
>
> It is our position that open source software which is modified by the Crown
> on behalf of the people of Canada should be as free as the original code,
> whether or not the software license requires it. Keeping modifications open
> gives benefit to Canadians to learn, reduce their own IT costs, and help
> the Crown ensure its software is as secure as possible.
>
>
> -----------------------------------------------------------
> Q10. What impact will No Charge Licensed Software have on
> Government Licensed End-User Networks
> (http://software.tpsgc.gc.ca//catalogue/index-e.cfm)
>
> We do not have a response to this question.
>
>
>
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists