W3C home > Mailing lists > Public > public-oilgaschem@w3.org > December 2011

Contributions

From: Roger Cutler <rogercutler@gmail.com>
Date: Thu, 8 Dec 2011 10:38:41 -0600
Message-ID: <CAMU31A6rzX4MUkowJfWEg7S7aMzrB+pdzPJ_kB8Yzh5iTcbW9Q@mail.gmail.com>
To: public-oilgaschem@w3.org, Ian Jacobs <ij@w3.org>
On reflection, I think I got off on the wrong foot with respect to
contributions and have gotten twisted off worrying about scenarios that
can't happen.  Let me back up a bit:

I see offhand four types of things that might be considered contributions
(or in one case might not): 1)Ontologies; 2)Documents describing business
processes or use cases for the technology; 3)Presentations describing
business solutions, applications of technology, etc; 4)Results of POC
(Proof of Concept) demonstrations in which group members collaborate to
build an application.

The first and second most obviously fit the definition of contribution in
the CLA.  Both are reasonably self-contained, formal and complete technical
specifications (using the term a bit differently) that I'm sure would need
to be approved by various corporate entities before submitting.  I do not
think that such approval mechanisms would make an appreciable distinction
between submission to a group that includes competitors and release to the
public, since in both cases there would be no NDA (non-disclosure
agreement) in place.  The third, presentations, would presumably require
the same kind of approval, again I believe essentially the same for group
and public consumption.  In this case, however, I question that you would
actually classify these as "contributions".  I recall a number of instances
at HCLS IG meetings in which members gave presentations summarizing their
work and achievements, and I think that this "just happens" and is
considered communication.  I suspect that in some cases the presentations
are archived publicly on a W3C site and possibly in others not, but I think
that's probably a different issue.

The last example is probably more complex.  I bring it up because I know
that this kind of thing has happened in the context of industry standards
groups, but unfortunately I've not been close enough to these efforts to
know exactly how they are structured.  I strongly suspect, however, that
these collaborations have a legal framework in addition to, or outside of,
the standards body.  Let me give an example.  Suppose companies A, B, and C
agree to work, under the auspices of standards body S, on a demonstration
of communication between companies in a simulated joint venture environment
established on servers provided by A.  (This kind of thing has actually
happened).  I am virtually positive that this would require some sort of
legal framework -- probably an NDA -- involving A,B and C but probably not
S.  Some suitably summarized report of the results, with some information
possibly obfuscated, would then be reported back to S with the expectation
of publication.  This report might or might not contain portions of the
actual code used in the demonstration, depending on details of whether that
code involves proprietary systems.  I can easily think of examples of
information that would have to be shared between A, B and C but probably
not reported to S and certainly not made public.  A trivial example would
be the passwords required to get into the server.  A less trivial example
could be the data model and API definitions for a vendor system used in the
demonstration.  I know from experience that there can be contractual
limitations to making this kind of thing public.

All this related to POC's is potentially complex and I think would need to
be worked out on a case by case basis.  I think it's well beyond the scope
of a charter.

So on balance, it seems to me that any reasonable "contribution", which to
me implies something rather formal and well thought out that has been
approved for release by appropriate corporate processes, should be headed
toward being made public.  I think that ensuring that there is an
appropriate level of detail and obfuscation in the contribution -- that is,
that it does not accidentally reveal any sensitive IPR or violate IP
(Information Protection) restrictions -- would be part of that process.  So
I think I am completely reversing myself and now I think that if a member
makes a formal contribution that there should NOT be an expectation of it
remaining restricted to the group.  In fact, I wonder whether trying to do
that would raise anti-trust concerns.  Let me recall that the primary
motivation for restricting access to work conversations is NOT to establish
confidentiality but rather to provide some level of protection for careless
talk.  That is, to provide an environment in which one does not have to be
quite so worried about all the possible ramifications of every statement.
In other words, the concern is that in conversation one might carelessly
say things that could be misconstrued or that are actually wrong or not
fully thought out, and one does not want these mistakes to become publicly
attributed to the company.

Finally, there may be the issue of timing.  Should a "contribution" be
available to group members before the public?  That might be an incentive
to join the group, I suppose, if that were perceived to be a potential
competitive advantage.  However, when one states it that way I again worry
-- and do not know because I am not in a position to get legal advice on
this -- whether that could be interpreted as an anti-trust violation.  That
thought, however, makes me want to stay away from the issue unless there is
a real reason to pursue it -- and at this point I don't see such a reason.
Of course, reading the CLA carefully I infer that the requirement for
publication of a contribution only applies if the contribution is actually
used in a deliverable of the group.  I'm not quite sure how to handle that.

How about saying in the charter that the group may choose not to accept a
contribution, but if it does accept it that the contribution will be made
public?  Is that reasonable and desirable?
Received on Thursday, 8 December 2011 16:39:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 8 December 2011 16:39:14 GMT