OSI enforcement?

[Philippe Verdy]

John Cowan [mailto:cowan at ccil.org] wrote:
> If you offer binaries by offering the right to copy them from a given
> place, and if you offer the sources by offering the right to copy from
> the same place (with a liberal definition of "same"), it is considered
> to be a joint offer, and no written offer is required.

I tend to disagree with what you consider "liberal". What really counts is
the working URL for downloading some file, and there's no easyway to
determine the URL to download the sources from the URL to download the
binary package, unless the only working way to get the binary package is
through some descriptive page that offers links to BOTH the sources and
binary packages on the same document.

In all cases, users should not have to search how to look for the sources.
Beware that some sites may reference cross-site downloads for the binaries
without even proving the link to the sources. OR the link may be provided as
part of an auto-update tool that processes the download automatically for
the binaries, without keeping trace of the location of the associated
sources. So it's important that the binary packages in this case, or the
tool used to download them, maintain a trace of the link to the sources
(even if their download is not automaticly performed by the tool).

Compliant tools that automate downloads of binaries and also offer optional
downloads for the binaries are similar to what the installer for Cygwin is
proposing.

But I'm not sure that the RedHat autoupdate system is compliant, because it
installs binaries automatically though some secure system, and with too
little possible interaction to inform the user about where the corresponding
sources are located. This automatic tool will work as long as the user as a
valid subscription to the RedHat support service, but as soon as it stops,
the user looses access to it, and there's no easy way to determine where the
sources are located without asking to the RedHat support (that RedHat
however should honour independently of the user's current or past
subscription status).

I suppose however that the access to these sources is guaranteed in the
RedHat subscription/licencing contract for its support in its written offer,
even if those sources are then provided without any other support. I've not
read any recent RedHat subscription contract

Last time was about 3 years ago, and I never needed it after that, for me or
any of the clients of my company, because we provide the support ourselves,
along with providing the binary installations, licences, and the written
offer as a mandatory annex to the service contract with the client; the
client is not required to renew the service with us, and may opt at any time
to buy, for itself, its own support service to RedHat without us interfering
with its decision, and independently of our service whose main focus is not
in this installation;

However, our service may depend on specific versions that we can know and
test, and by contract, they must inform us in due time, if they ever change
something in their platform, because we can't guarantee our service on all
versions they could possibly acquire); this includes for example the
maintenance of supported databases, or the additional time that may be
needed by us to recompile our applications on their new system version or to
comply with some new library versions and possible incompatibilities or
changes of features and functionalities; the client has a bundled limited
support given as minimum time for such changes (payed in advance as part of
the support, so that "emergency" corrections are possible in a reasonable
time without requiring prior negociation, only needing rescheduling for
other ongoing projects), but any extra time that may be needed to adapt our
support to such change requires prior negociation of conditions.

Such thing is true commerce, but the delivered products are still open
sourced (unless they are specific and the client requires strict ownership
on their specific development, in which case we will keep nothing or we will
negociate some price to capitalize it if it's beneficial for us to keep some
version and the client accepts such purchase by us), we provide the service
along with the sources as required by the GPL if GPL software is used in
these projects and the client has to manage itself these sources and keep
them for any later delivery by him to any other service provider that they
may request for the maintenance of their installed system (the client also
keeps the development documentation given as a deliverable with their signed
receipt of the projects made for them).

It sometimes happen that the client decides, at end of a proprietary
project, to make it partly of fully open source, so that we can keep it for
free, or because it will allow the client to seek for a more complete
integration within other open-sourced solutions where help from the
community (or more efficient support services) may be desirable to save them
money for the maintenance, or accelerate the development or deployment or
long term management of the installation. In fact, this happens quite often,
at end of a development cycle when it's time to think about redesigning
something and minimizing the cost of maintenance of the past project in the
interim, once the past development is financially amortized (3 to 5 years),
and the intrinsic value of the software becomes virtually void and offers no
specific competitive advantage.

In almost all projects that I have had to work with, the value of any system
is not in the software used to operate it, but in the data and schemas
collected. The system itself is secondary and must be replaceable and
adaptable at any time. Open sourcing software saves time and money for
everyone, and provides more responsiveness to emergency situations where the
work time and competence to service it is the most rare, most precious and
most expensive resource.