"Jon 'maddog' Hall" <mad...@li.org> writes:
>
> I will not comment on most of your discussion, since I think you and
> I agree that some of the words in Seth's document will be hard to
> prove as written, and perhaps should be modified so the opponents of
> the bill will not have statements to challenge.
Indeed.
> > > If you want to make "adherence to open, platform-neutral standards" as
> > > part of your definition of "Open Source" in 21-R:10 then this part is
> > > fine.
>
> > Only if it's also part of the definition of "Proprietary"....
>
> > It's not obvious to me that an Open-Source implementation of some weird
> > `standard' that's only supported by that one (open) implementation
> > is inherently *any worse* than a proprietary implementation of some
> > weird `standard' that's only supported by that one (closed) implementation.
>
> Here we are making a definition of what is "open". We do not have
> to necessarily address what is "proprietary". If you want to
> further define what is "standard", that is fine too.
Right, what I mean here is: maybe a clause about standards-compliance
should be part of a *general* `fitness' rule for software-`acquisition',
but that's a separate issue from software-licensing. It doesn't make sense
to put *additional* fitness-requirements for OSS acquisition/deployment
*beyond* the restrictions that are placed on acquisition and deployment
of proprietary packages.
That'd accomplish the *opposite* of what we want.
In forming our definition of "open", maybe we should revisit:
The Open Source Definition <http://opensource.org/docs/osd>
The Free Software Definition <http://www.gnu.org/philosophy/free-sw.html>
the Debian Free Software Guidelines
<http://www.debian.org/social_contract#guidelines>
Don't define yourself into a corner by using a peculiar definition
of "OSS" that may well block-out a significant portion of the actual
OSS `free market' for which you're trying to make explicit inroads,
when the proprietary market has no equivalent fitness-constraints.
If we want to add appeal by talking about *tendencies* and *likelihoods*
that OSS packages will conform to open conform to desirable standards,
or the *capabilities* of OSS packages to be *made* to conform
as part of the Integration process (even if they didn't `out of the box'!),
we can do that without over-restraining the definition such that
`OSS COTS that doesn't support a standard out-of-the-box doesn't count,
and can still be excluded from consideration even though proprietary COTS
that also doesn't support the standard is fine and can't be excluded'.
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
