OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-ccbp-analysis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Registry object persistence; are BPs owned?


At 08:16 AM 3/4/2001, Moberg, Dale wrote:
> Comments  (and one question) inline. Dale
> * * *
> DM: I have no idea who owns the copyright.   My point is that any one
> could go out of business--open standards organization, outsourcer
> and so on.  When that happens, the CPA is possibly jeopardized * * *

You bet.   There's lots of law, and corporate gyrations, out there on how
to structure a deal to minimize that risk, in the analogous case where a
user leases custom software from someone with credit risk.   Escrow of
source code, etc, etc.  I was merely pointing out that a BP user has the
same problems, if he relies on a design-time pointer to a process
specification that goes away before run-time is complete.

>> JBC:
>> It's a bit jarring to think about a shifting, changing base of IPR-limited
>> objects up in the registries.  But in my view this is the natural
>> free-market result * * *

> DM: I hadn't realized I was propagating a weltanschauung
> -- the message seemed a bit short for that -- but you do raise issues
> on IPR that I was not thinking about.  * * *  patenting/copyrighting or 
> otherwise protecting rights to  process specifications by outsourcers 
> (or even by the BP specifiers themselves).
>
> Outsourcers would presumably have contracts in place * * *
> I would think these contracts would be the relevant place to deal 
> with failures to maintain the URL, * * * 

Excellent.  The contract IS the right place for a user to protect itself,
IF it is using something that is not freely replicable.  If it's true open
source, you are not at risk, as you have the right to replicate it and rely
on the copy under your storage control.  

My hope for the spec schemas is simply that we will point out, in
user-friendly language, that ongoing run-time use of a BP is only as good
as the persistence of the source BP.   My hope for the core components
exercise is that there will be a basic common-processes ebXML Tinkertoy set
that is made public domain.   Without that, I doubt you ever get to
critical mass.  

> Also, could you recommend a place where the IPR issues relevant 
> to ebXML CC, or to Process Specifications more generally, have 
> been discussed?

Um, good question.  I noticed it wasn't being discussed much.   That's why
I have been doing so.  More concrete artifacts to come, on that topic, in
about a week.    Jamie

Also, here is Brian Hayes' extremely well thought out view, which you may
not have been cc'd with, and a couple of reactions:

>> Date: Mon, 05 Mar 2001 11:30:05 -0800
>> From: "Hayes, Brian" <Brian.Hayes@Commerceone.com>
>> Subject: RE: Registry object persistence; are BPs owned?
>> To: "'James Bryce Clark'" <jbc@lawyer.com>,
>>        ebxml-ccbp-analysis@lists.ebxml.org
>>
>> Business Process Ownership:
>>     I believe the Business Process Identifier Naming Scheme (BPINS),
>> "supports" aspects of what Jamie [described in his message].  The 
>> naming scheme is described at
>> http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00125.html.  
>> Briefly, the format is:
>>
>> bpid:<agency>:<agency-id>:<business-process-name>$<major-
>> version-number>.<minor-version-number>
>>
>> where the <agency>:<agency-id> part identifies the owner of the
>> business process.
>>     Of course, using this naming scheme assumes that everyone 
>> plays by the rules -- that is no user can save/change a business 
>> process in the business process registries (more than one!) using 
>> an improper <agency>:<agency-id>.

JBC:  I'm glad to see that source ID is provided.  I assume that individual
registries are free to use write-access controls to police "playing by the
rules" -- or not -- and users are free to use registries that offer
assurances about those controls -- or don't.   

>>Access Control:
>>     I believe that a registry/repository should have a certain amount of
>> access control for a) accessing the registry and b) accessing content.  
>> For example, I would hope that a company like Commerce One would 
>> support a business process registry at its GlobalTradingWeb.net.  
>> This registry would allow public access; but, would not allow the 
>> general public to see "private" business processes that are stored in 
>> its repositories.

JBC:  Note the comment below about transparency and trade secrets.  
 
>> Futures:
>>     I believe over time that there will be few private business 
>> processes that don't have a public version (cooked up by someone 
>> else -- after all, there are only so many reasonable ways of doing 
>> business).  The exception to that might be copyrighted or patented 
>> processes (is it possible to patent a collaborative business 
>> process?).
>>
>> /Brian

The enlightened, and I hope eventually correct, view is that logically
inevitable transaction archetypes should be uncopyrightable and
unpatentable.   The good news is that the law conceptually provides for
this, in such doctrines as the mathematical formula exception to copyright
and the nonobviousness requirement of patent law.   The bad news is that
things have been muddied up lately.  I am going to Philadelphia next week
to moderate a panel of patent lawyers about this very issue at an ABA
convention.  I'll let you know how it goes, if they let me live.    Jamie




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC