Re: Refactoring Create Order process during OFBiz Developers Conference Sponsored by Hotwax Media

[Jonathon -- Improov]

David (Jones),

This sounds serious. But I can't understand some (or most) of it. All I know is this sounds like I 
need to get every contributor to give some kind of "explicit consent" for us to keep the source 
"clean", so that we can pump their contributions back to OFBiz tree.

David, er, help?

Chris,

> There are at least five separate groups of community members (including one
> that you're involved with) vocally trying to collaborate on solutions that
> are beneficial to the OFBiz community at large that if allowed to their own
> devices will create great contributions that no one can benefit from without
> obtaining the source from disparate locations, unless they choose to ignore
> the possible repercussions.  I think this constitutes a need in the
> community.

That sentence is long. I'm lost. Which 5 groups? What need?

> I am shocked that no one who can post to the legal-discuss list will. The
> easier to beg forgiveness than to ask for permission has the potential of
> large repercussions especially when we're talking about software that is
> attempting to be the backbone of businesses.

Where's the legal-discuss list? How does forgiveness and permission weight against each other? 
What repercussions?

Jonathon

Chris Howe wrote:
Jonathon,

You are missing the whole legal obstacle.  

Given the IP clearances necessary in all of those wonderful legal links
that David provided, your rag tag team's collaborative contributions
cannot be submitted to Apache OFBiz and be accepted into the project in
the form that they're likely to be offered.

Any collaborative efforts on the ofbiz-sandbox project on
Sourceforge.net do not clear the IP hurdles.  As far as the discussion
surrounding the anon checkout process, that did not clear the IP
hurdles.  The manner in which the Developer's conference has been
proposed, does not clear the IP hurdles.  OFBiz itself did not clear
the IP hurdle.  

David,

IP law in America is insufficient to provide documented references so
everything regarding it has to do with the concepts that surround it
instead of actual legislation or clear case law.  Do a google search
for Intellectual Property Bankruptcy Case Law and you will see some
staggering rulings.

A few legal concepts, IANAL

See Joint authorship and Ownership
http://library.findlaw.com/1999/Jan/1/241478.html

Every person who writes code (not under contract) owns the copyright of
what they write, this is because each individual is a sole-proprietor.

When you collaborate with someone, you own the copyright for the
portion you write, and the other person owns the copyright for the
portion they write.  The problem occurs that the partnership between
the two of you owns the copyright for the work as a whole.  

Now, what's the big deal?

The findlaw link only refers to the assets, not the liabilities.
Say one of these partners goes to a client and says "So and So and me 
worked on this part of the code and I guarantee that it works."  The
source code says plain as day "No guarantees".  However, because one of
the partners guaranteed it, the partnership has guaranteed it.  The
members of the partnership are now jointly and SEVERELY liable for the
fulfillment of that guarantee.  The person spouting out guarantees has
overstepped his authority in making the guarantee, but that only makes
him liable to his partners as it's not fraudulent.   The partnership is
still liable to the bad partner's client.    Again, both jointly and
SEVERELY.

How does this likely affect Apache?  Likely only distribution will be
affected, not financial.  If it's found that the code is owned by the
partnership and there is some IP problem arising in that partnership,
Apache can be served a cease and desist order and will need to pull
that contribution out by it's root as well as any derivative of that
contribution.  No big deal, we can code around contributions. However,
Apache then cannot make previous revisions available through SVN
either. With jars this isn't a big problem, however the manner in which
OFBiz is written with it's components and services, and the largest
likely contribution not being in jar format, it is a HUGE problem.

If this is simply not a problem that can be solved in Apache, fine, I
accept that and we'll just have to live with either keeping our
collaborative contributions out of Apache OFBiz source, live with
limits of JIRA and the time and expertise (though limited :-)
)constraints of the committers or continue to accept the risk of
including these contributions in OFBiz source.

There are at least five separate groups of community members (including
one that you're involved with) vocally trying to collaborate on
solutions that are beneficial to the OFBiz community at large that if
allowed to their own devices will create great contributions that no
one can benefit from without obtaining the source from disparate
locations, unless they choose to ignore the possible repercussions.  I
think this constitutes a need in the community.  

I am shocked that no one who can post to the legal-discuss list will. 
The easier to beg forgiveness than to ask for permission has the
potential of large repercussions especially when we're talking about
software that is attempting to be the backbone of businesses.



--- Jonathon -- Improov <[EMAIL PROTECTED]> wrote:

David,

Just a brief response here.

Sandbox can be created outside of the OFBiz SVN. Even your personal
branch (assuming you do an 
"SVN copy/branch" from the OFBiz SVN trunk, not your read-only
workspace containing the downloaded 
OFBiz) is a sandbox.

 > - A sandbox with lots of committers isn't going to work. Thanks
for
 > explaining that in your e-mail, I didn't realize this wasn't
 > workable till now.

David's right. If an OFBiz SVN trunk isn't working as well as we'd
all like it (given limited 
committers' resources to audit and/or to commit patches), then a
sandbox given a disorganized 
ragtag (at least I consider myself ragtag) team of committers won't
work either (too many cooks).

 > Would it work to have a sandbox that is managed by the existing
 > committers, or perhaps a few new committers? As a committer, you
 > wouldn't need to give nearly the same amount of time and attention
to
 > trying to make sure the commitment met best practices, free of
bugs,
 > etc. Any developer could share their stuff that they've
implemented for
 > their business, or other neat components. And, since the
commitments
 > would be in svn on the other side of the "Donate to the Apache
 > Foundation legal radio button, it'd be easy for these developers
to
 > collaborate and slowly bring unworkable buggy messes into gold.
Finally,
 > users could easily find and try the components without mucking
with
 > patch files, etc.

I (and some others) are currently looking to "round off loose ends"
in OFBiz (for easy successful 
demonstration to business clients, not IT folks). We're doing it in
our own sandbox. If you'd like 
to join us, let me know.

Our sandbox will contain many patches that won't be in OFBiz SVN. We
(the ragtag team) will be 
responsible for crash-testing those patches to death before we submit
them to OFBiz. I believe 
this is an excellent way to free up the OFBiz committers. We really
test and audit our patches 
first before even posting to OFBiz committers, in the proper formats
(see 

http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices)
no less.

We're trying to take the heat off of the committers, allowing for a
playground without messing up 
the official OFBiz trunk for you/me/everybody, and create a
structured way to submit patches to 
OFBiz for review.

Well, at least that's my direction. The ragtag team isn't headed by
me (I'm not paying).

Jonathon

Daniel Kunkel wrote:
Hi

First, please understand I hold you in incredibly high regard, and
apologize for causing any frustration...  You and Andy have created
an
amazing software tool that I'm basing my business on, and you've
given
it away. I love that! As you can see, your efforts are now
multiplying
in to a system that has a life of its own, which will eventually
change
the face of many businesses throughout the world. 

During this process, you've needed to exercise great control in
choosing
what to allow into the project, and what to reject. Since I often
update
my production system to the svn head, I'm very glad someone is
there
watching, and if you think about it, it makes sense that access has
been
very limited to just the professionals that have devoted themselves
to
the project.

However, as it grows, there are more and more newbies that want to
help
in their little way. Many *non-committers* who have wanted to give
back
to the project have been stifled and frustrated, often because
their
contributions were not appropriate, but sometimes simply because
the
committers are too busy to review/test/correct their contributions.
In
other cases, the resultant solutions are too specific to just their
business, or as a employee, the business although willing to donate
the
code back, was not willing to devote the time needed to make the
consumable by the project at large. 

So, what can we do to create a space where non-committers can share
their bits with the community? Please understand, we are agreed
that
neither of us would want their contributions running on a system.

- The source forge sandbox isn't really a good fit, because, as
Chris
has researched, the legal ramifications of donating it back to the
project outweigh the benefits begotten from the group effort.

- Forcing developers to work alone isn't working very well.

- A sandbox with lots of committers isn't going to work. Thanks for
explaining that in your e-mail, I didn't realize this wasn't
workable
till now.

- Jira isn't working. 

- The wiki could possibly work, but it doesn't go through the legal
process with each submission, and I cringe even thinking of trying
to
work with code in wiki. Eek.

- Even using the wiki, to catalog which jira issues are "in play"
is
unwieldy. Patch nightmare actually.

David, can you think of way to make a space in this community where
the
new/non-polished committers can easily share and play together with
their ideas where they won't hurt the bigger project until the
components are well proven?

Would it work to have a sandbox that is managed by the existing
committers, or perhaps a few new committers? As a committer, you
wouldn't need to give nearly the same amount of time and attention
to
trying to make sure the commitment met best practices, free of
bugs,
etc. Any developer could share their stuff that they've implemented
for
their business, or other neat components. And, since the
commitments
would be in svn on the other side of the "Donate to the Apache
Foundation legal radio button, it'd be easy for these developers to
collaborate and slowly bring unworkable buggy messes into gold.
Finally,
users could easily find and try the components without mucking with
patch files, etc.

Thanks

Daniel

On Fri, 2007-01-26 at 00:45 -0700, David E. Jones wrote:
Okay, I just wrote a huge thing and deleted it. There might have
been  
good stuff in there, but I am really frustrated because I've said
it  
all before and based on the comments from Chris it doesn't seem
like  
anything it making it out there.

If you're not a lawyer, then reference documents and processes  
already established.

I'm not even going to bother going into detail unless people are  
willing to:

1. describe their understanding of how what they want to do would
be  
done under current policy
2. describe why that doesn't work for what you want to do
3. describe how the existing processes need to changed in order to
 
accommodate it

A sandbox is a BAD BAD BAD BAD IDEA. Like you mentioned Daniel it 
would create a huge mess. I'm afraid one of two things would
happen:
1. nothing
2. a lot

In the case of number 1 it's not worth the effort to set it up. In
 
the case of #2 it would required more effort to administer and  
monitor than we have resources for in OFBiz. There is no way I'd
even 
=== message truncated ===