[Fwd: Re: An Xmas present for you to peruse, comment, and mull..]

[Joshua Judson Rosen]

"Jon 'maddog' Hall" <maddog at 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))))."