Hi Manny!
On 12/27/06, manny <[EMAIL PROTECTED]> wrote:
On Wed, 27 Dec 2006, Dean Michael Berris wrote:
> Wait, the requirements were just that software to be used by
> government be FOSS. It had nothing said about technical requirements,
> which is why the Bill in my opinion doesn't make sense to require FOSS
> only in the first place.
Hold on. The bill does not supplant RFPs (flawed as they are). Were you
somehow led to believe that the FOSS bill -- and only the FOSS bill --
determines absolutely all the requirememts for software procurement?
Let me state for the record that if such is the intended interpretation of
the FOSS bill, then I will oppose it even more vehemently than you!!!
Apparently, the migration plans were based on the assumption that
every government computer not using a FOSS solution would have to find
a FOSS replacement to the existing solution. If this isn't a disregard
of RFP's that had been previously fulfilled or currently open (or a
complete disregard for the use/viability of RFP's by directly not
mentioning it), then I don't know what is.
The lack of mention of the procurement process or the proposed changes
to the procurement process as far as replacement, new (to be
acquired), and to be developed software solutions are concerned is
alarming as far as how I understand the bill is concerned. If it's
meant to supplant the RFP's, it seems like the choice on which
software to use will be made by law with blind regard for the
technical requirements of the government agencies in question.
Here's my take (and I believe Casino's) on the FOSS bill. It mandates an
additional set of standards, but do not totally replace the RFPs which
specify the technical requirements. It mandates certain licensing
requirments in addition to the technical requirements of the RFPs. The
requirements of *BOTH* have to be fulfilled.
So while a Hello World program may fulfill the licensing requirements of
the FOSS bill, it would fail to meet the requirements of the RFPs (flawed
as they are).
But promiseware can be put forth as proposals to these RFP's which
will meet the requirements both of the RFP's and the proposed FOSS
Bill.
Let me also state for the record that I'm not a big fan of promiseware. If
a FOSS solution can't meet the requirements of a government RFP, then it
FAILS. It cannot be further considered. The government must then consider
what else is left on the table. If no FOSS solution exists, too bad for
FOSS. That puts the pressure on FOSS developers, true, but that's a good
problem, isn't it?
Yes, that's always been a good problem for FOSS developers. :)
How about this: would you be happy if a no-promiseware provision were
added to the FOSS bill? Something like this: "In cases where the
government is to acquire existing software solutions, under no
circumstances may any 'promiseware' (no term yet; let the lawyers figure
this out), FOSS or otherwise, be selected over any existing solution (FOSS
or proprietary) that already meets requirements."
I think the above explicitly addresses the alleged loophole.
Yes, I agree it would cover the loophole I allege exists. :D
> Creating Software is what I was referring to. It is never about
> ethics/morals: it's about solving problems. Now if some people think
> that writing software is about freedom, then I can't help but think
> they're disillusioned or just wishful thinking.
It doesn't seem that way when people (including developers) actually get
to exercise the freedom given by the FOSS licenses. RMS and many others
wrote software to address ethical problems too.
Exercising the freedom is a vehicle to contribution and open
collaborative development. The freedom(s) granted by the GNU GPL is an
enabling factor for the further development of the solutions under
that license. There are other licenses (not necessarily FOSS) which
allow the exercise of open collaboration without limiting the usage of
the software (or just the source code) in question like the Apache,
BSD, MIT, and Boost Software License.
I am not aware of any piece of software (under the GPL or otherwise)
which was meant to directly address ethical problems without first and
foremost offering a technical solution. Maybe it's just me, but I see
software as a tool which enables you to do something far more
productive with a computer -- perhaps pushing an agenda is one, but
the software itself is just a tool. Much like how a pen is a tool, it
would be useless if someone didn't use to write something profound
with it.
Much like how the tool (any tool) can be used for many different
things not all of which are idealistic, noble, nor "good".
> Never? hmmm... I don't know about that. That's why I said any
> competent lawyer can make it stick, because with the help of this bill
> goes to law, it gives every third party FOSS developer the ammunition
> to propose a "FOSS from Scratch" solution every time there's an RFP.
> And because there's a formal bid that fulfills the requirements,
> Proprietary Software would never get the light of day of even being
> considered.
The bill doesn't allow promiseware. So it's not a problem. But to make it
even more explicit, one can propose the "no promiseware" provision
mentioned earlier.
The bill doesn't allow nor disallow promiseware, so that can be
contentious. The additional provision proposed above may cover it.
> Ah, but you just said that major overhaul matters! If modifying a
> GPLed Hello World program will take X amount of time and Y million
> pesos worth of resources to meet requirements, and the bid for such
> was entered for an RFP, and since the government is going to prefer
> that only FOSS is used, then Proprietary Software wouldn't see the
> light of day because "there is a suitable FOSS solution" entered as a
> bid.
Promiseware is NOT a suitable FOSS solution. The bill has no provisions
allowing it. The GPLed Helo World program would fail to meet requirements
outright.
Suitable as far as the promise goes. Buildings have been bought in the
same process, and apparently Software is still being considered
something similar by the government.
> 2) Misrepresentation is only applicable if there is an undue claim of
> representation.
Not so. See the first definition of "misrepresentation", not the second.
Yes, definition 1 goes for "with intent to deceive and/or mislead".
Crucial element is intent, which in my posts have only been based on
my interpretation. My interpretation was based on my opinion, and as
such had never been meant to represent anybody else's view but mine.
> Murder is not prohibited: it's punishable by law.
Dean, it IS prohibited. That is why it is punishable by law. Parking in a
"no parking" zone is PROHIBITED too. It is also punishable by law.
Murder in response to grave bodily harm, grave threats, and performed
although with premeditation while under fatal attack is considered
self defense. You may murder someone if only to protect yourself: you
can premeditate by bringing a deadly weapon with you and do all sorts
of psyching yourself out on how to do it, and bring yourself into a
situation when the person you want to murder will be attacking you.
Then murder will be justified and though punishable by law is NOT
prohibited.
Even the state can murder a convicted criminal -- yes, killing with
premeditation and intent. So no, it's not prohibited, but it is
punishable by law in cases where guilt beyond reasonable doubt is
established.
Parking in a no parking zone is punishable by law (if you get caught),
but you have the choice to park at your own risk. The act of parking
is not prohibited but if you park in certain parts where it's made
illegal to park you risk being at odds with the law.
Here's something interesting: suicide is also prohibited in some
countries. But it is also NOT punishable by law in some (who would the
government punish?).
Actually, an attempt to end one's own life is punishable in some
countries -- if your attempt fails, or is aborted -- and usually the
sentence is to a mental institution if not house arrest with medical
intervention.
There remains, the choice is there *always* but the consequences of
the choice is defined by the social contract between the government
and the people.
I think it's called "free will" where you always have your own will to
make your own choices -- nobody tells you or stops you from making a
choice and from making a certain choice -- but the consequences of the
choice you make is what you have to deal with given your obligations
and social contracts.
The law is more: "If you do this, then this is what happens to you."
than "Thou shalt not kill."
> If Government chooses to favor freedom and to enter into contractual
> agreements that are favorable to the government, shouldn't it preserve
> the freedom to choose without preference and prejudice based on
> classification, and to do it on an objective case to case basis?
No. The freedom (and accompanying benefits) granted by a license IS an
objective standard. It is NOT an arbitrary classification. It is a
practical public benefit and good governnance consideration.
Sorry, the freedom granted by a license is beside the point of the
technology in question which makes it a point merely of classification
-- even if it does have practical public benefit and good governance
considerations. Because the technology in question should fulfill
technical requirements (which is its first function anyway as a
technology), the point of differentiating on the licensing scheme is a
preference which is not objectively defined through measurable,
quantifiable, and verifiable (technical) requirements.
It might be a beaten dead horse, but it's paramount to choosing an
employee first and foremost by gender preferring one over another
instead of qualifications and relevant work experience.
> The FOSS licenses do give government a big advantage, there is no
> question about that. The question is whether the government should
> make the choice as mandated to be *required for all cases*. And my
> answer to that basic question is NO -- that the government should
> choose on a case to case basis based first on technical merit and then
> in terms advantageous to the government. If the FOSS solution proposed
> has technical merit and is procured in terms advantageous to the
> government then there should be no reason for government to choose the
> software being proposed -- but the same should go for proprietary
> software.
But if you use that formula, then the value of the FOSS license is NOT
recognized at all in any case. It would, at best, only consider
direct costs (or lack of it where the software is cost-free). But the
value that comes from the freedom to share, to modify, to redistribute,
etc. are not considered.
Although these values seem "priceless" and because you cannot put a
price on them, it will be very hard if not impossible to objectively
define the advantages in terms of quantifiable gains/savings or value
add especially when contested as an act of prejudice on the part of
government.
Yes, I want FOSS to get into government, but again I want it to get in
on technical merit alone -- that way there will be no question nor
hint of prejudice granting that it got in the same way other software
would and have gotten in. That way there wouldn't have to be
legislated preference for the "freedoms" that the FOSS licenses grant
the government, and still have government enjoy these same freedoms
with FOSS in the computer systems.
> What I'm saying is that instead of saying "only FOSS should be used by
> the government unless absolutely unavoidable" the government should be
> saying "the RFP's should not contain brand names, and that the
> technical specifications should abide by open standards for file
> formats and communication protocols". Instead of favoring FOSS blindly
> -- however righteous or idealistic it may seem -- I'm saying let's
> level the playing field so FOSS and other kinds of software have the
> same chance of getting into government systems.
I understand that. You were not remiss in explaining this point
(actually, you were very clear). What I am saying is that this would
totally disregard the value of the FOSS license because and makes it a
non-consideration in all cases. I contend that it is just as good a
standard as technical merit, and should therefore figure in the selection
process.
Now, as to HOW MUCH weight you give it, that can be worked out. As can
exactly WHEN it comes into play as well. There is actually room for
movement here. See possibilities below.
Just some ideas to ponder:
1. Favor FOSS by default, but only consider the freedom of the licenses
as a "last resort" consideration. This happens when when two or more
contending solutions (FOSS or otherwise) are practically equally
meritorious. That means any proposed proprietary solutions are
considered and studied from the very beginning of the process, just
like FOSS solutions. They compete on technical merit FIRST, then on
cost, other stuff (insert here), and then LAST, on the merit of the
license. Now, if the FOSS solution is eliminated before that, too bad.
FOSS developers just have to try harder.
2. No-promiseware clause. No FOSS solution may be acquired if it does
not ALREADTY meet requirments (for when the government is trying to
acquire an existing solution).
3. In cases where the government is asking for proposals to DEVELOP a
solution (software meeting certain requirements does not yet exist),
total costs must be considered first and cannot be renegotiated. The
#1 kicks in.
4. FOSS bill is ***NOT*** the ONLY standard to judge the merit of a
proposed solution (it never was intended to be so, as per the text
of the bill itself). The technical requirements outlined in the
RFP must be considered as well. NO FOSS solution may be acquired
that does not meet requirements of the RFP and the FOSS bill.
Those are ideas worth chewing on, I think. And they are still not very
developed. I wonder what they will look like by next year.
I like the four points up there, well written Manny. :)
FOSS might not even need to be the "tie breaker", because if there
were technically superior FOSS which can be procured with very little
cost, it would already trump most proprietary software solutions.
What I like best is that it gets equal opportunity.
--
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph