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

[Daniel Kunkel <Da...@BioWaves.com>]

David

Can you explain your reticence to adding an Apache OFBiz sandbox where
more members of the community could share their work?

I can see this section possibly getting a disorganized over time with
*junk*... but it can be deleted easily enough. As a top level project
would it possible and better to organize a sub project for this?

Thanks

Daniel



On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
> I think we're talking about two different things.  You're talking about
> developing and I'm talking about legal issues.  The manner of
> developing was already discussed in OFBIZ-499.  The only legal way to
> use JIRA to collaborate this type of thing is to keep sending updated
> patches to JIRA or to have a committer review and add it to a
> specialized application.  Neither one of these is speed of development
> friendly.
> 
> Legal concerns wouldn't have been one of the primary driving forces of
> moving to the ASF if it were true that "we've done fine for years". 
> The project still has technical exposure to a C & D order as the CLA
> only covered works the copyright holder gave directly to the ASF not
> the works the copyright holder gave to the OFBIZ project prior to
> incubation.  IANAL, and I don't think there is significant exposure,
> but it is still there. That opinion isn't based on the vehicle used to
> create Apache OFBiz, but on the impression of kindheartedness from the
> members of the community prior to incubation. 
> 
> I don't want to speculate on the legal relationship the group that
> worked on the anon checkout had, but I would suspect that it generated
> some negative legal exposure as well and that the proposed setup of
> Developers Conference will add to that.  
> 
> The only feedback that I've received from the general incubator list
> are speculations, all with the caveat that the poster is not a lawyer
> either and no one has been willing to post it to the legal-discuss
> list.
> 
> This issue is one of the MAJOR reasons for the existence of non-profit
> entities like the ASF, FSF, and SPI.  So again, I ask you to reconsider
> the need of a more public sandbox where this kind of community
> collaboration can be done without the complications of copyright
> infringement, or at the very least pose the question to legal-discuss
> for a formal opinion from those representing the ASF's interests.  It
> is my understanding that when it's added to Apache owned SVN, ASF is
> the copyright holder of the collective work instead of an impromptu
> partnership where the individuals have no legal authority to offer a
> collective work.
> 
> Regards,
> Chris
> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
> 
> > 
> > I REALLY don't think you need a sandbox for this. We've done fine for
> >  
> > years without one, even with the recently re-done ecommerce anonymous
> >  
> > checkout process and alternative checkout processes which were  
> > developed entirely outside of OFBiz.
> > 
> > Getting this stuff done is mostly a matter of knowing what you're  
> > doing and having a clear goal to work towards, a design of sorts if  
> > you will. A sandbox won't help that.
> > 
> > Once you have a design you can start building it without touching the
> >  
> > current stuff, just make it an alternate path and don't break  
> > anything existing along the way. Once it is complete, then another  
> > patch can go in to remove the old code.
> > 
> > It's that simple. That process has been followed well over a hundred 
> > 
> > times over the life of OFBiz and even for those with commit access  
> > it's the only way to go. If you don't have commit access, it's even  
> > better because you can develop until you're stuck or out of time,  
> > then throw in a patch and have it committed without breaking anything
> >  
> > else, even if the new thing isn't working 100%.
> > 
> > -David
> > 
> > 
> > On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
> > 
> > > Hey Anil,
> > >
> > > I've begun some of this already.  I'm taking the approach of
> > passing
> > > the cart to a simple method that first checks the order type and
> > then
> > > calls a method or service that is focused on that order type.  Each
> > > order type service will call a multitude of methods/services that
> > > prepare the cart data to be entered into the datasource.
> > >
> > > I would love to collaborate on this, but because of the size, it's
> > > rather difficult to do by passing patches back and forth through
> > JIRA
> > > without having a reference point that SVN provides.  This is one of
> > > those things that the ofbiz-sandbox project would be good for, but
> > it
> > > still has a legal issue that will prevent it from being entered
> > back
> > > into the project.  I can as an individual grant Apache the license
> > it
> > > needs for the work I do, you as an individual can grant Apache the
> > > license it needs for the work you do, but without each of us
> > assuming
> > > the liability of a partnership we cannot grant a license for the
> > work
> > > as a whole.  The only way around this is to use ofbiz-sandbox SVN
> > and
> > > make patches for each commit and each of us resubmit our own patch
> > to
> > > OFBiz JIRA with the order they need to be applied in.
> > >
> > > This would be sooooo much easier if the members of OFBiz PMC would
> > > respond on including a public sandbox in Apache OFBiz as each SVN
> > > commit will be licensed to Apache, and Apache will be the owner of
> > the
> > > work as a whole instead of an impromptu partnership being the
> > owner.
> > >
> > >
> > > --- Anil Patel <to...@gmail.com> wrote:
> > >
> > >> I planning to participate in this developer conference. I am
> > >> interested in
> > >> contributing towards making Order Entry process more flexible. If
> > >> there are
> > >> Others who will be interested we can start some ground work. I
> > >> request one
> > >> of the commiters who has interest in this to Please lead this
> > effort.
> > >>
> > >> The anonymous checkout process in Ecommerce component provides
> > some
> > >> high
> > >> level guiding principals. Few things that I can think of are
> > >> 1) moving some code that's embedded in Java classes into small
> > simple
> > >> methods.
> > >> 2) Moving process control logic from event handlers to Controller
> > >> file.
> > >>
> > >> Any Ideas
> > >>
> > >> Regards
> > >> Anil Patel
> > >>
> > >> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
> > >>>
> > >>>
> > >>> NOTE: I'm just sending this to the dev list as this event is
> > meant
> > >>> mainly for those who want to be involved with development of
> > OFBiz
> > >>> itself. There will be a variety of projects going on and we hope
> > >>> everyone will be able to work on both paid and fun stuff, but the
> > >>> results will all be going right back into OFBiz. Still, everyone
> > is
> > >>> welcome to attend and join the "party" so if you know of someone
> > >> who
> > >>> might be interested but isn't subscribed to the dev mailing list,
> > >>> please forward it on to them.
> > >>>
> > >>> NOTE2: While most of this conference will be centered around
> > >>> development, if you aren't a developer it doesn't mean you can't
> > >>> come. It would be great to have, for example, people like
> > business
> > >>> analysts and technical writers to help with requirements, design,
> > >> and
> > >>> documentation and such would be great!
> > >>>
> > >>> Included below is the original email about this, and most of the
> > >>> information there is still applicable. Here are a few decisions,
> > >>> based on feedback:
> > >>>
> > >>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
> > >> and
> > >>> may spill over into Sat the 10th
> > >>>
> > >>> 2. you don't have to come for the entire conference, but we
> > >> recommend
> > >>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
> > big-group
> > >>> meetings and any presentations for Wednesday; if you can come for
> > >> the
> > >>> whole week, please do, it'll be great!
> > >>>
> > >>> 3. people are welcome to come and enjoy local attractions for the
> > >>> weekend before and/or after (it will still be cool in the area
> > >> here,
> > >>> snowy in the mountains for skiing/boarding/snowmobiling, and
> > >>> depending on weather it can be a great time for visiting the
> > >> deserts
> > >>> and canyons south of here)
> > >>>
> > >>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
> > >> will
> > >>> be $175 for the week (or $35/day) per person; we will have
> > wireless
> > >>> internet access, and I have a bridge if anyone needs wired
> > access;
> > >> we
> > >>> will have at least 2 projectors and perhaps other large monitors
> > to
> > >>> facilitate group development and discussion
> > >>>
> > >>> 5. meals, lodging, etc are not included in the main price, but
> > >> we'll
> > >>> have 5-9 rooms available in the building (for $20-30 per night,
> > >> first
> > >>> come first serve); there is a decent hotel in town as well for
> > >> around
> > >>> $80 per night (contact me for details); for meals there are
> > various
> > >>> restaurants within walking distance
> > >>>
> > >>> 6. the attendance cap is initially 20 people; there seems to be a
> > >> lot
> > >>> of interest in this, so if we go over that we'll raise it by
> > >> perhaps
> > >>> 5-10 more people and convert some other adjacent rooms in the
> > >>> building to be for group meeting use as well (we're planning on 2
> > >> big
> > >>> rooms, plus a fairly big room with a small kitchen in it)
> > >>>
> > >>> 7. the actual development goals are not finalized, but there is
> > >> quite
> > >>> a bit of interest in various things on the original list I
> > included
> > >>> (below), the big things seem to be testing infrastructure and
> > >> project
> > >>> management functionality
> > >>>
> > >>> To register (ASAP please, to make my job of planning easier!),
> > >> please
> > >>> contact me by email (jonesde@hotwaxmedia.com) with the following
> > >>> information:
> > >>>
> > >>> 1. your name, company name, contact info (phone, email if
> > different
> > >>> than from address)
> > >>> 2. how many in your group (if more than one, their names too)
> > >>> 3. plans (as much as known) for how many days and which days
> > >>> 4. lodging preference - in the building (private rooms, shared
> > >>> toilets/showers) how many rooms, or nearby hotel (I'll respond
> > with
> > >>> contact info for the nice place close by, or there is a "fleabag"
> > >>> motel place too though not sure if I'd recommend it)
> > >>> 5. snack/diet preferences
> > >>> 6. local travel plans: do you need a ride, or do you plan to
> > rent/
> > 
> === message truncated ===
> 
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

Comments inline

On Jan 26, 2007, at 10:16 AM, Daniel Kunkel wrote:

> I think I pretty much covered this in my other post, but I'll share  
> the
> few things I think could be done better.
>
> 1.) The original effort was submitted and not "lost" in the anals of
> history even though it wasn't ready for prime time.
>
> 2.) You example worked because there were a small number of people
> actively pushing something that happened rather fast, so the code did
> not get too far out of date.
>

We also ensured that it didn't get out of date by updating our  
patches as things around them changed.  And yes, it was a smaller  
group of people, so it was easier to manage.

> 3.) You apparently worked on the code one at a time, and/or worked
> together er separately to avoid any patching nightmares.
>
> I'm not saying this the jira patch system doesn't work...  I'm  
> saying I
> think we could all benefit by creating a space for people to  
> contribute
> developments that aren't ready where it would be easy for others to  
> work
> on them piecemeal.

I definitely understand your pain here Daniel.  I would just ask the  
people who have these aspirations to try the existing system and  
first see how many people you actually get on board before building  
infrastructure to manage additional TEAMS of developers.

>
> I think back and wonder how many of the developers out there worked on
> projects specific to one business or another that DID not share it  
> back
> to the community because their efforts were not in a shape that  
> could be
> committed.
>

Having your code not be in shape enough to be committed probably  
never stopped anyone who really wanted their stuff to make it into  
the project :)  Open source is great and it does often bring out the  
best and works in people - I've always just taken the constructive  
criticism of people who have a bit more experience in the project -  
and that's always worked for me.

Cheers,
Tim

> Thanks
>
> Daniel
>
>
>
> On Fri, 2007-01-26 at 08:11 -0800, Adrian Crum wrote:
>> Thanks Tim! I suggested the same method some time ago. Personally,  
>> I like the
>> idea of using existing resources.
>>
>> Just set up a Jira issue and make it clear in the initial comment  
>> that it's a
>> "sandbox" - so everyone knows you're trying out ideas in that  
>> issue. Then follow
>> Tim's flow.
>>
>> Simple.
>>
>> -Adrian
>>
>>
>> Tim Ruppert wrote:
>>> I know this sounds overly simplified, but someone please explain  
>>> to me
>>> why this doesn't work:
>>>
>>> 1. Someone - let's say Chris has a great idea for a new project
>>> 2. He creates a JIRA issue describing it
>>> 3. He attaches an initial patch
>>> 4. Someone else - let's say Daniel decides that he wants to  
>>> contribute
>>> to this effort and downloads the patch
>>> 5. He makes some improvements, so he updates the existing patch  
>>> as well
>>> as adds another patch containing additional data
>>> 6. Chris downloads it and makes some mods and reposts.
>>>
>>> Now, to me this doesn't seem that crazy - and is totally legal.   
>>> And . .
>>> . just so you know - replace Chris with Tim and Daniel with  
>>> either Anil
>>> or Ashish and you have EXACTLY what happened with the anonymous  
>>> checkout
>>> process!
>>>
>>> This shouldn't be this hard guys.  My suggestion would be to TRY  
>>> one of
>>> these in this format and if you can't do it this way - THEN let's  
>>> try
>>> and address it.  A separately maintained sandbox is absolutely no
>>> different  than managing patches - since both have to deal with
>>> integration back into the OFBiz trunk in some form or fashion.
>>>
>>> Personally, I think the patches will be EASIER to maintain  
>>> because they
>>> will allow you to make changes to existing code in an easier, more
>>> trackable format.  The alternative would be for you to maintain a
>>> sandbox - AND patches for updates to the source - doesn't that sound
>>> MORE tedious?
>>>
>>> Anyways, thanks for listening to my ramble.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
> -- 
> Daniel
>
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> Have a GREAT Day!
>
> Daniel Kunkel           DanielKunkel@BioWaves.com
> BioWaves, LLC           http://www.BioWaves.com
> 14150 NE 20th St. Suite F1
> Bellevue, WA 98007
> 800-734-3588    425-895-0050
> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> http://www.Card-Offer.com      http://www.RackWine.com
> http://www.JokesBlonde.com     http://www.Brain-Fun.com
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>

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

[Daniel Kunkel <Da...@BioWaves.com>]

I think I pretty much covered this in my other post, but I'll share the
few things I think could be done better.

1.) The original effort was submitted and not "lost" in the anals of
history even though it wasn't ready for prime time.

2.) You example worked because there were a small number of people
actively pushing something that happened rather fast, so the code did
not get too far out of date.

3.) You apparently worked on the code one at a time, and/or worked
together er separately to avoid any patching nightmares.

I'm not saying this the jira patch system doesn't work...  I'm saying I
think we could all benefit by creating a space for people to contribute
developments that aren't ready where it would be easy for others to work
on them piecemeal.

I think back and wonder how many of the developers out there worked on
projects specific to one business or another that DID not share it back
to the community because their efforts were not in a shape that could be
committed.

Thanks

Daniel



On Fri, 2007-01-26 at 08:11 -0800, Adrian Crum wrote:
> Thanks Tim! I suggested the same method some time ago. Personally, I like the 
> idea of using existing resources.
> 
> Just set up a Jira issue and make it clear in the initial comment that it's a 
> "sandbox" - so everyone knows you're trying out ideas in that issue. Then follow 
> Tim's flow.
> 
> Simple.
> 
> -Adrian
> 
> 
> Tim Ruppert wrote:
> > I know this sounds overly simplified, but someone please explain to me 
> > why this doesn't work:
> > 
> > 1. Someone - let's say Chris has a great idea for a new project
> > 2. He creates a JIRA issue describing it
> > 3. He attaches an initial patch
> > 4. Someone else - let's say Daniel decides that he wants to contribute 
> > to this effort and downloads the patch
> > 5. He makes some improvements, so he updates the existing patch as well 
> > as adds another patch containing additional data
> > 6. Chris downloads it and makes some mods and reposts.
> > 
> > Now, to me this doesn't seem that crazy - and is totally legal.  And . . 
> > . just so you know - replace Chris with Tim and Daniel with either Anil 
> > or Ashish and you have EXACTLY what happened with the anonymous checkout 
> > process!
> > 
> > This shouldn't be this hard guys.  My suggestion would be to TRY one of 
> > these in this format and if you can't do it this way - THEN let's try 
> > and address it.  A separately maintained sandbox is absolutely no 
> > different  than managing patches - since both have to deal with 
> > integration back into the OFBiz trunk in some form or fashion.  
> > 
> > Personally, I think the patches will be EASIER to maintain because they 
> > will allow you to make changes to existing code in an easier, more 
> > trackable format.  The alternative would be for you to maintain a 
> > sandbox - AND patches for updates to the source - doesn't that sound 
> > MORE tedious?
> > 
> > Anyways, thanks for listening to my ramble.
> > 
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> > 
> > o:801.649.6594
> > f:801.649.6595
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

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

[Adrian Crum <ad...@hlmksw.com>]

Thanks Tim! I suggested the same method some time ago. Personally, I like the 
idea of using existing resources.

Just set up a Jira issue and make it clear in the initial comment that it's a 
"sandbox" - so everyone knows you're trying out ideas in that issue. Then follow 
Tim's flow.

Simple.

-Adrian


Tim Ruppert wrote:
> I know this sounds overly simplified, but someone please explain to me 
> why this doesn't work:
> 
> 1. Someone - let's say Chris has a great idea for a new project
> 2. He creates a JIRA issue describing it
> 3. He attaches an initial patch
> 4. Someone else - let's say Daniel decides that he wants to contribute 
> to this effort and downloads the patch
> 5. He makes some improvements, so he updates the existing patch as well 
> as adds another patch containing additional data
> 6. Chris downloads it and makes some mods and reposts.
> 
> Now, to me this doesn't seem that crazy - and is totally legal.  And . . 
> . just so you know - replace Chris with Tim and Daniel with either Anil 
> or Ashish and you have EXACTLY what happened with the anonymous checkout 
> process!
> 
> This shouldn't be this hard guys.  My suggestion would be to TRY one of 
> these in this format and if you can't do it this way - THEN let's try 
> and address it.  A separately maintained sandbox is absolutely no 
> different  than managing patches - since both have to deal with 
> integration back into the OFBiz trunk in some form or fashion.  
> 
> Personally, I think the patches will be EASIER to maintain because they 
> will allow you to make changes to existing code in an easier, more 
> trackable format.  The alternative would be for you to maintain a 
> sandbox - AND patches for updates to the source - doesn't that sound 
> MORE tedious?
> 
> Anyways, thanks for listening to my ramble.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595

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

[Jacopo Cappellato <ti...@sastau.it>]

Jonathon -- Improov wrote:
> Tim,
> 
> For some reason I can't quite put my finger on, I am confident that I 
> can process patches to my own sandbox faster than the OFBiz committers 
> can process patches to OFBiz.
> 
> Maybe it's because I am becoming an OFBiz addict that I work on it 
> tirelessly and relentlessly? I don't know.
> 
> And also, for some reason that escapes me, my commits seem to be more 
> tested and less unsettling than some of OFBiz's.
> 
> Maybe it's because I don't have 10 paying clients to serve at once.

Indeed very amusing...

Jacopo

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

["David E. Jones" <jo...@hotwaxmedia.com>]

On Jan 26, 2007, at 11:15 AM, Jonathon -- Improov wrote:

> A common cry on JIRA: "Will somebody test this patch please? Gonna  
> commit inside of 48 hours."

Hopefully in the future we'll have people testing things before a  
committer looks at it. On a similar note, hopefully you won't see any  
more messages like the above. It's a bad practice that is hopefully  
now corrected among the committers. In short a committer should not  
commit anything if they don't know what the impact of it is and  
hasn't at least done a sanity check and code review on it.

Of course, even if a committer does a thorough review it is possible  
to miss stuff, things are just complicated that way and certain parts  
of OFBiz are still very poorly implemented and brittle, so any review  
and testing of patches or the project in general is always helpful!  
This is especially true for people testing it against real-world  
requirements and business scenarios because they'll can't things that  
no automated test can, and because it will bring up issues that  
others may not have even realized were issues.

-David

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

+1

On Jan 26, 2007, at 11:15 AM, Jonathon -- Improov wrote:

> Tim,
>
> Glad to be of help. :)
>
> Frankly, I believe that the rate at which patches are processed/ 
> audited/committed has a lot to do with us non-committers (or simply  
> interested parties) testing and reviewing those patches.
>
> A common cry on JIRA: "Will somebody test this patch please? Gonna  
> commit inside of 48 hours."
>
> Jonathon
>
> Tim Ruppert wrote:
>> Jonathon - I'm sure that you may be able to process patches VERY  
>> quickly - and that my friend, is a totally invaluable resource to  
>> have going on.  I mean please do more of them and report your  
>> findings, so that the project can move forward even more quickly.   
>> It doesn't take a committer role to be actively involved in this.  
>> You may in fact grow into a role of a committer if you continue  
>> with the project and are able to help push the project forward as  
>> much as you appear to be motivated to do.  Thanks for being here -  
>> and keep up the JIRA testing - it means A LOT to all of us.
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>> o:801.649.6594
>> f:801.649.6595
>> On Jan 26, 2007, at 10:00 AM, Jonathon -- Improov wrote:
>>> Tim,
>>>
>>> For some reason I can't quite put my finger on, I am confident  
>>> that I can process patches to my own sandbox faster than the  
>>> OFBiz committers can process patches to OFBiz.
>>>
>>> Maybe it's because I am becoming an OFBiz addict that I work on  
>>> it tirelessly and relentlessly? I don't know.
>>>
>>> And also, for some reason that escapes me, my commits seem to be  
>>> more tested and less unsettling than some of OFBiz's.
>>>
>>> Maybe it's because I don't have 10 paying clients to serve at once.
>>>
>>> Or maybe I do understand the OFBiz framework enough to be able to  
>>> do a "OFBiz-wide grep or other scan" in order to check whether my  
>>> patches break stuff. Sort of like what a good IDE will do,  
>>> probably. But I'm always stone-age, stick to simple tools (with  
>>> good mind map).
>>>
>>> There's still this need to put together stable audited releases.  
>>> I'm sort of doing that with my personal "sandbox" on my harddisk.
>>>
>>> I can't guarantee I can do the same if I'm a committer in OFBiz  
>>> myself.
>>>
>>> Jonathon
>>>
>>> Tim Ruppert wrote:
>>>> I know this sounds overly simplified, but someone please explain  
>>>> to me why this doesn't work:
>>>> 1. Someone - let's say Chris has a great idea for a new project
>>>> 2. He creates a JIRA issue describing it
>>>> 3. He attaches an initial patch
>>>> 4. Someone else - let's say Daniel decides that he wants to  
>>>> contribute to this effort and downloads the patch
>>>> 5. He makes some improvements, so he updates the existing patch  
>>>> as well as adds another patch containing additional data
>>>> 6. Chris downloads it and makes some mods and reposts.
>>>> Now, to me this doesn't seem that crazy - and is totally legal.   
>>>> And . . . just so you know - replace Chris with Tim and Daniel  
>>>> with either Anil or Ashish and you have EXACTLY what happened  
>>>> with the anonymous checkout process!
>>>> This shouldn't be this hard guys.  My suggestion would be to TRY  
>>>> one of these in this format and if you can't do it this way -  
>>>> THEN let's try and address it.  A separately maintained sandbox  
>>>> is absolutely no different  than managing patches - since both  
>>>> have to deal with integration back into the OFBiz trunk in some  
>>>> form or fashion.  Personally, I think the patches will be EASIER  
>>>> to maintain because they will allow you to make changes to  
>>>> existing code in an easier, more trackable format.  The  
>>>> alternative would be for you to maintain a sandbox - AND patches  
>>>> for updates to the source - doesn't that sound MORE tedious?
>>>> Anyways, thanks for listening to my ramble.
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>> On Jan 26, 2007, at 3:04 AM, 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  think about doing this under the ASF  
>>>>>> umbrella because I am not  willing to take on the  
>>>>>> responsibility of vetting a large number of  committers and  
>>>>>> recommending them as committers in the ASF, which is  BIG  
>>>>>> DEAL, and a responsibility and some people seem to be  
>>>>>> forgetting  that.
>>>>>>
>>>>>> If you want to be a committer you have to help with the  
>>>>>> project. You  have to take ownership of it, defend it, be  
>>>>>> committed to it, and so  on. Okay, now I'm doing what I was in  
>>>>>> the 2 page email I just deleted  and I'm stopping.
>>>>>>
>>>>>> If you want to know more about becoming and being a committer  
>>>>>> and  about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>>>>
>>>>>> I don't know WHY these questions are coming up here. Stop  
>>>>>> asking  them. Read the documents. I won't be baited into this  
>>>>>> any more. It's  a waste of time, and all based on supposition  
>>>>>> and not any real  problems or issues as far as I can see.
>>>>>>
>>>>>> If you develop something outside of OFBiz and want to  
>>>>>> contribute it,  here is the page describing how it works:
>>>>>>
>>>>>> http://incubator.apache.org/ip-clearance/index.html
>>>>>>
>>>>>> This is basically a streamlined incubation process for code  
>>>>>> going  into existing projects.
>>>>>>
>>>>>> If you really want to help and be involved in the project it  
>>>>>> means  working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it  
>>>>>> makes it  easier to get your own stuff in but if that is all  
>>>>>> you're about  related to the project, then being a committer  
>>>>>> isn't for you.
>>>>>>
>>>>>> If you want to know more about contributing and being a  
>>>>>> committer,  read the docs:
>>>>>>
>>>>>> http://docs.ofbiz.org/x/mQ
>>>>>> http://docs.ofbiz.org/x/r
>>>>>>
>>>>>> If you want to know more about licensing and legal issues,  
>>>>>> read the  docs:
>>>>>>
>>>>>> http://incubator.apache.org/incubation/Incubation_Policy.html
>>>>>> http://incubator.apache.org/ip-clearance/index.html
>>>>>> http://www.apache.org/foundation/how-it-works.html
>>>>>> http://www.apache.org/foundation/licence-FAQ.html
>>>>>> http://www.apache.org/legal/src-headers.html
>>>>>>
>>>>>> For a lot of good information, broaden the scope and study under:
>>>>>>
>>>>>> http://www.apache.org/dev/
>>>>>>
>>>>>> These were not written because someone was looking for some   
>>>>>> entertainment. They were written so things wouldn't have to  
>>>>>> be  explained over and over.
>>>>>>
>>>>>> I'm calling it a day now, as soon as I take care of some real  
>>>>>> issues,  and as long as my son with the flu doesn't throw up  
>>>>>> again. Sorry,  this is really frustrating, and really silly.  
>>>>>> Reality sucks, but we  all have to live with it.
>>>>>>
>>>>>> If people want to help, then help. Don't just ask for help.  
>>>>>> Start by  being a giver, not a taker.
>>>>>>
>>>>>> If this sounds a bit harsh, great! Go for a walk and think  
>>>>>> about how  things work in real life, then read it again. If  
>>>>>> you're still upset,  read it again. Then go read all of the  
>>>>>> documents referenced. Then if  you still have a question, send  
>>>>>> it on in, but PLEASE try to look at  it from the point of a  
>>>>>> MEMBER of the OFBiz community, and not a user  of OFBiz who  
>>>>>> really doesn't want to get involved.
>>>>>>
>>>>>> If you're asking "how are you going to solve this problem"  
>>>>>> then  you're asking the wrong question. If you want to  
>>>>>> participate as "how  can I solve this problem", if "I" can't,  
>>>>>> then do with "how can we  solve this problem". I don't mean  
>>>>>> that is what should be in your  email, I mean that is what  
>>>>>> should be in your head. If you can't find  an answer yourself  
>>>>>> that is 100% okay, just start a discussion and  accept what  
>>>>>> you asked for.
>>>>>>
>>>>>> If you don't like the answer explain why it doesn't work for  
>>>>>> you,  which brings us back to the beginning of this email...
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> Can you explain your reticence to adding an Apache OFBiz  
>>>>>>> sandbox where
>>>>>>> more members of the community could share their work?
>>>>>>>
>>>>>>> I can see this section possibly getting a disorganized over  
>>>>>>> time with
>>>>>>> *junk*... but it can be deleted easily enough. As a top level  
>>>>>>> project
>>>>>>> would it possible and better to organize a sub project for this?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>>>>> I think we're talking about two different things.  You're  
>>>>>>>> talking  about
>>>>>>>> developing and I'm talking about legal issues.  The manner of
>>>>>>>> developing was already discussed in OFBIZ-499.  The only  
>>>>>>>> legal way to
>>>>>>>> use JIRA to collaborate this type of thing is to keep  
>>>>>>>> sending updated
>>>>>>>> patches to JIRA or to have a committer review and add it to a
>>>>>>>> specialized application.  Neither one of these is speed of   
>>>>>>>> development
>>>>>>>> friendly.
>>>>>>>>
>>>>>>>> Legal concerns wouldn't have been one of the primary  
>>>>>>>> driving  forces of
>>>>>>>> moving to the ASF if it were true that "we've done fine for  
>>>>>>>> years".
>>>>>>>> The project still has technical exposure to a C & D order as  
>>>>>>>> the CLA
>>>>>>>> only covered works the copyright holder gave directly to the  
>>>>>>>> ASF not
>>>>>>>> the works the copyright holder gave to the OFBIZ project  
>>>>>>>> prior to
>>>>>>>> incubation.  IANAL, and I don't think there is significant  
>>>>>>>> exposure,
>>>>>>>> but it is still there. That opinion isn't based on the  
>>>>>>>> vehicle  used to
>>>>>>>> create Apache OFBiz, but on the impression of  
>>>>>>>> kindheartedness from  the
>>>>>>>> members of the community prior to incubation.
>>>>>>>>
>>>>>>>> I don't want to speculate on the legal relationship the  
>>>>>>>> group that
>>>>>>>> worked on the anon checkout had, but I would suspect that  
>>>>>>>> it  generated
>>>>>>>> some negative legal exposure as well and that the proposed  
>>>>>>>> setup of
>>>>>>>> Developers Conference will add to that.
>>>>>>>>
>>>>>>>> The only feedback that I've received from the general  
>>>>>>>> incubator list
>>>>>>>> are speculations, all with the caveat that the poster is not  
>>>>>>>> a lawyer
>>>>>>>> either and no one has been willing to post it to the legal- 
>>>>>>>> discuss
>>>>>>>> list.
>>>>>>>>
>>>>>>>> This issue is one of the MAJOR reasons for the existence of  
>>>>>>>> non- profit
>>>>>>>> entities like the ASF, FSF, and SPI.  So again, I ask you  
>>>>>>>> to  reconsider
>>>>>>>> the need of a more public sandbox where this kind of community
>>>>>>>> collaboration can be done without the complications of  
>>>>>>>> copyright
>>>>>>>> infringement, or at the very least pose the question to  
>>>>>>>> legal-discuss
>>>>>>>> for a formal opinion from those representing the ASF's  
>>>>>>>> interests.  It
>>>>>>>> is my understanding that when it's added to Apache owned  
>>>>>>>> SVN, ASF is
>>>>>>>> the copyright holder of the collective work instead of an  
>>>>>>>> impromptu
>>>>>>>> partnership where the individuals have no legal authority to  
>>>>>>>> offer a
>>>>>>>> collective work.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Chris
>>>>>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com  
>>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I REALLY don't think you need a sandbox for this. We've  
>>>>>>>>> done fine  for
>>>>>>>>>
>>>>>>>>> years without one, even with the recently re-done  
>>>>>>>>> ecommerce  anonymous
>>>>>>>>>
>>>>>>>>> checkout process and alternative checkout processes which were
>>>>>>>>> developed entirely outside of OFBiz.
>>>>>>>>>
>>>>>>>>> Getting this stuff done is mostly a matter of knowing what  
>>>>>>>>> you're
>>>>>>>>> doing and having a clear goal to work towards, a design of  
>>>>>>>>> sorts if
>>>>>>>>> you will. A sandbox won't help that.
>>>>>>>>>
>>>>>>>>> Once you have a design you can start building it without  
>>>>>>>>> touching  the
>>>>>>>>>
>>>>>>>>> current stuff, just make it an alternate path and don't break
>>>>>>>>> anything existing along the way. Once it is complete, then  
>>>>>>>>> another
>>>>>>>>> patch can go in to remove the old code.
>>>>>>>>>
>>>>>>>>> It's that simple. That process has been followed well over  
>>>>>>>>> a hundred
>>>>>>>>>
>>>>>>>>> times over the life of OFBiz and even for those with commit  
>>>>>>>>> access
>>>>>>>>> it's the only way to go. If you don't have commit access,  
>>>>>>>>> it's even
>>>>>>>>> better because you can develop until you're stuck or out of  
>>>>>>>>> time,
>>>>>>>>> then throw in a patch and have it committed without  
>>>>>>>>> breaking  anything
>>>>>>>>>
>>>>>>>>> else, even if the new thing isn't working 100%.
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>>>>
>>>>>>>>>> Hey Anil,
>>>>>>>>>>
>>>>>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>>>>>> passing
>>>>>>>>>> the cart to a simple method that first checks the order  
>>>>>>>>>> type and
>>>>>>>>> then
>>>>>>>>>> calls a method or service that is focused on that order  
>>>>>>>>>> type.  Each
>>>>>>>>>> order type service will call a multitude of methods/ 
>>>>>>>>>> services that
>>>>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>>>>
>>>>>>>>>> I would love to collaborate on this, but because of the  
>>>>>>>>>> size, it's
>>>>>>>>>> rather difficult to do by passing patches back and forth  
>>>>>>>>>> through
>>>>>>>>> JIRA
>>>>>>>>>> without having a reference point that SVN provides.  This  
>>>>>>>>>> is one of
>>>>>>>>>> those things that the ofbiz-sandbox project would be good  
>>>>>>>>>> for, but
>>>>>>>>> it
>>>>>>>>>> still has a legal issue that will prevent it from being  
>>>>>>>>>> entered
>>>>>>>>> back
>>>>>>>>>> into the project.  I can as an individual grant Apache the  
>>>>>>>>>> license
>>>>>>>>> it
>>>>>>>>>> needs for the work I do, you as an individual can grant  
>>>>>>>>>> Apache the
>>>>>>>>>> license it needs for the work you do, but without each of us
>>>>>>>>> assuming
>>>>>>>>>> the liability of a partnership we cannot grant a license  
>>>>>>>>>> for the
>>>>>>>>> work
>>>>>>>>>> as a whole.  The only way around this is to use ofbiz- 
>>>>>>>>>> sandbox SVN
>>>>>>>>> and
>>>>>>>>>> make patches for each commit and each of us resubmit our  
>>>>>>>>>> own patch
>>>>>>>>> to
>>>>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>>>>
>>>>>>>>>> This would be sooooo much easier if the members of OFBiz  
>>>>>>>>>> PMC would
>>>>>>>>>> respond on including a public sandbox in Apache OFBiz as  
>>>>>>>>>> each SVN
>>>>>>>>>> commit will be licensed to Apache, and Apache will be the  
>>>>>>>>>> owner of
>>>>>>>>> the
>>>>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>>>>> owner.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --- Anil Patel <toanilpatel@gmail.com  
>>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>>>>> interested in
>>>>>>>>>>> contributing towards making Order Entry process more  
>>>>>>>>>>> flexible. If
>>>>>>>>>>> there are
>>>>>>>>>>> Others who will be interested we can start some ground  
>>>>>>>>>>> work. I
>>>>>>>>>>> request one
>>>>>>>>>>> of the commiters who has interest in this to Please lead  
>>>>>>>>>>> this
>>>>>>>>> effort.
>>>>>>>>>>>
>>>>>>>>>>> The anonymous checkout process in Ecommerce component  
>>>>>>>>>>> provides
>>>>>>>>> some
>>>>>>>>>>> high
>>>>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>>>>> 1) moving some code that's embedded in Java classes into  
>>>>>>>>>>> small
>>>>>>>>> simple
>>>>>>>>>>> methods.
>>>>>>>>>>> 2) Moving process control logic from event handlers to  
>>>>>>>>>>> Controller
>>>>>>>>>>> file.
>>>>>>>>>>>
>>>>>>>>>>> Any Ideas
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Anil Patel
>>>>>>>>>>>
>>>>>>>>>>> On 1/16/07, David E. Jones <jonesde@hotwaxmedia.com  
>>>>>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> NOTE: I'm just sending this to the dev list as this  
>>>>>>>>>>>> event is
>>>>>>>>> meant
>>>>>>>>>>>> mainly for those who want to be involved with  
>>>>>>>>>>>> development of
>>>>>>>>> OFBiz
>>>>>>>>>>>> itself. There will be a variety of projects going on and  
>>>>>>>>>>>> we hope
>>>>>>>>>>>> everyone will be able to work on both paid and fun  
>>>>>>>>>>>> stuff, but the
>>>>>>>>>>>> results will all be going right back into OFBiz. Still,  
>>>>>>>>>>>> everyone
>>>>>>>>> is
>>>>>>>>>>>> welcome to attend and join the "party" so if you know of  
>>>>>>>>>>>> someone
>>>>>>>>>>> who
>>>>>>>>>>>> might be interested but isn't subscribed to the dev  
>>>>>>>>>>>> mailing list,
>>>>>>>>>>>> please forward it on to them.
>>>>>>>>>>>>
>>>>>>>>>>>> NOTE2: While most of this conference will be centered  
>>>>>>>>>>>> around
>>>>>>>>>>>> development, if you aren't a developer it doesn't mean  
>>>>>>>>>>>> you can't
>>>>>>>>>>>> come. It would be great to have, for example, people like
>>>>>>>>> business
>>>>>>>>>>>> analysts and technical writers to help with  
>>>>>>>>>>>> requirements, design,
>>>>>>>>>>> and
>>>>>>>>>>>> documentation and such would be great!
>>>>>>>>>>>>
>>>>>>>>>>>> Included below is the original email about this, and  
>>>>>>>>>>>> most of the
>>>>>>>>>>>> information there is still applicable. Here are a few  
>>>>>>>>>>>> decisions,
>>>>>>>>>>>> based on feedback:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday -  
>>>>>>>>>>>> Friday),
>>>>>>>>>>> and
>>>>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>>>>
>>>>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>>>>> recommend
>>>>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>>>>> big-group
>>>>>>>>>>>> meetings and any presentations for Wednesday; if you can  
>>>>>>>>>>>> come for
>>>>>>>>>>> the
>>>>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>>>>
>>>>>>>>>>>> 3. people are welcome to come and enjoy local  
>>>>>>>>>>>> attractions for the
>>>>>>>>>>>> weekend before and/or after (it will still be cool in  
>>>>>>>>>>>> the area
>>>>>>>>>>> here,
>>>>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling,  
>>>>>>>>>>>> and
>>>>>>>>>>>> depending on weather it can be a great time for visiting  
>>>>>>>>>>>> the
>>>>>>>>>>> deserts
>>>>>>>>>>>> and canyons south of here)
>>>>>>>>>>>>
>>>>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra  
>>>>>>>>>>>> stuff, etc
>>>>>>>>>>> will
>>>>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>>>>> wireless
>>>>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>>>>> access;
>>>>>>>>>>> we
>>>>>>>>>>>> will have at least 2 projectors and perhaps other large  
>>>>>>>>>>>> monitors
>>>>>>>>> to
>>>>>>>>>>>> facilitate group development and discussion
>>>>>>>>>>>>
>>>>>>>>>>>> 5. meals, lodging, etc are not included in the main  
>>>>>>>>>>>> price, but
>>>>>>>>>>> we'll
>>>>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per  
>>>>>>>>>>>> night,
>>>>>>>>>>> first
>>>>>>>>>>>> come first serve); there is a decent hotel in town as  
>>>>>>>>>>>> well for
>>>>>>>>>>> around
>>>>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>>>>> various
>>>>>>>>>>>> restaurants within walking distance
>>>>>>>>>>>>
>>>>>>>>>>>> 6. the attendance cap is initially 20 people; there  
>>>>>>>>>>>> seems to be a
>>>>>>>>>>> lot
>>>>>>>>>>>> of interest in this, so if we go over that we'll raise  
>>>>>>>>>>>> it by
>>>>>>>>>>> perhaps
>>>>>>>>>>>> 5-10 more people and convert some other adjacent rooms  
>>>>>>>>>>>> in the
>>>>>>>>>>>> building to be for group meeting use as well (we're  
>>>>>>>>>>>> planning on 2
>>>>>>>>>>> big
>>>>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>>>>
>>>>>>>>>>>> 7. the actual development goals are not finalized, but  
>>>>>>>>>>>> there is
>>>>>>>>>>> quite
>>>>>>>>>>>> a bit of interest in various things on the original list I
>>>>>>>>> included
>>>>>>>>>>>> (below), the big things seem to be testing  
>>>>>>>>>>>> infrastructure and
>>>>>>>>>>> project
>>>>>>>>>>>> management functionality
>>>>>>>>>>>>
>>>>>>>>>>>> To register (ASAP please, to make my job of planning  
>>>>>>>>>>>> easier!),
>>>>>>>>>>> please
>>>>>>>>>>>> contact me by email (jonesde@hotwaxmedia.com  
>>>>>>>>>>>> <ma...@hotwaxmedia.com>) with the following
>>>>>>>>>>>> information:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>>>>> different
>>>>>>>>>>>> than from address)
>>>>>>>>>>>> 2. how many in your group (if more than one, their names  
>>>>>>>>>>>> too)
>>>>>>>>>>>> 3. plans (as much as known) for how many days and which  
>>>>>>>>>>>> days
>>>>>>>>>>>> 4. lodging preference - in the building (private rooms,  
>>>>>>>>>>>> shared
>>>>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll  
>>>>>>>>>>>> respond
>>>>>>>>> with
>>>>>>>>>>>> contact info for the nice place close by, or there is a  
>>>>>>>>>>>> "fleabag"
>>>>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>>>>> 5. snack/diet preferences
>>>>>>>>>>>> 6. local travel plans: do you need a ride, or do you  
>>>>>>>>>>>> plan to
>>>>>>>>> rent/
>>>>>>>>>
>>>>>>>> === message truncated ===
>>>>>>>>
>>>>>>> -- 
>>>>>>> Daniel
>>>>>>>
>>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.- 
>>>>>>> *"*-
>>>>>>> Have a GREAT Day!
>>>>>>>
>>>>>>> Daniel Kunkel           DanielKunkel@BioWaves.com  
>>>>>>> <ma...@BioWaves.com>
>>>>>>> BioWaves, LLC           http://www.BioWaves.com
>>>>>>> 14150 NE 20th St. Suite F1
>>>>>>> Bellevue, WA 98007
>>>>>>> 800-734-3588    425-895-0050
>>>>>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>>>>>> http://www.Card-Offer.com      http://www.RackWine.com
>>>>>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.- 
>>>>>>> *"*-
>>>>>>>
>>>>>>
>>>>>
>>>
>

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

["David E. Jones" <jo...@hotwaxmedia.com>]

On Jan 26, 2007, at 11:15 AM, Jonathon -- Improov wrote:

> Frankly, I believe that the rate at which patches are processed/ 
> audited/committed has a lot to do with us non-committers (or simply  
> interested parties) testing and reviewing those patches.

A big problem here is that we as a PMC are way behind on adding new  
committers. This is mostly because with the recent work load of  
finalizing incubation, graduating, and migrating to the new  
infrastructure has soaked up most of the PMC free time in the last  
couple of months (along with the oft-lamented excess of  
contracts... ;) ).

In any case, we HAVE been working on this and selected half a dozen  
people we'd like to invite as committers about two months ago. We  
should be getting to this soon, and hopefully that will help solve  
the problem of the issue back log.

Still, invited as committers or not we still always need help  
reviewing and testing patches and offering feedback. This is  
EXTREMELY helpful!

-David

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

[Jonathon -- Improov <jo...@improov.com>]

Tim,

Glad to be of help. :)

Frankly, I believe that the rate at which patches are processed/audited/committed has a lot to do 
with us non-committers (or simply interested parties) testing and reviewing those patches.

A common cry on JIRA: "Will somebody test this patch please? Gonna commit inside of 48 hours."

Jonathon

Tim Ruppert wrote:
> Jonathon - I'm sure that you may be able to process patches VERY quickly 
> - and that my friend, is a totally invaluable resource to have going 
> on.  I mean please do more of them and report your findings, so that the 
> project can move forward even more quickly.  It doesn't take a committer 
> role to be actively involved in this. 
> 
> You may in fact grow into a role of a committer if you continue with the 
> project and are able to help push the project forward as much as you 
> appear to be motivated to do.  Thanks for being here - and keep up the 
> JIRA testing - it means A LOT to all of us.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> On Jan 26, 2007, at 10:00 AM, Jonathon -- Improov wrote:
> 
>> Tim,
>>
>> For some reason I can't quite put my finger on, I am confident that I 
>> can process patches to my own sandbox faster than the OFBiz committers 
>> can process patches to OFBiz.
>>
>> Maybe it's because I am becoming an OFBiz addict that I work on it 
>> tirelessly and relentlessly? I don't know.
>>
>> And also, for some reason that escapes me, my commits seem to be more 
>> tested and less unsettling than some of OFBiz's.
>>
>> Maybe it's because I don't have 10 paying clients to serve at once.
>>
>> Or maybe I do understand the OFBiz framework enough to be able to do a 
>> "OFBiz-wide grep or other scan" in order to check whether my patches 
>> break stuff. Sort of like what a good IDE will do, probably. But I'm 
>> always stone-age, stick to simple tools (with good mind map).
>>
>> There's still this need to put together stable audited releases. I'm 
>> sort of doing that with my personal "sandbox" on my harddisk.
>>
>> I can't guarantee I can do the same if I'm a committer in OFBiz myself.
>>
>> Jonathon
>>
>> Tim Ruppert wrote:
>>> I know this sounds overly simplified, but someone please explain to 
>>> me why this doesn't work:
>>> 1. Someone - let's say Chris has a great idea for a new project
>>> 2. He creates a JIRA issue describing it
>>> 3. He attaches an initial patch
>>> 4. Someone else - let's say Daniel decides that he wants to 
>>> contribute to this effort and downloads the patch
>>> 5. He makes some improvements, so he updates the existing patch as 
>>> well as adds another patch containing additional data
>>> 6. Chris downloads it and makes some mods and reposts.
>>> Now, to me this doesn't seem that crazy - and is totally legal.  And 
>>> . . . just so you know - replace Chris with Tim and Daniel with 
>>> either Anil or Ashish and you have EXACTLY what happened with the 
>>> anonymous checkout process!
>>> This shouldn't be this hard guys.  My suggestion would be to TRY one 
>>> of these in this format and if you can't do it this way - THEN let's 
>>> try and address it.  A separately maintained sandbox is absolutely no 
>>> different  than managing patches - since both have to deal with 
>>> integration back into the OFBiz trunk in some form or fashion.  
>>> Personally, I think the patches will be EASIER to maintain because 
>>> they will allow you to make changes to existing code in an easier, 
>>> more trackable format.  The alternative would be for you to maintain 
>>> a sandbox - AND patches for updates to the source - doesn't that 
>>> sound MORE tedious?
>>> Anyways, thanks for listening to my ramble.
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>> o:801.649.6594
>>> f:801.649.6595
>>> On Jan 26, 2007, at 3:04 AM, 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  think about doing this under the ASF umbrella because I am 
>>>>> not  willing to take on the responsibility of vetting a large 
>>>>> number of  committers and recommending them as committers in the 
>>>>> ASF, which is  BIG DEAL, and a responsibility and some people seem 
>>>>> to be forgetting  that.
>>>>>
>>>>> If you want to be a committer you have to help with the project. 
>>>>> You  have to take ownership of it, defend it, be committed to it, 
>>>>> and so  on. Okay, now I'm doing what I was in the 2 page email I 
>>>>> just deleted  and I'm stopping.
>>>>>
>>>>> If you want to know more about becoming and being a committer and  
>>>>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>>>
>>>>> I don't know WHY these questions are coming up here. Stop asking  
>>>>> them. Read the documents. I won't be baited into this any more. 
>>>>> It's  a waste of time, and all based on supposition and not any 
>>>>> real  problems or issues as far as I can see.
>>>>>
>>>>> If you develop something outside of OFBiz and want to contribute 
>>>>> it,  here is the page describing how it works:
>>>>>
>>>>> http://incubator.apache.org/ip-clearance/index.html
>>>>>
>>>>> This is basically a streamlined incubation process for code going  
>>>>> into existing projects.
>>>>>
>>>>> If you really want to help and be involved in the project it means  
>>>>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
>>>>> easier to get your own stuff in but if that is all you're about  
>>>>> related to the project, then being a committer isn't for you.
>>>>>
>>>>> If you want to know more about contributing and being a committer,  
>>>>> read the docs:
>>>>>
>>>>> http://docs.ofbiz.org/x/mQ
>>>>> http://docs.ofbiz.org/x/r
>>>>>
>>>>> If you want to know more about licensing and legal issues, read 
>>>>> the  docs:
>>>>>
>>>>> http://incubator.apache.org/incubation/Incubation_Policy.html
>>>>> http://incubator.apache.org/ip-clearance/index.html
>>>>> http://www.apache.org/foundation/how-it-works.html
>>>>> http://www.apache.org/foundation/licence-FAQ.html
>>>>> http://www.apache.org/legal/src-headers.html
>>>>>
>>>>> For a lot of good information, broaden the scope and study under:
>>>>>
>>>>> http://www.apache.org/dev/
>>>>>
>>>>> These were not written because someone was looking for some  
>>>>> entertainment. They were written so things wouldn't have to be  
>>>>> explained over and over.
>>>>>
>>>>> I'm calling it a day now, as soon as I take care of some real 
>>>>> issues,  and as long as my son with the flu doesn't throw up again. 
>>>>> Sorry,  this is really frustrating, and really silly. Reality 
>>>>> sucks, but we  all have to live with it.
>>>>>
>>>>> If people want to help, then help. Don't just ask for help. Start 
>>>>> by  being a giver, not a taker.
>>>>>
>>>>> If this sounds a bit harsh, great! Go for a walk and think about 
>>>>> how  things work in real life, then read it again. If you're still 
>>>>> upset,  read it again. Then go read all of the documents 
>>>>> referenced. Then if  you still have a question, send it on in, but 
>>>>> PLEASE try to look at  it from the point of a MEMBER of the OFBiz 
>>>>> community, and not a user  of OFBiz who really doesn't want to get 
>>>>> involved.
>>>>>
>>>>> If you're asking "how are you going to solve this problem" then  
>>>>> you're asking the wrong question. If you want to participate as 
>>>>> "how  can I solve this problem", if "I" can't, then do with "how 
>>>>> can we  solve this problem". I don't mean that is what should be in 
>>>>> your  email, I mean that is what should be in your head. If you 
>>>>> can't find  an answer yourself that is 100% okay, just start a 
>>>>> discussion and  accept what you asked for.
>>>>>
>>>>> If you don't like the answer explain why it doesn't work for you,  
>>>>> which brings us back to the beginning of this email...
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>>>
>>>>>> David
>>>>>>
>>>>>> Can you explain your reticence to adding an Apache OFBiz sandbox where
>>>>>> more members of the community could share their work?
>>>>>>
>>>>>> I can see this section possibly getting a disorganized over time with
>>>>>> *junk*... but it can be deleted easily enough. As a top level project
>>>>>> would it possible and better to organize a sub project for this?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>>>> I think we're talking about two different things.  You're 
>>>>>>> talking  about
>>>>>>> developing and I'm talking about legal issues.  The manner of
>>>>>>> developing was already discussed in OFBIZ-499.  The only legal way to
>>>>>>> use JIRA to collaborate this type of thing is to keep sending updated
>>>>>>> patches to JIRA or to have a committer review and add it to a
>>>>>>> specialized application.  Neither one of these is speed of  
>>>>>>> development
>>>>>>> friendly.
>>>>>>>
>>>>>>> Legal concerns wouldn't have been one of the primary driving  
>>>>>>> forces of
>>>>>>> moving to the ASF if it were true that "we've done fine for years".
>>>>>>> The project still has technical exposure to a C & D order as the CLA
>>>>>>> only covered works the copyright holder gave directly to the ASF not
>>>>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>>>>> incubation.  IANAL, and I don't think there is significant exposure,
>>>>>>> but it is still there. That opinion isn't based on the vehicle  
>>>>>>> used to
>>>>>>> create Apache OFBiz, but on the impression of kindheartedness 
>>>>>>> from  the
>>>>>>> members of the community prior to incubation.
>>>>>>>
>>>>>>> I don't want to speculate on the legal relationship the group that
>>>>>>> worked on the anon checkout had, but I would suspect that it  
>>>>>>> generated
>>>>>>> some negative legal exposure as well and that the proposed setup of
>>>>>>> Developers Conference will add to that.
>>>>>>>
>>>>>>> The only feedback that I've received from the general incubator list
>>>>>>> are speculations, all with the caveat that the poster is not a lawyer
>>>>>>> either and no one has been willing to post it to the legal-discuss
>>>>>>> list.
>>>>>>>
>>>>>>> This issue is one of the MAJOR reasons for the existence of non- 
>>>>>>> profit
>>>>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to  
>>>>>>> reconsider
>>>>>>> the need of a more public sandbox where this kind of community
>>>>>>> collaboration can be done without the complications of copyright
>>>>>>> infringement, or at the very least pose the question to legal-discuss
>>>>>>> for a formal opinion from those representing the ASF's interests.  It
>>>>>>> is my understanding that when it's added to Apache owned SVN, ASF is
>>>>>>> the copyright holder of the collective work instead of an impromptu
>>>>>>> partnership where the individuals have no legal authority to offer a
>>>>>>> collective work.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Chris
>>>>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com 
>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I REALLY don't think you need a sandbox for this. We've done 
>>>>>>>> fine  for
>>>>>>>>
>>>>>>>> years without one, even with the recently re-done ecommerce  
>>>>>>>> anonymous
>>>>>>>>
>>>>>>>> checkout process and alternative checkout processes which were
>>>>>>>> developed entirely outside of OFBiz.
>>>>>>>>
>>>>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>>>>> doing and having a clear goal to work towards, a design of sorts if
>>>>>>>> you will. A sandbox won't help that.
>>>>>>>>
>>>>>>>> Once you have a design you can start building it without 
>>>>>>>> touching  the
>>>>>>>>
>>>>>>>> current stuff, just make it an alternate path and don't break
>>>>>>>> anything existing along the way. Once it is complete, then another
>>>>>>>> patch can go in to remove the old code.
>>>>>>>>
>>>>>>>> It's that simple. That process has been followed well over a hundred
>>>>>>>>
>>>>>>>> times over the life of OFBiz and even for those with commit access
>>>>>>>> it's the only way to go. If you don't have commit access, it's even
>>>>>>>> better because you can develop until you're stuck or out of time,
>>>>>>>> then throw in a patch and have it committed without breaking  
>>>>>>>> anything
>>>>>>>>
>>>>>>>> else, even if the new thing isn't working 100%.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>>>
>>>>>>>>> Hey Anil,
>>>>>>>>>
>>>>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>>>>> passing
>>>>>>>>> the cart to a simple method that first checks the order type and
>>>>>>>> then
>>>>>>>>> calls a method or service that is focused on that order type.  Each
>>>>>>>>> order type service will call a multitude of methods/services that
>>>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>>>
>>>>>>>>> I would love to collaborate on this, but because of the size, it's
>>>>>>>>> rather difficult to do by passing patches back and forth through
>>>>>>>> JIRA
>>>>>>>>> without having a reference point that SVN provides.  This is one of
>>>>>>>>> those things that the ofbiz-sandbox project would be good for, but
>>>>>>>> it
>>>>>>>>> still has a legal issue that will prevent it from being entered
>>>>>>>> back
>>>>>>>>> into the project.  I can as an individual grant Apache the license
>>>>>>>> it
>>>>>>>>> needs for the work I do, you as an individual can grant Apache the
>>>>>>>>> license it needs for the work you do, but without each of us
>>>>>>>> assuming
>>>>>>>>> the liability of a partnership we cannot grant a license for the
>>>>>>>> work
>>>>>>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>>>>>>> and
>>>>>>>>> make patches for each commit and each of us resubmit our own patch
>>>>>>>> to
>>>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>>>
>>>>>>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>>>>> commit will be licensed to Apache, and Apache will be the owner of
>>>>>>>> the
>>>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>>>> owner.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --- Anil Patel <toanilpatel@gmail.com 
>>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>>>> interested in
>>>>>>>>>> contributing towards making Order Entry process more flexible. If
>>>>>>>>>> there are
>>>>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>>>>> request one
>>>>>>>>>> of the commiters who has interest in this to Please lead this
>>>>>>>> effort.
>>>>>>>>>>
>>>>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>>>>> some
>>>>>>>>>> high
>>>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>>>>> simple
>>>>>>>>>> methods.
>>>>>>>>>> 2) Moving process control logic from event handlers to Controller
>>>>>>>>>> file.
>>>>>>>>>>
>>>>>>>>>> Any Ideas
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Anil Patel
>>>>>>>>>>
>>>>>>>>>> On 1/16/07, David E. Jones <jonesde@hotwaxmedia.com 
>>>>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>>>>> meant
>>>>>>>>>>> mainly for those who want to be involved with development of
>>>>>>>> OFBiz
>>>>>>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>>>>>>> results will all be going right back into OFBiz. Still, everyone
>>>>>>>> is
>>>>>>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>>>>>>> who
>>>>>>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>>>>>>> please forward it on to them.
>>>>>>>>>>>
>>>>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>>>>>>> come. It would be great to have, for example, people like
>>>>>>>> business
>>>>>>>>>>> analysts and technical writers to help with requirements, design,
>>>>>>>>>> and
>>>>>>>>>>> documentation and such would be great!
>>>>>>>>>>>
>>>>>>>>>>> Included below is the original email about this, and most of the
>>>>>>>>>>> information there is still applicable. Here are a few decisions,
>>>>>>>>>>> based on feedback:
>>>>>>>>>>>
>>>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>>>>>>> and
>>>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>>>
>>>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>>>> recommend
>>>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>>>> big-group
>>>>>>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>>>>>>> the
>>>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>>>
>>>>>>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>>>>> here,
>>>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>>>>> deserts
>>>>>>>>>>> and canyons south of here)
>>>>>>>>>>>
>>>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>>>>>>> will
>>>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>>>> wireless
>>>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>>>> access;
>>>>>>>>>> we
>>>>>>>>>>> will have at least 2 projectors and perhaps other large monitors
>>>>>>>> to
>>>>>>>>>>> facilitate group development and discussion
>>>>>>>>>>>
>>>>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>>>>> we'll
>>>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>>>>> first
>>>>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>>>>> around
>>>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>>>> various
>>>>>>>>>>> restaurants within walking distance
>>>>>>>>>>>
>>>>>>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>>>>>>> lot
>>>>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>>>>> perhaps
>>>>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>>>>>>> big
>>>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>>>
>>>>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>>>>> quite
>>>>>>>>>>> a bit of interest in various things on the original list I
>>>>>>>> included
>>>>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>>>>> project
>>>>>>>>>>> management functionality
>>>>>>>>>>>
>>>>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>>>>> please
>>>>>>>>>>> contact me by email (jonesde@hotwaxmedia.com 
>>>>>>>>>>> <ma...@hotwaxmedia.com>) with the following
>>>>>>>>>>> information:
>>>>>>>>>>>
>>>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>>>> different
>>>>>>>>>>> than from address)
>>>>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>>>>> with
>>>>>>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>>>> 5. snack/diet preferences
>>>>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>>>>> rent/
>>>>>>>>
>>>>>>> === message truncated ===
>>>>>>>
>>>>>> -- 
>>>>>> Daniel
>>>>>>
>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>>> Have a GREAT Day!
>>>>>>
>>>>>> Daniel Kunkel           DanielKunkel@BioWaves.com 
>>>>>> <ma...@BioWaves.com>
>>>>>> BioWaves, LLC           http://www.BioWaves.com
>>>>>> 14150 NE 20th St. Suite F1
>>>>>> Bellevue, WA 98007
>>>>>> 800-734-3588    425-895-0050
>>>>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>>>>> http://www.Card-Offer.com      http://www.RackWine.com
>>>>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>>>
>>>>>
>>>>
>>
> 

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

Jonathon - I'm sure that you may be able to process patches VERY  
quickly - and that my friend, is a totally invaluable resource to  
have going on.  I mean please do more of them and report your  
findings, so that the project can move forward even more quickly.  It  
doesn't take a committer role to be actively involved in this.

You may in fact grow into a role of a committer if you continue with  
the project and are able to help push the project forward as much as  
you appear to be motivated to do.  Thanks for being here - and keep  
up the JIRA testing - it means A LOT to all of us.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 26, 2007, at 10:00 AM, Jonathon -- Improov wrote:

> Tim,
>
> For some reason I can't quite put my finger on, I am confident that  
> I can process patches to my own sandbox faster than the OFBiz  
> committers can process patches to OFBiz.
>
> Maybe it's because I am becoming an OFBiz addict that I work on it  
> tirelessly and relentlessly? I don't know.
>
> And also, for some reason that escapes me, my commits seem to be  
> more tested and less unsettling than some of OFBiz's.
>
> Maybe it's because I don't have 10 paying clients to serve at once.
>
> Or maybe I do understand the OFBiz framework enough to be able to  
> do a "OFBiz-wide grep or other scan" in order to check whether my  
> patches break stuff. Sort of like what a good IDE will do,  
> probably. But I'm always stone-age, stick to simple tools (with  
> good mind map).
>
> There's still this need to put together stable audited releases.  
> I'm sort of doing that with my personal "sandbox" on my harddisk.
>
> I can't guarantee I can do the same if I'm a committer in OFBiz  
> myself.
>
> Jonathon
>
> Tim Ruppert wrote:
>> I know this sounds overly simplified, but someone please explain  
>> to me why this doesn't work:
>> 1. Someone - let's say Chris has a great idea for a new project
>> 2. He creates a JIRA issue describing it
>> 3. He attaches an initial patch
>> 4. Someone else - let's say Daniel decides that he wants to  
>> contribute to this effort and downloads the patch
>> 5. He makes some improvements, so he updates the existing patch as  
>> well as adds another patch containing additional data
>> 6. Chris downloads it and makes some mods and reposts.
>> Now, to me this doesn't seem that crazy - and is totally legal.   
>> And . . . just so you know - replace Chris with Tim and Daniel  
>> with either Anil or Ashish and you have EXACTLY what happened with  
>> the anonymous checkout process!
>> This shouldn't be this hard guys.  My suggestion would be to TRY  
>> one of these in this format and if you can't do it this way - THEN  
>> let's try and address it.  A separately maintained sandbox is  
>> absolutely no different  than managing patches - since both have  
>> to deal with integration back into the OFBiz trunk in some form or  
>> fashion.  Personally, I think the patches will be EASIER to  
>> maintain because they will allow you to make changes to existing  
>> code in an easier, more trackable format.  The alternative would  
>> be for you to maintain a sandbox - AND patches for updates to the  
>> source - doesn't that sound MORE tedious?
>> Anyways, thanks for listening to my ramble.
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>> o:801.649.6594
>> f:801.649.6595
>> On Jan 26, 2007, at 3:04 AM, 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  think about doing this under the ASF umbrella  
>>>> because I am not  willing to take on the responsibility of  
>>>> vetting a large number of  committers and recommending them as  
>>>> committers in the ASF, which is  BIG DEAL, and a responsibility  
>>>> and some people seem to be forgetting  that.
>>>>
>>>> If you want to be a committer you have to help with the project.  
>>>> You  have to take ownership of it, defend it, be committed to  
>>>> it, and so  on. Okay, now I'm doing what I was in the 2 page  
>>>> email I just deleted  and I'm stopping.
>>>>
>>>> If you want to know more about becoming and being a committer  
>>>> and  about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>>
>>>> I don't know WHY these questions are coming up here. Stop  
>>>> asking  them. Read the documents. I won't be baited into this  
>>>> any more. It's  a waste of time, and all based on supposition  
>>>> and not any real  problems or issues as far as I can see.
>>>>
>>>> If you develop something outside of OFBiz and want to contribute  
>>>> it,  here is the page describing how it works:
>>>>
>>>> http://incubator.apache.org/ip-clearance/index.html
>>>>
>>>> This is basically a streamlined incubation process for code  
>>>> going  into existing projects.
>>>>
>>>> If you really want to help and be involved in the project it  
>>>> means  working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it  
>>>> makes it  easier to get your own stuff in but if that is all  
>>>> you're about  related to the project, then being a committer  
>>>> isn't for you.
>>>>
>>>> If you want to know more about contributing and being a  
>>>> committer,  read the docs:
>>>>
>>>> http://docs.ofbiz.org/x/mQ
>>>> http://docs.ofbiz.org/x/r
>>>>
>>>> If you want to know more about licensing and legal issues, read  
>>>> the  docs:
>>>>
>>>> http://incubator.apache.org/incubation/Incubation_Policy.html
>>>> http://incubator.apache.org/ip-clearance/index.html
>>>> http://www.apache.org/foundation/how-it-works.html
>>>> http://www.apache.org/foundation/licence-FAQ.html
>>>> http://www.apache.org/legal/src-headers.html
>>>>
>>>> For a lot of good information, broaden the scope and study under:
>>>>
>>>> http://www.apache.org/dev/
>>>>
>>>> These were not written because someone was looking for some   
>>>> entertainment. They were written so things wouldn't have to be   
>>>> explained over and over.
>>>>
>>>> I'm calling it a day now, as soon as I take care of some real  
>>>> issues,  and as long as my son with the flu doesn't throw up  
>>>> again. Sorry,  this is really frustrating, and really silly.  
>>>> Reality sucks, but we  all have to live with it.
>>>>
>>>> If people want to help, then help. Don't just ask for help.  
>>>> Start by  being a giver, not a taker.
>>>>
>>>> If this sounds a bit harsh, great! Go for a walk and think about  
>>>> how  things work in real life, then read it again. If you're  
>>>> still upset,  read it again. Then go read all of the documents  
>>>> referenced. Then if  you still have a question, send it on in,  
>>>> but PLEASE try to look at  it from the point of a MEMBER of the  
>>>> OFBiz community, and not a user  of OFBiz who really doesn't  
>>>> want to get involved.
>>>>
>>>> If you're asking "how are you going to solve this problem" then   
>>>> you're asking the wrong question. If you want to participate as  
>>>> "how  can I solve this problem", if "I" can't, then do with "how  
>>>> can we  solve this problem". I don't mean that is what should be  
>>>> in your  email, I mean that is what should be in your head. If  
>>>> you can't find  an answer yourself that is 100% okay, just start  
>>>> a discussion and  accept what you asked for.
>>>>
>>>> If you don't like the answer explain why it doesn't work for  
>>>> you,  which brings us back to the beginning of this email...
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>>
>>>>> David
>>>>>
>>>>> Can you explain your reticence to adding an Apache OFBiz  
>>>>> sandbox where
>>>>> more members of the community could share their work?
>>>>>
>>>>> I can see this section possibly getting a disorganized over  
>>>>> time with
>>>>> *junk*... but it can be deleted easily enough. As a top level  
>>>>> project
>>>>> would it possible and better to organize a sub project for this?
>>>>>
>>>>> Thanks
>>>>>
>>>>> Daniel
>>>>>
>>>>>
>>>>>
>>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>>> I think we're talking about two different things.  You're  
>>>>>> talking  about
>>>>>> developing and I'm talking about legal issues.  The manner of
>>>>>> developing was already discussed in OFBIZ-499.  The only legal  
>>>>>> way to
>>>>>> use JIRA to collaborate this type of thing is to keep sending  
>>>>>> updated
>>>>>> patches to JIRA or to have a committer review and add it to a
>>>>>> specialized application.  Neither one of these is speed of   
>>>>>> development
>>>>>> friendly.
>>>>>>
>>>>>> Legal concerns wouldn't have been one of the primary driving   
>>>>>> forces of
>>>>>> moving to the ASF if it were true that "we've done fine for  
>>>>>> years".
>>>>>> The project still has technical exposure to a C & D order as  
>>>>>> the CLA
>>>>>> only covered works the copyright holder gave directly to the  
>>>>>> ASF not
>>>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>>>> incubation.  IANAL, and I don't think there is significant  
>>>>>> exposure,
>>>>>> but it is still there. That opinion isn't based on the  
>>>>>> vehicle  used to
>>>>>> create Apache OFBiz, but on the impression of kindheartedness  
>>>>>> from  the
>>>>>> members of the community prior to incubation.
>>>>>>
>>>>>> I don't want to speculate on the legal relationship the group  
>>>>>> that
>>>>>> worked on the anon checkout had, but I would suspect that it   
>>>>>> generated
>>>>>> some negative legal exposure as well and that the proposed  
>>>>>> setup of
>>>>>> Developers Conference will add to that.
>>>>>>
>>>>>> The only feedback that I've received from the general  
>>>>>> incubator list
>>>>>> are speculations, all with the caveat that the poster is not a  
>>>>>> lawyer
>>>>>> either and no one has been willing to post it to the legal- 
>>>>>> discuss
>>>>>> list.
>>>>>>
>>>>>> This issue is one of the MAJOR reasons for the existence of  
>>>>>> non- profit
>>>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to   
>>>>>> reconsider
>>>>>> the need of a more public sandbox where this kind of community
>>>>>> collaboration can be done without the complications of copyright
>>>>>> infringement, or at the very least pose the question to legal- 
>>>>>> discuss
>>>>>> for a formal opinion from those representing the ASF's  
>>>>>> interests.  It
>>>>>> is my understanding that when it's added to Apache owned SVN,  
>>>>>> ASF is
>>>>>> the copyright holder of the collective work instead of an  
>>>>>> impromptu
>>>>>> partnership where the individuals have no legal authority to  
>>>>>> offer a
>>>>>> collective work.
>>>>>>
>>>>>> Regards,
>>>>>> Chris
>>>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com  
>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>
>>>>>>>
>>>>>>> I REALLY don't think you need a sandbox for this. We've done  
>>>>>>> fine  for
>>>>>>>
>>>>>>> years without one, even with the recently re-done ecommerce   
>>>>>>> anonymous
>>>>>>>
>>>>>>> checkout process and alternative checkout processes which were
>>>>>>> developed entirely outside of OFBiz.
>>>>>>>
>>>>>>> Getting this stuff done is mostly a matter of knowing what  
>>>>>>> you're
>>>>>>> doing and having a clear goal to work towards, a design of  
>>>>>>> sorts if
>>>>>>> you will. A sandbox won't help that.
>>>>>>>
>>>>>>> Once you have a design you can start building it without  
>>>>>>> touching  the
>>>>>>>
>>>>>>> current stuff, just make it an alternate path and don't break
>>>>>>> anything existing along the way. Once it is complete, then  
>>>>>>> another
>>>>>>> patch can go in to remove the old code.
>>>>>>>
>>>>>>> It's that simple. That process has been followed well over a  
>>>>>>> hundred
>>>>>>>
>>>>>>> times over the life of OFBiz and even for those with commit  
>>>>>>> access
>>>>>>> it's the only way to go. If you don't have commit access,  
>>>>>>> it's even
>>>>>>> better because you can develop until you're stuck or out of  
>>>>>>> time,
>>>>>>> then throw in a patch and have it committed without breaking   
>>>>>>> anything
>>>>>>>
>>>>>>> else, even if the new thing isn't working 100%.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>>
>>>>>>>> Hey Anil,
>>>>>>>>
>>>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>>>> passing
>>>>>>>> the cart to a simple method that first checks the order type  
>>>>>>>> and
>>>>>>> then
>>>>>>>> calls a method or service that is focused on that order  
>>>>>>>> type.  Each
>>>>>>>> order type service will call a multitude of methods/services  
>>>>>>>> that
>>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>>
>>>>>>>> I would love to collaborate on this, but because of the  
>>>>>>>> size, it's
>>>>>>>> rather difficult to do by passing patches back and forth  
>>>>>>>> through
>>>>>>> JIRA
>>>>>>>> without having a reference point that SVN provides.  This is  
>>>>>>>> one of
>>>>>>>> those things that the ofbiz-sandbox project would be good  
>>>>>>>> for, but
>>>>>>> it
>>>>>>>> still has a legal issue that will prevent it from being entered
>>>>>>> back
>>>>>>>> into the project.  I can as an individual grant Apache the  
>>>>>>>> license
>>>>>>> it
>>>>>>>> needs for the work I do, you as an individual can grant  
>>>>>>>> Apache the
>>>>>>>> license it needs for the work you do, but without each of us
>>>>>>> assuming
>>>>>>>> the liability of a partnership we cannot grant a license for  
>>>>>>>> the
>>>>>>> work
>>>>>>>> as a whole.  The only way around this is to use ofbiz- 
>>>>>>>> sandbox SVN
>>>>>>> and
>>>>>>>> make patches for each commit and each of us resubmit our own  
>>>>>>>> patch
>>>>>>> to
>>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>>
>>>>>>>> This would be sooooo much easier if the members of OFBiz PMC  
>>>>>>>> would
>>>>>>>> respond on including a public sandbox in Apache OFBiz as  
>>>>>>>> each SVN
>>>>>>>> commit will be licensed to Apache, and Apache will be the  
>>>>>>>> owner of
>>>>>>> the
>>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>>> owner.
>>>>>>>>
>>>>>>>>
>>>>>>>> --- Anil Patel <toanilpatel@gmail.com  
>>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>>
>>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>>> interested in
>>>>>>>>> contributing towards making Order Entry process more  
>>>>>>>>> flexible. If
>>>>>>>>> there are
>>>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>>>> request one
>>>>>>>>> of the commiters who has interest in this to Please lead this
>>>>>>> effort.
>>>>>>>>>
>>>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>>>> some
>>>>>>>>> high
>>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>>>> simple
>>>>>>>>> methods.
>>>>>>>>> 2) Moving process control logic from event handlers to  
>>>>>>>>> Controller
>>>>>>>>> file.
>>>>>>>>>
>>>>>>>>> Any Ideas
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Anil Patel
>>>>>>>>>
>>>>>>>>> On 1/16/07, David E. Jones <jonesde@hotwaxmedia.com  
>>>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>>>> meant
>>>>>>>>>> mainly for those who want to be involved with development of
>>>>>>> OFBiz
>>>>>>>>>> itself. There will be a variety of projects going on and  
>>>>>>>>>> we hope
>>>>>>>>>> everyone will be able to work on both paid and fun stuff,  
>>>>>>>>>> but the
>>>>>>>>>> results will all be going right back into OFBiz. Still,  
>>>>>>>>>> everyone
>>>>>>> is
>>>>>>>>>> welcome to attend and join the "party" so if you know of  
>>>>>>>>>> someone
>>>>>>>>> who
>>>>>>>>>> might be interested but isn't subscribed to the dev  
>>>>>>>>>> mailing list,
>>>>>>>>>> please forward it on to them.
>>>>>>>>>>
>>>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>>>> development, if you aren't a developer it doesn't mean you  
>>>>>>>>>> can't
>>>>>>>>>> come. It would be great to have, for example, people like
>>>>>>> business
>>>>>>>>>> analysts and technical writers to help with requirements,  
>>>>>>>>>> design,
>>>>>>>>> and
>>>>>>>>>> documentation and such would be great!
>>>>>>>>>>
>>>>>>>>>> Included below is the original email about this, and most  
>>>>>>>>>> of the
>>>>>>>>>> information there is still applicable. Here are a few  
>>>>>>>>>> decisions,
>>>>>>>>>> based on feedback:
>>>>>>>>>>
>>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday -  
>>>>>>>>>> Friday),
>>>>>>>>> and
>>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>>
>>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>>> recommend
>>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>>> big-group
>>>>>>>>>> meetings and any presentations for Wednesday; if you can  
>>>>>>>>>> come for
>>>>>>>>> the
>>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>>
>>>>>>>>>> 3. people are welcome to come and enjoy local attractions  
>>>>>>>>>> for the
>>>>>>>>>> weekend before and/or after (it will still be cool in the  
>>>>>>>>>> area
>>>>>>>>> here,
>>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>>>> deserts
>>>>>>>>>> and canyons south of here)
>>>>>>>>>>
>>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra  
>>>>>>>>>> stuff, etc
>>>>>>>>> will
>>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>>> wireless
>>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>>> access;
>>>>>>>>> we
>>>>>>>>>> will have at least 2 projectors and perhaps other large  
>>>>>>>>>> monitors
>>>>>>> to
>>>>>>>>>> facilitate group development and discussion
>>>>>>>>>>
>>>>>>>>>> 5. meals, lodging, etc are not included in the main price,  
>>>>>>>>>> but
>>>>>>>>> we'll
>>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per  
>>>>>>>>>> night,
>>>>>>>>> first
>>>>>>>>>> come first serve); there is a decent hotel in town as well  
>>>>>>>>>> for
>>>>>>>>> around
>>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>>> various
>>>>>>>>>> restaurants within walking distance
>>>>>>>>>>
>>>>>>>>>> 6. the attendance cap is initially 20 people; there seems  
>>>>>>>>>> to be a
>>>>>>>>> lot
>>>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>>>> perhaps
>>>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>>>> building to be for group meeting use as well (we're  
>>>>>>>>>> planning on 2
>>>>>>>>> big
>>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>>
>>>>>>>>>> 7. the actual development goals are not finalized, but  
>>>>>>>>>> there is
>>>>>>>>> quite
>>>>>>>>>> a bit of interest in various things on the original list I
>>>>>>> included
>>>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>>>> project
>>>>>>>>>> management functionality
>>>>>>>>>>
>>>>>>>>>> To register (ASAP please, to make my job of planning  
>>>>>>>>>> easier!),
>>>>>>>>> please
>>>>>>>>>> contact me by email (jonesde@hotwaxmedia.com  
>>>>>>>>>> <ma...@hotwaxmedia.com>) with the following
>>>>>>>>>> information:
>>>>>>>>>>
>>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>>> different
>>>>>>>>>> than from address)
>>>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>>>> 4. lodging preference - in the building (private rooms,  
>>>>>>>>>> shared
>>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll  
>>>>>>>>>> respond
>>>>>>> with
>>>>>>>>>> contact info for the nice place close by, or there is a  
>>>>>>>>>> "fleabag"
>>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>>> 5. snack/diet preferences
>>>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>>>> rent/
>>>>>>>
>>>>>> === message truncated ===
>>>>>>
>>>>> -- 
>>>>> Daniel
>>>>>
>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>> Have a GREAT Day!
>>>>>
>>>>> Daniel Kunkel           DanielKunkel@BioWaves.com  
>>>>> <ma...@BioWaves.com>
>>>>> BioWaves, LLC           http://www.BioWaves.com
>>>>> 14150 NE 20th St. Suite F1
>>>>> Bellevue, WA 98007
>>>>> 800-734-3588    425-895-0050
>>>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>>>> http://www.Card-Offer.com      http://www.RackWine.com
>>>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>>
>>>>
>>>
>

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

[Jonathon -- Improov <jo...@improov.com>]

Tim,

For some reason I can't quite put my finger on, I am confident that I can process patches to my 
own sandbox faster than the OFBiz committers can process patches to OFBiz.

Maybe it's because I am becoming an OFBiz addict that I work on it tirelessly and relentlessly? I 
don't know.

And also, for some reason that escapes me, my commits seem to be more tested and less unsettling 
than some of OFBiz's.

Maybe it's because I don't have 10 paying clients to serve at once.

Or maybe I do understand the OFBiz framework enough to be able to do a "OFBiz-wide grep or other 
scan" in order to check whether my patches break stuff. Sort of like what a good IDE will do, 
probably. But I'm always stone-age, stick to simple tools (with good mind map).

There's still this need to put together stable audited releases. I'm sort of doing that with my 
personal "sandbox" on my harddisk.

I can't guarantee I can do the same if I'm a committer in OFBiz myself.

Jonathon

Tim Ruppert wrote:
> I know this sounds overly simplified, but someone please explain to me 
> why this doesn't work:
> 
> 1. Someone - let's say Chris has a great idea for a new project
> 2. He creates a JIRA issue describing it
> 3. He attaches an initial patch
> 4. Someone else - let's say Daniel decides that he wants to contribute 
> to this effort and downloads the patch
> 5. He makes some improvements, so he updates the existing patch as well 
> as adds another patch containing additional data
> 6. Chris downloads it and makes some mods and reposts.
> 
> Now, to me this doesn't seem that crazy - and is totally legal.  And . . 
> . just so you know - replace Chris with Tim and Daniel with either Anil 
> or Ashish and you have EXACTLY what happened with the anonymous checkout 
> process!
> 
> This shouldn't be this hard guys.  My suggestion would be to TRY one of 
> these in this format and if you can't do it this way - THEN let's try 
> and address it.  A separately maintained sandbox is absolutely no 
> different  than managing patches - since both have to deal with 
> integration back into the OFBiz trunk in some form or fashion.  
> 
> Personally, I think the patches will be EASIER to maintain because they 
> will allow you to make changes to existing code in an easier, more 
> trackable format.  The alternative would be for you to maintain a 
> sandbox - AND patches for updates to the source - doesn't that sound 
> MORE tedious?
> 
> Anyways, thanks for listening to my ramble.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> On Jan 26, 2007, at 3:04 AM, 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  
>>> think about doing this under the ASF umbrella because I am not  
>>> willing to take on the responsibility of vetting a large number of  
>>> committers and recommending them as committers in the ASF, which is  
>>> BIG DEAL, and a responsibility and some people seem to be forgetting  
>>> that.
>>>
>>> If you want to be a committer you have to help with the project. You  
>>> have to take ownership of it, defend it, be committed to it, and so  
>>> on. Okay, now I'm doing what I was in the 2 page email I just deleted  
>>> and I'm stopping.
>>>
>>> If you want to know more about becoming and being a committer and  
>>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>
>>> I don't know WHY these questions are coming up here. Stop asking  
>>> them. Read the documents. I won't be baited into this any more. It's  
>>> a waste of time, and all based on supposition and not any real  
>>> problems or issues as far as I can see.
>>>
>>> If you develop something outside of OFBiz and want to contribute it,  
>>> here is the page describing how it works:
>>>
>>> http://incubator.apache.org/ip-clearance/index.html
>>>
>>> This is basically a streamlined incubation process for code going  
>>> into existing projects.
>>>
>>> If you really want to help and be involved in the project it means  
>>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
>>> easier to get your own stuff in but if that is all you're about  
>>> related to the project, then being a committer isn't for you.
>>>
>>> If you want to know more about contributing and being a committer,  
>>> read the docs:
>>>
>>> http://docs.ofbiz.org/x/mQ
>>> http://docs.ofbiz.org/x/r
>>>
>>> If you want to know more about licensing and legal issues, read the  
>>> docs:
>>>
>>> http://incubator.apache.org/incubation/Incubation_Policy.html
>>> http://incubator.apache.org/ip-clearance/index.html
>>> http://www.apache.org/foundation/how-it-works.html
>>> http://www.apache.org/foundation/licence-FAQ.html
>>> http://www.apache.org/legal/src-headers.html
>>>
>>> For a lot of good information, broaden the scope and study under:
>>>
>>> http://www.apache.org/dev/
>>>
>>> These were not written because someone was looking for some  
>>> entertainment. They were written so things wouldn't have to be  
>>> explained over and over.
>>>
>>> I'm calling it a day now, as soon as I take care of some real issues,  
>>> and as long as my son with the flu doesn't throw up again. Sorry,  
>>> this is really frustrating, and really silly. Reality sucks, but we  
>>> all have to live with it.
>>>
>>> If people want to help, then help. Don't just ask for help. Start by  
>>> being a giver, not a taker.
>>>
>>> If this sounds a bit harsh, great! Go for a walk and think about how  
>>> things work in real life, then read it again. If you're still upset,  
>>> read it again. Then go read all of the documents referenced. Then if  
>>> you still have a question, send it on in, but PLEASE try to look at  
>>> it from the point of a MEMBER of the OFBiz community, and not a user  
>>> of OFBiz who really doesn't want to get involved.
>>>
>>> If you're asking "how are you going to solve this problem" then  
>>> you're asking the wrong question. If you want to participate as "how  
>>> can I solve this problem", if "I" can't, then do with "how can we  
>>> solve this problem". I don't mean that is what should be in your  
>>> email, I mean that is what should be in your head. If you can't find  
>>> an answer yourself that is 100% okay, just start a discussion and  
>>> accept what you asked for.
>>>
>>> If you don't like the answer explain why it doesn't work for you,  
>>> which brings us back to the beginning of this email...
>>>
>>> -David
>>>
>>>
>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>
>>>> David
>>>>
>>>> Can you explain your reticence to adding an Apache OFBiz sandbox where
>>>> more members of the community could share their work?
>>>>
>>>> I can see this section possibly getting a disorganized over time with
>>>> *junk*... but it can be deleted easily enough. As a top level project
>>>> would it possible and better to organize a sub project for this?
>>>>
>>>> Thanks
>>>>
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>> I think we're talking about two different things.  You're talking  
>>>>> about
>>>>> developing and I'm talking about legal issues.  The manner of
>>>>> developing was already discussed in OFBIZ-499.  The only legal way to
>>>>> use JIRA to collaborate this type of thing is to keep sending updated
>>>>> patches to JIRA or to have a committer review and add it to a
>>>>> specialized application.  Neither one of these is speed of  
>>>>> development
>>>>> friendly.
>>>>>
>>>>> Legal concerns wouldn't have been one of the primary driving  
>>>>> forces of
>>>>> moving to the ASF if it were true that "we've done fine for years".
>>>>> The project still has technical exposure to a C & D order as the CLA
>>>>> only covered works the copyright holder gave directly to the ASF not
>>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>>> incubation.  IANAL, and I don't think there is significant exposure,
>>>>> but it is still there. That opinion isn't based on the vehicle  
>>>>> used to
>>>>> create Apache OFBiz, but on the impression of kindheartedness from  
>>>>> the
>>>>> members of the community prior to incubation.
>>>>>
>>>>> I don't want to speculate on the legal relationship the group that
>>>>> worked on the anon checkout had, but I would suspect that it  
>>>>> generated
>>>>> some negative legal exposure as well and that the proposed setup of
>>>>> Developers Conference will add to that.
>>>>>
>>>>> The only feedback that I've received from the general incubator list
>>>>> are speculations, all with the caveat that the poster is not a lawyer
>>>>> either and no one has been willing to post it to the legal-discuss
>>>>> list.
>>>>>
>>>>> This issue is one of the MAJOR reasons for the existence of non- 
>>>>> profit
>>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to  
>>>>> reconsider
>>>>> the need of a more public sandbox where this kind of community
>>>>> collaboration can be done without the complications of copyright
>>>>> infringement, or at the very least pose the question to legal-discuss
>>>>> for a formal opinion from those representing the ASF's interests.  It
>>>>> is my understanding that when it's added to Apache owned SVN, ASF is
>>>>> the copyright holder of the collective work instead of an impromptu
>>>>> partnership where the individuals have no legal authority to offer a
>>>>> collective work.
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>> --- "David E. Jones" <jonesde@hotwaxmedia.com 
>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>
>>>>>>
>>>>>> I REALLY don't think you need a sandbox for this. We've done fine  
>>>>>> for
>>>>>>
>>>>>> years without one, even with the recently re-done ecommerce  
>>>>>> anonymous
>>>>>>
>>>>>> checkout process and alternative checkout processes which were
>>>>>> developed entirely outside of OFBiz.
>>>>>>
>>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>>> doing and having a clear goal to work towards, a design of sorts if
>>>>>> you will. A sandbox won't help that.
>>>>>>
>>>>>> Once you have a design you can start building it without touching  
>>>>>> the
>>>>>>
>>>>>> current stuff, just make it an alternate path and don't break
>>>>>> anything existing along the way. Once it is complete, then another
>>>>>> patch can go in to remove the old code.
>>>>>>
>>>>>> It's that simple. That process has been followed well over a hundred
>>>>>>
>>>>>> times over the life of OFBiz and even for those with commit access
>>>>>> it's the only way to go. If you don't have commit access, it's even
>>>>>> better because you can develop until you're stuck or out of time,
>>>>>> then throw in a patch and have it committed without breaking  
>>>>>> anything
>>>>>>
>>>>>> else, even if the new thing isn't working 100%.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>
>>>>>>> Hey Anil,
>>>>>>>
>>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>>> passing
>>>>>>> the cart to a simple method that first checks the order type and
>>>>>> then
>>>>>>> calls a method or service that is focused on that order type.  Each
>>>>>>> order type service will call a multitude of methods/services that
>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>
>>>>>>> I would love to collaborate on this, but because of the size, it's
>>>>>>> rather difficult to do by passing patches back and forth through
>>>>>> JIRA
>>>>>>> without having a reference point that SVN provides.  This is one of
>>>>>>> those things that the ofbiz-sandbox project would be good for, but
>>>>>> it
>>>>>>> still has a legal issue that will prevent it from being entered
>>>>>> back
>>>>>>> into the project.  I can as an individual grant Apache the license
>>>>>> it
>>>>>>> needs for the work I do, you as an individual can grant Apache the
>>>>>>> license it needs for the work you do, but without each of us
>>>>>> assuming
>>>>>>> the liability of a partnership we cannot grant a license for the
>>>>>> work
>>>>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>>>>> and
>>>>>>> make patches for each commit and each of us resubmit our own patch
>>>>>> to
>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>
>>>>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>>> commit will be licensed to Apache, and Apache will be the owner of
>>>>>> the
>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>> owner.
>>>>>>>
>>>>>>>
>>>>>>> --- Anil Patel <toanilpatel@gmail.com 
>>>>>>> <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>> interested in
>>>>>>>> contributing towards making Order Entry process more flexible. If
>>>>>>>> there are
>>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>>> request one
>>>>>>>> of the commiters who has interest in this to Please lead this
>>>>>> effort.
>>>>>>>>
>>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>>> some
>>>>>>>> high
>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>>> simple
>>>>>>>> methods.
>>>>>>>> 2) Moving process control logic from event handlers to Controller
>>>>>>>> file.
>>>>>>>>
>>>>>>>> Any Ideas
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Anil Patel
>>>>>>>>
>>>>>>>> On 1/16/07, David E. Jones <jonesde@hotwaxmedia.com 
>>>>>>>> <ma...@hotwaxmedia.com>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>>> meant
>>>>>>>>> mainly for those who want to be involved with development of
>>>>>> OFBiz
>>>>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>>>>> results will all be going right back into OFBiz. Still, everyone
>>>>>> is
>>>>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>>>>> who
>>>>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>>>>> please forward it on to them.
>>>>>>>>>
>>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>>>>> come. It would be great to have, for example, people like
>>>>>> business
>>>>>>>>> analysts and technical writers to help with requirements, design,
>>>>>>>> and
>>>>>>>>> documentation and such would be great!
>>>>>>>>>
>>>>>>>>> Included below is the original email about this, and most of the
>>>>>>>>> information there is still applicable. Here are a few decisions,
>>>>>>>>> based on feedback:
>>>>>>>>>
>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>>>>> and
>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>
>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>> recommend
>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>> big-group
>>>>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>>>>> the
>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>
>>>>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>>> here,
>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>>> deserts
>>>>>>>>> and canyons south of here)
>>>>>>>>>
>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>>>>> will
>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>> wireless
>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>> access;
>>>>>>>> we
>>>>>>>>> will have at least 2 projectors and perhaps other large monitors
>>>>>> to
>>>>>>>>> facilitate group development and discussion
>>>>>>>>>
>>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>>> we'll
>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>>> first
>>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>>> around
>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>> various
>>>>>>>>> restaurants within walking distance
>>>>>>>>>
>>>>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>>>>> lot
>>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>>> perhaps
>>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>>>>> big
>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>
>>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>>> quite
>>>>>>>>> a bit of interest in various things on the original list I
>>>>>> included
>>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>>> project
>>>>>>>>> management functionality
>>>>>>>>>
>>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>>> please
>>>>>>>>> contact me by email (jonesde@hotwaxmedia.com 
>>>>>>>>> <ma...@hotwaxmedia.com>) with the following
>>>>>>>>> information:
>>>>>>>>>
>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>> different
>>>>>>>>> than from address)
>>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>>> with
>>>>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>> 5. snack/diet preferences
>>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>>> rent/
>>>>>>
>>>>> === message truncated ===
>>>>>
>>>> -- 
>>>> Daniel
>>>>
>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>> Have a GREAT Day!
>>>>
>>>> Daniel Kunkel           DanielKunkel@BioWaves.com 
>>>> <ma...@BioWaves.com>
>>>> BioWaves, LLC           http://www.BioWaves.com
>>>> 14150 NE 20th St. Suite F1
>>>> Bellevue, WA 98007
>>>> 800-734-3588    425-895-0050
>>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>>> http://www.Card-Offer.com      http://www.RackWine.com
>>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>
>>>
>>
> 

Re: Intellectual Property and Sandbox SVN

[Jonathon -- Improov <jo...@improov.com>]

Hi all,

 > - A quickly disappearing svn code state that the patch was created against.

Just thought I'd comment quickly on this, since it's technical and it's in my field.

1. Audit differences between my sandbox and OFBiz regularly.

2. Update regularly (after audit).

3a. Complain quickly if I see a commit in OFBiz that breaks my work.

3b. Change my wrong work direction quickly if my direction is gonna make my
     private branch literally break off of OFBiz main branch due to severe
     incompatibilities.

As for the "quickly disappearing svn code state", it's always there for me, never disappeared. I 
always know which revision I forked from, so I know which revision to "diff upwards from" when 
doing a merge-in from official OFBiz branch.

Hope that was clear. I've done it so often that it's become 2nd nature to me. Not even sure if 
it's right. It just works right, feels right, somehow.

I don't know about the other not-so-technical issues.

I'm touching on SVN topic regarding synchronizing sandboxes with official OFBiz branch. Not 
off-topic, I hope.

Jonathon

Daniel Kunkel wrote:
> Hi
> 
> Ok, Chris, now you've confused me.
> 
> I don't have a problem understanding that collaborative efforts co-
> mingled outside of "Apache Assigned" jira issues could have severe
> issues, but it seems to me that collaboration is currently possible via
> the inefficient jira patch process.
> 
> Isn't it completely appropriate for Collaborator A, say Phani to make an
> "Apache Assigned" contribution in jira which Collaborator B improves and
> again assigns it to Apache in an updated patch?
> 
> This still has all of the challenges I've mentioned before, 
> 
> - One collaborator at a time.
> - A quickly disappearing svn code state that the patch was created
> against.
> - inefficient and often chaotic patch handling.
> - likelihood of losing the work to history
> - lost opportunity to create strong community with more active energized
> contributors.
> - duplication of effort as more than one developer independently work on
> features.
> etc.
> 
> If this jira patch process is legal, then I think we're at the point of
> beating a dead horse, but hopefully with the wheels of change in motion.
> 
> Daniel
> 
> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>> Tim,
>> I do agree that there is a protocol in place, but I do not agree that
>> everyone is following it. Those that seem the most opposed to a
>> discussion about a sandbox are the ones that keep pumping out the joint
>> works.  From my limited understanding, this does not appear to be a
>> legal format to license under open source without exposing the
>> contributor to partnership liability and the exposing the community
>> with the task of rooting out the offending code.
>>
>> I gave you a list of 10 environments that are complex enough and
>> require 
>> more than incremental changes. Tabling this discussion will continue to
>> lose many of the valuable contributions of the community (Like Phani's
>> work on Google Checkout integration).
>>
>> In addition, continuing to table this discussion will increase the
>> likelihood that offending code makes its way into the project.  If
>> someone makes a stink about it, my understanding is that the remedy is
>> for the ASF and anyone using Apache OFBiz to cease and desist until the
>> offending code is removed.  If a business is running off Apache OFBiz,
>> how much will it cost them to cease and desist?  If they choose not to
>> C & D, how much will it cost them to defend against a copyright
>> infringement claim?
>>
>> If my legal understanding is incorrect, someone please post the
>> question to legal-discuss and get a real lawyer's opinion.  If there is
>> no real risk in these joint works being added to the project, address
>> it as such.
>>
>> Regards,
>> Chris
>>
>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>
>>> Can we all agree on the fact that there is a protocol in place, that 
>>>
>>> if followed, allows everyone the ability to pass code around in a  
>>> legal format?  This may or may not be the most optimal format for  
>>> said collaboration, but it does permit us to contribute back to the  
>>> community in a meaningful way.
>>>
>>> Let's table this sandbox discussion until we find a movement complex 
>>>
>>> enough that it requires something more than incremental changes to be
>>>  
>>> made to the trunk before we can agree to include it.  Does that sound
>>>  
>>> reasonable?  Once there is an idea to build something that cannot  
>>> follow this incremental pattern, we can evaluate where we are in  
>>> terms of resources and determine the best course of action to follow.
>>>
>>> Cheers,
>>> Tim
>>> --
>>> Tim Ruppert
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> o:801.649.6594
>>> f:801.649.6595
>>>

Re: Intellectual Property and Sandbox SVN

["David E. Jones" <jo...@hotwaxmedia.com>]

On Jan 27, 2007, at 9:27 PM, Daniel Kunkel wrote:

> I was just trying to use the best example I could think of.
>
> My thinking ran the lines of:
>
> There are people in production using the Si's Financial module in
> production, and I didn't think it would be possible for these  
> people to
> update to the latest svn trunk during the development of the  
> accounting
> module as there would probably be conflicts. If I'm wrong, that's
> great...  but it's likely to cause some real trouble if an update ever
> caused any mistakes.

This is always a bit of a risk for things going into SVN, which is  
why committers need to be careful, and also check on things regularly  
just in case one of their changes messes something up they can fix  
quickly and such.

For this type of thing there are a lot of ways to develop it so that  
it does not conflict with another module that does similar thing. On  
the webapp side the URLs and webapps would be totally separate. On  
the logic side it is all triggered through ECA rules, and anything  
else done for accounting should do the same thing.

With ECA rules we simply leave them commented out (probably the whole  
file inclusion commented out in the ofbiz-component.xml file) until  
it is stable. Whenever those ECAs are enabled those who with to use  
the OSS financials module would simply exclude that ECA file again.

Fortunately for most parts of OFBiz there are facilities to build  
things and mount them on links or ECA rules or whatever that do not  
conflict with existing functionality.

> Finally I think you and I are thinking along the same lines from  
> Jacques
> original idea. The Apache Lab is really great for collaborative  
> projects
> that stand apart from the svn source tree, but it's better to bring  
> the
> developments as close to the svn trunk as possible to ease the source
> conflicts.

Yes, I think we're on the same page here. That sounds like an  
accurate summary of that part of things.

-David


> On Sat, 2007-01-27 at 20:25 -0700, David E. Jones wrote:
>> On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:
>>
>>> I think you may be on to something great here, however I still
>>> wonder if
>>> a branch and merge would work even better.
>>>
>>> For the fun of it, I'll take an example David mentioned a while
>>> back, a
>>> clean room accounting system. This is a large project that is
>>> likely to
>>> take a long time to develop, even in a collaborative environment,  
>>> and
>>> will probably require significant testing before being dumped  
>>> into svn
>>> trunk.
>>>
>>> Because it's likely to take a long time during development, a
>>> branch and
>>> merge might make more sense instead of merging and upgrading in the
>>> way
>>> Jonathan mentioned, since there are likely to be lots of conflicts
>>> that
>>> will need to be resolved over time.
>>
>> Why not build that, as with everything else in OFBiz, directly into
>> the main code base? That's certainly how I would do it...
>>
>> The main reason to use a branch is when you need to break existing
>> functionality and leave it broken for an extended period of time.
>> When adding new functionality even if it is incomplete it can, and
>> most definitely should, go right into the trunk as the work is done.
>>
>> -David
>>
>

Re: Intellectual Property and Sandbox SVN

[Daniel Kunkel <Da...@BioWaves.com>]

I was just trying to use the best example I could think of. 

My thinking ran the lines of: 

There are people in production using the Si's Financial module in
production, and I didn't think it would be possible for these people to
update to the latest svn trunk during the development of the accounting
module as there would probably be conflicts. If I'm wrong, that's
great...  but it's likely to cause some real trouble if an update ever
caused any mistakes. 

Finally I think you and I are thinking along the same lines from Jacques
original idea. The Apache Lab is really great for collaborative projects
that stand apart from the svn source tree, but it's better to bring the
developments as close to the svn trunk as possible to ease the source
conflicts.


On Sat, 2007-01-27 at 20:25 -0700, David E. Jones wrote:
> On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:
> 
> > I think you may be on to something great here, however I still  
> > wonder if
> > a branch and merge would work even better.
> >
> > For the fun of it, I'll take an example David mentioned a while  
> > back, a
> > clean room accounting system. This is a large project that is  
> > likely to
> > take a long time to develop, even in a collaborative environment, and
> > will probably require significant testing before being dumped into svn
> > trunk.
> >
> > Because it's likely to take a long time during development, a  
> > branch and
> > merge might make more sense instead of merging and upgrading in the  
> > way
> > Jonathan mentioned, since there are likely to be lots of conflicts  
> > that
> > will need to be resolved over time.
> 
> Why not build that, as with everything else in OFBiz, directly into  
> the main code base? That's certainly how I would do it...
> 
> The main reason to use a branch is when you need to break existing  
> functionality and leave it broken for an extended period of time.  
> When adding new functionality even if it is incomplete it can, and  
> most definitely should, go right into the trunk as the work is done.
> 
> -David
> 

Re: Intellectual Property and Sandbox SVN

["David E. Jones" <jo...@hotwaxmedia.com>]

On Jan 27, 2007, at 3:19 PM, Daniel Kunkel wrote:

> I think you may be on to something great here, however I still  
> wonder if
> a branch and merge would work even better.
>
> For the fun of it, I'll take an example David mentioned a while  
> back, a
> clean room accounting system. This is a large project that is  
> likely to
> take a long time to develop, even in a collaborative environment, and
> will probably require significant testing before being dumped into svn
> trunk.
>
> Because it's likely to take a long time during development, a  
> branch and
> merge might make more sense instead of merging and upgrading in the  
> way
> Jonathan mentioned, since there are likely to be lots of conflicts  
> that
> will need to be resolved over time.

Why not build that, as with everything else in OFBiz, directly into  
the main code base? That's certainly how I would do it...

The main reason to use a branch is when you need to break existing  
functionality and leave it broken for an extended period of time.  
When adding new functionality even if it is incomplete it can, and  
most definitely should, go right into the trunk as the work is done.

-David

Re: Intellectual Property and Sandbox SVN

[Daniel Kunkel <Da...@BioWaves.com>]

Hi

I think you may be on to something great here, however I still wonder if
a branch and merge would work even better.

For the fun of it, I'll take an example David mentioned a while back, a
clean room accounting system. This is a large project that is likely to
take a long time to develop, even in a collaborative environment, and
will probably require significant testing before being dumped into svn
trunk.

Because it's likely to take a long time during development, a branch and
merge might make more sense instead of merging and upgrading in the way
Jonathan mentioned, since there are likely to be lots of conflicts that
will need to be resolved over time.

Regardless, having more committers definitely helps build the community,
and for that I am excited.

Daniel

On Sat, 2007-01-27 at 21:38 +0100, Jacques Le Roux wrote:
> > Hi all,
> >
> > There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs
> http://labs.apache.org/
> > http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters.
> >
> > But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters
> if every person accept to assume of course.
> >
> > Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle
> it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard
> process (Jira patches).
> >
> > What do you think folks ?
> >
> > Jacques
> >
> 
> Of course this is not a solution to the hypothetical  problem that Chris raises. We might use the knowledge available (Legal
> discuss) to clear things, why not ?
> 
> Jacques
> 
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

Re: Intellectual Property and Sandbox SVN

[Jacques Le Roux <ja...@les7arts.com>]

> Hi all,
>
> There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs
http://labs.apache.org/
> http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters.
>
> But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters
if every person accept to assume of course.
>
> Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle
it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard
process (Jira patches).
>
> What do you think folks ?
>
> Jacques
>

Of course this is not a solution to the hypothetical  problem that Chris raises. We might use the knowledge available (Legal
discuss) to clear things, why not ?

Jacques

Re: Intellectual Property and Sandbox SVN

[Jacques Le Roux <ja...@les7arts.com>]

Hi all,

There is perhaps a solution to this kind of problems. You maybe know that recently the ASF created a sort of sandbox : the labs http://labs.apache.org/
http://hammett.castleproject.org/?p=91. Unfortunately this is reserved to Apache commiters. 

But in a recent mail David explained that soon 6 new OFBiz commiters will be invited. So in a near future we will be 13 commiters if every person accept to assume of course.

Then, when needed (by vote I guess) we may create an entry in the labs for a specific task if at least a commiter is OK to tackle it. By needed I mean if enough people want to work on a subject (aka task) that is really too hard to manage through the standard process (Jira patches).

What do you think folks ? 

Jacques

Re: Intellectual Property and Sandbox SVN

[Tim Ruppert <ti...@hotwaxmedia.com>]

Chris, no need to worry about pointing me out specifically because I  
HAVE been following the procedures that I outlined in a previous  
message.  If you'd like to talk to me about my contributions  
specifically - and the workflow that was followed - please feel free  
to call me directly at the office number listed below.

There's really aren't any good reasons to bring any BS I told ya so  
into the discussion (and yes I saw your follow on disclaimer) - we're  
all trying to work towards the same altruist goal here.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:

> Daniel,
>
> IMO you are exactly right both on JIRA and it becoming a dead horse
> (usually a good sign that has occurred when someone politely asks you
> to change the subject line ;) ).
>
> The JIRA process appears perfectly fine for individual works and works
> owned by corporations.  The problem I was pointing out to Tim  is that
> he is asking others to follow a protocol that he has not been  
> following
> himself.   The protocol Tim has been following created joint works
> instead of individual works (Not meaning to point Tim out  
> specifically,
> MANY contributions has been made in a similar manner).
>
> Whoever has the ability to subscribe to the legal-discuss mailing list
> (committers) could you please post the following questions?
>
> Given the following excerpt from FindLaw
> http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> personal
> legal background,
>
> "When the copyright in a work is jointly owned, each joint owner can
> use or license the work in the United States without the consent of  
> the
> other owner, provided that the use does not destroy the value of the
> work and the parties do not have an agreement requiring the consent of
> each owner for use or licensing. A joint owner who licenses a work  
> must
> share any royalties he or she receives with the other owners."
>
> Is it possible for a joint owner to license the jointly owned work
> under Apache2 or other compatible license?
>
> It appears on the surface that the Apache2 license destroys the value
> of the joint work itself (albeit increasing the value of the ether).
>
> If it is only possible with the consent of the other joint owners,  
> does
> that agreement constitute a partnership between the joint owners?
>
> If it does constitute a partnership, does this partnership bind each
> joint owner jointly and severely to any and all liabilities another
> joint owner may create in their representations of the joint work?
>
> Thank You!
>
> --- Daniel Kunkel <Da...@BioWaves.com> wrote:
>
>> Hi
>>
>> Ok, Chris, now you've confused me.
>>
>> I don't have a problem understanding that collaborative efforts co-
>> mingled outside of "Apache Assigned" jira issues could have severe
>> issues, but it seems to me that collaboration is currently possible
>> via
>> the inefficient jira patch process.
>>
>> Isn't it completely appropriate for Collaborator A, say Phani to make
>> an
>> "Apache Assigned" contribution in jira which Collaborator B improves
>> and
>> again assigns it to Apache in an updated patch?
>>
>> This still has all of the challenges I've mentioned before,
>>
>> - One collaborator at a time.
>> - A quickly disappearing svn code state that the patch was created
>> against.
>> - inefficient and often chaotic patch handling.
>> - likelihood of losing the work to history
>> - lost opportunity to create strong community with more active
>> energized
>> contributors.
>> - duplication of effort as more than one developer independently work
>> on
>> features.
>> etc.
>>
>> If this jira patch process is legal, then I think we're at the point
>> of
>> beating a dead horse, but hopefully with the wheels of change in
>> motion.
>>
>> Daniel
>>
>> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>>> Tim,
>>> I do agree that there is a protocol in place, but I do not agree
>> that
>>> everyone is following it. Those that seem the most opposed to a
>>> discussion about a sandbox are the ones that keep pumping out the
>> joint
>>> works.  From my limited understanding, this does not appear to be a
>>> legal format to license under open source without exposing the
>>> contributor to partnership liability and the exposing the community
>>> with the task of rooting out the offending code.
>>>
>>> I gave you a list of 10 environments that are complex enough and
>>> require
>>> more than incremental changes. Tabling this discussion will
>> continue to
>>> lose many of the valuable contributions of the community (Like
>> Phani's
>>> work on Google Checkout integration).
>>>
>>> In addition, continuing to table this discussion will increase the
>>> likelihood that offending code makes its way into the project.  If
>>> someone makes a stink about it, my understanding is that the remedy
>> is
>>> for the ASF and anyone using Apache OFBiz to cease and desist until
>> the
>>> offending code is removed.  If a business is running off Apache
>> OFBiz,
>>> how much will it cost them to cease and desist?  If they choose not
>> to
>>> C & D, how much will it cost them to defend against a copyright
>>> infringement claim?
>>>
>>> If my legal understanding is incorrect, someone please post the
>>> question to legal-discuss and get a real lawyer's opinion.  If
>> there is
>>> no real risk in these joint works being added to the project,
>> address
>>> it as such.
>>>
>>> Regards,
>>> Chris
>>>
>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>
>>>> Can we all agree on the fact that there is a protocol in place,
>> that
>>>>
>>>> if followed, allows everyone the ability to pass code around in a
>>
>>>> legal format?  This may or may not be the most optimal format for
>>
>>>> said collaboration, but it does permit us to contribute back to
>> the
>>>> community in a meaningful way.
>>>>
>>>> Let's table this sandbox discussion until we find a movement
>> complex
>>>>
>>>> enough that it requires something more than incremental changes
>> to be
>>>>
>>>> made to the trunk before we can agree to include it.  Does that
>> sound
>>>>
>>>> reasonable?  Once there is an idea to build something that cannot
>>
>>>> follow this incremental pattern, we can evaluate where we are in
>>
>>>> terms of resources and determine the best course of action to
>> follow.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>> -- 
>> Daniel
>>
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>> Have a GREAT Day!
>>
>> Daniel Kunkel           DanielKunkel@BioWaves.com
>> BioWaves, LLC           http://www.BioWaves.com
>> 14150 NE 20th St. Suite F1
>> Bellevue, WA 98007
>> 800-734-3588    425-895-0050
>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>> http://www.Card-Offer.com      http://www.RackWine.com
>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>
>>
>

Re: Intellectual Property and Sandbox SVN

[Chris Howe <cj...@yahoo.com>]

David,

I didn't say anything about #3 or #4, but I suppose those are correct
as well.  That still doesn't talk to the point of joint works.

Every document that you have linked to only mentions the distinctions
of copyright owned by a single entity.  That individual being a single
person, or that entity being a corporation.

>From the Apache 2.0 license:
"Licensor" shall mean the copyright owner or entity authorized by the
copyright owner that is granting the License.
...
"You" (or "Your") shall mean an individual or Legal Entity exercising
permissions granted by this License.
...
"Contributor" shall mean Licensor and any individual or Legal Entity on
behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.

There is a distinct absence of a reference of a plurality of owners.
There is absolutely NO mention that I have come across or that you have
linked to of works jointly owned.  And yet we don't want to clarify the
issue by posing the question to the legal brains at ASF and we keep
allowing code into the project where the copyright is jointly owned. 
This does not suggest sound policy.

If the lawyers have thought of EVERYTHING then why has there been a
need for a 2nd and 3rd revision?  If there are revisions, it means
something wasn't covered substantially enough to allow us to share our
work in the spirit of open source.  Revisions are good, but to be of
the opinion that the current revision are impenetrable, without
subjecting it to all possible scenarios including joint works, IMO, is
naive.  

We are all capable of overlooking something.  Jacques, Scott and
yourself just completed OFBIZ-637 because of an overlooked change in
policy.  Why was this policy changed?  It could have been construed
that the ASF was asserting a copyright on the code that followed in
that file.  That was not the ASF's intention and has since been changed
so that it can't be construed in that manner. Lawyers apparently had
reviewed that policy many times before the recent policy change as
well, right? 

Should the ASF have a policy at all regarding joint works?  I don't
know.  That's what posing the question to legal-discuss would answer.

It is a bit of a tired argument that you keep asserting that if someone
says something you disagree with and they continue to push the topic
they are either trolling or spreading fear uncertainty and doubt.  As a
user of OFBiz and as someone trying to extend the capabilities of
OFBiz, I _have fear, uncertainty and doubt. I am looking for somebody
in the project to _alleviate those _fears, _uncertainties and _doubts. 


Asking questions that raise fears, uncertainties and doubts is only
negative if it is put into a forum that the fears, uncertainty and
doubt cannot be explained away.  This channel is the place to alleviate
fear, uncertainty and doubt.  That can only be positive.


Regarding your problems list

1. Giving away the source code under Apache2 destroys the value of the
work itself.  Make no mistake.  This can be shown by taking your
initial contribution to this great project.  Prior to releasing OFBiz
under the MIT license, could you have licensed the work itself (not
consulting) to to a reasonable, knowledgeable person for a fee? The
answer in your head should be yes.  Now ask yourself, can you
legitimately license that work itself to to a reasonable knowledgeable
person for a fee  (not consulting) today?  The answer in your head
should be a resounding NO.  Why? Because by licensing it under MIT and
subsequently Apache2, you have destroyed the value of the work itself. 
The value of the project itself is greatly raised, but the project work
as a whole is not that same work. From what I've read and my
understanding, a single entity can do this, joint owners cannot without
creating undue liability for the other joint owners.

2.  Patches are in fact a work on their own.  From the Apache2 License:
"Work" shall mean the work of authorship, whether in Source or Object
form, made available under the License, as indicated by a copyright
notice that is included in or attached to the work (an example is
provided in the Appendix below).

>From the inconsistency of your comments to the Apache license it is
clear you have at least as little certainty in your opinion as I do
mine.  Please post the question to legal.

--- "David E. Jones" <jo...@hotwaxmedia.com> wrote:

> 
> Chris,
> 
> I've already answered on this topic and I'll include my previous  
> answer below because in spite of the conversation in the interim, it 
> 
> still applies just fine.
> 
> Before that, maybe we should step back a little bit. Let me rephrase 
> 
> what I'm hearing from you and see if I'm understanding right:
> 
> 1. you (Chris Howe) are not a lawyer
> 2. the Apache 2.0 license and supporting documents form a process of 
> 
> creating, maintaining and licensing software projects
> 3. the Apache 2.0 license and supporting documents were prepared and 
> 
> reviewed by a number of different lawyers and are in their third  
> major revision (that I'm aware of, ie 1.0, 1.1, 2.0), each of those  
> having gone through significant review and discussion
> 4. the Apache 2.0 license and supporting documents have garnered  
> support from large corporations such as IBM and Sun
> 5. somehow in spite of all of this they missed some basic tenets of  
> intellectual property law that is part of the USA copyright code
> 
> Am I getting this right?
> 
> Have you considered the possibility that your understanding and  
> interpretations are wrong?
> 
> Have you considered that this is such a strong possibility that maybe
>  
> you should start looking for reasons why it works rather than reasons
>  
> why it doesn't and bias your interpretations in that direction?
> 
> Have you considered looking around on the internet or in books for  
> more information specifically about how the Apache 2.0 license works 
> 
> (especially if you're not satisfied by the documents on apache.org)?
> 
> Have you considered that you are spreading a fairly thick and foul  
> smelling cloud of FUD and that this isn't necessarily good for the  
> project? If there really was a problem then this would be important  
> to discuss, but as I said before and I guess you didn't agree with,  
> there is no problem, and what's more is that it's not your  
> responsibility to manage and those whose responsibility it IS to  
> manage have spoken on the topic.
> 
> I read over your comments last night and based on my understanding of
>  
> how the licensing and development process fit together there are some
>  
> pretty significant problems with your assertions. The first thing to 
> 
> consider is what the ASF is all about and how the process works. That
>  
> is what the apache.org/dev/ documents teach committers and PMC  
> members about, ie the processes they should follow and the things  
> they should be checking.
> 
> The main thing that committers need to remember is that there are 2  
> important categories of things that might come in as contributions,  
> or that they might work on. If it is developed with the intent of  
> going into the open source project and is a natural extension or  
> modification to the existing artifacts, then it can go right in and  
> is immediately covered by the Apache 2 license. If something was  
> developed independently or varies a lot from the normal process, or  
> if the source of the software isn't clear (ie exactly who worked on  
> it), and that they did it with the understanding of contributing it  
> and such, then we can't just commit it "willy nilly". Any time there 
> 
> is a higher risk situation then we need to go through a more thorough
>  
> review and get the incubator folks involved, as described here:
> 
> http://incubator.apache.org/ip-clearance/index.html
> 
> Note that this is reference from the PMC Guide here:
> 
> http://www.apache.org/dev/pmc.html
> 
> If you want to know what the OFBiz PMC, or any ASF PMC, is  
> responsible for and does, this is where to look.
> 
> So, for an external sandbox you can go ahead with it. If there is  
> anything a committer is unsure about, it will go through the "mini- 
> incubation" IP clearance process.
> 
> Okay, now I think I've duplicated everything significant in my  
> original answer.
> 
> So, based on my understanding of the process and recommendations and 
> 
> documents prepared by the actual lawyers, here are some places where 
> 
> I think you assertions might have problems:
> 
> 1. if something is developed with the intent of contributing it to  
> any ASF project then licensing and distributing it through the ASF  
> under the Apache 2 license will not destroy it's value, in fact it  
> will INCREASE the value; from one way of looking at it, the  
> contribution is only of any value to the world or the developers  
> after it has been committed to the project, if that was the intent/ 
> goal from the beginning
> 
> 2. a patch or contribution created for such a purpose is not a "Work"
>  
> on its own from a legal perspective, it is part of a larger Work,  
> namely OFBiz or whatever the ASF project is
> 
> So, why haven't I asked about this on the legal-discuss mailing list?
>  
> I explained that in my other post as well. I really don't see an  
> issue to bug them about. They have already documented the process and
>  
> explained some distinctions between normal commits and what needs to 
> 
> go through the IP clearance process. That's all there is to it.
> 
> -David
> 
> 
> 
> On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:
> 
> > Daniel,
> >
> > IMO you are exactly right both on JIRA and it becoming a dead horse
> > (usually a good sign that has occurred when someone politely asks
> you
> > to change the subject line ;) ).
> >
> > The JIRA process appears perfectly fine for individual works and
> works
> > owned by corporations.  The problem I was pointing out to Tim  is
> that
> > he is asking others to follow a protocol that he has not been  
> > following
> > himself.   The protocol Tim has been following created joint works
> > instead of individual works (Not meaning to point Tim out  
> > specifically,
> > MANY contributions has been made in a similar manner).
> >
> > Whoever has the ability to subscribe to the legal-discuss mailing
> list
> > (committers) could you please post the following questions?
> >
> > Given the following excerpt from FindLaw
> > http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> > personal
> > legal background,
> >
> > "When the copyright in a work is jointly owned, each joint owner
> can
> > use or license the work in the United States without the consent of
>  
> > the
> > other owner, provided that the use does not destroy the value of
> the
> > work and the parties do not have an agreement requiring the consent
> of
> > each owner for use or licensing. A joint owner who licenses a work 
> 
> > must
> > share any royalties he or she receives with the other owners."
> >
> > Is it possible for a joint owner to license the jointly owned work
> > under Apache2 or other compatible license?
> >
> > It appears on the surface that the Apache2 license destroys the
> value
> > of the joint work itself (albeit increasing the value of the
> ether).
> >
> > If it is only possible with the consent of the other joint owners, 
> 
> > does
> > that agreement constitute a partnership between the joint owners?
> >
> > If it does constitute a partnership, does this partnership bind
> each
> > joint owner jointly and severely to any and all liabilities another
> > joint owner may create in their representations of the joint work?
> >
> > Thank You!
> >
> > --- Daniel Kunkel <Da...@BioWaves.com> wrote:
> >
> >> Hi
> >>
> >> Ok, Chris, now you've confused me.
> >>
> >> I don't have a problem understanding that collaborative efforts
> co-
> >> mingled outside of "Apache Assigned" jira issues could have severe
> >> issues, but it seems to me that collaboration is currently
> possible
> >> via
> >> the inefficient jira patch process.
> 
=== message truncated ===

Re: Intellectual Property and Sandbox SVN

["David E. Jones" <jo...@hotwaxmedia.com>]

Chris,

I've already answered on this topic and I'll include my previous  
answer below because in spite of the conversation in the interim, it  
still applies just fine.

Before that, maybe we should step back a little bit. Let me rephrase  
what I'm hearing from you and see if I'm understanding right:

1. you (Chris Howe) are not a lawyer
2. the Apache 2.0 license and supporting documents form a process of  
creating, maintaining and licensing software projects
3. the Apache 2.0 license and supporting documents were prepared and  
reviewed by a number of different lawyers and are in their third  
major revision (that I'm aware of, ie 1.0, 1.1, 2.0), each of those  
having gone through significant review and discussion
4. the Apache 2.0 license and supporting documents have garnered  
support from large corporations such as IBM and Sun
5. somehow in spite of all of this they missed some basic tenets of  
intellectual property law that is part of the USA copyright code

Am I getting this right?

Have you considered the possibility that your understanding and  
interpretations are wrong?

Have you considered that this is such a strong possibility that maybe  
you should start looking for reasons why it works rather than reasons  
why it doesn't and bias your interpretations in that direction?

Have you considered looking around on the internet or in books for  
more information specifically about how the Apache 2.0 license works  
(especially if you're not satisfied by the documents on apache.org)?

Have you considered that you are spreading a fairly thick and foul  
smelling cloud of FUD and that this isn't necessarily good for the  
project? If there really was a problem then this would be important  
to discuss, but as I said before and I guess you didn't agree with,  
there is no problem, and what's more is that it's not your  
responsibility to manage and those whose responsibility it IS to  
manage have spoken on the topic.

I read over your comments last night and based on my understanding of  
how the licensing and development process fit together there are some  
pretty significant problems with your assertions. The first thing to  
consider is what the ASF is all about and how the process works. That  
is what the apache.org/dev/ documents teach committers and PMC  
members about, ie the processes they should follow and the things  
they should be checking.

The main thing that committers need to remember is that there are 2  
important categories of things that might come in as contributions,  
or that they might work on. If it is developed with the intent of  
going into the open source project and is a natural extension or  
modification to the existing artifacts, then it can go right in and  
is immediately covered by the Apache 2 license. If something was  
developed independently or varies a lot from the normal process, or  
if the source of the software isn't clear (ie exactly who worked on  
it), and that they did it with the understanding of contributing it  
and such, then we can't just commit it "willy nilly". Any time there  
is a higher risk situation then we need to go through a more thorough  
review and get the incubator folks involved, as described here:

http://incubator.apache.org/ip-clearance/index.html

Note that this is reference from the PMC Guide here:

http://www.apache.org/dev/pmc.html

If you want to know what the OFBiz PMC, or any ASF PMC, is  
responsible for and does, this is where to look.

So, for an external sandbox you can go ahead with it. If there is  
anything a committer is unsure about, it will go through the "mini- 
incubation" IP clearance process.

Okay, now I think I've duplicated everything significant in my  
original answer.

So, based on my understanding of the process and recommendations and  
documents prepared by the actual lawyers, here are some places where  
I think you assertions might have problems:

1. if something is developed with the intent of contributing it to  
any ASF project then licensing and distributing it through the ASF  
under the Apache 2 license will not destroy it's value, in fact it  
will INCREASE the value; from one way of looking at it, the  
contribution is only of any value to the world or the developers  
after it has been committed to the project, if that was the intent/ 
goal from the beginning

2. a patch or contribution created for such a purpose is not a "Work"  
on its own from a legal perspective, it is part of a larger Work,  
namely OFBiz or whatever the ASF project is

So, why haven't I asked about this on the legal-discuss mailing list?  
I explained that in my other post as well. I really don't see an  
issue to bug them about. They have already documented the process and  
explained some distinctions between normal commits and what needs to  
go through the IP clearance process. That's all there is to it.

-David



On Jan 27, 2007, at 10:44 AM, Chris Howe wrote:

> Daniel,
>
> IMO you are exactly right both on JIRA and it becoming a dead horse
> (usually a good sign that has occurred when someone politely asks you
> to change the subject line ;) ).
>
> The JIRA process appears perfectly fine for individual works and works
> owned by corporations.  The problem I was pointing out to Tim  is that
> he is asking others to follow a protocol that he has not been  
> following
> himself.   The protocol Tim has been following created joint works
> instead of individual works (Not meaning to point Tim out  
> specifically,
> MANY contributions has been made in a similar manner).
>
> Whoever has the ability to subscribe to the legal-discuss mailing list
> (committers) could you please post the following questions?
>
> Given the following excerpt from FindLaw
> http://library.findlaw.com/1999/Jan/1/241478.html and your own  
> personal
> legal background,
>
> "When the copyright in a work is jointly owned, each joint owner can
> use or license the work in the United States without the consent of  
> the
> other owner, provided that the use does not destroy the value of the
> work and the parties do not have an agreement requiring the consent of
> each owner for use or licensing. A joint owner who licenses a work  
> must
> share any royalties he or she receives with the other owners."
>
> Is it possible for a joint owner to license the jointly owned work
> under Apache2 or other compatible license?
>
> It appears on the surface that the Apache2 license destroys the value
> of the joint work itself (albeit increasing the value of the ether).
>
> If it is only possible with the consent of the other joint owners,  
> does
> that agreement constitute a partnership between the joint owners?
>
> If it does constitute a partnership, does this partnership bind each
> joint owner jointly and severely to any and all liabilities another
> joint owner may create in their representations of the joint work?
>
> Thank You!
>
> --- Daniel Kunkel <Da...@BioWaves.com> wrote:
>
>> Hi
>>
>> Ok, Chris, now you've confused me.
>>
>> I don't have a problem understanding that collaborative efforts co-
>> mingled outside of "Apache Assigned" jira issues could have severe
>> issues, but it seems to me that collaboration is currently possible
>> via
>> the inefficient jira patch process.
>>
>> Isn't it completely appropriate for Collaborator A, say Phani to make
>> an
>> "Apache Assigned" contribution in jira which Collaborator B improves
>> and
>> again assigns it to Apache in an updated patch?
>>
>> This still has all of the challenges I've mentioned before,
>>
>> - One collaborator at a time.
>> - A quickly disappearing svn code state that the patch was created
>> against.
>> - inefficient and often chaotic patch handling.
>> - likelihood of losing the work to history
>> - lost opportunity to create strong community with more active
>> energized
>> contributors.
>> - duplication of effort as more than one developer independently work
>> on
>> features.
>> etc.
>>
>> If this jira patch process is legal, then I think we're at the point
>> of
>> beating a dead horse, but hopefully with the wheels of change in
>> motion.
>>
>> Daniel
>>
>> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
>>> Tim,
>>> I do agree that there is a protocol in place, but I do not agree
>> that
>>> everyone is following it. Those that seem the most opposed to a
>>> discussion about a sandbox are the ones that keep pumping out the
>> joint
>>> works.  From my limited understanding, this does not appear to be a
>>> legal format to license under open source without exposing the
>>> contributor to partnership liability and the exposing the community
>>> with the task of rooting out the offending code.
>>>
>>> I gave you a list of 10 environments that are complex enough and
>>> require
>>> more than incremental changes. Tabling this discussion will
>> continue to
>>> lose many of the valuable contributions of the community (Like
>> Phani's
>>> work on Google Checkout integration).
>>>
>>> In addition, continuing to table this discussion will increase the
>>> likelihood that offending code makes its way into the project.  If
>>> someone makes a stink about it, my understanding is that the remedy
>> is
>>> for the ASF and anyone using Apache OFBiz to cease and desist until
>> the
>>> offending code is removed.  If a business is running off Apache
>> OFBiz,
>>> how much will it cost them to cease and desist?  If they choose not
>> to
>>> C & D, how much will it cost them to defend against a copyright
>>> infringement claim?
>>>
>>> If my legal understanding is incorrect, someone please post the
>>> question to legal-discuss and get a real lawyer's opinion.  If
>> there is
>>> no real risk in these joint works being added to the project,
>> address
>>> it as such.
>>>
>>> Regards,
>>> Chris
>>>
>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>
>>>> Can we all agree on the fact that there is a protocol in place,
>> that
>>>>
>>>> if followed, allows everyone the ability to pass code around in a
>>
>>>> legal format?  This may or may not be the most optimal format for
>>
>>>> said collaboration, but it does permit us to contribute back to
>> the
>>>> community in a meaningful way.
>>>>
>>>> Let's table this sandbox discussion until we find a movement
>> complex
>>>>
>>>> enough that it requires something more than incremental changes
>> to be
>>>>
>>>> made to the trunk before we can agree to include it.  Does that
>> sound
>>>>
>>>> reasonable?  Once there is an idea to build something that cannot
>>
>>>> follow this incremental pattern, we can evaluate where we are in
>>
>>>> terms of resources and determine the best course of action to
>> follow.
>>>>
>>>> Cheers,
>>>> Tim
>>>> --
>>>> Tim Ruppert
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> o:801.649.6594
>>>> f:801.649.6595
>>>>
>> -- 
>> Daniel
>>
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>> Have a GREAT Day!
>>
>> Daniel Kunkel           DanielKunkel@BioWaves.com
>> BioWaves, LLC           http://www.BioWaves.com
>> 14150 NE 20th St. Suite F1
>> Bellevue, WA 98007
>> 800-734-3588    425-895-0050
>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>> http://www.Card-Offer.com      http://www.RackWine.com
>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>
>>
>

Re: Intellectual Property and Sandbox SVN

[Chris Howe <cj...@yahoo.com>]

Daniel,

IMO you are exactly right both on JIRA and it becoming a dead horse
(usually a good sign that has occurred when someone politely asks you
to change the subject line ;) ).  

The JIRA process appears perfectly fine for individual works and works
owned by corporations.  The problem I was pointing out to Tim  is that
he is asking others to follow a protocol that he has not been following
himself.   The protocol Tim has been following created joint works
instead of individual works (Not meaning to point Tim out specifically,
MANY contributions has been made in a similar manner).

Whoever has the ability to subscribe to the legal-discuss mailing list
(committers) could you please post the following questions?

Given the following excerpt from FindLaw
http://library.findlaw.com/1999/Jan/1/241478.html and your own personal
legal background, 

"When the copyright in a work is jointly owned, each joint owner can
use or license the work in the United States without the consent of the
other owner, provided that the use does not destroy the value of the
work and the parties do not have an agreement requiring the consent of
each owner for use or licensing. A joint owner who licenses a work must
share any royalties he or she receives with the other owners."

Is it possible for a joint owner to license the jointly owned work
under Apache2 or other compatible license? 

It appears on the surface that the Apache2 license destroys the value
of the joint work itself (albeit increasing the value of the ether).

If it is only possible with the consent of the other joint owners, does
that agreement constitute a partnership between the joint owners? 

If it does constitute a partnership, does this partnership bind each
joint owner jointly and severely to any and all liabilities another
joint owner may create in their representations of the joint work?

Thank You!

--- Daniel Kunkel <Da...@BioWaves.com> wrote:

> Hi
> 
> Ok, Chris, now you've confused me.
> 
> I don't have a problem understanding that collaborative efforts co-
> mingled outside of "Apache Assigned" jira issues could have severe
> issues, but it seems to me that collaboration is currently possible
> via
> the inefficient jira patch process.
> 
> Isn't it completely appropriate for Collaborator A, say Phani to make
> an
> "Apache Assigned" contribution in jira which Collaborator B improves
> and
> again assigns it to Apache in an updated patch?
> 
> This still has all of the challenges I've mentioned before, 
> 
> - One collaborator at a time.
> - A quickly disappearing svn code state that the patch was created
> against.
> - inefficient and often chaotic patch handling.
> - likelihood of losing the work to history
> - lost opportunity to create strong community with more active
> energized
> contributors.
> - duplication of effort as more than one developer independently work
> on
> features.
> etc.
> 
> If this jira patch process is legal, then I think we're at the point
> of
> beating a dead horse, but hopefully with the wheels of change in
> motion.
> 
> Daniel
> 
> On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
> > Tim,
> > I do agree that there is a protocol in place, but I do not agree
> that
> > everyone is following it. Those that seem the most opposed to a
> > discussion about a sandbox are the ones that keep pumping out the
> joint
> > works.  From my limited understanding, this does not appear to be a
> > legal format to license under open source without exposing the
> > contributor to partnership liability and the exposing the community
> > with the task of rooting out the offending code.
> > 
> > I gave you a list of 10 environments that are complex enough and
> > require 
> > more than incremental changes. Tabling this discussion will
> continue to
> > lose many of the valuable contributions of the community (Like
> Phani's
> > work on Google Checkout integration).
> > 
> > In addition, continuing to table this discussion will increase the
> > likelihood that offending code makes its way into the project.  If
> > someone makes a stink about it, my understanding is that the remedy
> is
> > for the ASF and anyone using Apache OFBiz to cease and desist until
> the
> > offending code is removed.  If a business is running off Apache
> OFBiz,
> > how much will it cost them to cease and desist?  If they choose not
> to
> > C & D, how much will it cost them to defend against a copyright
> > infringement claim?
> > 
> > If my legal understanding is incorrect, someone please post the
> > question to legal-discuss and get a real lawyer's opinion.  If
> there is
> > no real risk in these joint works being added to the project,
> address
> > it as such.
> > 
> > Regards,
> > Chris
> > 
> > --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> > 
> > > Can we all agree on the fact that there is a protocol in place,
> that 
> > > 
> > > if followed, allows everyone the ability to pass code around in a
>  
> > > legal format?  This may or may not be the most optimal format for
>  
> > > said collaboration, but it does permit us to contribute back to
> the  
> > > community in a meaningful way.
> > > 
> > > Let's table this sandbox discussion until we find a movement
> complex 
> > > 
> > > enough that it requires something more than incremental changes
> to be
> > >  
> > > made to the trunk before we can agree to include it.  Does that
> sound
> > >  
> > > reasonable?  Once there is an idea to build something that cannot
>  
> > > follow this incremental pattern, we can evaluate where we are in 
> 
> > > terms of resources and determine the best course of action to
> follow.
> > > 
> > > Cheers,
> > > Tim
> > > --
> > > Tim Ruppert
> > > HotWax Media
> > > http://www.hotwaxmedia.com
> > > 
> > > o:801.649.6594
> > > f:801.649.6595
> > > 
> -- 
> Daniel
> 
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> Have a GREAT Day!
> 
> Daniel Kunkel           DanielKunkel@BioWaves.com
> BioWaves, LLC           http://www.BioWaves.com
> 14150 NE 20th St. Suite F1
> Bellevue, WA 98007
> 800-734-3588    425-895-0050
> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> http://www.Card-Offer.com      http://www.RackWine.com
> http://www.JokesBlonde.com     http://www.Brain-Fun.com 
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> 
> 

Re: Intellectual Property and Sandbox SVN

[Daniel Kunkel <Da...@BioWaves.com>]

Hi

Ok, Chris, now you've confused me.

I don't have a problem understanding that collaborative efforts co-
mingled outside of "Apache Assigned" jira issues could have severe
issues, but it seems to me that collaboration is currently possible via
the inefficient jira patch process.

Isn't it completely appropriate for Collaborator A, say Phani to make an
"Apache Assigned" contribution in jira which Collaborator B improves and
again assigns it to Apache in an updated patch?

This still has all of the challenges I've mentioned before, 

- One collaborator at a time.
- A quickly disappearing svn code state that the patch was created
against.
- inefficient and often chaotic patch handling.
- likelihood of losing the work to history
- lost opportunity to create strong community with more active energized
contributors.
- duplication of effort as more than one developer independently work on
features.
etc.

If this jira patch process is legal, then I think we're at the point of
beating a dead horse, but hopefully with the wheels of change in motion.

Daniel

On Sat, 2007-01-27 at 08:28 -0800, Chris Howe wrote:
> Tim,
> I do agree that there is a protocol in place, but I do not agree that
> everyone is following it. Those that seem the most opposed to a
> discussion about a sandbox are the ones that keep pumping out the joint
> works.  From my limited understanding, this does not appear to be a
> legal format to license under open source without exposing the
> contributor to partnership liability and the exposing the community
> with the task of rooting out the offending code.
> 
> I gave you a list of 10 environments that are complex enough and
> require 
> more than incremental changes. Tabling this discussion will continue to
> lose many of the valuable contributions of the community (Like Phani's
> work on Google Checkout integration).
> 
> In addition, continuing to table this discussion will increase the
> likelihood that offending code makes its way into the project.  If
> someone makes a stink about it, my understanding is that the remedy is
> for the ASF and anyone using Apache OFBiz to cease and desist until the
> offending code is removed.  If a business is running off Apache OFBiz,
> how much will it cost them to cease and desist?  If they choose not to
> C & D, how much will it cost them to defend against a copyright
> infringement claim?
> 
> If my legal understanding is incorrect, someone please post the
> question to legal-discuss and get a real lawyer's opinion.  If there is
> no real risk in these joint works being added to the project, address
> it as such.
> 
> Regards,
> Chris
> 
> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> 
> > Can we all agree on the fact that there is a protocol in place, that 
> > 
> > if followed, allows everyone the ability to pass code around in a  
> > legal format?  This may or may not be the most optimal format for  
> > said collaboration, but it does permit us to contribute back to the  
> > community in a meaningful way.
> > 
> > Let's table this sandbox discussion until we find a movement complex 
> > 
> > enough that it requires something more than incremental changes to be
> >  
> > made to the trunk before we can agree to include it.  Does that sound
> >  
> > reasonable?  Once there is an idea to build something that cannot  
> > follow this incremental pattern, we can evaluate where we are in  
> > terms of resources and determine the best course of action to follow.
> > 
> > Cheers,
> > Tim
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> > 
> > o:801.649.6594
> > f:801.649.6595
> > 
-- 
Daniel

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
Have a GREAT Day!

Daniel Kunkel           DanielKunkel@BioWaves.com
BioWaves, LLC           http://www.BioWaves.com
14150 NE 20th St. Suite F1
Bellevue, WA 98007
800-734-3588    425-895-0050
http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
http://www.Card-Offer.com      http://www.RackWine.com
http://www.JokesBlonde.com     http://www.Brain-Fun.com 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

Re: Intellectual Property and Sandbox SVN

[Tim Ruppert <ti...@hotwaxmedia.com>]

And as I said last night Chris - I'm not opposed to doing something  
to rectify the situation - all anyone is asking here that you try ONE  
of the ten things you have going and try doing it iteratively using  
the same model that's been outlined many times before.

Just do it once, see how many people get involved - see how  
unmanageable the process is with someone making a patch, submitting  
it, people testing it, and it going into the project.

I believe that the first of such patches could easily be just a new  
application, some controller and web xml files, and ofbiz- 
component.xml, etc, etc.  Then a proposal would be put forth to the  
community for the project.  People could jump in and the changes  
could be built upon quite easily.  We've been managing updates in  
this way for a good long while now and it has been quite manageable  
and made for quick turnarounds.

I personally think that it is easier to manage small patches as they  
are created versus trying to submit something that's TOTALLY new  
application.  Think about how much time it would take for the  
committers to review an application that grows that large?  Why not  
try it iteratively and see how you like it?

As for the legal concerns, if there's someone at the ASF we can send  
this question to once and for all - by all means let's find a way to  
at least send it over there.  Chris, if you have a lawyer that you'd  
like to review all of the docs and give you a formal understanding of  
everything - please knock yourself and let us know how it all goes.   
If there is anyone else that wants to donate legal time - we would  
all love for this to be resolved so that it doesn't come up again.

So, here's my final two cents on the issue:

1. START USING THE EXISTING PROCESS
2. Check and see if someone can donate some legal time to quiesce any  
legal questions
3. Check and see if the ASF can help us with this conundrum
4. Evaluate legal resolutions and make infrastructure decisions based  
on true need resource availability.

Chris, I hope this works for you both as a short-term solution and as  
an understanding that we must wait until a true need shows itself  
(not proven) and some of these legal questions are answered by  
someone classically trained (instead of just someone's conjecture).

This is the last time I want to address this issue until we have both  
a real life situation that's not working AND legal answers from  
someone that specializes in Intellectual Property Law and knows the  
ASF intimately.  Anybody else that wants to continue deliberating on  
this topic - please feel free.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 27, 2007, at 9:28 AM, Chris Howe wrote:

> Tim,
> I do agree that there is a protocol in place, but I do not agree that
> everyone is following it. Those that seem the most opposed to a
> discussion about a sandbox are the ones that keep pumping out the  
> joint
> works.  From my limited understanding, this does not appear to be a
> legal format to license under open source without exposing the
> contributor to partnership liability and the exposing the community
> with the task of rooting out the offending code.
>
> I gave you a list of 10 environments that are complex enough and
> require
> more than incremental changes. Tabling this discussion will  
> continue to
> lose many of the valuable contributions of the community (Like Phani's
> work on Google Checkout integration).
>
> In addition, continuing to table this discussion will increase the
> likelihood that offending code makes its way into the project.  If
> someone makes a stink about it, my understanding is that the remedy is
> for the ASF and anyone using Apache OFBiz to cease and desist until  
> the
> offending code is removed.  If a business is running off Apache OFBiz,
> how much will it cost them to cease and desist?  If they choose not to
> C & D, how much will it cost them to defend against a copyright
> infringement claim?
>
> If my legal understanding is incorrect, someone please post the
> question to legal-discuss and get a real lawyer's opinion.  If  
> there is
> no real risk in these joint works being added to the project, address
> it as such.
>
> Regards,
> Chris
>
> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>
>> Can we all agree on the fact that there is a protocol in place, that
>>
>> if followed, allows everyone the ability to pass code around in a
>> legal format?  This may or may not be the most optimal format for
>> said collaboration, but it does permit us to contribute back to the
>> community in a meaningful way.
>>
>> Let's table this sandbox discussion until we find a movement complex
>>
>> enough that it requires something more than incremental changes to be
>>
>> made to the trunk before we can agree to include it.  Does that sound
>>
>> reasonable?  Once there is an idea to build something that cannot
>> follow this incremental pattern, we can evaluate where we are in
>> terms of resources and determine the best course of action to follow.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>>
>> On Jan 26, 2007, at 9:39 PM, Chris Howe wrote:
>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> Chris,
>>>>
>>>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>>>> fodder for big boys with lawyers.)
>>>>
>>>>> This structure, however does not protect the contributor (you) of
>>>> a
>>>>> joint work.
>>>>
>>>> Ok. So if I stole someone else's private work and contributed it
>> to a
>>>> committer who commits this
>>>> stolen work to ASF, then I'm liable for the theft, and ASF and the
>>>> committer are not liable.
>>>>
>>>
>>> ASF will need to remove the offending code from distribution.
>>>
>>>> That'll also mean I better make sure that the contributions put
>> into
>>>> my private sandbox are not
>>>> stolen as well. I'll just follow ASF's "license grant" process, so
>> I
>>>> won't be liable for any
>>>> thefts committed by contributors in my sandbox team.
>>>>
>>>
>>> That may not be sufficient.  The ASF does quite a bit more than the
>>
>>> CLA
>>> and license grant to protect itself.
>>>
>>>>> The only way as I see around this is to have a specific agreement
>>>>> amongst all joint owners allowing for its distribution under
>>>> Apache
>>>>> 2.
>>>>
>>>> Alright. So I just need to make sure all those committing to my
>>>> ragtag sandbox assigns rights to
>>>> ASF to distribute their contributions under Apache 2.
>>>>
>>>
>>> AFAIK
>>> The only way you can grant a license to the ASF is if you make your
>>> contribution directly to the ASF.  If they make their contribution
>> to
>>> you, they are granting you a license not Apache.  However, since
>> their
>>> contribution is intended to be inseparable from your contribution,
>> it
>>> is now a joint work absent some sort of agreement. This is the
>> point
>>> where it gets cloudy and no definitive answer has been offered.
>> Still
>>> not a pretty pickle and thus my ranting for a sandbox that is
>>> available
>>> to the community but owned by ASF.
>>>
>>>>> Not a pretty pickle.
>>>>
>>>> No, it's not pretty to software vendors, OFBiz consultants needing
>>>> money for a living, etc. But
>>>> that's not my concern. I leave that to businessmen.
>>>>
>>>>> Does this make my understanding of the scenario clear?
>>>>
>>>> Quite a bit clearer. Thanks.
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> IMO, this is certainly not a non-issue, it's the issue I've been
>>>> trying
>>>>> to get a definitive answer to for the last few weeks and everyone
>>>> wants
>>>>> to simply ignore it and act like we're a bunch of hippies.  It's
>>>> fun
>>>>> being a hippie until some large corporation comes by and carts
>> your
>>>>> commune off their land.  Then you're not a hippie, you're just
>>>>> homeless.
>>>>>
>>>>> I've changed my stance slightly contemplating Jonathon's
>> questions.
>>>>  I
>>>>> think this explanation is more correct, consistent and also
>> easier
>>>> to
>>>>> follow.  But again IANAL.
>>>>> Comments inline.
>>>>>
>>>>>
>>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>>
>>>>>> David (Jones), Tim, Chris,
>>>>>>
>>>>>> Sorry, I know this thread isn't about legal issues with OFBiz.
>> But
>>>>>> Chris often has a way of
>>>>>> spotting some oft-missed angle, and I'm concerned about a
>>>> particular
>>>>>> angle now. Though I'm also
>>>>>> often lost in his long complex explanations, please forgive me
>> if
>>>> I
>>>>>> feel scared/concerned about
>>>>>> some issues mentioned. Need just a bit of advice here.
>>>>>>
>>>>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
>>>> note
>>>>>> those words between **.
>>>>>>
>>>>>> "When the copyright... *provided that the use does not destroy
>> the
>>>>>> value of the
>>>>>> work* ..."
>>>>>>
>>>>>> I understand that the ASF license is like the MIT license, so
>> the
>>>>>> open sourced codes can be packed
>>>>>> into a commercial package (much like the LGPL?).
>>>>>>
>>>>>
>>>>> AFAIK, correct.
>>>>>
>>>>>> How do I publish codes (assuming I do have a semi-public SVN
>>>> shared
>>>>>> between a few friends) without
>>>>>> damaging that license?
>>>>>>
>>>>>
>>>>> The license is fine.  The owner of a copyright can write as many
>>>>> nonexclusive licenses as he/she/it/they wish.  However, I don't
>>>> believe
>>>>> a joint owner can grant the Apache 2 license to anyone without
>>>> greatly
>>>>> diminishes the financial value of the work itself.  This is
>> further
>>>>> compounded by granting the Apache 2 license to the ASF as one of
>>>> their
>>>>> main functions is to distribute that work freely to anyone who
>>>> points a
>>>>> browser or other client software in their direction.
>>>>>
>>>>>> "According to the Copyright Act... *a work prepared by two or
>> more
>>>>>> authors with the intention that their contributions be merged
>> into
>>>>>> inseparable or interdependent parts of a unitary whole*."
>>>>>>
>>>>>> What if I explicitly mention that I INTEND to merge my private
>>>>>> sandbox into OFBiz as a collection
>>>>>> of "interdependent parts of a unitary whole". Will that mean the
>>>>>> OFBiz core team and my own ragtag
>>>>>> team become a partnership?
>>>>>
>>>>> No. This I believe is the trick of the contributor license
>>>> agreement.
>>>>> Your "patch" is a complete work and you are granting license to
>>>> anyone
>>>>> who has access to JIRA the Apache 2 license.  The committers of
>>>> OFBiz
>>>>> as individuals accept your complete work and make a contribution
>> to
>>>> the
>>>>> ASF project under the terms of the CLA.  The only interaction
>> with
>>>> the
>>
> === message truncated ===
>

Re: Intellectual Property and Sandbox SVN

[Chris Howe <cj...@yahoo.com>]

Tim,
I do agree that there is a protocol in place, but I do not agree that
everyone is following it. Those that seem the most opposed to a
discussion about a sandbox are the ones that keep pumping out the joint
works.  From my limited understanding, this does not appear to be a
legal format to license under open source without exposing the
contributor to partnership liability and the exposing the community
with the task of rooting out the offending code.

I gave you a list of 10 environments that are complex enough and
require 
more than incremental changes. Tabling this discussion will continue to
lose many of the valuable contributions of the community (Like Phani's
work on Google Checkout integration).

In addition, continuing to table this discussion will increase the
likelihood that offending code makes its way into the project.  If
someone makes a stink about it, my understanding is that the remedy is
for the ASF and anyone using Apache OFBiz to cease and desist until the
offending code is removed.  If a business is running off Apache OFBiz,
how much will it cost them to cease and desist?  If they choose not to
C & D, how much will it cost them to defend against a copyright
infringement claim?

If my legal understanding is incorrect, someone please post the
question to legal-discuss and get a real lawyer's opinion.  If there is
no real risk in these joint works being added to the project, address
it as such.

Regards,
Chris

--- Tim Ruppert <ti...@hotwaxmedia.com> wrote:

> Can we all agree on the fact that there is a protocol in place, that 
> 
> if followed, allows everyone the ability to pass code around in a  
> legal format?  This may or may not be the most optimal format for  
> said collaboration, but it does permit us to contribute back to the  
> community in a meaningful way.
> 
> Let's table this sandbox discussion until we find a movement complex 
> 
> enough that it requires something more than incremental changes to be
>  
> made to the trunk before we can agree to include it.  Does that sound
>  
> reasonable?  Once there is an idea to build something that cannot  
> follow this incremental pattern, we can evaluate where we are in  
> terms of resources and determine the best course of action to follow.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> 
> On Jan 26, 2007, at 9:39 PM, Chris Howe wrote:
> 
> >
> > --- Jonathon -- Improov <jo...@improov.com> wrote:
> >
> >> Chris,
> >>
> >> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
> >> fodder for big boys with lawyers.)
> >>
> >>> This structure, however does not protect the contributor (you) of
> >> a
> >>> joint work.
> >>
> >> Ok. So if I stole someone else's private work and contributed it
> to a
> >> committer who commits this
> >> stolen work to ASF, then I'm liable for the theft, and ASF and the
> >> committer are not liable.
> >>
> >
> > ASF will need to remove the offending code from distribution.
> >
> >> That'll also mean I better make sure that the contributions put
> into
> >> my private sandbox are not
> >> stolen as well. I'll just follow ASF's "license grant" process, so
> I
> >> won't be liable for any
> >> thefts committed by contributors in my sandbox team.
> >>
> >
> > That may not be sufficient.  The ASF does quite a bit more than the
>  
> > CLA
> > and license grant to protect itself.
> >
> >>> The only way as I see around this is to have a specific agreement
> >>> amongst all joint owners allowing for its distribution under
> >> Apache
> >>> 2.
> >>
> >> Alright. So I just need to make sure all those committing to my
> >> ragtag sandbox assigns rights to
> >> ASF to distribute their contributions under Apache 2.
> >>
> >
> > AFAIK
> > The only way you can grant a license to the ASF is if you make your
> > contribution directly to the ASF.  If they make their contribution
> to
> > you, they are granting you a license not Apache.  However, since
> their
> > contribution is intended to be inseparable from your contribution,
> it
> > is now a joint work absent some sort of agreement. This is the
> point
> > where it gets cloudy and no definitive answer has been offered. 
> Still
> > not a pretty pickle and thus my ranting for a sandbox that is  
> > available
> > to the community but owned by ASF.
> >
> >>> Not a pretty pickle.
> >>
> >> No, it's not pretty to software vendors, OFBiz consultants needing
> >> money for a living, etc. But
> >> that's not my concern. I leave that to businessmen.
> >>
> >>> Does this make my understanding of the scenario clear?
> >>
> >> Quite a bit clearer. Thanks.
> >>
> >> Jonathon
> >>
> >> Chris Howe wrote:
> >>> IMO, this is certainly not a non-issue, it's the issue I've been
> >> trying
> >>> to get a definitive answer to for the last few weeks and everyone
> >> wants
> >>> to simply ignore it and act like we're a bunch of hippies.  It's
> >> fun
> >>> being a hippie until some large corporation comes by and carts
> your
> >>> commune off their land.  Then you're not a hippie, you're just
> >>> homeless.
> >>>
> >>> I've changed my stance slightly contemplating Jonathon's
> questions.
> >>  I
> >>> think this explanation is more correct, consistent and also
> easier
> >> to
> >>> follow.  But again IANAL.
> >>> Comments inline.
> >>>
> >>>
> >>> --- Jonathon -- Improov <jo...@improov.com> wrote:
> >>>
> >>>> David (Jones), Tim, Chris,
> >>>>
> >>>> Sorry, I know this thread isn't about legal issues with OFBiz.
> But
> >>>> Chris often has a way of
> >>>> spotting some oft-missed angle, and I'm concerned about a
> >> particular
> >>>> angle now. Though I'm also
> >>>> often lost in his long complex explanations, please forgive me
> if
> >> I
> >>>> feel scared/concerned about
> >>>> some issues mentioned. Need just a bit of advice here.
> >>>>
> >>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
> >> note
> >>>> those words between **.
> >>>>
> >>>> "When the copyright... *provided that the use does not destroy
> the
> >>>> value of the
> >>>> work* ..."
> >>>>
> >>>> I understand that the ASF license is like the MIT license, so
> the
> >>>> open sourced codes can be packed
> >>>> into a commercial package (much like the LGPL?).
> >>>>
> >>>
> >>> AFAIK, correct.
> >>>
> >>>> How do I publish codes (assuming I do have a semi-public SVN
> >> shared
> >>>> between a few friends) without
> >>>> damaging that license?
> >>>>
> >>>
> >>> The license is fine.  The owner of a copyright can write as many
> >>> nonexclusive licenses as he/she/it/they wish.  However, I don't
> >> believe
> >>> a joint owner can grant the Apache 2 license to anyone without
> >> greatly
> >>> diminishes the financial value of the work itself.  This is
> further
> >>> compounded by granting the Apache 2 license to the ASF as one of
> >> their
> >>> main functions is to distribute that work freely to anyone who
> >> points a
> >>> browser or other client software in their direction.
> >>>
> >>>> "According to the Copyright Act... *a work prepared by two or
> more
> >>>> authors with the intention that their contributions be merged
> into
> >>>> inseparable or interdependent parts of a unitary whole*."
> >>>>
> >>>> What if I explicitly mention that I INTEND to merge my private
> >>>> sandbox into OFBiz as a collection
> >>>> of "interdependent parts of a unitary whole". Will that mean the
> >>>> OFBiz core team and my own ragtag
> >>>> team become a partnership?
> >>>
> >>> No. This I believe is the trick of the contributor license
> >> agreement.
> >>> Your "patch" is a complete work and you are granting license to
> >> anyone
> >>> who has access to JIRA the Apache 2 license.  The committers of
> >> OFBiz
> >>> as individuals accept your complete work and make a contribution
> to
> >> the
> >>> ASF project under the terms of the CLA.  The only interaction
> with
> >> the
> 
=== message truncated ===

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

Can we all agree on the fact that there is a protocol in place, that  
if followed, allows everyone the ability to pass code around in a  
legal format?  This may or may not be the most optimal format for  
said collaboration, but it does permit us to contribute back to the  
community in a meaningful way.

Let's table this sandbox discussion until we find a movement complex  
enough that it requires something more than incremental changes to be  
made to the trunk before we can agree to include it.  Does that sound  
reasonable?  Once there is an idea to build something that cannot  
follow this incremental pattern, we can evaluate where we are in  
terms of resources and determine the best course of action to follow.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595


On Jan 26, 2007, at 9:39 PM, Chris Howe wrote:

>
> --- Jonathon -- Improov <jo...@improov.com> wrote:
>
>> Chris,
>>
>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>> fodder for big boys with lawyers.)
>>
>>> This structure, however does not protect the contributor (you) of
>> a
>>> joint work.
>>
>> Ok. So if I stole someone else's private work and contributed it to a
>> committer who commits this
>> stolen work to ASF, then I'm liable for the theft, and ASF and the
>> committer are not liable.
>>
>
> ASF will need to remove the offending code from distribution.
>
>> That'll also mean I better make sure that the contributions put into
>> my private sandbox are not
>> stolen as well. I'll just follow ASF's "license grant" process, so I
>> won't be liable for any
>> thefts committed by contributors in my sandbox team.
>>
>
> That may not be sufficient.  The ASF does quite a bit more than the  
> CLA
> and license grant to protect itself.
>
>>> The only way as I see around this is to have a specific agreement
>>> amongst all joint owners allowing for its distribution under
>> Apache
>>> 2.
>>
>> Alright. So I just need to make sure all those committing to my
>> ragtag sandbox assigns rights to
>> ASF to distribute their contributions under Apache 2.
>>
>
> AFAIK
> The only way you can grant a license to the ASF is if you make your
> contribution directly to the ASF.  If they make their contribution to
> you, they are granting you a license not Apache.  However, since their
> contribution is intended to be inseparable from your contribution, it
> is now a joint work absent some sort of agreement. This is the point
> where it gets cloudy and no definitive answer has been offered.  Still
> not a pretty pickle and thus my ranting for a sandbox that is  
> available
> to the community but owned by ASF.
>
>>> Not a pretty pickle.
>>
>> No, it's not pretty to software vendors, OFBiz consultants needing
>> money for a living, etc. But
>> that's not my concern. I leave that to businessmen.
>>
>>> Does this make my understanding of the scenario clear?
>>
>> Quite a bit clearer. Thanks.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> IMO, this is certainly not a non-issue, it's the issue I've been
>> trying
>>> to get a definitive answer to for the last few weeks and everyone
>> wants
>>> to simply ignore it and act like we're a bunch of hippies.  It's
>> fun
>>> being a hippie until some large corporation comes by and carts your
>>> commune off their land.  Then you're not a hippie, you're just
>>> homeless.
>>>
>>> I've changed my stance slightly contemplating Jonathon's questions.
>>  I
>>> think this explanation is more correct, consistent and also easier
>> to
>>> follow.  But again IANAL.
>>> Comments inline.
>>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> David (Jones), Tim, Chris,
>>>>
>>>> Sorry, I know this thread isn't about legal issues with OFBiz. But
>>>> Chris often has a way of
>>>> spotting some oft-missed angle, and I'm concerned about a
>> particular
>>>> angle now. Though I'm also
>>>> often lost in his long complex explanations, please forgive me if
>> I
>>>> feel scared/concerned about
>>>> some issues mentioned. Need just a bit of advice here.
>>>>
>>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
>> note
>>>> those words between **.
>>>>
>>>> "When the copyright... *provided that the use does not destroy the
>>>> value of the
>>>> work* ..."
>>>>
>>>> I understand that the ASF license is like the MIT license, so the
>>>> open sourced codes can be packed
>>>> into a commercial package (much like the LGPL?).
>>>>
>>>
>>> AFAIK, correct.
>>>
>>>> How do I publish codes (assuming I do have a semi-public SVN
>> shared
>>>> between a few friends) without
>>>> damaging that license?
>>>>
>>>
>>> The license is fine.  The owner of a copyright can write as many
>>> nonexclusive licenses as he/she/it/they wish.  However, I don't
>> believe
>>> a joint owner can grant the Apache 2 license to anyone without
>> greatly
>>> diminishes the financial value of the work itself.  This is further
>>> compounded by granting the Apache 2 license to the ASF as one of
>> their
>>> main functions is to distribute that work freely to anyone who
>> points a
>>> browser or other client software in their direction.
>>>
>>>> "According to the Copyright Act... *a work prepared by two or more
>>>> authors with the intention that their contributions be merged into
>>>> inseparable or interdependent parts of a unitary whole*."
>>>>
>>>> What if I explicitly mention that I INTEND to merge my private
>>>> sandbox into OFBiz as a collection
>>>> of "interdependent parts of a unitary whole". Will that mean the
>>>> OFBiz core team and my own ragtag
>>>> team become a partnership?
>>>
>>> No. This I believe is the trick of the contributor license
>> agreement.
>>> Your "patch" is a complete work and you are granting license to
>> anyone
>>> who has access to JIRA the Apache 2 license.  The committers of
>> OFBiz
>>> as individuals accept your complete work and make a contribution to
>> the
>>> ASF project under the terms of the CLA.  The only interaction with
>> the
>>> ASF is between the committer and the ASF, not you.  This, I believe
>>> protects the ASF to only being subject to cease and desist orders
>> in
>>> the event of infringement.  This structure should also protect the
>>> committer as it is their impression the work is being licensed
>> under
>>> Apache 2.  This structure, however does not protect the contributor
>>> (you) of a joint work.
>>>
>>> The problem as I see it with your semi-private SVN is that your
>> "patch"
>>> is not exclusively yours, it's the joint owners.  You as a joint
>> owner
>>> can license it anyway you want as long as you share the royalties
>> and
>>> don't diminish its value.
>>>
>>> Distributing it under Apache 2, diminishes its value. So, only an
>>> individual entity (individual or corporation) can distribute it
>> under
>>> Apache 2.  The only way as I see around this is to have a specific
>>> agreement amongst all joint owners allowing for its distribution
>> under
>>> Apache 2.  This agreement creates a legally binding partnership and
>> now
>>> you're subject to the representations and liabilities that the
>> other
>>> joint owners make regarding the joint work in their licensing to
>> other
>>> people.  Not a pretty pickle.
>>>
>>> Does this make my understanding of the scenario clear?
>>>
>>>
>>>
>>> On a side note (from the findlaw article), a copyright holder
>> cannot
>>> waive their termination right in advance.  This makes for an
>>> interesting scenario 35 years from now. Perhaps the ASF should
>>> reconsider the copyright assignment that the FSF has adopted.
>> Although
>>> then you have to rethink the trick of the CLA.  This could get
>> scary as
>>> the copyright is owned by the estate and thus can be distributed to
>>> heirs/debtors upon death.
>>>
>>>
>>>> I'm really lost. Anyway, if it's a non-issue, just let me know?
>>>> Thanks.
>>>>
>>>> Don't need to brief me about open source and GPL/LGPL, I already
>> know
>>>> all that.
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>> <snip>
>>>>>> I reviewed patches for Anil and Ashish - that is correct.
>> There's
>>>> no
>>>>>>
>>>>>> fancy partnership here - nor is there any any legal concern, but
>>
>>>>>> that's truly not what this discussion should be about.
>>>>>>
>>>>> <snip>
>>>>>
>>>>> You're absolutely correct that there isn't a _fancy partnership
>>>>> present.  The partnership created is the same mundane one that is
>>>>> created every day.  I must disagree with you, it is of GREAT
>> legal
>>>>> concern.  Since you obviously did not follow the link of
>> background
>>
> === message truncated ===
>

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

+1

On Jan 26, 2007, at 9:52 PM, Scott Gray wrote:

> Could anyone wishing to post further regarding licensing issues  
> please change the subject line?
>
> Thanks
> Scott
>
> Chris Howe wrote:
>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>
>>
>>> Chris,
>>>
>>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>>> fodder for big boys with lawyers.)
>>>
>>>  > This structure, however does not protect the contributor (you) of
>>> a
>>>  > joint work.
>>>
>>> Ok. So if I stole someone else's private work and contributed it  
>>> to a
>>> committer who commits this stolen work to ASF, then I'm liable  
>>> for the theft, and ASF and the
>>> committer are not liable.
>>>
>>>
>>
>> ASF will need to remove the offending code from distribution.
>>
>>
>>> That'll also mean I better make sure that the contributions put into
>>> my private sandbox are not stolen as well. I'll just follow ASF's  
>>> "license grant" process, so I
>>> won't be liable for any thefts committed by contributors in my  
>>> sandbox team.
>>>
>>>
>>
>> That may not be sufficient.  The ASF does quite a bit more than  
>> the CLA
>> and license grant to protect itself.
>>
>>
>>>  > The only way as I see around this is to have a specific agreement
>>>  > amongst all joint owners allowing for its distribution under
>>> Apache
>>>  > 2.
>>>
>>> Alright. So I just need to make sure all those committing to my
>>> ragtag sandbox assigns rights to ASF to distribute their  
>>> contributions under Apache 2.
>>>
>>>
>>
>> AFAIK
>> The only way you can grant a license to the ASF is if you make your
>> contribution directly to the ASF.  If they make their contribution to
>> you, they are granting you a license not Apache.  However, since  
>> their
>> contribution is intended to be inseparable from your contribution, it
>> is now a joint work absent some sort of agreement. This is the point
>> where it gets cloudy and no definitive answer has been offered.   
>> Still
>> not a pretty pickle and thus my ranting for a sandbox that is  
>> available
>> to the community but owned by ASF.
>>
>>
>>>  > Not a pretty pickle.
>>>
>>> No, it's not pretty to software vendors, OFBiz consultants needing
>>> money for a living, etc. But that's not my concern. I leave that  
>>> to businessmen.
>>>
>>>  > Does this make my understanding of the scenario clear?
>>>
>>> Quite a bit clearer. Thanks.
>>>
>>> Jonathon
>>>
>>> Chris Howe wrote:
>>>
>>>> IMO, this is certainly not a non-issue, it's the issue I've been
>>>>
>>> trying
>>>
>>>> to get a definitive answer to for the last few weeks and everyone
>>>>
>>> wants
>>>
>>>> to simply ignore it and act like we're a bunch of hippies.  It's
>>>>
>>> fun
>>>
>>>> being a hippie until some large corporation comes by and carts your
>>>> commune off their land.  Then you're not a hippie, you're just
>>>> homeless.
>>>> I've changed my stance slightly contemplating Jonathon's questions.
>>>>
>>>  I
>>>
>>>> think this explanation is more correct, consistent and also easier
>>>>
>>> to
>>>
>>>> follow.  But again IANAL.
>>>> Comments inline.
>>>>
>>>>
>>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>>
>>>>
>>>>> David (Jones), Tim, Chris,
>>>>>
>>>>> Sorry, I know this thread isn't about legal issues with OFBiz. But
>>>>> Chris often has a way of spotting some oft-missed angle, and  
>>>>> I'm concerned about a
>>>>>
>>> particular
>>>
>>>>> angle now. Though I'm also often lost in his long complex  
>>>>> explanations, please forgive me if
>>>>>
>>> I
>>>
>>>>> feel scared/concerned about some issues mentioned. Need just a  
>>>>> bit of advice here.
>>>>>
>>>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
>>>>>
>>> note
>>>
>>>>> those words between **.
>>>>>
>>>>> "When the copyright... *provided that the use does not destroy the
>>>>> value of the
>>>>> work* ..."
>>>>>
>>>>> I understand that the ASF license is like the MIT license, so the
>>>>> open sourced codes can be packed into a commercial package  
>>>>> (much like the LGPL?).
>>>>>
>>>>>
>>>> AFAIK, correct.
>>>>
>>>>
>>>>> How do I publish codes (assuming I do have a semi-public SVN
>>>>>
>>> shared
>>>
>>>>> between a few friends) without damaging that license?
>>>>>
>>>>>
>>>> The license is fine.  The owner of a copyright can write as many
>>>> nonexclusive licenses as he/she/it/they wish.  However, I don't
>>>>
>>> believe
>>>
>>>> a joint owner can grant the Apache 2 license to anyone without
>>>>
>>> greatly
>>>
>>>> diminishes the financial value of the work itself.  This is further
>>>> compounded by granting the Apache 2 license to the ASF as one of
>>>>
>>> their
>>>
>>>> main functions is to distribute that work freely to anyone who
>>>>
>>> points a
>>>
>>>> browser or other client software in their direction.
>>>>
>>>>
>>>>> "According to the Copyright Act... *a work prepared by two or more
>>>>> authors with the intention that their contributions be merged into
>>>>> inseparable or interdependent parts of a unitary whole*."
>>>>>
>>>>> What if I explicitly mention that I INTEND to merge my private
>>>>> sandbox into OFBiz as a collection of "interdependent parts of  
>>>>> a unitary whole". Will that mean the
>>>>> OFBiz core team and my own ragtag team become a partnership?
>>>>>
>>>> No. This I believe is the trick of the contributor license
>>>>
>>> agreement.
>>>
>>>> Your "patch" is a complete work and you are granting license to
>>>>
>>> anyone
>>>
>>>> who has access to JIRA the Apache 2 license.  The committers of
>>>>
>>> OFBiz
>>>
>>>> as individuals accept your complete work and make a contribution to
>>>>
>>> the
>>>
>>>> ASF project under the terms of the CLA.  The only interaction with
>>>>
>>> the
>>>
>>>> ASF is between the committer and the ASF, not you.  This, I believe
>>>> protects the ASF to only being subject to cease and desist orders
>>>>
>>> in
>>>
>>>> the event of infringement.  This structure should also protect the
>>>> committer as it is their impression the work is being licensed
>>>>
>>> under
>>>
>>>> Apache 2.  This structure, however does not protect the contributor
>>>> (you) of a joint work.
>>>>
>>>> The problem as I see it with your semi-private SVN is that your
>>>>
>>> "patch"
>>>
>>>> is not exclusively yours, it's the joint owners.  You as a joint
>>>>
>>> owner
>>>
>>>> can license it anyway you want as long as you share the royalties
>>>>
>>> and
>>>
>>>> don't diminish its value.
>>>> Distributing it under Apache 2, diminishes its value. So, only an
>>>> individual entity (individual or corporation) can distribute it
>>>>
>>> under
>>>
>>>> Apache 2.  The only way as I see around this is to have a specific
>>>> agreement amongst all joint owners allowing for its distribution
>>>>
>>> under
>>>
>>>> Apache 2.  This agreement creates a legally binding partnership and
>>>>
>>> now
>>>
>>>> you're subject to the representations and liabilities that the
>>>>
>>> other
>>>
>>>> joint owners make regarding the joint work in their licensing to
>>>>
>>> other
>>>
>>>> people.  Not a pretty pickle.
>>>>
>>>> Does this make my understanding of the scenario clear?
>>>>
>>>>
>>>>
>>>> On a side note (from the findlaw article), a copyright holder
>>>>
>>> cannot
>>>
>>>> waive their termination right in advance.  This makes for an
>>>> interesting scenario 35 years from now. Perhaps the ASF should
>>>> reconsider the copyright assignment that the FSF has adopted.
>>>>
>>> Although
>>>
>>>> then you have to rethink the trick of the CLA.  This could get
>>>>
>>> scary as
>>>
>>>> the copyright is owned by the estate and thus can be distributed to
>>>> heirs/debtors upon death.
>>>>
>>>>
>>>>> I'm really lost. Anyway, if it's a non-issue, just let me know?
>>>>> Thanks.
>>>>>
>>>>> Don't need to brief me about open source and GPL/LGPL, I already
>>>>>
>>> know
>>>
>>>>> all that.
>>>>>
>>>>> Jonathon
>>>>>
>>>>> Chris Howe wrote:
>>>>>
>>>>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>>> <snip>
>>>>>>
>>>>>>> I reviewed patches for Anil and Ashish - that is correct.
>>> There's
>>>
>>>>> no
>>>>>
>>>>>>>  fancy partnership here - nor is there any any legal concern,  
>>>>>>> but
>>>>>>>
>>>
>>>>>>> that's truly not what this discussion should be about.
>>>>>>>
>>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>> You're absolutely correct that there isn't a _fancy partnership
>>>>>> present.  The partnership created is the same mundane one that is
>>>>>> created every day.  I must disagree with you, it is of GREAT
>>>>>>
>>> legal
>>>
>>>>>> concern.  Since you obviously did not follow the link of
>>>>>>
>>> background
>>>
>>>
>> === message truncated ===
>>
>>
>>
>

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

[Scott Gray <le...@gmail.com>]

Could anyone wishing to post further regarding licensing issues please 
change the subject line?

Thanks
Scott

Chris Howe wrote:
> --- Jonathon -- Improov <jo...@improov.com> wrote:
>
>   
>> Chris,
>>
>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>> fodder for big boys with lawyers.)
>>
>>  > This structure, however does not protect the contributor (you) of
>> a
>>  > joint work.
>>
>> Ok. So if I stole someone else's private work and contributed it to a
>> committer who commits this 
>> stolen work to ASF, then I'm liable for the theft, and ASF and the
>> committer are not liable.
>>
>>     
>
> ASF will need to remove the offending code from distribution.
>
>   
>> That'll also mean I better make sure that the contributions put into
>> my private sandbox are not 
>> stolen as well. I'll just follow ASF's "license grant" process, so I
>> won't be liable for any 
>> thefts committed by contributors in my sandbox team.
>>
>>     
>
> That may not be sufficient.  The ASF does quite a bit more than the CLA
> and license grant to protect itself.
>
>   
>>  > The only way as I see around this is to have a specific agreement
>>  > amongst all joint owners allowing for its distribution under
>> Apache
>>  > 2.
>>
>> Alright. So I just need to make sure all those committing to my
>> ragtag sandbox assigns rights to 
>> ASF to distribute their contributions under Apache 2.
>>
>>     
>
> AFAIK
> The only way you can grant a license to the ASF is if you make your
> contribution directly to the ASF.  If they make their contribution to
> you, they are granting you a license not Apache.  However, since their
> contribution is intended to be inseparable from your contribution, it
> is now a joint work absent some sort of agreement. This is the point
> where it gets cloudy and no definitive answer has been offered.  Still
> not a pretty pickle and thus my ranting for a sandbox that is available
> to the community but owned by ASF.
>
>   
>>  > Not a pretty pickle.
>>
>> No, it's not pretty to software vendors, OFBiz consultants needing
>> money for a living, etc. But 
>> that's not my concern. I leave that to businessmen.
>>
>>  > Does this make my understanding of the scenario clear?
>>
>> Quite a bit clearer. Thanks.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>     
>>> IMO, this is certainly not a non-issue, it's the issue I've been
>>>       
>> trying
>>     
>>> to get a definitive answer to for the last few weeks and everyone
>>>       
>> wants
>>     
>>> to simply ignore it and act like we're a bunch of hippies.  It's
>>>       
>> fun
>>     
>>> being a hippie until some large corporation comes by and carts your
>>> commune off their land.  Then you're not a hippie, you're just
>>> homeless.  
>>>
>>> I've changed my stance slightly contemplating Jonathon's questions.
>>>       
>>  I
>>     
>>> think this explanation is more correct, consistent and also easier
>>>       
>> to
>>     
>>> follow.  But again IANAL.
>>> Comments inline.
>>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>       
>>>> David (Jones), Tim, Chris,
>>>>
>>>> Sorry, I know this thread isn't about legal issues with OFBiz. But
>>>> Chris often has a way of 
>>>> spotting some oft-missed angle, and I'm concerned about a
>>>>         
>> particular
>>     
>>>> angle now. Though I'm also 
>>>> often lost in his long complex explanations, please forgive me if
>>>>         
>> I
>>     
>>>> feel scared/concerned about 
>>>> some issues mentioned. Need just a bit of advice here.
>>>>
>>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
>>>>         
>> note
>>     
>>>> those words between **.
>>>>
>>>> "When the copyright... *provided that the use does not destroy the
>>>> value of the
>>>> work* ..."
>>>>
>>>> I understand that the ASF license is like the MIT license, so the
>>>> open sourced codes can be packed 
>>>> into a commercial package (much like the LGPL?).
>>>>
>>>>         
>>> AFAIK, correct.
>>>
>>>       
>>>> How do I publish codes (assuming I do have a semi-public SVN
>>>>         
>> shared
>>     
>>>> between a few friends) without 
>>>> damaging that license?
>>>>
>>>>         
>>> The license is fine.  The owner of a copyright can write as many
>>> nonexclusive licenses as he/she/it/they wish.  However, I don't
>>>       
>> believe
>>     
>>> a joint owner can grant the Apache 2 license to anyone without
>>>       
>> greatly
>>     
>>> diminishes the financial value of the work itself.  This is further
>>> compounded by granting the Apache 2 license to the ASF as one of
>>>       
>> their
>>     
>>> main functions is to distribute that work freely to anyone who
>>>       
>> points a
>>     
>>> browser or other client software in their direction.
>>>
>>>       
>>>> "According to the Copyright Act... *a work prepared by two or more
>>>> authors with the intention that their contributions be merged into
>>>> inseparable or interdependent parts of a unitary whole*."
>>>>
>>>> What if I explicitly mention that I INTEND to merge my private
>>>> sandbox into OFBiz as a collection 
>>>> of "interdependent parts of a unitary whole". Will that mean the
>>>> OFBiz core team and my own ragtag 
>>>> team become a partnership?
>>>>         
>>> No. This I believe is the trick of the contributor license
>>>       
>> agreement.
>>     
>>> Your "patch" is a complete work and you are granting license to
>>>       
>> anyone
>>     
>>> who has access to JIRA the Apache 2 license.  The committers of
>>>       
>> OFBiz
>>     
>>> as individuals accept your complete work and make a contribution to
>>>       
>> the
>>     
>>> ASF project under the terms of the CLA.  The only interaction with
>>>       
>> the
>>     
>>> ASF is between the committer and the ASF, not you.  This, I believe
>>> protects the ASF to only being subject to cease and desist orders
>>>       
>> in
>>     
>>> the event of infringement.  This structure should also protect the
>>> committer as it is their impression the work is being licensed
>>>       
>> under
>>     
>>> Apache 2.  This structure, however does not protect the contributor
>>> (you) of a joint work.
>>>
>>> The problem as I see it with your semi-private SVN is that your
>>>       
>> "patch"
>>     
>>> is not exclusively yours, it's the joint owners.  You as a joint
>>>       
>> owner
>>     
>>> can license it anyway you want as long as you share the royalties
>>>       
>> and
>>     
>>> don't diminish its value.  
>>>
>>> Distributing it under Apache 2, diminishes its value. So, only an
>>> individual entity (individual or corporation) can distribute it
>>>       
>> under
>>     
>>> Apache 2.  The only way as I see around this is to have a specific
>>> agreement amongst all joint owners allowing for its distribution
>>>       
>> under
>>     
>>> Apache 2.  This agreement creates a legally binding partnership and
>>>       
>> now
>>     
>>> you're subject to the representations and liabilities that the
>>>       
>> other
>>     
>>> joint owners make regarding the joint work in their licensing to
>>>       
>> other
>>     
>>> people.  Not a pretty pickle.
>>>
>>> Does this make my understanding of the scenario clear?
>>>
>>>
>>>
>>> On a side note (from the findlaw article), a copyright holder
>>>       
>> cannot
>>     
>>> waive their termination right in advance.  This makes for an
>>> interesting scenario 35 years from now. Perhaps the ASF should
>>> reconsider the copyright assignment that the FSF has adopted.
>>>       
>> Although
>>     
>>> then you have to rethink the trick of the CLA.  This could get
>>>       
>> scary as
>>     
>>> the copyright is owned by the estate and thus can be distributed to
>>> heirs/debtors upon death. 
>>>
>>>
>>>       
>>>> I'm really lost. Anyway, if it's a non-issue, just let me know?
>>>> Thanks.
>>>>
>>>> Don't need to brief me about open source and GPL/LGPL, I already
>>>>         
>> know
>>     
>>>> all that.
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>         
>>>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>> <snip>
>>>>>           
>>>>>> I reviewed patches for Anil and Ashish - that is correct. 
>>>>>>             
>> There's
>>     
>>>> no
>>>>         
>>>>>>  
>>>>>> fancy partnership here - nor is there any any legal concern, but
>>>>>>             
>>  
>>     
>>>>>> that's truly not what this discussion should be about.
>>>>>>
>>>>>>             
>>>>> <snip>
>>>>>
>>>>> You're absolutely correct that there isn't a _fancy partnership
>>>>> present.  The partnership created is the same mundane one that is
>>>>> created every day.  I must disagree with you, it is of GREAT
>>>>>           
>> legal
>>     
>>>>> concern.  Since you obviously did not follow the link of
>>>>>           
>> background
>>
>>     
> === message truncated ===
>
>
>   

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

[Jonathon -- Improov <jo...@improov.com>]

Chris,

Sigh. If there's any case of "severe physical mishap" involving a lawyer, you know where to find 
the usual suspects.

 > That may not be sufficient.  The ASF does quite a bit more than the CLA and
 > license grant to protect itself.

If someone can help me with setting up this "protection", I'd really appreciate it. Seems an LGPL 
is so much easier.

 > AFAIK
 > The only way you can grant a license to the ASF is if you make your
 > contribution directly to the ASF.  If they make their contribution to
 > you, they are granting you a license not Apache.  However, since their
 > contribution is intended to be inseparable from your contribution, it
 > is now a joint work absent some sort of agreement. This is the point
 > where it gets cloudy and no definitive answer has been offered.  Still
 > not a pretty pickle and thus my ranting for a sandbox that is available
 > to the community but owned by ASF.

Oh, I see. So that's why you guys had to go through the monumental effort to gather every 
contributor that ever put in to OFBiz codes when getting into ASF.

Argh. I don't know anymore. I'll just try to mimic ASF licensing procedures as much as I can.

Jonathon

Chris Howe wrote:
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> Chris,
>>
>> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
>> fodder for big boys with lawyers.)
>>
>>  > This structure, however does not protect the contributor (you) of
>> a
>>  > joint work.
>>
>> Ok. So if I stole someone else's private work and contributed it to a
>> committer who commits this 
>> stolen work to ASF, then I'm liable for the theft, and ASF and the
>> committer are not liable.
>>
> 
> ASF will need to remove the offending code from distribution.
> 
>> That'll also mean I better make sure that the contributions put into
>> my private sandbox are not 
>> stolen as well. I'll just follow ASF's "license grant" process, so I
>> won't be liable for any 
>> thefts committed by contributors in my sandbox team.
>>
> 
> That may not be sufficient.  The ASF does quite a bit more than the CLA
> and license grant to protect itself.
> 
>>  > The only way as I see around this is to have a specific agreement
>>  > amongst all joint owners allowing for its distribution under
>> Apache
>>  > 2.
>>
>> Alright. So I just need to make sure all those committing to my
>> ragtag sandbox assigns rights to 
>> ASF to distribute their contributions under Apache 2.
>>
> 
> AFAIK
> The only way you can grant a license to the ASF is if you make your
> contribution directly to the ASF.  If they make their contribution to
> you, they are granting you a license not Apache.  However, since their
> contribution is intended to be inseparable from your contribution, it
> is now a joint work absent some sort of agreement. This is the point
> where it gets cloudy and no definitive answer has been offered.  Still
> not a pretty pickle and thus my ranting for a sandbox that is available
> to the community but owned by ASF.
> 
>>  > Not a pretty pickle.
>>
>> No, it's not pretty to software vendors, OFBiz consultants needing
>> money for a living, etc. But 
>> that's not my concern. I leave that to businessmen.
>>
>>  > Does this make my understanding of the scenario clear?
>>
>> Quite a bit clearer. Thanks.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> IMO, this is certainly not a non-issue, it's the issue I've been
>> trying
>>> to get a definitive answer to for the last few weeks and everyone
>> wants
>>> to simply ignore it and act like we're a bunch of hippies.  It's
>> fun
>>> being a hippie until some large corporation comes by and carts your
>>> commune off their land.  Then you're not a hippie, you're just
>>> homeless.  
>>>
>>> I've changed my stance slightly contemplating Jonathon's questions.
>>  I
>>> think this explanation is more correct, consistent and also easier
>> to
>>> follow.  But again IANAL.
>>> Comments inline.
>>>
>>>
>>> --- Jonathon -- Improov <jo...@improov.com> wrote:
>>>
>>>> David (Jones), Tim, Chris,
>>>>
>>>> Sorry, I know this thread isn't about legal issues with OFBiz. But
>>>> Chris often has a way of 
>>>> spotting some oft-missed angle, and I'm concerned about a
>> particular
>>>> angle now. Though I'm also 
>>>> often lost in his long complex explanations, please forgive me if
>> I
>>>> feel scared/concerned about 
>>>> some issues mentioned. Need just a bit of advice here.
>>>>
>>>> I'm looking at some excertps from Chris' "findlaw" URL. Please
>> note
>>>> those words between **.
>>>>
>>>> "When the copyright... *provided that the use does not destroy the
>>>> value of the
>>>> work* ..."
>>>>
>>>> I understand that the ASF license is like the MIT license, so the
>>>> open sourced codes can be packed 
>>>> into a commercial package (much like the LGPL?).
>>>>
>>> AFAIK, correct.
>>>
>>>> How do I publish codes (assuming I do have a semi-public SVN
>> shared
>>>> between a few friends) without 
>>>> damaging that license?
>>>>
>>> The license is fine.  The owner of a copyright can write as many
>>> nonexclusive licenses as he/she/it/they wish.  However, I don't
>> believe
>>> a joint owner can grant the Apache 2 license to anyone without
>> greatly
>>> diminishes the financial value of the work itself.  This is further
>>> compounded by granting the Apache 2 license to the ASF as one of
>> their
>>> main functions is to distribute that work freely to anyone who
>> points a
>>> browser or other client software in their direction.
>>>
>>>> "According to the Copyright Act... *a work prepared by two or more
>>>> authors with the intention that their contributions be merged into
>>>> inseparable or interdependent parts of a unitary whole*."
>>>>
>>>> What if I explicitly mention that I INTEND to merge my private
>>>> sandbox into OFBiz as a collection 
>>>> of "interdependent parts of a unitary whole". Will that mean the
>>>> OFBiz core team and my own ragtag 
>>>> team become a partnership?
>>> No. This I believe is the trick of the contributor license
>> agreement.
>>> Your "patch" is a complete work and you are granting license to
>> anyone
>>> who has access to JIRA the Apache 2 license.  The committers of
>> OFBiz
>>> as individuals accept your complete work and make a contribution to
>> the
>>> ASF project under the terms of the CLA.  The only interaction with
>> the
>>> ASF is between the committer and the ASF, not you.  This, I believe
>>> protects the ASF to only being subject to cease and desist orders
>> in
>>> the event of infringement.  This structure should also protect the
>>> committer as it is their impression the work is being licensed
>> under
>>> Apache 2.  This structure, however does not protect the contributor
>>> (you) of a joint work.
>>>
>>> The problem as I see it with your semi-private SVN is that your
>> "patch"
>>> is not exclusively yours, it's the joint owners.  You as a joint
>> owner
>>> can license it anyway you want as long as you share the royalties
>> and
>>> don't diminish its value.  
>>>
>>> Distributing it under Apache 2, diminishes its value. So, only an
>>> individual entity (individual or corporation) can distribute it
>> under
>>> Apache 2.  The only way as I see around this is to have a specific
>>> agreement amongst all joint owners allowing for its distribution
>> under
>>> Apache 2.  This agreement creates a legally binding partnership and
>> now
>>> you're subject to the representations and liabilities that the
>> other
>>> joint owners make regarding the joint work in their licensing to
>> other
>>> people.  Not a pretty pickle.
>>>
>>> Does this make my understanding of the scenario clear?
>>>
>>>
>>>
>>> On a side note (from the findlaw article), a copyright holder
>> cannot
>>> waive their termination right in advance.  This makes for an
>>> interesting scenario 35 years from now. Perhaps the ASF should
>>> reconsider the copyright assignment that the FSF has adopted.
>> Although
>>> then you have to rethink the trick of the CLA.  This could get
>> scary as
>>> the copyright is owned by the estate and thus can be distributed to
>>> heirs/debtors upon death. 
>>>
>>>
>>>> I'm really lost. Anyway, if it's a non-issue, just let me know?
>>>> Thanks.
>>>>
>>>> Don't need to brief me about open source and GPL/LGPL, I already
>> know
>>>> all that.
>>>>
>>>> Jonathon
>>>>
>>>> Chris Howe wrote:
>>>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>>>> <snip>
>>>>>> I reviewed patches for Anil and Ashish - that is correct. 
>> There's
>>>> no
>>>>>>  
>>>>>> fancy partnership here - nor is there any any legal concern, but
>>  
>>>>>> that's truly not what this discussion should be about.
>>>>>>
>>>>> <snip>
>>>>>
>>>>> You're absolutely correct that there isn't a _fancy partnership
>>>>> present.  The partnership created is the same mundane one that is
>>>>> created every day.  I must disagree with you, it is of GREAT
>> legal
>>>>> concern.  Since you obviously did not follow the link of
>> background
>>
> === message truncated ===
> 
> 

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

[Chris Howe <cj...@yahoo.com>]

--- Jonathon -- Improov <jo...@improov.com> wrote:

> Chris,
> 
> Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon
> fodder for big boys with lawyers.)
> 
>  > This structure, however does not protect the contributor (you) of
> a
>  > joint work.
> 
> Ok. So if I stole someone else's private work and contributed it to a
> committer who commits this 
> stolen work to ASF, then I'm liable for the theft, and ASF and the
> committer are not liable.
> 

ASF will need to remove the offending code from distribution.

> That'll also mean I better make sure that the contributions put into
> my private sandbox are not 
> stolen as well. I'll just follow ASF's "license grant" process, so I
> won't be liable for any 
> thefts committed by contributors in my sandbox team.
> 

That may not be sufficient.  The ASF does quite a bit more than the CLA
and license grant to protect itself.

>  > The only way as I see around this is to have a specific agreement
>  > amongst all joint owners allowing for its distribution under
> Apache
>  > 2.
> 
> Alright. So I just need to make sure all those committing to my
> ragtag sandbox assigns rights to 
> ASF to distribute their contributions under Apache 2.
> 

AFAIK
The only way you can grant a license to the ASF is if you make your
contribution directly to the ASF.  If they make their contribution to
you, they are granting you a license not Apache.  However, since their
contribution is intended to be inseparable from your contribution, it
is now a joint work absent some sort of agreement. This is the point
where it gets cloudy and no definitive answer has been offered.  Still
not a pretty pickle and thus my ranting for a sandbox that is available
to the community but owned by ASF.

>  > Not a pretty pickle.
> 
> No, it's not pretty to software vendors, OFBiz consultants needing
> money for a living, etc. But 
> that's not my concern. I leave that to businessmen.
> 
>  > Does this make my understanding of the scenario clear?
> 
> Quite a bit clearer. Thanks.
> 
> Jonathon
> 
> Chris Howe wrote:
> > IMO, this is certainly not a non-issue, it's the issue I've been
> trying
> > to get a definitive answer to for the last few weeks and everyone
> wants
> > to simply ignore it and act like we're a bunch of hippies.  It's
> fun
> > being a hippie until some large corporation comes by and carts your
> > commune off their land.  Then you're not a hippie, you're just
> > homeless.  
> > 
> > I've changed my stance slightly contemplating Jonathon's questions.
>  I
> > think this explanation is more correct, consistent and also easier
> to
> > follow.  But again IANAL.
> > Comments inline.
> > 
> > 
> > --- Jonathon -- Improov <jo...@improov.com> wrote:
> > 
> >> David (Jones), Tim, Chris,
> >>
> >> Sorry, I know this thread isn't about legal issues with OFBiz. But
> >> Chris often has a way of 
> >> spotting some oft-missed angle, and I'm concerned about a
> particular
> >> angle now. Though I'm also 
> >> often lost in his long complex explanations, please forgive me if
> I
> >> feel scared/concerned about 
> >> some issues mentioned. Need just a bit of advice here.
> >>
> >> I'm looking at some excertps from Chris' "findlaw" URL. Please
> note
> >> those words between **.
> >>
> >> "When the copyright... *provided that the use does not destroy the
> >> value of the
> >> work* ..."
> >>
> >> I understand that the ASF license is like the MIT license, so the
> >> open sourced codes can be packed 
> >> into a commercial package (much like the LGPL?).
> >>
> > 
> > AFAIK, correct.
> > 
> >> How do I publish codes (assuming I do have a semi-public SVN
> shared
> >> between a few friends) without 
> >> damaging that license?
> >>
> > 
> > The license is fine.  The owner of a copyright can write as many
> > nonexclusive licenses as he/she/it/they wish.  However, I don't
> believe
> > a joint owner can grant the Apache 2 license to anyone without
> greatly
> > diminishes the financial value of the work itself.  This is further
> > compounded by granting the Apache 2 license to the ASF as one of
> their
> > main functions is to distribute that work freely to anyone who
> points a
> > browser or other client software in their direction.
> > 
> >> "According to the Copyright Act... *a work prepared by two or more
> >> authors with the intention that their contributions be merged into
> >> inseparable or interdependent parts of a unitary whole*."
> >>
> >> What if I explicitly mention that I INTEND to merge my private
> >> sandbox into OFBiz as a collection 
> >> of "interdependent parts of a unitary whole". Will that mean the
> >> OFBiz core team and my own ragtag 
> >> team become a partnership?
> > 
> > No. This I believe is the trick of the contributor license
> agreement.
> > Your "patch" is a complete work and you are granting license to
> anyone
> > who has access to JIRA the Apache 2 license.  The committers of
> OFBiz
> > as individuals accept your complete work and make a contribution to
> the
> > ASF project under the terms of the CLA.  The only interaction with
> the
> > ASF is between the committer and the ASF, not you.  This, I believe
> > protects the ASF to only being subject to cease and desist orders
> in
> > the event of infringement.  This structure should also protect the
> > committer as it is their impression the work is being licensed
> under
> > Apache 2.  This structure, however does not protect the contributor
> > (you) of a joint work.
> > 
> > The problem as I see it with your semi-private SVN is that your
> "patch"
> > is not exclusively yours, it's the joint owners.  You as a joint
> owner
> > can license it anyway you want as long as you share the royalties
> and
> > don't diminish its value.  
> > 
> > Distributing it under Apache 2, diminishes its value. So, only an
> > individual entity (individual or corporation) can distribute it
> under
> > Apache 2.  The only way as I see around this is to have a specific
> > agreement amongst all joint owners allowing for its distribution
> under
> > Apache 2.  This agreement creates a legally binding partnership and
> now
> > you're subject to the representations and liabilities that the
> other
> > joint owners make regarding the joint work in their licensing to
> other
> > people.  Not a pretty pickle.
> > 
> > Does this make my understanding of the scenario clear?
> > 
> > 
> > 
> > On a side note (from the findlaw article), a copyright holder
> cannot
> > waive their termination right in advance.  This makes for an
> > interesting scenario 35 years from now. Perhaps the ASF should
> > reconsider the copyright assignment that the FSF has adopted.
> Although
> > then you have to rethink the trick of the CLA.  This could get
> scary as
> > the copyright is owned by the estate and thus can be distributed to
> > heirs/debtors upon death. 
> > 
> > 
> >> I'm really lost. Anyway, if it's a non-issue, just let me know?
> >> Thanks.
> >>
> >> Don't need to brief me about open source and GPL/LGPL, I already
> know
> >> all that.
> >>
> >> Jonathon
> >>
> >> Chris Howe wrote:
> >>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> >>> <snip>
> >>>> I reviewed patches for Anil and Ashish - that is correct. 
> There's
> >> no
> >>>>  
> >>>> fancy partnership here - nor is there any any legal concern, but
>  
> >>>> that's truly not what this discussion should be about.
> >>>>
> >>> <snip>
> >>>
> >>> You're absolutely correct that there isn't a _fancy partnership
> >>> present.  The partnership created is the same mundane one that is
> >>> created every day.  I must disagree with you, it is of GREAT
> legal
> >>> concern.  Since you obviously did not follow the link of
> background
> 
=== message truncated ===

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

[Jonathon -- Improov <jo...@improov.com>]

Chris,

Ugh. Remind me never to take up law. (Yeah, I know, I'll be cannon fodder for big boys with lawyers.)

 > This structure, however does not protect the contributor (you) of a
 > joint work.

Ok. So if I stole someone else's private work and contributed it to a committer who commits this 
stolen work to ASF, then I'm liable for the theft, and ASF and the committer are not liable.

That'll also mean I better make sure that the contributions put into my private sandbox are not 
stolen as well. I'll just follow ASF's "license grant" process, so I won't be liable for any 
thefts committed by contributors in my sandbox team.

 > The only way as I see around this is to have a specific agreement
 > amongst all joint owners allowing for its distribution under Apache
 > 2.

Alright. So I just need to make sure all those committing to my ragtag sandbox assigns rights to 
ASF to distribute their contributions under Apache 2.

 > Not a pretty pickle.

No, it's not pretty to software vendors, OFBiz consultants needing money for a living, etc. But 
that's not my concern. I leave that to businessmen.

 > Does this make my understanding of the scenario clear?

Quite a bit clearer. Thanks.

Jonathon

Chris Howe wrote:
> IMO, this is certainly not a non-issue, it's the issue I've been trying
> to get a definitive answer to for the last few weeks and everyone wants
> to simply ignore it and act like we're a bunch of hippies.  It's fun
> being a hippie until some large corporation comes by and carts your
> commune off their land.  Then you're not a hippie, you're just
> homeless.  
> 
> I've changed my stance slightly contemplating Jonathon's questions.  I
> think this explanation is more correct, consistent and also easier to
> follow.  But again IANAL.
> Comments inline.
> 
> 
> --- Jonathon -- Improov <jo...@improov.com> wrote:
> 
>> David (Jones), Tim, Chris,
>>
>> Sorry, I know this thread isn't about legal issues with OFBiz. But
>> Chris often has a way of 
>> spotting some oft-missed angle, and I'm concerned about a particular
>> angle now. Though I'm also 
>> often lost in his long complex explanations, please forgive me if I
>> feel scared/concerned about 
>> some issues mentioned. Need just a bit of advice here.
>>
>> I'm looking at some excertps from Chris' "findlaw" URL. Please note
>> those words between **.
>>
>> "When the copyright... *provided that the use does not destroy the
>> value of the
>> work* ..."
>>
>> I understand that the ASF license is like the MIT license, so the
>> open sourced codes can be packed 
>> into a commercial package (much like the LGPL?).
>>
> 
> AFAIK, correct.
> 
>> How do I publish codes (assuming I do have a semi-public SVN shared
>> between a few friends) without 
>> damaging that license?
>>
> 
> The license is fine.  The owner of a copyright can write as many
> nonexclusive licenses as he/she/it/they wish.  However, I don't believe
> a joint owner can grant the Apache 2 license to anyone without greatly
> diminishes the financial value of the work itself.  This is further
> compounded by granting the Apache 2 license to the ASF as one of their
> main functions is to distribute that work freely to anyone who points a
> browser or other client software in their direction.
> 
>> "According to the Copyright Act... *a work prepared by two or more
>> authors with the intention that their contributions be merged into
>> inseparable or interdependent parts of a unitary whole*."
>>
>> What if I explicitly mention that I INTEND to merge my private
>> sandbox into OFBiz as a collection 
>> of "interdependent parts of a unitary whole". Will that mean the
>> OFBiz core team and my own ragtag 
>> team become a partnership?
> 
> No. This I believe is the trick of the contributor license agreement.
> Your "patch" is a complete work and you are granting license to anyone
> who has access to JIRA the Apache 2 license.  The committers of OFBiz
> as individuals accept your complete work and make a contribution to the
> ASF project under the terms of the CLA.  The only interaction with the
> ASF is between the committer and the ASF, not you.  This, I believe
> protects the ASF to only being subject to cease and desist orders in
> the event of infringement.  This structure should also protect the
> committer as it is their impression the work is being licensed under
> Apache 2.  This structure, however does not protect the contributor
> (you) of a joint work.
> 
> The problem as I see it with your semi-private SVN is that your "patch"
> is not exclusively yours, it's the joint owners.  You as a joint owner
> can license it anyway you want as long as you share the royalties and
> don't diminish its value.  
> 
> Distributing it under Apache 2, diminishes its value. So, only an
> individual entity (individual or corporation) can distribute it under
> Apache 2.  The only way as I see around this is to have a specific
> agreement amongst all joint owners allowing for its distribution under
> Apache 2.  This agreement creates a legally binding partnership and now
> you're subject to the representations and liabilities that the other
> joint owners make regarding the joint work in their licensing to other
> people.  Not a pretty pickle.
> 
> Does this make my understanding of the scenario clear?
> 
> 
> 
> On a side note (from the findlaw article), a copyright holder cannot
> waive their termination right in advance.  This makes for an
> interesting scenario 35 years from now. Perhaps the ASF should
> reconsider the copyright assignment that the FSF has adopted. Although
> then you have to rethink the trick of the CLA.  This could get scary as
> the copyright is owned by the estate and thus can be distributed to
> heirs/debtors upon death. 
> 
> 
>> I'm really lost. Anyway, if it's a non-issue, just let me know?
>> Thanks.
>>
>> Don't need to brief me about open source and GPL/LGPL, I already know
>> all that.
>>
>> Jonathon
>>
>> Chris Howe wrote:
>>> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>>> <snip>
>>>> I reviewed patches for Anil and Ashish - that is correct.  There's
>> no
>>>>  
>>>> fancy partnership here - nor is there any any legal concern, but  
>>>> that's truly not what this discussion should be about.
>>>>
>>> <snip>
>>>
>>> You're absolutely correct that there isn't a _fancy partnership
>>> present.  The partnership created is the same mundane one that is
>>> created every day.  I must disagree with you, it is of GREAT legal
>>> concern.  Since you obviously did not follow the link of background
>>> information I provided David in my reply, I'll take a quote from a
>>> section of http://library.findlaw.com/1999/Jan/1/241478.html
>>>
>>> 'According to the Copyright Act, the authors of a joint work
>> jointly
>>> own the copyright in the work they create. A joint work is defined
>> in
>>> Section 101 of the Copyright Act as "a work prepared by two or more
>>> authors with the intention that their contributions be merged into
>>> inseparable or interdependent parts of a unitary whole."'
>>>
>>> "When the copyright in a work is jointly owned, each joint owner
>> can
>>> use or license the work in the United States without the consent of
>> the
>>> other owner, provided that the use does not destroy the value of
>> the
>>> work and the parties do not have an agreement requiring the consent
>> of
>>> each owner for use or licensing. A joint owner who licenses a work
>> must
>>> share any royalties he or she receives with the other owners."
>>>
>>> If this doesn't sound like what you did with Anil and Ashish, read
>> it
>>> again.  If it doesn't sound dangerous, read it again and then
>> _again
>>> and then consider whether releasing something as "open source"
>> destroys
>>> the value of the work.   It does, there is no doubt about it. 
>> Since a
>>> joint owner who license a work must share any royalties he or she
>>> receives with the other owners, guess what, the owners must share
>> the
>>> liability that a joint owner creates regarding that work.  
>>>
>>> A _fancy partnership would spell out who and how the joint work can
>> be
>>> distributed and be agreed to in writing and the extent to which the
>>> other joint owners can accept liability on behalf of the class of
>> joint
>>> owners.  The _fancy partnership would protect us all.
>>>
>>>> 1. There already is an SVN for managing the OFBiz
>>> Yes, and IMO the only things that should go into that project are
>>> tested contributions that can hopefully be the basis of what
>> someone
>>> can run their business off of.  Half tested, half implemented ideas
>>> should be in a sandbox SVN so that the community can get them ready
>> for
>>> the parent project.
>>>
>>>> 2. You will have to manage mods to the trunk in patches regardless
>> - 
>>>> unless you'd want to go with some vendor branch scheme, which in
>> my  
>>>> experience is WAY more trouble than it's worth.
>>> The sandbox isn't suggesting a branch or a branch structure, so
>> there's
>>> no trouble.  Since the two options are neutral in comparrison in
>> how
>>> they get re assimilated into OFBiz, we should only concern
>> ourselves in
>>> the easiest manner to incorporate the contribution into the teams
>>> (using someone else's word).  That is SVN by a long shot over JIRA
>>> patches.
>>>
>>>> 3. Why can't you play on your own box like the rest of us - and
>> only 
>>>> submit (or commit) when you have something to say that you want  
>>>> reviewed or to be shared?
>>> That is the whole point of the discussion, no one is playing on
>> their
>>> own box.  You, Anil and Ashish aren't, the ofbiz-sandbox project on
>>> sourceforge would not be and the proposed platform of the
>> developers
>>> conference will not be.  
>>>
>>> Currently, the only _safe manner for a non committer to collaborate
>> on
>>> his own box is to 
>>>
>>> download from Apache Ofbiz, 
>>> upload to JIRA, 
>>> have your collaborator download from JIRA, 
>>> make sure the patch works because you two may be using different
>>> revisions
>>> make changes
>>> then upload to JIRA, 
>>> you download from JIRA, 
>>> make sure the patch works because you two may be using different
>>> revisions
>>> and so on...
>>>
>>> Committers only have the additional benefit of using
>> labs.apache.org or
>>> trunk instead of patches.  This limits their possible collaborators
>> to
>>> other committers.
>>>
>>>> Chris, know that I feel you here, but why don't we just try this
>> and 
>>>> see how it goes?  If you end up having a huge following for these 
>>>> types of things, then I'll be the first person backing you and
>> doing 
>>>> the leg work to put more infrastructure in place will be most  
>>>> beneficial.
>>> I've been trying it in the manner suggested by David in my spare
>> time
>>> for the past two years.  Other's aren't so patient and have simply
>>> moved on.  And yes, it does work somewhat, but it could work a lot
>>> better and without us having to cross our fingers, hoping no one
>> tries
>>> to sabotage the project.  
>>>
>>> Depending on your definition of "huge" it already exists. (this
>> also
>>> answers someone's question earlier on who the groups were)
>>> 1. Those wanting to develop google checkout
>>>   has code, but has been lost because Phani apparently has since
>>> stopped monitoring the mailing lists.
>>> 2. Those wanting more modularization between the components
>>>   has code, not sure where to contribute it because of the legal
>>> scenario
>>> 3. The upcoming developer's "hackathon"
>>>   will undoubtedly have code and will be contributed in a manner
>> that
>>> is subject to all the questions I have been asking.
>>> 4. Those wanting to refactor the create order process
>>>   has code, been contributed to JIRA, though because it's a patch
>> will
>>> only attract those that are _really committed to the topic and not
>>> those that have a passing interest.
>>> 5. Jonathon's rag tag team
>>>   Jonathon claims it has lots of code
> === message truncated ===
> 
> 

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

[Chris Howe <cj...@yahoo.com>]

IMO, this is certainly not a non-issue, it's the issue I've been trying
to get a definitive answer to for the last few weeks and everyone wants
to simply ignore it and act like we're a bunch of hippies.  It's fun
being a hippie until some large corporation comes by and carts your
commune off their land.  Then you're not a hippie, you're just
homeless.  

I've changed my stance slightly contemplating Jonathon's questions.  I
think this explanation is more correct, consistent and also easier to
follow.  But again IANAL.
Comments inline.


--- Jonathon -- Improov <jo...@improov.com> wrote:

> David (Jones), Tim, Chris,
> 
> Sorry, I know this thread isn't about legal issues with OFBiz. But
> Chris often has a way of 
> spotting some oft-missed angle, and I'm concerned about a particular
> angle now. Though I'm also 
> often lost in his long complex explanations, please forgive me if I
> feel scared/concerned about 
> some issues mentioned. Need just a bit of advice here.
> 
> I'm looking at some excertps from Chris' "findlaw" URL. Please note
> those words between **.
> 
> "When the copyright... *provided that the use does not destroy the
> value of the
> work* ..."
> 
> I understand that the ASF license is like the MIT license, so the
> open sourced codes can be packed 
> into a commercial package (much like the LGPL?).
> 

AFAIK, correct.

> How do I publish codes (assuming I do have a semi-public SVN shared
> between a few friends) without 
> damaging that license?
> 

The license is fine.  The owner of a copyright can write as many
nonexclusive licenses as he/she/it/they wish.  However, I don't believe
a joint owner can grant the Apache 2 license to anyone without greatly
diminishes the financial value of the work itself.  This is further
compounded by granting the Apache 2 license to the ASF as one of their
main functions is to distribute that work freely to anyone who points a
browser or other client software in their direction.

> "According to the Copyright Act... *a work prepared by two or more
> authors with the intention that their contributions be merged into
> inseparable or interdependent parts of a unitary whole*."
> 
> What if I explicitly mention that I INTEND to merge my private
> sandbox into OFBiz as a collection 
> of "interdependent parts of a unitary whole". Will that mean the
> OFBiz core team and my own ragtag 
> team become a partnership?

No. This I believe is the trick of the contributor license agreement.
Your "patch" is a complete work and you are granting license to anyone
who has access to JIRA the Apache 2 license.  The committers of OFBiz
as individuals accept your complete work and make a contribution to the
ASF project under the terms of the CLA.  The only interaction with the
ASF is between the committer and the ASF, not you.  This, I believe
protects the ASF to only being subject to cease and desist orders in
the event of infringement.  This structure should also protect the
committer as it is their impression the work is being licensed under
Apache 2.  This structure, however does not protect the contributor
(you) of a joint work.

The problem as I see it with your semi-private SVN is that your "patch"
is not exclusively yours, it's the joint owners.  You as a joint owner
can license it anyway you want as long as you share the royalties and
don't diminish its value.  

Distributing it under Apache 2, diminishes its value. So, only an
individual entity (individual or corporation) can distribute it under
Apache 2.  The only way as I see around this is to have a specific
agreement amongst all joint owners allowing for its distribution under
Apache 2.  This agreement creates a legally binding partnership and now
you're subject to the representations and liabilities that the other
joint owners make regarding the joint work in their licensing to other
people.  Not a pretty pickle.

Does this make my understanding of the scenario clear?



On a side note (from the findlaw article), a copyright holder cannot
waive their termination right in advance.  This makes for an
interesting scenario 35 years from now. Perhaps the ASF should
reconsider the copyright assignment that the FSF has adopted. Although
then you have to rethink the trick of the CLA.  This could get scary as
the copyright is owned by the estate and thus can be distributed to
heirs/debtors upon death. 


> 
> I'm really lost. Anyway, if it's a non-issue, just let me know?
> Thanks.
> 
> Don't need to brief me about open source and GPL/LGPL, I already know
> all that.
> 
> Jonathon
> 
> Chris Howe wrote:
> > --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> > <snip>
> >> I reviewed patches for Anil and Ashish - that is correct.  There's
> no
> >>  
> >> fancy partnership here - nor is there any any legal concern, but  
> >> that's truly not what this discussion should be about.
> >>
> > <snip>
> > 
> > You're absolutely correct that there isn't a _fancy partnership
> > present.  The partnership created is the same mundane one that is
> > created every day.  I must disagree with you, it is of GREAT legal
> > concern.  Since you obviously did not follow the link of background
> > information I provided David in my reply, I'll take a quote from a
> > section of http://library.findlaw.com/1999/Jan/1/241478.html
> > 
> > 'According to the Copyright Act, the authors of a joint work
> jointly
> > own the copyright in the work they create. A joint work is defined
> in
> > Section 101 of the Copyright Act as "a work prepared by two or more
> > authors with the intention that their contributions be merged into
> > inseparable or interdependent parts of a unitary whole."'
> > 
> > "When the copyright in a work is jointly owned, each joint owner
> can
> > use or license the work in the United States without the consent of
> the
> > other owner, provided that the use does not destroy the value of
> the
> > work and the parties do not have an agreement requiring the consent
> of
> > each owner for use or licensing. A joint owner who licenses a work
> must
> > share any royalties he or she receives with the other owners."
> > 
> > If this doesn't sound like what you did with Anil and Ashish, read
> it
> > again.  If it doesn't sound dangerous, read it again and then
> _again
> > and then consider whether releasing something as "open source"
> destroys
> > the value of the work.   It does, there is no doubt about it. 
> Since a
> > joint owner who license a work must share any royalties he or she
> > receives with the other owners, guess what, the owners must share
> the
> > liability that a joint owner creates regarding that work.  
> > 
> > A _fancy partnership would spell out who and how the joint work can
> be
> > distributed and be agreed to in writing and the extent to which the
> > other joint owners can accept liability on behalf of the class of
> joint
> > owners.  The _fancy partnership would protect us all.
> > 
> >> 1. There already is an SVN for managing the OFBiz
> > Yes, and IMO the only things that should go into that project are
> > tested contributions that can hopefully be the basis of what
> someone
> > can run their business off of.  Half tested, half implemented ideas
> > should be in a sandbox SVN so that the community can get them ready
> for
> > the parent project.
> > 
> >> 2. You will have to manage mods to the trunk in patches regardless
> - 
> >>
> >> unless you'd want to go with some vendor branch scheme, which in
> my  
> >> experience is WAY more trouble than it's worth.
> > 
> > The sandbox isn't suggesting a branch or a branch structure, so
> there's
> > no trouble.  Since the two options are neutral in comparrison in
> how
> > they get re assimilated into OFBiz, we should only concern
> ourselves in
> > the easiest manner to incorporate the contribution into the teams
> > (using someone else's word).  That is SVN by a long shot over JIRA
> > patches.
> > 
> >> 3. Why can't you play on your own box like the rest of us - and
> only 
> >>
> >> submit (or commit) when you have something to say that you want  
> >> reviewed or to be shared?
> > 
> > That is the whole point of the discussion, no one is playing on
> their
> > own box.  You, Anil and Ashish aren't, the ofbiz-sandbox project on
> > sourceforge would not be and the proposed platform of the
> developers
> > conference will not be.  
> > 
> > Currently, the only _safe manner for a non committer to collaborate
> on
> > his own box is to 
> > 
> > download from Apache Ofbiz, 
> > upload to JIRA, 
> > have your collaborator download from JIRA, 
> > make sure the patch works because you two may be using different
> > revisions
> > make changes
> > then upload to JIRA, 
> > you download from JIRA, 
> > make sure the patch works because you two may be using different
> > revisions
> > and so on...
> > 
> > Committers only have the additional benefit of using
> labs.apache.org or
> > trunk instead of patches.  This limits their possible collaborators
> to
> > other committers.
> > 
> >> Chris, know that I feel you here, but why don't we just try this
> and 
> >>
> >> see how it goes?  If you end up having a huge following for these 
> 
> >> types of things, then I'll be the first person backing you and
> doing 
> >>
> >> the leg work to put more infrastructure in place will be most  
> >> beneficial.
> > 
> > I've been trying it in the manner suggested by David in my spare
> time
> > for the past two years.  Other's aren't so patient and have simply
> > moved on.  And yes, it does work somewhat, but it could work a lot
> > better and without us having to cross our fingers, hoping no one
> tries
> > to sabotage the project.  
> > 
> > Depending on your definition of "huge" it already exists. (this
> also
> > answers someone's question earlier on who the groups were)
> > 1. Those wanting to develop google checkout
> >   has code, but has been lost because Phani apparently has since
> > stopped monitoring the mailing lists.
> > 2. Those wanting more modularization between the components
> >   has code, not sure where to contribute it because of the legal
> > scenario
> > 3. The upcoming developer's "hackathon"
> >   will undoubtedly have code and will be contributed in a manner
> that
> > is subject to all the questions I have been asking.
> > 4. Those wanting to refactor the create order process
> >   has code, been contributed to JIRA, though because it's a patch
> will
> > only attract those that are _really committed to the topic and not
> > those that have a passing interest.
> > 5. Jonathon's rag tag team
> >   Jonathon claims it has lots of code
> 
=== message truncated ===

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

[Jonathon -- Improov <jo...@improov.com>]

David (Jones), Tim, Chris,

Sorry, I know this thread isn't about legal issues with OFBiz. But Chris often has a way of 
spotting some oft-missed angle, and I'm concerned about a particular angle now. Though I'm also 
often lost in his long complex explanations, please forgive me if I feel scared/concerned about 
some issues mentioned. Need just a bit of advice here.

I'm looking at some excertps from Chris' "findlaw" URL. Please note those words between **.

"When the copyright... *provided that the use does not destroy the value of the
work* ..."

I understand that the ASF license is like the MIT license, so the open sourced codes can be packed 
into a commercial package (much like the LGPL?).

How do I publish codes (assuming I do have a semi-public SVN shared between a few friends) without 
damaging that license?

"According to the Copyright Act... *a work prepared by two or more
authors with the intention that their contributions be merged into
inseparable or interdependent parts of a unitary whole*."

What if I explicitly mention that I INTEND to merge my private sandbox into OFBiz as a collection 
of "interdependent parts of a unitary whole". Will that mean the OFBiz core team and my own ragtag 
team become a partnership?

I'm really lost. Anyway, if it's a non-issue, just let me know? Thanks.

Don't need to brief me about open source and GPL/LGPL, I already know all that.

Jonathon

Chris Howe wrote:
> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
> <snip>
>> I reviewed patches for Anil and Ashish - that is correct.  There's no
>>  
>> fancy partnership here - nor is there any any legal concern, but  
>> that's truly not what this discussion should be about.
>>
> <snip>
> 
> You're absolutely correct that there isn't a _fancy partnership
> present.  The partnership created is the same mundane one that is
> created every day.  I must disagree with you, it is of GREAT legal
> concern.  Since you obviously did not follow the link of background
> information I provided David in my reply, I'll take a quote from a
> section of http://library.findlaw.com/1999/Jan/1/241478.html
> 
> 'According to the Copyright Act, the authors of a joint work jointly
> own the copyright in the work they create. A joint work is defined in
> Section 101 of the Copyright Act as "a work prepared by two or more
> authors with the intention that their contributions be merged into
> inseparable or interdependent parts of a unitary whole."'
> 
> "When the copyright in a work is jointly owned, each joint owner can
> use or license the work in the United States without the consent of the
> other owner, provided that the use does not destroy the value of the
> work and the parties do not have an agreement requiring the consent of
> each owner for use or licensing. A joint owner who licenses a work must
> share any royalties he or she receives with the other owners."
> 
> If this doesn't sound like what you did with Anil and Ashish, read it
> again.  If it doesn't sound dangerous, read it again and then _again
> and then consider whether releasing something as "open source" destroys
> the value of the work.   It does, there is no doubt about it.  Since a
> joint owner who license a work must share any royalties he or she
> receives with the other owners, guess what, the owners must share the
> liability that a joint owner creates regarding that work.  
> 
> A _fancy partnership would spell out who and how the joint work can be
> distributed and be agreed to in writing and the extent to which the
> other joint owners can accept liability on behalf of the class of joint
> owners.  The _fancy partnership would protect us all.
> 
>> 1. There already is an SVN for managing the OFBiz
> Yes, and IMO the only things that should go into that project are
> tested contributions that can hopefully be the basis of what someone
> can run their business off of.  Half tested, half implemented ideas
> should be in a sandbox SVN so that the community can get them ready for
> the parent project.
> 
>> 2. You will have to manage mods to the trunk in patches regardless - 
>>
>> unless you'd want to go with some vendor branch scheme, which in my  
>> experience is WAY more trouble than it's worth.
> 
> The sandbox isn't suggesting a branch or a branch structure, so there's
> no trouble.  Since the two options are neutral in comparrison in how
> they get re assimilated into OFBiz, we should only concern ourselves in
> the easiest manner to incorporate the contribution into the teams
> (using someone else's word).  That is SVN by a long shot over JIRA
> patches.
> 
>> 3. Why can't you play on your own box like the rest of us - and only 
>>
>> submit (or commit) when you have something to say that you want  
>> reviewed or to be shared?
> 
> That is the whole point of the discussion, no one is playing on their
> own box.  You, Anil and Ashish aren't, the ofbiz-sandbox project on
> sourceforge would not be and the proposed platform of the developers
> conference will not be.  
> 
> Currently, the only _safe manner for a non committer to collaborate on
> his own box is to 
> 
> download from Apache Ofbiz, 
> upload to JIRA, 
> have your collaborator download from JIRA, 
> make sure the patch works because you two may be using different
> revisions
> make changes
> then upload to JIRA, 
> you download from JIRA, 
> make sure the patch works because you two may be using different
> revisions
> and so on...
> 
> Committers only have the additional benefit of using labs.apache.org or
> trunk instead of patches.  This limits their possible collaborators to
> other committers.
> 
>> Chris, know that I feel you here, but why don't we just try this and 
>>
>> see how it goes?  If you end up having a huge following for these  
>> types of things, then I'll be the first person backing you and doing 
>>
>> the leg work to put more infrastructure in place will be most  
>> beneficial.
> 
> I've been trying it in the manner suggested by David in my spare time
> for the past two years.  Other's aren't so patient and have simply
> moved on.  And yes, it does work somewhat, but it could work a lot
> better and without us having to cross our fingers, hoping no one tries
> to sabotage the project.  
> 
> Depending on your definition of "huge" it already exists. (this also
> answers someone's question earlier on who the groups were)
> 1. Those wanting to develop google checkout
>   has code, but has been lost because Phani apparently has since
> stopped monitoring the mailing lists.
> 2. Those wanting more modularization between the components
>   has code, not sure where to contribute it because of the legal
> scenario
> 3. The upcoming developer's "hackathon"
>   will undoubtedly have code and will be contributed in a manner that
> is subject to all the questions I have been asking.
> 4. Those wanting to refactor the create order process
>   has code, been contributed to JIRA, though because it's a patch will
> only attract those that are _really committed to the topic and not
> those that have a passing interest.
> 5. Jonathon's rag tag team
>   Jonathon claims it has lots of code
> 6. Anil and Ashish's asset management that's utilizing
> code.google.com/hosting
>   has 54 revisions, I don't know Anil's and Ashish's relationship, but
> it would appear that it will need to answer the same legal questions
> I've been asking to make it back into the project.
> 7. I understand Daniel K is wanting to collaborate on something
>   I think he's wanting to learn by doing, but I don't know specifically
> what he has in mind at this point.
> 8. Those that responded they wanted to help get Asterisk PBX
> integration
>   Code in SVN.  Has functionality but could blow the socks off of
> someone with some collaborative work
> 9. Those wanting to refactor PartyRelationship
>   has code, at the moment has gotten too specific to be beneficial to
> the community
> 10. Those wanting to collaborate on Business Intelligence
>   there's a writeup on docs.ofbiz.org on how to kind of integrate openi
> with ofbiz.  Someone contributed a bit of code, I believe to the ML. 
> And Si Chen had made mention of completing some OLAP cubes based on the
> openi writeup
> 
> These are just the instances I can think of off the top of my head. 
> There's my huge following, so where's your backing?
> 
> Regards, 
> Chris
> 
> 

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

[Chris Howe <cj...@yahoo.com>]

--- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
<snip>
> 
> I reviewed patches for Anil and Ashish - that is correct.  There's no
>  
> fancy partnership here - nor is there any any legal concern, but  
> that's truly not what this discussion should be about.
> 
<snip>

You're absolutely correct that there isn't a _fancy partnership
present.  The partnership created is the same mundane one that is
created every day.  I must disagree with you, it is of GREAT legal
concern.  Since you obviously did not follow the link of background
information I provided David in my reply, I'll take a quote from a
section of http://library.findlaw.com/1999/Jan/1/241478.html

'According to the Copyright Act, the authors of a joint work jointly
own the copyright in the work they create. A joint work is defined in
Section 101 of the Copyright Act as "a work prepared by two or more
authors with the intention that their contributions be merged into
inseparable or interdependent parts of a unitary whole."'

"When the copyright in a work is jointly owned, each joint owner can
use or license the work in the United States without the consent of the
other owner, provided that the use does not destroy the value of the
work and the parties do not have an agreement requiring the consent of
each owner for use or licensing. A joint owner who licenses a work must
share any royalties he or she receives with the other owners."

If this doesn't sound like what you did with Anil and Ashish, read it
again.  If it doesn't sound dangerous, read it again and then _again
and then consider whether releasing something as "open source" destroys
the value of the work.   It does, there is no doubt about it.  Since a
joint owner who license a work must share any royalties he or she
receives with the other owners, guess what, the owners must share the
liability that a joint owner creates regarding that work.  

A _fancy partnership would spell out who and how the joint work can be
distributed and be agreed to in writing and the extent to which the
other joint owners can accept liability on behalf of the class of joint
owners.  The _fancy partnership would protect us all.

> 1. There already is an SVN for managing the OFBiz
Yes, and IMO the only things that should go into that project are
tested contributions that can hopefully be the basis of what someone
can run their business off of.  Half tested, half implemented ideas
should be in a sandbox SVN so that the community can get them ready for
the parent project.

> 2. You will have to manage mods to the trunk in patches regardless - 
> 
> unless you'd want to go with some vendor branch scheme, which in my  
> experience is WAY more trouble than it's worth.

The sandbox isn't suggesting a branch or a branch structure, so there's
no trouble.  Since the two options are neutral in comparrison in how
they get re assimilated into OFBiz, we should only concern ourselves in
the easiest manner to incorporate the contribution into the teams
(using someone else's word).  That is SVN by a long shot over JIRA
patches.

> 3. Why can't you play on your own box like the rest of us - and only 
> 
> submit (or commit) when you have something to say that you want  
> reviewed or to be shared?

That is the whole point of the discussion, no one is playing on their
own box.  You, Anil and Ashish aren't, the ofbiz-sandbox project on
sourceforge would not be and the proposed platform of the developers
conference will not be.  

Currently, the only _safe manner for a non committer to collaborate on
his own box is to 

download from Apache Ofbiz, 
upload to JIRA, 
have your collaborator download from JIRA, 
make sure the patch works because you two may be using different
revisions
make changes
then upload to JIRA, 
you download from JIRA, 
make sure the patch works because you two may be using different
revisions
and so on...

Committers only have the additional benefit of using labs.apache.org or
trunk instead of patches.  This limits their possible collaborators to
other committers.

> Chris, know that I feel you here, but why don't we just try this and 
> 
> see how it goes?  If you end up having a huge following for these  
> types of things, then I'll be the first person backing you and doing 
> 
> the leg work to put more infrastructure in place will be most  
> beneficial.

I've been trying it in the manner suggested by David in my spare time
for the past two years.  Other's aren't so patient and have simply
moved on.  And yes, it does work somewhat, but it could work a lot
better and without us having to cross our fingers, hoping no one tries
to sabotage the project.  

Depending on your definition of "huge" it already exists. (this also
answers someone's question earlier on who the groups were)
1. Those wanting to develop google checkout
  has code, but has been lost because Phani apparently has since
stopped monitoring the mailing lists.
2. Those wanting more modularization between the components
  has code, not sure where to contribute it because of the legal
scenario
3. The upcoming developer's "hackathon"
  will undoubtedly have code and will be contributed in a manner that
is subject to all the questions I have been asking.
4. Those wanting to refactor the create order process
  has code, been contributed to JIRA, though because it's a patch will
only attract those that are _really committed to the topic and not
those that have a passing interest.
5. Jonathon's rag tag team
  Jonathon claims it has lots of code
6. Anil and Ashish's asset management that's utilizing
code.google.com/hosting
  has 54 revisions, I don't know Anil's and Ashish's relationship, but
it would appear that it will need to answer the same legal questions
I've been asking to make it back into the project.
7. I understand Daniel K is wanting to collaborate on something
  I think he's wanting to learn by doing, but I don't know specifically
what he has in mind at this point.
8. Those that responded they wanted to help get Asterisk PBX
integration
  Code in SVN.  Has functionality but could blow the socks off of
someone with some collaborative work
9. Those wanting to refactor PartyRelationship
  has code, at the moment has gotten too specific to be beneficial to
the community
10. Those wanting to collaborate on Business Intelligence
  there's a writeup on docs.ofbiz.org on how to kind of integrate openi
with ofbiz.  Someone contributed a bit of code, I believe to the ML. 
And Si Chen had made mention of completing some OLAP cubes based on the
openi writeup

These are just the instances I can think of off the top of my head. 
There's my huge following, so where's your backing?

Regards, 
Chris

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

Comments inline - lemme preface this with the fact that these are my  
thoughts, I'll support whatever we can do to help people be more  
active, but I don't have time to deliberate this over email for too  
much longer . . . I hope everyone understands

On Jan 26, 2007, at 10:02 AM, Chris Howe wrote:

> Tim,
>
> If Anil and Ashish wrote anything in OFBIZ-510, then that's not
> _exactly how anon checkout was created.  By quick glance, of the 61
> messages containing the words OFBIZ-510 in them, you were the only one
> who attached a patch, Anil and Ashish did not.  You three may have
> passed patches amongst yourselves outside of the JIRA issue.  My
> understanding is this constitutes collaboration and therefore the  
> asset
> you created is owned by the informal partnership between you three,  
> not
> one individual and not the ASF.
>

I reviewed patches for Anil and Ashish - that is correct.  There's no  
fancy partnership here - nor is there any any legal concern, but  
that's truly not what this discussion should be about.

> In regards to the patches vs SVN argument, I am not following your
> logic at all.  SVN is a tool to manage patches.  That's what it is,
> that's what it does.  How could individual patches be easier to
> maintain than the tool that is designed to do that maintenance? Are  
> you
> talking about the collaboration part or just the part to merge back
> into OFBiz?

The point that I obviously didn't articulate very clearly is this :

1. There already is an SVN for managing the OFBiz
2. You will have to manage mods to the trunk in patches regardless -  
unless you'd want to go with some vendor branch scheme, which in my  
experience is WAY more trouble than it's worth.
3. Why can't you play on your own box like the rest of us - and only  
submit (or commit) when you have something to say that you want  
reviewed or to be shared?

>
> A liberal sub-project SVN does not require patches be attached to a
> JIRA issue until it's at a point to be contributed back into the major
> work.  The collaborator simply commits his change.  That's what a
> sandbox is for, to play in.  Unlike OFBiz itself, no one should expect
> that the sandbox work.  At the time when it does work and it is
> necessary to merge those changes back into the parent project, it will
> require a single patch. Which because of the way OFBiz is set up, is
> fairly small work.  That patch should have most bugs worked out and
> testing is small work.
>

Chris, know that I feel you here, but why don't we just try this and  
see how it goes?  If you end up having a huge following for these  
types of things, then I'll be the first person backing you and doing  
the leg work to put more infrastructure in place will be most  
beneficial.

Cheers,
Tim

> --- Tim Ruppert <ti...@hotwaxmedia.com> wrote:
>
>> I know this sounds overly simplified, but someone please explain to
>> me why this doesn't work:
>>
>> 1. Someone - let's say Chris has a great idea for a new project
>> 2. He creates a JIRA issue describing it
>> 3. He attaches an initial patch
>> 4. Someone else - let's say Daniel decides that he wants to
>> contribute to this effort and downloads the patch
>> 5. He makes some improvements, so he updates the existing patch as
>> well as adds another patch containing additional data
>> 6. Chris downloads it and makes some mods and reposts.
>>
>> Now, to me this doesn't seem that crazy - and is totally legal.
>> And . . . just so you know - replace Chris with Tim and Daniel with
>> either Anil or Ashish and you have EXACTLY what happened with the
>> anonymous checkout process!
>>
>> This shouldn't be this hard guys.  My suggestion would be to TRY one
>>
>> of these in this format and if you can't do it this way - THEN let's
>>
>> try and address it.  A separately maintained sandbox is absolutely no
>>
>> different  than managing patches - since both have to deal with
>> integration back into the OFBiz trunk in some form or fashion.
>>
>> Personally, I think the patches will be EASIER to maintain because
>> they will allow you to make changes to existing code in an easier,
>> more trackable format.  The alternative would be for you to maintain
>>
>> a sandbox - AND patches for updates to the source - doesn't that
>> sound MORE tedious?
>>
>> Anyways, thanks for listening to my ramble.
>>
>> Cheers,
>> Tim
>> --
>> Tim Ruppert
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> o:801.649.6594
>> f:801.649.6595
>>
>> On Jan 26, 2007, at 3:04 AM, 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
>>>> think about doing this under the ASF umbrella because I am not
>>>> willing to take on the responsibility of vetting a large number of
>>>> committers and recommending them as committers in the ASF, which
>> is
>>>> BIG DEAL, and a responsibility and some people seem to be
>> forgetting
>>>> that.
>>>>
>>>> If you want to be a committer you have to help with the project.
>> You
>>>> have to take ownership of it, defend it, be committed to it, and
>> so
>>>> on. Okay, now I'm doing what I was in the 2 page email I just
>> deleted
>>>> and I'm stopping.
>>>>
>>>> If you want to know more about becoming and being a committer and
>>>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>>
>>
> === message truncated ===
>

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

[Chris Howe <cj...@yahoo.com>]

Tim, 

If Anil and Ashish wrote anything in OFBIZ-510, then that's not
_exactly how anon checkout was created.  By quick glance, of the 61
messages containing the words OFBIZ-510 in them, you were the only one
who attached a patch, Anil and Ashish did not.  You three may have
passed patches amongst yourselves outside of the JIRA issue.  My
understanding is this constitutes collaboration and therefore the asset
you created is owned by the informal partnership between you three, not
one individual and not the ASF.

In regards to the patches vs SVN argument, I am not following your
logic at all.  SVN is a tool to manage patches.  That's what it is,
that's what it does.  How could individual patches be easier to
maintain than the tool that is designed to do that maintenance? Are you
talking about the collaboration part or just the part to merge back
into OFBiz?

A liberal sub-project SVN does not require patches be attached to a
JIRA issue until it's at a point to be contributed back into the major
work.  The collaborator simply commits his change.  That's what a
sandbox is for, to play in.  Unlike OFBiz itself, no one should expect
that the sandbox work.  At the time when it does work and it is
necessary to merge those changes back into the parent project, it will
require a single patch. Which because of the way OFBiz is set up, is
fairly small work.  That patch should have most bugs worked out and
testing is small work.

--- Tim Ruppert <ti...@hotwaxmedia.com> wrote:

> I know this sounds overly simplified, but someone please explain to  
> me why this doesn't work:
> 
> 1. Someone - let's say Chris has a great idea for a new project
> 2. He creates a JIRA issue describing it
> 3. He attaches an initial patch
> 4. Someone else - let's say Daniel decides that he wants to  
> contribute to this effort and downloads the patch
> 5. He makes some improvements, so he updates the existing patch as  
> well as adds another patch containing additional data
> 6. Chris downloads it and makes some mods and reposts.
> 
> Now, to me this doesn't seem that crazy - and is totally legal.   
> And . . . just so you know - replace Chris with Tim and Daniel with  
> either Anil or Ashish and you have EXACTLY what happened with the  
> anonymous checkout process!
> 
> This shouldn't be this hard guys.  My suggestion would be to TRY one 
> 
> of these in this format and if you can't do it this way - THEN let's 
> 
> try and address it.  A separately maintained sandbox is absolutely no
>  
> different  than managing patches - since both have to deal with  
> integration back into the OFBiz trunk in some form or fashion.
> 
> Personally, I think the patches will be EASIER to maintain because  
> they will allow you to make changes to existing code in an easier,  
> more trackable format.  The alternative would be for you to maintain 
> 
> a sandbox - AND patches for updates to the source - doesn't that  
> sound MORE tedious?
> 
> Anyways, thanks for listening to my ramble.
> 
> Cheers,
> Tim
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
> 
> o:801.649.6594
> f:801.649.6595
> 
> On Jan 26, 2007, at 3:04 AM, 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
> >> think about doing this under the ASF umbrella because I am not
> >> willing to take on the responsibility of vetting a large number of
> >> committers and recommending them as committers in the ASF, which
> is
> >> BIG DEAL, and a responsibility and some people seem to be
> forgetting
> >> that.
> >>
> >> If you want to be a committer you have to help with the project.
> You
> >> have to take ownership of it, defend it, be committed to it, and
> so
> >> on. Okay, now I'm doing what I was in the 2 page email I just
> deleted
> >> and I'm stopping.
> >>
> >> If you want to know more about becoming and being a committer and
> >> about contributing to OFBiz, READ THE DARN DOCUMENTS!
> >>
> 
=== message truncated ===

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

[Tim Ruppert <ti...@hotwaxmedia.com>]

I know this sounds overly simplified, but someone please explain to  
me why this doesn't work:

1. Someone - let's say Chris has a great idea for a new project
2. He creates a JIRA issue describing it
3. He attaches an initial patch
4. Someone else - let's say Daniel decides that he wants to  
contribute to this effort and downloads the patch
5. He makes some improvements, so he updates the existing patch as  
well as adds another patch containing additional data
6. Chris downloads it and makes some mods and reposts.

Now, to me this doesn't seem that crazy - and is totally legal.   
And . . . just so you know - replace Chris with Tim and Daniel with  
either Anil or Ashish and you have EXACTLY what happened with the  
anonymous checkout process!

This shouldn't be this hard guys.  My suggestion would be to TRY one  
of these in this format and if you can't do it this way - THEN let's  
try and address it.  A separately maintained sandbox is absolutely no  
different  than managing patches - since both have to deal with  
integration back into the OFBiz trunk in some form or fashion.

Personally, I think the patches will be EASIER to maintain because  
they will allow you to make changes to existing code in an easier,  
more trackable format.  The alternative would be for you to maintain  
a sandbox - AND patches for updates to the source - doesn't that  
sound MORE tedious?

Anyways, thanks for listening to my ramble.

Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

On Jan 26, 2007, at 3:04 AM, 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
>> think about doing this under the ASF umbrella because I am not
>> willing to take on the responsibility of vetting a large number of
>> committers and recommending them as committers in the ASF, which is
>> BIG DEAL, and a responsibility and some people seem to be forgetting
>> that.
>>
>> If you want to be a committer you have to help with the project. You
>> have to take ownership of it, defend it, be committed to it, and so
>> on. Okay, now I'm doing what I was in the 2 page email I just deleted
>> and I'm stopping.
>>
>> If you want to know more about becoming and being a committer and
>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>
>> I don't know WHY these questions are coming up here. Stop asking
>> them. Read the documents. I won't be baited into this any more. It's
>> a waste of time, and all based on supposition and not any real
>> problems or issues as far as I can see.
>>
>> If you develop something outside of OFBiz and want to contribute it,
>> here is the page describing how it works:
>>
>> http://incubator.apache.org/ip-clearance/index.html
>>
>> This is basically a streamlined incubation process for code going
>> into existing projects.
>>
>> If you really want to help and be involved in the project it means
>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it
>> easier to get your own stuff in but if that is all you're about
>> related to the project, then being a committer isn't for you.
>>
>> If you want to know more about contributing and being a committer,
>> read the docs:
>>
>> http://docs.ofbiz.org/x/mQ
>> http://docs.ofbiz.org/x/r
>>
>> If you want to know more about licensing and legal issues, read the
>> docs:
>>
>> http://incubator.apache.org/incubation/Incubation_Policy.html
>> http://incubator.apache.org/ip-clearance/index.html
>> http://www.apache.org/foundation/how-it-works.html
>> http://www.apache.org/foundation/licence-FAQ.html
>> http://www.apache.org/legal/src-headers.html
>>
>> For a lot of good information, broaden the scope and study under:
>>
>> http://www.apache.org/dev/
>>
>> These were not written because someone was looking for some
>> entertainment. They were written so things wouldn't have to be
>> explained over and over.
>>
>> I'm calling it a day now, as soon as I take care of some real issues,
>> and as long as my son with the flu doesn't throw up again. Sorry,
>> this is really frustrating, and really silly. Reality sucks, but we
>> all have to live with it.
>>
>> If people want to help, then help. Don't just ask for help. Start by
>> being a giver, not a taker.
>>
>> If this sounds a bit harsh, great! Go for a walk and think about how
>> things work in real life, then read it again. If you're still upset,
>> read it again. Then go read all of the documents referenced. Then if
>> you still have a question, send it on in, but PLEASE try to look at
>> it from the point of a MEMBER of the OFBiz community, and not a user
>> of OFBiz who really doesn't want to get involved.
>>
>> If you're asking "how are you going to solve this problem" then
>> you're asking the wrong question. If you want to participate as "how
>> can I solve this problem", if "I" can't, then do with "how can we
>> solve this problem". I don't mean that is what should be in your
>> email, I mean that is what should be in your head. If you can't find
>> an answer yourself that is 100% okay, just start a discussion and
>> accept what you asked for.
>>
>> If you don't like the answer explain why it doesn't work for you,
>> which brings us back to the beginning of this email...
>>
>> -David
>>
>>
>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>
>>> David
>>>
>>> Can you explain your reticence to adding an Apache OFBiz sandbox  
>>> where
>>> more members of the community could share their work?
>>>
>>> I can see this section possibly getting a disorganized over time  
>>> with
>>> *junk*... but it can be deleted easily enough. As a top level  
>>> project
>>> would it possible and better to organize a sub project for this?
>>>
>>> Thanks
>>>
>>> Daniel
>>>
>>>
>>>
>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>> I think we're talking about two different things.  You're talking
>>>> about
>>>> developing and I'm talking about legal issues.  The manner of
>>>> developing was already discussed in OFBIZ-499.  The only legal  
>>>> way to
>>>> use JIRA to collaborate this type of thing is to keep sending  
>>>> updated
>>>> patches to JIRA or to have a committer review and add it to a
>>>> specialized application.  Neither one of these is speed of
>>>> development
>>>> friendly.
>>>>
>>>> Legal concerns wouldn't have been one of the primary driving
>>>> forces of
>>>> moving to the ASF if it were true that "we've done fine for years".
>>>> The project still has technical exposure to a C & D order as the  
>>>> CLA
>>>> only covered works the copyright holder gave directly to the ASF  
>>>> not
>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>> incubation.  IANAL, and I don't think there is significant  
>>>> exposure,
>>>> but it is still there. That opinion isn't based on the vehicle
>>>> used to
>>>> create Apache OFBiz, but on the impression of kindheartedness from
>>>> the
>>>> members of the community prior to incubation.
>>>>
>>>> I don't want to speculate on the legal relationship the group that
>>>> worked on the anon checkout had, but I would suspect that it
>>>> generated
>>>> some negative legal exposure as well and that the proposed setup of
>>>> Developers Conference will add to that.
>>>>
>>>> The only feedback that I've received from the general incubator  
>>>> list
>>>> are speculations, all with the caveat that the poster is not a  
>>>> lawyer
>>>> either and no one has been willing to post it to the legal-discuss
>>>> list.
>>>>
>>>> This issue is one of the MAJOR reasons for the existence of non-
>>>> profit
>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to
>>>> reconsider
>>>> the need of a more public sandbox where this kind of community
>>>> collaboration can be done without the complications of copyright
>>>> infringement, or at the very least pose the question to legal- 
>>>> discuss
>>>> for a formal opinion from those representing the ASF's  
>>>> interests.  It
>>>> is my understanding that when it's added to Apache owned SVN,  
>>>> ASF is
>>>> the copyright holder of the collective work instead of an impromptu
>>>> partnership where the individuals have no legal authority to  
>>>> offer a
>>>> collective work.
>>>>
>>>> Regards,
>>>> Chris
>>>> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
>>>>
>>>>>
>>>>> I REALLY don't think you need a sandbox for this. We've done fine
>>>>> for
>>>>>
>>>>> years without one, even with the recently re-done ecommerce
>>>>> anonymous
>>>>>
>>>>> checkout process and alternative checkout processes which were
>>>>> developed entirely outside of OFBiz.
>>>>>
>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>> doing and having a clear goal to work towards, a design of  
>>>>> sorts if
>>>>> you will. A sandbox won't help that.
>>>>>
>>>>> Once you have a design you can start building it without touching
>>>>> the
>>>>>
>>>>> current stuff, just make it an alternate path and don't break
>>>>> anything existing along the way. Once it is complete, then another
>>>>> patch can go in to remove the old code.
>>>>>
>>>>> It's that simple. That process has been followed well over a  
>>>>> hundred
>>>>>
>>>>> times over the life of OFBiz and even for those with commit access
>>>>> it's the only way to go. If you don't have commit access, it's  
>>>>> even
>>>>> better because you can develop until you're stuck or out of time,
>>>>> then throw in a patch and have it committed without breaking
>>>>> anything
>>>>>
>>>>> else, even if the new thing isn't working 100%.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>
>>>>>> Hey Anil,
>>>>>>
>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>> passing
>>>>>> the cart to a simple method that first checks the order type and
>>>>> then
>>>>>> calls a method or service that is focused on that order type.   
>>>>>> Each
>>>>>> order type service will call a multitude of methods/services that
>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>
>>>>>> I would love to collaborate on this, but because of the size,  
>>>>>> it's
>>>>>> rather difficult to do by passing patches back and forth through
>>>>> JIRA
>>>>>> without having a reference point that SVN provides.  This is  
>>>>>> one of
>>>>>> those things that the ofbiz-sandbox project would be good for,  
>>>>>> but
>>>>> it
>>>>>> still has a legal issue that will prevent it from being entered
>>>>> back
>>>>>> into the project.  I can as an individual grant Apache the  
>>>>>> license
>>>>> it
>>>>>> needs for the work I do, you as an individual can grant Apache  
>>>>>> the
>>>>>> license it needs for the work you do, but without each of us
>>>>> assuming
>>>>>> the liability of a partnership we cannot grant a license for the
>>>>> work
>>>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>>>> and
>>>>>> make patches for each commit and each of us resubmit our own  
>>>>>> patch
>>>>> to
>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>
>>>>>> This would be sooooo much easier if the members of OFBiz PMC  
>>>>>> would
>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>> commit will be licensed to Apache, and Apache will be the  
>>>>>> owner of
>>>>> the
>>>>>> work as a whole instead of an impromptu partnership being the
>>>>> owner.
>>>>>>
>>>>>>
>>>>>> --- Anil Patel <to...@gmail.com> wrote:
>>>>>>
>>>>>>> I planning to participate in this developer conference. I am
>>>>>>> interested in
>>>>>>> contributing towards making Order Entry process more  
>>>>>>> flexible. If
>>>>>>> there are
>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>> request one
>>>>>>> of the commiters who has interest in this to Please lead this
>>>>> effort.
>>>>>>>
>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>> some
>>>>>>> high
>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>> simple
>>>>>>> methods.
>>>>>>> 2) Moving process control logic from event handlers to  
>>>>>>> Controller
>>>>>>> file.
>>>>>>>
>>>>>>> Any Ideas
>>>>>>>
>>>>>>> Regards
>>>>>>> Anil Patel
>>>>>>>
>>>>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>> meant
>>>>>>>> mainly for those who want to be involved with development of
>>>>> OFBiz
>>>>>>>> itself. There will be a variety of projects going on and we  
>>>>>>>> hope
>>>>>>>> everyone will be able to work on both paid and fun stuff,  
>>>>>>>> but the
>>>>>>>> results will all be going right back into OFBiz. Still,  
>>>>>>>> everyone
>>>>> is
>>>>>>>> welcome to attend and join the "party" so if you know of  
>>>>>>>> someone
>>>>>>> who
>>>>>>>> might be interested but isn't subscribed to the dev mailing  
>>>>>>>> list,
>>>>>>>> please forward it on to them.
>>>>>>>>
>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>> development, if you aren't a developer it doesn't mean you  
>>>>>>>> can't
>>>>>>>> come. It would be great to have, for example, people like
>>>>> business
>>>>>>>> analysts and technical writers to help with requirements,  
>>>>>>>> design,
>>>>>>> and
>>>>>>>> documentation and such would be great!
>>>>>>>>
>>>>>>>> Included below is the original email about this, and most of  
>>>>>>>> the
>>>>>>>> information there is still applicable. Here are a few  
>>>>>>>> decisions,
>>>>>>>> based on feedback:
>>>>>>>>
>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday -  
>>>>>>>> Friday),
>>>>>>> and
>>>>>>>> may spill over into Sat the 10th
>>>>>>>>
>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>> recommend
>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>> big-group
>>>>>>>> meetings and any presentations for Wednesday; if you can  
>>>>>>>> come for
>>>>>>> the
>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>
>>>>>>>> 3. people are welcome to come and enjoy local attractions  
>>>>>>>> for the
>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>> here,
>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>> deserts
>>>>>>>> and canyons south of here)
>>>>>>>>
>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff,  
>>>>>>>> etc
>>>>>>> will
>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>> wireless
>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>> access;
>>>>>>> we
>>>>>>>> will have at least 2 projectors and perhaps other large  
>>>>>>>> monitors
>>>>> to
>>>>>>>> facilitate group development and discussion
>>>>>>>>
>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>> we'll
>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>> first
>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>> around
>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>> various
>>>>>>>> restaurants within walking distance
>>>>>>>>
>>>>>>>> 6. the attendance cap is initially 20 people; there seems to  
>>>>>>>> be a
>>>>>>> lot
>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>> perhaps
>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>> building to be for group meeting use as well (we're planning  
>>>>>>>> on 2
>>>>>>> big
>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>
>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>> quite
>>>>>>>> a bit of interest in various things on the original list I
>>>>> included
>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>> project
>>>>>>>> management functionality
>>>>>>>>
>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>> please
>>>>>>>> contact me by email (jonesde@hotwaxmedia.com) with the  
>>>>>>>> following
>>>>>>>> information:
>>>>>>>>
>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>> different
>>>>>>>> than from address)
>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>> with
>>>>>>>> contact info for the nice place close by, or there is a  
>>>>>>>> "fleabag"
>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>> 5. snack/diet preferences
>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>> rent/
>>>>>
>>>> === message truncated ===
>>>>
>>> -- 
>>> Daniel
>>>
>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>> Have a GREAT Day!
>>>
>>> Daniel Kunkel           DanielKunkel@BioWaves.com
>>> BioWaves, LLC           http://www.BioWaves.com
>>> 14150 NE 20th St. Suite F1
>>> Bellevue, WA 98007
>>> 800-734-3588    425-895-0050
>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>> http://www.Card-Offer.com      http://www.RackWine.com
>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>
>>
>

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

[Jacques Le Roux <ja...@les7arts.com>]

Daniel,

Just one very quick point : I do not totally agree about "Jira isn't working.". What is making you think that ? Please can you
elaborate ? From your comment we may find solutions...

Jacques

From: "Daniel Kunkel" <Da...@BioWaves.com>
To: <de...@ofbiz.apache.org>
Sent: Friday, January 26, 2007 11:04 AM
Subject: Re: Refactoring Create Order process during OFBiz DevelopersConference Sponsored by Hotwax Media


> 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
> > think about doing this under the ASF umbrella because I am not
> > willing to take on the responsibility of vetting a large number of
> > committers and recommending them as committers in the ASF, which is
> > BIG DEAL, and a responsibility and some people seem to be forgetting
> > that.
> >
> > If you want to be a committer you have to help with the project. You
> > have to take ownership of it, defend it, be committed to it, and so
> > on. Okay, now I'm doing what I was in the 2 page email I just deleted
> > and I'm stopping.
> >
> > If you want to know more about becoming and being a committer and
> > about contributing to OFBiz, READ THE DARN DOCUMENTS!
> >
> > I don't know WHY these questions are coming up here. Stop asking
> > them. Read the documents. I won't be baited into this any more. It's
> > a waste of time, and all based on supposition and not any real
> > problems or issues as far as I can see.
> >
> > If you develop something outside of OFBiz and want to contribute it,
> > here is the page describing how it works:
> >
> > http://incubator.apache.org/ip-clearance/index.html
> >
> > This is basically a streamlined incubation process for code going
> > into existing projects.
> >
> > If you really want to help and be involved in the project it means
> > working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it
> > easier to get your own stuff in but if that is all you're about
> > related to the project, then being a committer isn't for you.
> >
> > If you want to know more about contributing and being a committer,
> > read the docs:
> >
> > http://docs.ofbiz.org/x/mQ
> > http://docs.ofbiz.org/x/r
> >
> > If you want to know more about licensing and legal issues, read the
> > docs:
> >
> > http://incubator.apache.org/incubation/Incubation_Policy.html
> > http://incubator.apache.org/ip-clearance/index.html
> > http://www.apache.org/foundation/how-it-works.html
> > http://www.apache.org/foundation/licence-FAQ.html
> > http://www.apache.org/legal/src-headers.html
> >
> > For a lot of good information, broaden the scope and study under:
> >
> > http://www.apache.org/dev/
> >
> > These were not written because someone was looking for some
> > entertainment. They were written so things wouldn't have to be
> > explained over and over.
> >
> > I'm calling it a day now, as soon as I take care of some real issues,
> > and as long as my son with the flu doesn't throw up again. Sorry,
> > this is really frustrating, and really silly. Reality sucks, but we
> > all have to live with it.
> >
> > If people want to help, then help. Don't just ask for help. Start by
> > being a giver, not a taker.
> >
> > If this sounds a bit harsh, great! Go for a walk and think about how
> > things work in real life, then read it again. If you're still upset,
> > read it again. Then go read all of the documents referenced. Then if
> > you still have a question, send it on in, but PLEASE try to look at
> > it from the point of a MEMBER of the OFBiz community, and not a user
> > of OFBiz who really doesn't want to get involved.
> >
> > If you're asking "how are you going to solve this problem" then
> > you're asking the wrong question. If you want to participate as "how
> > can I solve this problem", if "I" can't, then do with "how can we
> > solve this problem". I don't mean that is what should be in your
> > email, I mean that is what should be in your head. If you can't find
> > an answer yourself that is 100% okay, just start a discussion and
> > accept what you asked for.
> >
> > If you don't like the answer explain why it doesn't work for you,
> > which brings us back to the beginning of this email...
> >
> > -David
> >
> >
> > On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
> >
> > > David
> > >
> > > Can you explain your reticence to adding an Apache OFBiz sandbox where
> > > more members of the community could share their work?
> > >
> > > I can see this section possibly getting a disorganized over time with
> > > *junk*... but it can be deleted easily enough. As a top level project
> > > would it possible and better to organize a sub project for this?
> > >
> > > Thanks
> > >
> > > Daniel
> > >
> > >
> > >
> > > On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
> > >> I think we're talking about two different things.  You're talking
> > >> about
> > >> developing and I'm talking about legal issues.  The manner of
> > >> developing was already discussed in OFBIZ-499.  The only legal way to
> > >> use JIRA to collaborate this type of thing is to keep sending updated
> > >> patches to JIRA or to have a committer review and add it to a
> > >> specialized application.  Neither one of these is speed of
> > >> development
> > >> friendly.
> > >>
> > >> Legal concerns wouldn't have been one of the primary driving
> > >> forces of
> > >> moving to the ASF if it were true that "we've done fine for years".
> > >> The project still has technical exposure to a C & D order as the CLA
> > >> only covered works the copyright holder gave directly to the ASF not
> > >> the works the copyright holder gave to the OFBIZ project prior to
> > >> incubation.  IANAL, and I don't think there is significant exposure,
> > >> but it is still there. That opinion isn't based on the vehicle
> > >> used to
> > >> create Apache OFBiz, but on the impression of kindheartedness from
> > >> the
> > >> members of the community prior to incubation.
> > >>
> > >> I don't want to speculate on the legal relationship the group that
> > >> worked on the anon checkout had, but I would suspect that it
> > >> generated
> > >> some negative legal exposure as well and that the proposed setup of
> > >> Developers Conference will add to that.
> > >>
> > >> The only feedback that I've received from the general incubator list
> > >> are speculations, all with the caveat that the poster is not a lawyer
> > >> either and no one has been willing to post it to the legal-discuss
> > >> list.
> > >>
> > >> This issue is one of the MAJOR reasons for the existence of non-
> > >> profit
> > >> entities like the ASF, FSF, and SPI.  So again, I ask you to
> > >> reconsider
> > >> the need of a more public sandbox where this kind of community
> > >> collaboration can be done without the complications of copyright
> > >> infringement, or at the very least pose the question to legal-discuss
> > >> for a formal opinion from those representing the ASF's interests.  It
> > >> is my understanding that when it's added to Apache owned SVN, ASF is
> > >> the copyright holder of the collective work instead of an impromptu
> > >> partnership where the individuals have no legal authority to offer a
> > >> collective work.
> > >>
> > >> Regards,
> > >> Chris
> > >> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
> > >>
> > >>>
> > >>> I REALLY don't think you need a sandbox for this. We've done fine
> > >>> for
> > >>>
> > >>> years without one, even with the recently re-done ecommerce
> > >>> anonymous
> > >>>
> > >>> checkout process and alternative checkout processes which were
> > >>> developed entirely outside of OFBiz.
> > >>>
> > >>> Getting this stuff done is mostly a matter of knowing what you're
> > >>> doing and having a clear goal to work towards, a design of sorts if
> > >>> you will. A sandbox won't help that.
> > >>>
> > >>> Once you have a design you can start building it without touching
> > >>> the
> > >>>
> > >>> current stuff, just make it an alternate path and don't break
> > >>> anything existing along the way. Once it is complete, then another
> > >>> patch can go in to remove the old code.
> > >>>
> > >>> It's that simple. That process has been followed well over a hundred
> > >>>
> > >>> times over the life of OFBiz and even for those with commit access
> > >>> it's the only way to go. If you don't have commit access, it's even
> > >>> better because you can develop until you're stuck or out of time,
> > >>> then throw in a patch and have it committed without breaking
> > >>> anything
> > >>>
> > >>> else, even if the new thing isn't working 100%.
> > >>>
> > >>> -David
> > >>>
> > >>>
> > >>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
> > >>>
> > >>>> Hey Anil,
> > >>>>
> > >>>> I've begun some of this already.  I'm taking the approach of
> > >>> passing
> > >>>> the cart to a simple method that first checks the order type and
> > >>> then
> > >>>> calls a method or service that is focused on that order type.  Each
> > >>>> order type service will call a multitude of methods/services that
> > >>>> prepare the cart data to be entered into the datasource.
> > >>>>
> > >>>> I would love to collaborate on this, but because of the size, it's
> > >>>> rather difficult to do by passing patches back and forth through
> > >>> JIRA
> > >>>> without having a reference point that SVN provides.  This is one of
> > >>>> those things that the ofbiz-sandbox project would be good for, but
> > >>> it
> > >>>> still has a legal issue that will prevent it from being entered
> > >>> back
> > >>>> into the project.  I can as an individual grant Apache the license
> > >>> it
> > >>>> needs for the work I do, you as an individual can grant Apache the
> > >>>> license it needs for the work you do, but without each of us
> > >>> assuming
> > >>>> the liability of a partnership we cannot grant a license for the
> > >>> work
> > >>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
> > >>> and
> > >>>> make patches for each commit and each of us resubmit our own patch
> > >>> to
> > >>>> OFBiz JIRA with the order they need to be applied in.
> > >>>>
> > >>>> This would be sooooo much easier if the members of OFBiz PMC would
> > >>>> respond on including a public sandbox in Apache OFBiz as each SVN
> > >>>> commit will be licensed to Apache, and Apache will be the owner of
> > >>> the
> > >>>> work as a whole instead of an impromptu partnership being the
> > >>> owner.
> > >>>>
> > >>>>
> > >>>> --- Anil Patel <to...@gmail.com> wrote:
> > >>>>
> > >>>>> I planning to participate in this developer conference. I am
> > >>>>> interested in
> > >>>>> contributing towards making Order Entry process more flexible. If
> > >>>>> there are
> > >>>>> Others who will be interested we can start some ground work. I
> > >>>>> request one
> > >>>>> of the commiters who has interest in this to Please lead this
> > >>> effort.
> > >>>>>
> > >>>>> The anonymous checkout process in Ecommerce component provides
> > >>> some
> > >>>>> high
> > >>>>> level guiding principals. Few things that I can think of are
> > >>>>> 1) moving some code that's embedded in Java classes into small
> > >>> simple
> > >>>>> methods.
> > >>>>> 2) Moving process control logic from event handlers to Controller
> > >>>>> file.
> > >>>>>
> > >>>>> Any Ideas
> > >>>>>
> > >>>>> Regards
> > >>>>> Anil Patel
> > >>>>>
> > >>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> NOTE: I'm just sending this to the dev list as this event is
> > >>> meant
> > >>>>>> mainly for those who want to be involved with development of
> > >>> OFBiz
> > >>>>>> itself. There will be a variety of projects going on and we hope
> > >>>>>> everyone will be able to work on both paid and fun stuff, but the
> > >>>>>> results will all be going right back into OFBiz. Still, everyone
> > >>> is
> > >>>>>> welcome to attend and join the "party" so if you know of someone
> > >>>>> who
> > >>>>>> might be interested but isn't subscribed to the dev mailing list,
> > >>>>>> please forward it on to them.
> > >>>>>>
> > >>>>>> NOTE2: While most of this conference will be centered around
> > >>>>>> development, if you aren't a developer it doesn't mean you can't
> > >>>>>> come. It would be great to have, for example, people like
> > >>> business
> > >>>>>> analysts and technical writers to help with requirements, design,
> > >>>>> and
> > >>>>>> documentation and such would be great!
> > >>>>>>
> > >>>>>> Included below is the original email about this, and most of the
> > >>>>>> information there is still applicable. Here are a few decisions,
> > >>>>>> based on feedback:
> > >>>>>>
> > >>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
> > >>>>> and
> > >>>>>> may spill over into Sat the 10th
> > >>>>>>
> > >>>>>> 2. you don't have to come for the entire conference, but we
> > >>>>> recommend
> > >>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
> > >>> big-group
> > >>>>>> meetings and any presentations for Wednesday; if you can come for
> > >>>>> the
> > >>>>>> whole week, please do, it'll be great!
> > >>>>>>
> > >>>>>> 3. people are welcome to come and enjoy local attractions for the
> > >>>>>> weekend before and/or after (it will still be cool in the area
> > >>>>> here,
> > >>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
> > >>>>>> depending on weather it can be a great time for visiting the
> > >>>>> deserts
> > >>>>>> and canyons south of here)
> > >>>>>>
> > >>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
> > >>>>> will
> > >>>>>> be $175 for the week (or $35/day) per person; we will have
> > >>> wireless
> > >>>>>> internet access, and I have a bridge if anyone needs wired
> > >>> access;
> > >>>>> we
> > >>>>>> will have at least 2 projectors and perhaps other large monitors
> > >>> to
> > >>>>>> facilitate group development and discussion
> > >>>>>>
> > >>>>>> 5. meals, lodging, etc are not included in the main price, but
> > >>>>> we'll
> > >>>>>> have 5-9 rooms available in the building (for $20-30 per night,
> > >>>>> first
> > >>>>>> come first serve); there is a decent hotel in town as well for
> > >>>>> around
> > >>>>>> $80 per night (contact me for details); for meals there are
> > >>> various
> > >>>>>> restaurants within walking distance
> > >>>>>>
> > >>>>>> 6. the attendance cap is initially 20 people; there seems to be a
> > >>>>> lot
> > >>>>>> of interest in this, so if we go over that we'll raise it by
> > >>>>> perhaps
> > >>>>>> 5-10 more people and convert some other adjacent rooms in the
> > >>>>>> building to be for group meeting use as well (we're planning on 2
> > >>>>> big
> > >>>>>> rooms, plus a fairly big room with a small kitchen in it)
> > >>>>>>
> > >>>>>> 7. the actual development goals are not finalized, but there is
> > >>>>> quite
> > >>>>>> a bit of interest in various things on the original list I
> > >>> included
> > >>>>>> (below), the big things seem to be testing infrastructure and
> > >>>>> project
> > >>>>>> management functionality
> > >>>>>>
> > >>>>>> To register (ASAP please, to make my job of planning easier!),
> > >>>>> please
> > >>>>>> contact me by email (jonesde@hotwaxmedia.com) with the following
> > >>>>>> information:
> > >>>>>>
> > >>>>>> 1. your name, company name, contact info (phone, email if
> > >>> different
> > >>>>>> than from address)
> > >>>>>> 2. how many in your group (if more than one, their names too)
> > >>>>>> 3. plans (as much as known) for how many days and which days
> > >>>>>> 4. lodging preference - in the building (private rooms, shared
> > >>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
> > >>> with
> > >>>>>> contact info for the nice place close by, or there is a "fleabag"
> > >>>>>> motel place too though not sure if I'd recommend it)
> > >>>>>> 5. snack/diet preferences
> > >>>>>> 6. local travel plans: do you need a ride, or do you plan to
> > >>> rent/
> > >>>
> > >> === message truncated ===
> > >>
> > > -- 
> > > Daniel
> > >
> > > *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> > > Have a GREAT Day!
> > >
> > > Daniel Kunkel           DanielKunkel@BioWaves.com
> > > BioWaves, LLC           http://www.BioWaves.com
> > > 14150 NE 20th St. Suite F1
> > > Bellevue, WA 98007
> > > 800-734-3588    425-895-0050
> > > http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> > > http://www.Card-Offer.com      http://www.RackWine.com
> > > http://www.JokesBlonde.com     http://www.Brain-Fun.com
> > > *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> > >
> >

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

[Jonathon -- Improov <jo...@improov.com>]

Oh dear, I meant to write to Daniel Kunkel, not David Kunkel.

Jonathon

Jonathon -- Improov 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  think about doing this under the ASF umbrella because I am not  
>>> willing to take on the responsibility of vetting a large number of  
>>> committers and recommending them as committers in the ASF, which is  
>>> BIG DEAL, and a responsibility and some people seem to be forgetting  
>>> that.
>>>
>>> If you want to be a committer you have to help with the project. You  
>>> have to take ownership of it, defend it, be committed to it, and so  
>>> on. Okay, now I'm doing what I was in the 2 page email I just 
>>> deleted  and I'm stopping.
>>>
>>> If you want to know more about becoming and being a committer and  
>>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>>
>>> I don't know WHY these questions are coming up here. Stop asking  
>>> them. Read the documents. I won't be baited into this any more. It's  
>>> a waste of time, and all based on supposition and not any real  
>>> problems or issues as far as I can see.
>>>
>>> If you develop something outside of OFBiz and want to contribute it,  
>>> here is the page describing how it works:
>>>
>>> http://incubator.apache.org/ip-clearance/index.html
>>>
>>> This is basically a streamlined incubation process for code going  
>>> into existing projects.
>>>
>>> If you really want to help and be involved in the project it means  
>>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
>>> easier to get your own stuff in but if that is all you're about  
>>> related to the project, then being a committer isn't for you.
>>>
>>> If you want to know more about contributing and being a committer,  
>>> read the docs:
>>>
>>> http://docs.ofbiz.org/x/mQ
>>> http://docs.ofbiz.org/x/r
>>>
>>> If you want to know more about licensing and legal issues, read the  
>>> docs:
>>>
>>> http://incubator.apache.org/incubation/Incubation_Policy.html
>>> http://incubator.apache.org/ip-clearance/index.html
>>> http://www.apache.org/foundation/how-it-works.html
>>> http://www.apache.org/foundation/licence-FAQ.html
>>> http://www.apache.org/legal/src-headers.html
>>>
>>> For a lot of good information, broaden the scope and study under:
>>>
>>> http://www.apache.org/dev/
>>>
>>> These were not written because someone was looking for some  
>>> entertainment. They were written so things wouldn't have to be  
>>> explained over and over.
>>>
>>> I'm calling it a day now, as soon as I take care of some real 
>>> issues,  and as long as my son with the flu doesn't throw up again. 
>>> Sorry,  this is really frustrating, and really silly. Reality sucks, 
>>> but we  all have to live with it.
>>>
>>> If people want to help, then help. Don't just ask for help. Start by  
>>> being a giver, not a taker.
>>>
>>> If this sounds a bit harsh, great! Go for a walk and think about how  
>>> things work in real life, then read it again. If you're still upset,  
>>> read it again. Then go read all of the documents referenced. Then if  
>>> you still have a question, send it on in, but PLEASE try to look at  
>>> it from the point of a MEMBER of the OFBiz community, and not a user  
>>> of OFBiz who really doesn't want to get involved.
>>>
>>> If you're asking "how are you going to solve this problem" then  
>>> you're asking the wrong question. If you want to participate as "how  
>>> can I solve this problem", if "I" can't, then do with "how can we  
>>> solve this problem". I don't mean that is what should be in your  
>>> email, I mean that is what should be in your head. If you can't find  
>>> an answer yourself that is 100% okay, just start a discussion and  
>>> accept what you asked for.
>>>
>>> If you don't like the answer explain why it doesn't work for you,  
>>> which brings us back to the beginning of this email...
>>>
>>> -David
>>>
>>>
>>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>>
>>>> David
>>>>
>>>> Can you explain your reticence to adding an Apache OFBiz sandbox where
>>>> more members of the community could share their work?
>>>>
>>>> I can see this section possibly getting a disorganized over time with
>>>> *junk*... but it can be deleted easily enough. As a top level project
>>>> would it possible and better to organize a sub project for this?
>>>>
>>>> Thanks
>>>>
>>>> Daniel
>>>>
>>>>
>>>>
>>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>>> I think we're talking about two different things.  You're talking  
>>>>> about
>>>>> developing and I'm talking about legal issues.  The manner of
>>>>> developing was already discussed in OFBIZ-499.  The only legal way to
>>>>> use JIRA to collaborate this type of thing is to keep sending updated
>>>>> patches to JIRA or to have a committer review and add it to a
>>>>> specialized application.  Neither one of these is speed of  
>>>>> development
>>>>> friendly.
>>>>>
>>>>> Legal concerns wouldn't have been one of the primary driving  
>>>>> forces of
>>>>> moving to the ASF if it were true that "we've done fine for years".
>>>>> The project still has technical exposure to a C & D order as the CLA
>>>>> only covered works the copyright holder gave directly to the ASF not
>>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>>> incubation.  IANAL, and I don't think there is significant exposure,
>>>>> but it is still there. That opinion isn't based on the vehicle  
>>>>> used to
>>>>> create Apache OFBiz, but on the impression of kindheartedness from  
>>>>> the
>>>>> members of the community prior to incubation.
>>>>>
>>>>> I don't want to speculate on the legal relationship the group that
>>>>> worked on the anon checkout had, but I would suspect that it  
>>>>> generated
>>>>> some negative legal exposure as well and that the proposed setup of
>>>>> Developers Conference will add to that.
>>>>>
>>>>> The only feedback that I've received from the general incubator list
>>>>> are speculations, all with the caveat that the poster is not a lawyer
>>>>> either and no one has been willing to post it to the legal-discuss
>>>>> list.
>>>>>
>>>>> This issue is one of the MAJOR reasons for the existence of non- 
>>>>> profit
>>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to  
>>>>> reconsider
>>>>> the need of a more public sandbox where this kind of community
>>>>> collaboration can be done without the complications of copyright
>>>>> infringement, or at the very least pose the question to legal-discuss
>>>>> for a formal opinion from those representing the ASF's interests.  It
>>>>> is my understanding that when it's added to Apache owned SVN, ASF is
>>>>> the copyright holder of the collective work instead of an impromptu
>>>>> partnership where the individuals have no legal authority to offer a
>>>>> collective work.
>>>>>
>>>>> Regards,
>>>>> Chris
>>>>> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
>>>>>
>>>>>> I REALLY don't think you need a sandbox for this. We've done fine  
>>>>>> for
>>>>>>
>>>>>> years without one, even with the recently re-done ecommerce  
>>>>>> anonymous
>>>>>>
>>>>>> checkout process and alternative checkout processes which were
>>>>>> developed entirely outside of OFBiz.
>>>>>>
>>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>>> doing and having a clear goal to work towards, a design of sorts if
>>>>>> you will. A sandbox won't help that.
>>>>>>
>>>>>> Once you have a design you can start building it without touching  
>>>>>> the
>>>>>>
>>>>>> current stuff, just make it an alternate path and don't break
>>>>>> anything existing along the way. Once it is complete, then another
>>>>>> patch can go in to remove the old code.
>>>>>>
>>>>>> It's that simple. That process has been followed well over a hundred
>>>>>>
>>>>>> times over the life of OFBiz and even for those with commit access
>>>>>> it's the only way to go. If you don't have commit access, it's even
>>>>>> better because you can develop until you're stuck or out of time,
>>>>>> then throw in a patch and have it committed without breaking  
>>>>>> anything
>>>>>>
>>>>>> else, even if the new thing isn't working 100%.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>>
>>>>>>> Hey Anil,
>>>>>>>
>>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>>> passing
>>>>>>> the cart to a simple method that first checks the order type and
>>>>>> then
>>>>>>> calls a method or service that is focused on that order type.  Each
>>>>>>> order type service will call a multitude of methods/services that
>>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>>
>>>>>>> I would love to collaborate on this, but because of the size, it's
>>>>>>> rather difficult to do by passing patches back and forth through
>>>>>> JIRA
>>>>>>> without having a reference point that SVN provides.  This is one of
>>>>>>> those things that the ofbiz-sandbox project would be good for, but
>>>>>> it
>>>>>>> still has a legal issue that will prevent it from being entered
>>>>>> back
>>>>>>> into the project.  I can as an individual grant Apache the license
>>>>>> it
>>>>>>> needs for the work I do, you as an individual can grant Apache the
>>>>>>> license it needs for the work you do, but without each of us
>>>>>> assuming
>>>>>>> the liability of a partnership we cannot grant a license for the
>>>>>> work
>>>>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>>>>> and
>>>>>>> make patches for each commit and each of us resubmit our own patch
>>>>>> to
>>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>>
>>>>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>>> commit will be licensed to Apache, and Apache will be the owner of
>>>>>> the
>>>>>>> work as a whole instead of an impromptu partnership being the
>>>>>> owner.
>>>>>>>
>>>>>>> --- Anil Patel <to...@gmail.com> wrote:
>>>>>>>
>>>>>>>> I planning to participate in this developer conference. I am
>>>>>>>> interested in
>>>>>>>> contributing towards making Order Entry process more flexible. If
>>>>>>>> there are
>>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>>> request one
>>>>>>>> of the commiters who has interest in this to Please lead this
>>>>>> effort.
>>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>>> some
>>>>>>>> high
>>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>>> simple
>>>>>>>> methods.
>>>>>>>> 2) Moving process control logic from event handlers to Controller
>>>>>>>> file.
>>>>>>>>
>>>>>>>> Any Ideas
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Anil Patel
>>>>>>>>
>>>>>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>>>>>>>>>
>>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>>> meant
>>>>>>>>> mainly for those who want to be involved with development of
>>>>>> OFBiz
>>>>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>>>>> results will all be going right back into OFBiz. Still, everyone
>>>>>> is
>>>>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>>>>> who
>>>>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>>>>> please forward it on to them.
>>>>>>>>>
>>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>>>>> come. It would be great to have, for example, people like
>>>>>> business
>>>>>>>>> analysts and technical writers to help with requirements, design,
>>>>>>>> and
>>>>>>>>> documentation and such would be great!
>>>>>>>>>
>>>>>>>>> Included below is the original email about this, and most of the
>>>>>>>>> information there is still applicable. Here are a few decisions,
>>>>>>>>> based on feedback:
>>>>>>>>>
>>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>>>>> and
>>>>>>>>> may spill over into Sat the 10th
>>>>>>>>>
>>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>>> recommend
>>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>>> big-group
>>>>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>>>>> the
>>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>>
>>>>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>>> here,
>>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>>> deserts
>>>>>>>>> and canyons south of here)
>>>>>>>>>
>>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>>>>> will
>>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>>> wireless
>>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>>> access;
>>>>>>>> we
>>>>>>>>> will have at least 2 projectors and perhaps other large monitors
>>>>>> to
>>>>>>>>> facilitate group development and discussion
>>>>>>>>>
>>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>>> we'll
>>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>>> first
>>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>>> around
>>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>>> various
>>>>>>>>> restaurants within walking distance
>>>>>>>>>
>>>>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>>>>> lot
>>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>>> perhaps
>>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>>>>> big
>>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>>
>>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>>> quite
>>>>>>>>> a bit of interest in various things on the original list I
>>>>>> included
>>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>>> project
>>>>>>>>> management functionality
>>>>>>>>>
>>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>>> please
>>>>>>>>> contact me by email (jonesde@hotwaxmedia.com) with the following
>>>>>>>>> information:
>>>>>>>>>
>>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>>> different
>>>>>>>>> than from address)
>>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>>> with
>>>>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>>> 5. snack/diet preferences
>>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>>> rent/
>>>>>>
>>>>> === message truncated ===
>>>>>
>>>> -- 
>>>> Daniel
>>>>
>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>> Have a GREAT Day!
>>>>
>>>> Daniel Kunkel           DanielKunkel@BioWaves.com
>>>> BioWaves, LLC           http://www.BioWaves.com
>>>> 14150 NE 20th St. Suite F1
>>>> Bellevue, WA 98007
>>>> 800-734-3588    425-895-0050
>>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>>> http://www.Card-Offer.com      http://www.RackWine.com
>>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>>
>>
>>
> 
> 

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

[Jacques Le Roux <ja...@les7arts.com>]

Chris,

I noticed one point in your mail.

----- Original Message ----- 
From: "Chris Howe" <cj...@yahoo.com>
<snip>
> OFBiz itself did not clear the IP hurdle.  
</snip>

Can you elaborate please ? 

Thank you

Jacques

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

[Jonathon -- Improov <jo...@improov.com>]

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 <jo...@improov.com> 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 ===
> 
> 

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

[Chris Howe <cj...@yahoo.com>]

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 <jo...@improov.com> 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 ===

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

[Jonathon -- Improov <jo...@improov.com>]

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  
>> think about doing this under the ASF umbrella because I am not  
>> willing to take on the responsibility of vetting a large number of  
>> committers and recommending them as committers in the ASF, which is  
>> BIG DEAL, and a responsibility and some people seem to be forgetting  
>> that.
>>
>> If you want to be a committer you have to help with the project. You  
>> have to take ownership of it, defend it, be committed to it, and so  
>> on. Okay, now I'm doing what I was in the 2 page email I just deleted  
>> and I'm stopping.
>>
>> If you want to know more about becoming and being a committer and  
>> about contributing to OFBiz, READ THE DARN DOCUMENTS!
>>
>> I don't know WHY these questions are coming up here. Stop asking  
>> them. Read the documents. I won't be baited into this any more. It's  
>> a waste of time, and all based on supposition and not any real  
>> problems or issues as far as I can see.
>>
>> If you develop something outside of OFBiz and want to contribute it,  
>> here is the page describing how it works:
>>
>> http://incubator.apache.org/ip-clearance/index.html
>>
>> This is basically a streamlined incubation process for code going  
>> into existing projects.
>>
>> If you really want to help and be involved in the project it means  
>> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
>> easier to get your own stuff in but if that is all you're about  
>> related to the project, then being a committer isn't for you.
>>
>> If you want to know more about contributing and being a committer,  
>> read the docs:
>>
>> http://docs.ofbiz.org/x/mQ
>> http://docs.ofbiz.org/x/r
>>
>> If you want to know more about licensing and legal issues, read the  
>> docs:
>>
>> http://incubator.apache.org/incubation/Incubation_Policy.html
>> http://incubator.apache.org/ip-clearance/index.html
>> http://www.apache.org/foundation/how-it-works.html
>> http://www.apache.org/foundation/licence-FAQ.html
>> http://www.apache.org/legal/src-headers.html
>>
>> For a lot of good information, broaden the scope and study under:
>>
>> http://www.apache.org/dev/
>>
>> These were not written because someone was looking for some  
>> entertainment. They were written so things wouldn't have to be  
>> explained over and over.
>>
>> I'm calling it a day now, as soon as I take care of some real issues,  
>> and as long as my son with the flu doesn't throw up again. Sorry,  
>> this is really frustrating, and really silly. Reality sucks, but we  
>> all have to live with it.
>>
>> If people want to help, then help. Don't just ask for help. Start by  
>> being a giver, not a taker.
>>
>> If this sounds a bit harsh, great! Go for a walk and think about how  
>> things work in real life, then read it again. If you're still upset,  
>> read it again. Then go read all of the documents referenced. Then if  
>> you still have a question, send it on in, but PLEASE try to look at  
>> it from the point of a MEMBER of the OFBiz community, and not a user  
>> of OFBiz who really doesn't want to get involved.
>>
>> If you're asking "how are you going to solve this problem" then  
>> you're asking the wrong question. If you want to participate as "how  
>> can I solve this problem", if "I" can't, then do with "how can we  
>> solve this problem". I don't mean that is what should be in your  
>> email, I mean that is what should be in your head. If you can't find  
>> an answer yourself that is 100% okay, just start a discussion and  
>> accept what you asked for.
>>
>> If you don't like the answer explain why it doesn't work for you,  
>> which brings us back to the beginning of this email...
>>
>> -David
>>
>>
>> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
>>
>>> David
>>>
>>> Can you explain your reticence to adding an Apache OFBiz sandbox where
>>> more members of the community could share their work?
>>>
>>> I can see this section possibly getting a disorganized over time with
>>> *junk*... but it can be deleted easily enough. As a top level project
>>> would it possible and better to organize a sub project for this?
>>>
>>> Thanks
>>>
>>> Daniel
>>>
>>>
>>>
>>> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>>>> I think we're talking about two different things.  You're talking  
>>>> about
>>>> developing and I'm talking about legal issues.  The manner of
>>>> developing was already discussed in OFBIZ-499.  The only legal way to
>>>> use JIRA to collaborate this type of thing is to keep sending updated
>>>> patches to JIRA or to have a committer review and add it to a
>>>> specialized application.  Neither one of these is speed of  
>>>> development
>>>> friendly.
>>>>
>>>> Legal concerns wouldn't have been one of the primary driving  
>>>> forces of
>>>> moving to the ASF if it were true that "we've done fine for years".
>>>> The project still has technical exposure to a C & D order as the CLA
>>>> only covered works the copyright holder gave directly to the ASF not
>>>> the works the copyright holder gave to the OFBIZ project prior to
>>>> incubation.  IANAL, and I don't think there is significant exposure,
>>>> but it is still there. That opinion isn't based on the vehicle  
>>>> used to
>>>> create Apache OFBiz, but on the impression of kindheartedness from  
>>>> the
>>>> members of the community prior to incubation.
>>>>
>>>> I don't want to speculate on the legal relationship the group that
>>>> worked on the anon checkout had, but I would suspect that it  
>>>> generated
>>>> some negative legal exposure as well and that the proposed setup of
>>>> Developers Conference will add to that.
>>>>
>>>> The only feedback that I've received from the general incubator list
>>>> are speculations, all with the caveat that the poster is not a lawyer
>>>> either and no one has been willing to post it to the legal-discuss
>>>> list.
>>>>
>>>> This issue is one of the MAJOR reasons for the existence of non- 
>>>> profit
>>>> entities like the ASF, FSF, and SPI.  So again, I ask you to  
>>>> reconsider
>>>> the need of a more public sandbox where this kind of community
>>>> collaboration can be done without the complications of copyright
>>>> infringement, or at the very least pose the question to legal-discuss
>>>> for a formal opinion from those representing the ASF's interests.  It
>>>> is my understanding that when it's added to Apache owned SVN, ASF is
>>>> the copyright holder of the collective work instead of an impromptu
>>>> partnership where the individuals have no legal authority to offer a
>>>> collective work.
>>>>
>>>> Regards,
>>>> Chris
>>>> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
>>>>
>>>>> I REALLY don't think you need a sandbox for this. We've done fine  
>>>>> for
>>>>>
>>>>> years without one, even with the recently re-done ecommerce  
>>>>> anonymous
>>>>>
>>>>> checkout process and alternative checkout processes which were
>>>>> developed entirely outside of OFBiz.
>>>>>
>>>>> Getting this stuff done is mostly a matter of knowing what you're
>>>>> doing and having a clear goal to work towards, a design of sorts if
>>>>> you will. A sandbox won't help that.
>>>>>
>>>>> Once you have a design you can start building it without touching  
>>>>> the
>>>>>
>>>>> current stuff, just make it an alternate path and don't break
>>>>> anything existing along the way. Once it is complete, then another
>>>>> patch can go in to remove the old code.
>>>>>
>>>>> It's that simple. That process has been followed well over a hundred
>>>>>
>>>>> times over the life of OFBiz and even for those with commit access
>>>>> it's the only way to go. If you don't have commit access, it's even
>>>>> better because you can develop until you're stuck or out of time,
>>>>> then throw in a patch and have it committed without breaking  
>>>>> anything
>>>>>
>>>>> else, even if the new thing isn't working 100%.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>>>
>>>>>> Hey Anil,
>>>>>>
>>>>>> I've begun some of this already.  I'm taking the approach of
>>>>> passing
>>>>>> the cart to a simple method that first checks the order type and
>>>>> then
>>>>>> calls a method or service that is focused on that order type.  Each
>>>>>> order type service will call a multitude of methods/services that
>>>>>> prepare the cart data to be entered into the datasource.
>>>>>>
>>>>>> I would love to collaborate on this, but because of the size, it's
>>>>>> rather difficult to do by passing patches back and forth through
>>>>> JIRA
>>>>>> without having a reference point that SVN provides.  This is one of
>>>>>> those things that the ofbiz-sandbox project would be good for, but
>>>>> it
>>>>>> still has a legal issue that will prevent it from being entered
>>>>> back
>>>>>> into the project.  I can as an individual grant Apache the license
>>>>> it
>>>>>> needs for the work I do, you as an individual can grant Apache the
>>>>>> license it needs for the work you do, but without each of us
>>>>> assuming
>>>>>> the liability of a partnership we cannot grant a license for the
>>>>> work
>>>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>>>> and
>>>>>> make patches for each commit and each of us resubmit our own patch
>>>>> to
>>>>>> OFBiz JIRA with the order they need to be applied in.
>>>>>>
>>>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>>>> commit will be licensed to Apache, and Apache will be the owner of
>>>>> the
>>>>>> work as a whole instead of an impromptu partnership being the
>>>>> owner.
>>>>>>
>>>>>> --- Anil Patel <to...@gmail.com> wrote:
>>>>>>
>>>>>>> I planning to participate in this developer conference. I am
>>>>>>> interested in
>>>>>>> contributing towards making Order Entry process more flexible. If
>>>>>>> there are
>>>>>>> Others who will be interested we can start some ground work. I
>>>>>>> request one
>>>>>>> of the commiters who has interest in this to Please lead this
>>>>> effort.
>>>>>>> The anonymous checkout process in Ecommerce component provides
>>>>> some
>>>>>>> high
>>>>>>> level guiding principals. Few things that I can think of are
>>>>>>> 1) moving some code that's embedded in Java classes into small
>>>>> simple
>>>>>>> methods.
>>>>>>> 2) Moving process control logic from event handlers to Controller
>>>>>>> file.
>>>>>>>
>>>>>>> Any Ideas
>>>>>>>
>>>>>>> Regards
>>>>>>> Anil Patel
>>>>>>>
>>>>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>>>>>>>>
>>>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>>>> meant
>>>>>>>> mainly for those who want to be involved with development of
>>>>> OFBiz
>>>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>>>> results will all be going right back into OFBiz. Still, everyone
>>>>> is
>>>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>>>> who
>>>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>>>> please forward it on to them.
>>>>>>>>
>>>>>>>> NOTE2: While most of this conference will be centered around
>>>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>>>> come. It would be great to have, for example, people like
>>>>> business
>>>>>>>> analysts and technical writers to help with requirements, design,
>>>>>>> and
>>>>>>>> documentation and such would be great!
>>>>>>>>
>>>>>>>> Included below is the original email about this, and most of the
>>>>>>>> information there is still applicable. Here are a few decisions,
>>>>>>>> based on feedback:
>>>>>>>>
>>>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>>>> and
>>>>>>>> may spill over into Sat the 10th
>>>>>>>>
>>>>>>>> 2. you don't have to come for the entire conference, but we
>>>>>>> recommend
>>>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>>>> big-group
>>>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>>>> the
>>>>>>>> whole week, please do, it'll be great!
>>>>>>>>
>>>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>>>> weekend before and/or after (it will still be cool in the area
>>>>>>> here,
>>>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>>>> depending on weather it can be a great time for visiting the
>>>>>>> deserts
>>>>>>>> and canyons south of here)
>>>>>>>>
>>>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>>>> will
>>>>>>>> be $175 for the week (or $35/day) per person; we will have
>>>>> wireless
>>>>>>>> internet access, and I have a bridge if anyone needs wired
>>>>> access;
>>>>>>> we
>>>>>>>> will have at least 2 projectors and perhaps other large monitors
>>>>> to
>>>>>>>> facilitate group development and discussion
>>>>>>>>
>>>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>>>> we'll
>>>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>>>> first
>>>>>>>> come first serve); there is a decent hotel in town as well for
>>>>>>> around
>>>>>>>> $80 per night (contact me for details); for meals there are
>>>>> various
>>>>>>>> restaurants within walking distance
>>>>>>>>
>>>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>>>> lot
>>>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>>>> perhaps
>>>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>>>> big
>>>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>>>
>>>>>>>> 7. the actual development goals are not finalized, but there is
>>>>>>> quite
>>>>>>>> a bit of interest in various things on the original list I
>>>>> included
>>>>>>>> (below), the big things seem to be testing infrastructure and
>>>>>>> project
>>>>>>>> management functionality
>>>>>>>>
>>>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>>>> please
>>>>>>>> contact me by email (jonesde@hotwaxmedia.com) with the following
>>>>>>>> information:
>>>>>>>>
>>>>>>>> 1. your name, company name, contact info (phone, email if
>>>>> different
>>>>>>>> than from address)
>>>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>>>> with
>>>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>>>> motel place too though not sure if I'd recommend it)
>>>>>>>> 5. snack/diet preferences
>>>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>>>> rent/
>>>>>
>>>> === message truncated ===
>>>>
>>> -- 
>>> Daniel
>>>
>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>> Have a GREAT Day!
>>>
>>> Daniel Kunkel           DanielKunkel@BioWaves.com
>>> BioWaves, LLC           http://www.BioWaves.com
>>> 14150 NE 20th St. Suite F1
>>> Bellevue, WA 98007
>>> 800-734-3588    425-895-0050
>>> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
>>> http://www.Card-Offer.com      http://www.RackWine.com
>>> http://www.JokesBlonde.com     http://www.Brain-Fun.com
>>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>>
> 
> 

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

[Daniel Kunkel <Da...@BioWaves.com>]

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  
> think about doing this under the ASF umbrella because I am not  
> willing to take on the responsibility of vetting a large number of  
> committers and recommending them as committers in the ASF, which is  
> BIG DEAL, and a responsibility and some people seem to be forgetting  
> that.
> 
> If you want to be a committer you have to help with the project. You  
> have to take ownership of it, defend it, be committed to it, and so  
> on. Okay, now I'm doing what I was in the 2 page email I just deleted  
> and I'm stopping.
> 
> If you want to know more about becoming and being a committer and  
> about contributing to OFBiz, READ THE DARN DOCUMENTS!
> 
> I don't know WHY these questions are coming up here. Stop asking  
> them. Read the documents. I won't be baited into this any more. It's  
> a waste of time, and all based on supposition and not any real  
> problems or issues as far as I can see.
> 
> If you develop something outside of OFBiz and want to contribute it,  
> here is the page describing how it works:
> 
> http://incubator.apache.org/ip-clearance/index.html
> 
> This is basically a streamlined incubation process for code going  
> into existing projects.
> 
> If you really want to help and be involved in the project it means  
> working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
> easier to get your own stuff in but if that is all you're about  
> related to the project, then being a committer isn't for you.
> 
> If you want to know more about contributing and being a committer,  
> read the docs:
> 
> http://docs.ofbiz.org/x/mQ
> http://docs.ofbiz.org/x/r
> 
> If you want to know more about licensing and legal issues, read the  
> docs:
> 
> http://incubator.apache.org/incubation/Incubation_Policy.html
> http://incubator.apache.org/ip-clearance/index.html
> http://www.apache.org/foundation/how-it-works.html
> http://www.apache.org/foundation/licence-FAQ.html
> http://www.apache.org/legal/src-headers.html
> 
> For a lot of good information, broaden the scope and study under:
> 
> http://www.apache.org/dev/
> 
> These were not written because someone was looking for some  
> entertainment. They were written so things wouldn't have to be  
> explained over and over.
> 
> I'm calling it a day now, as soon as I take care of some real issues,  
> and as long as my son with the flu doesn't throw up again. Sorry,  
> this is really frustrating, and really silly. Reality sucks, but we  
> all have to live with it.
> 
> If people want to help, then help. Don't just ask for help. Start by  
> being a giver, not a taker.
> 
> If this sounds a bit harsh, great! Go for a walk and think about how  
> things work in real life, then read it again. If you're still upset,  
> read it again. Then go read all of the documents referenced. Then if  
> you still have a question, send it on in, but PLEASE try to look at  
> it from the point of a MEMBER of the OFBiz community, and not a user  
> of OFBiz who really doesn't want to get involved.
> 
> If you're asking "how are you going to solve this problem" then  
> you're asking the wrong question. If you want to participate as "how  
> can I solve this problem", if "I" can't, then do with "how can we  
> solve this problem". I don't mean that is what should be in your  
> email, I mean that is what should be in your head. If you can't find  
> an answer yourself that is 100% okay, just start a discussion and  
> accept what you asked for.
> 
> If you don't like the answer explain why it doesn't work for you,  
> which brings us back to the beginning of this email...
> 
> -David
> 
> 
> On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:
> 
> > David
> >
> > Can you explain your reticence to adding an Apache OFBiz sandbox where
> > more members of the community could share their work?
> >
> > I can see this section possibly getting a disorganized over time with
> > *junk*... but it can be deleted easily enough. As a top level project
> > would it possible and better to organize a sub project for this?
> >
> > Thanks
> >
> > Daniel
> >
> >
> >
> > On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
> >> I think we're talking about two different things.  You're talking  
> >> about
> >> developing and I'm talking about legal issues.  The manner of
> >> developing was already discussed in OFBIZ-499.  The only legal way to
> >> use JIRA to collaborate this type of thing is to keep sending updated
> >> patches to JIRA or to have a committer review and add it to a
> >> specialized application.  Neither one of these is speed of  
> >> development
> >> friendly.
> >>
> >> Legal concerns wouldn't have been one of the primary driving  
> >> forces of
> >> moving to the ASF if it were true that "we've done fine for years".
> >> The project still has technical exposure to a C & D order as the CLA
> >> only covered works the copyright holder gave directly to the ASF not
> >> the works the copyright holder gave to the OFBIZ project prior to
> >> incubation.  IANAL, and I don't think there is significant exposure,
> >> but it is still there. That opinion isn't based on the vehicle  
> >> used to
> >> create Apache OFBiz, but on the impression of kindheartedness from  
> >> the
> >> members of the community prior to incubation.
> >>
> >> I don't want to speculate on the legal relationship the group that
> >> worked on the anon checkout had, but I would suspect that it  
> >> generated
> >> some negative legal exposure as well and that the proposed setup of
> >> Developers Conference will add to that.
> >>
> >> The only feedback that I've received from the general incubator list
> >> are speculations, all with the caveat that the poster is not a lawyer
> >> either and no one has been willing to post it to the legal-discuss
> >> list.
> >>
> >> This issue is one of the MAJOR reasons for the existence of non- 
> >> profit
> >> entities like the ASF, FSF, and SPI.  So again, I ask you to  
> >> reconsider
> >> the need of a more public sandbox where this kind of community
> >> collaboration can be done without the complications of copyright
> >> infringement, or at the very least pose the question to legal-discuss
> >> for a formal opinion from those representing the ASF's interests.  It
> >> is my understanding that when it's added to Apache owned SVN, ASF is
> >> the copyright holder of the collective work instead of an impromptu
> >> partnership where the individuals have no legal authority to offer a
> >> collective work.
> >>
> >> Regards,
> >> Chris
> >> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
> >>
> >>>
> >>> I REALLY don't think you need a sandbox for this. We've done fine  
> >>> for
> >>>
> >>> years without one, even with the recently re-done ecommerce  
> >>> anonymous
> >>>
> >>> checkout process and alternative checkout processes which were
> >>> developed entirely outside of OFBiz.
> >>>
> >>> Getting this stuff done is mostly a matter of knowing what you're
> >>> doing and having a clear goal to work towards, a design of sorts if
> >>> you will. A sandbox won't help that.
> >>>
> >>> Once you have a design you can start building it without touching  
> >>> the
> >>>
> >>> current stuff, just make it an alternate path and don't break
> >>> anything existing along the way. Once it is complete, then another
> >>> patch can go in to remove the old code.
> >>>
> >>> It's that simple. That process has been followed well over a hundred
> >>>
> >>> times over the life of OFBiz and even for those with commit access
> >>> it's the only way to go. If you don't have commit access, it's even
> >>> better because you can develop until you're stuck or out of time,
> >>> then throw in a patch and have it committed without breaking  
> >>> anything
> >>>
> >>> else, even if the new thing isn't working 100%.
> >>>
> >>> -David
> >>>
> >>>
> >>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
> >>>
> >>>> Hey Anil,
> >>>>
> >>>> I've begun some of this already.  I'm taking the approach of
> >>> passing
> >>>> the cart to a simple method that first checks the order type and
> >>> then
> >>>> calls a method or service that is focused on that order type.  Each
> >>>> order type service will call a multitude of methods/services that
> >>>> prepare the cart data to be entered into the datasource.
> >>>>
> >>>> I would love to collaborate on this, but because of the size, it's
> >>>> rather difficult to do by passing patches back and forth through
> >>> JIRA
> >>>> without having a reference point that SVN provides.  This is one of
> >>>> those things that the ofbiz-sandbox project would be good for, but
> >>> it
> >>>> still has a legal issue that will prevent it from being entered
> >>> back
> >>>> into the project.  I can as an individual grant Apache the license
> >>> it
> >>>> needs for the work I do, you as an individual can grant Apache the
> >>>> license it needs for the work you do, but without each of us
> >>> assuming
> >>>> the liability of a partnership we cannot grant a license for the
> >>> work
> >>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
> >>> and
> >>>> make patches for each commit and each of us resubmit our own patch
> >>> to
> >>>> OFBiz JIRA with the order they need to be applied in.
> >>>>
> >>>> This would be sooooo much easier if the members of OFBiz PMC would
> >>>> respond on including a public sandbox in Apache OFBiz as each SVN
> >>>> commit will be licensed to Apache, and Apache will be the owner of
> >>> the
> >>>> work as a whole instead of an impromptu partnership being the
> >>> owner.
> >>>>
> >>>>
> >>>> --- Anil Patel <to...@gmail.com> wrote:
> >>>>
> >>>>> I planning to participate in this developer conference. I am
> >>>>> interested in
> >>>>> contributing towards making Order Entry process more flexible. If
> >>>>> there are
> >>>>> Others who will be interested we can start some ground work. I
> >>>>> request one
> >>>>> of the commiters who has interest in this to Please lead this
> >>> effort.
> >>>>>
> >>>>> The anonymous checkout process in Ecommerce component provides
> >>> some
> >>>>> high
> >>>>> level guiding principals. Few things that I can think of are
> >>>>> 1) moving some code that's embedded in Java classes into small
> >>> simple
> >>>>> methods.
> >>>>> 2) Moving process control logic from event handlers to Controller
> >>>>> file.
> >>>>>
> >>>>> Any Ideas
> >>>>>
> >>>>> Regards
> >>>>> Anil Patel
> >>>>>
> >>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>> NOTE: I'm just sending this to the dev list as this event is
> >>> meant
> >>>>>> mainly for those who want to be involved with development of
> >>> OFBiz
> >>>>>> itself. There will be a variety of projects going on and we hope
> >>>>>> everyone will be able to work on both paid and fun stuff, but the
> >>>>>> results will all be going right back into OFBiz. Still, everyone
> >>> is
> >>>>>> welcome to attend and join the "party" so if you know of someone
> >>>>> who
> >>>>>> might be interested but isn't subscribed to the dev mailing list,
> >>>>>> please forward it on to them.
> >>>>>>
> >>>>>> NOTE2: While most of this conference will be centered around
> >>>>>> development, if you aren't a developer it doesn't mean you can't
> >>>>>> come. It would be great to have, for example, people like
> >>> business
> >>>>>> analysts and technical writers to help with requirements, design,
> >>>>> and
> >>>>>> documentation and such would be great!
> >>>>>>
> >>>>>> Included below is the original email about this, and most of the
> >>>>>> information there is still applicable. Here are a few decisions,
> >>>>>> based on feedback:
> >>>>>>
> >>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
> >>>>> and
> >>>>>> may spill over into Sat the 10th
> >>>>>>
> >>>>>> 2. you don't have to come for the entire conference, but we
> >>>>> recommend
> >>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
> >>> big-group
> >>>>>> meetings and any presentations for Wednesday; if you can come for
> >>>>> the
> >>>>>> whole week, please do, it'll be great!
> >>>>>>
> >>>>>> 3. people are welcome to come and enjoy local attractions for the
> >>>>>> weekend before and/or after (it will still be cool in the area
> >>>>> here,
> >>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
> >>>>>> depending on weather it can be a great time for visiting the
> >>>>> deserts
> >>>>>> and canyons south of here)
> >>>>>>
> >>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
> >>>>> will
> >>>>>> be $175 for the week (or $35/day) per person; we will have
> >>> wireless
> >>>>>> internet access, and I have a bridge if anyone needs wired
> >>> access;
> >>>>> we
> >>>>>> will have at least 2 projectors and perhaps other large monitors
> >>> to
> >>>>>> facilitate group development and discussion
> >>>>>>
> >>>>>> 5. meals, lodging, etc are not included in the main price, but
> >>>>> we'll
> >>>>>> have 5-9 rooms available in the building (for $20-30 per night,
> >>>>> first
> >>>>>> come first serve); there is a decent hotel in town as well for
> >>>>> around
> >>>>>> $80 per night (contact me for details); for meals there are
> >>> various
> >>>>>> restaurants within walking distance
> >>>>>>
> >>>>>> 6. the attendance cap is initially 20 people; there seems to be a
> >>>>> lot
> >>>>>> of interest in this, so if we go over that we'll raise it by
> >>>>> perhaps
> >>>>>> 5-10 more people and convert some other adjacent rooms in the
> >>>>>> building to be for group meeting use as well (we're planning on 2
> >>>>> big
> >>>>>> rooms, plus a fairly big room with a small kitchen in it)
> >>>>>>
> >>>>>> 7. the actual development goals are not finalized, but there is
> >>>>> quite
> >>>>>> a bit of interest in various things on the original list I
> >>> included
> >>>>>> (below), the big things seem to be testing infrastructure and
> >>>>> project
> >>>>>> management functionality
> >>>>>>
> >>>>>> To register (ASAP please, to make my job of planning easier!),
> >>>>> please
> >>>>>> contact me by email (jonesde@hotwaxmedia.com) with the following
> >>>>>> information:
> >>>>>>
> >>>>>> 1. your name, company name, contact info (phone, email if
> >>> different
> >>>>>> than from address)
> >>>>>> 2. how many in your group (if more than one, their names too)
> >>>>>> 3. plans (as much as known) for how many days and which days
> >>>>>> 4. lodging preference - in the building (private rooms, shared
> >>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
> >>> with
> >>>>>> contact info for the nice place close by, or there is a "fleabag"
> >>>>>> motel place too though not sure if I'd recommend it)
> >>>>>> 5. snack/diet preferences
> >>>>>> 6. local travel plans: do you need a ride, or do you plan to
> >>> rent/
> >>>
> >> === message truncated ===
> >>
> > -- 
> > Daniel
> >
> > *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> > Have a GREAT Day!
> >
> > Daniel Kunkel           DanielKunkel@BioWaves.com
> > BioWaves, LLC           http://www.BioWaves.com
> > 14150 NE 20th St. Suite F1
> > Bellevue, WA 98007
> > 800-734-3588    425-895-0050
> > http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> > http://www.Card-Offer.com      http://www.RackWine.com
> > http://www.JokesBlonde.com     http://www.Brain-Fun.com
> > *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> >
> 

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

["David E. Jones" <jo...@hotwaxmedia.com>]

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  
think about doing this under the ASF umbrella because I am not  
willing to take on the responsibility of vetting a large number of  
committers and recommending them as committers in the ASF, which is  
BIG DEAL, and a responsibility and some people seem to be forgetting  
that.

If you want to be a committer you have to help with the project. You  
have to take ownership of it, defend it, be committed to it, and so  
on. Okay, now I'm doing what I was in the 2 page email I just deleted  
and I'm stopping.

If you want to know more about becoming and being a committer and  
about contributing to OFBiz, READ THE DARN DOCUMENTS!

I don't know WHY these questions are coming up here. Stop asking  
them. Read the documents. I won't be baited into this any more. It's  
a waste of time, and all based on supposition and not any real  
problems or issues as far as I can see.

If you develop something outside of OFBiz and want to contribute it,  
here is the page describing how it works:

http://incubator.apache.org/ip-clearance/index.html

This is basically a streamlined incubation process for code going  
into existing projects.

If you really want to help and be involved in the project it means  
working on OTHER PEOPLE'S STUFF, NOT YOUR OWN! Yes, it makes it  
easier to get your own stuff in but if that is all you're about  
related to the project, then being a committer isn't for you.

If you want to know more about contributing and being a committer,  
read the docs:

http://docs.ofbiz.org/x/mQ
http://docs.ofbiz.org/x/r

If you want to know more about licensing and legal issues, read the  
docs:

http://incubator.apache.org/incubation/Incubation_Policy.html
http://incubator.apache.org/ip-clearance/index.html
http://www.apache.org/foundation/how-it-works.html
http://www.apache.org/foundation/licence-FAQ.html
http://www.apache.org/legal/src-headers.html

For a lot of good information, broaden the scope and study under:

http://www.apache.org/dev/

These were not written because someone was looking for some  
entertainment. They were written so things wouldn't have to be  
explained over and over.

I'm calling it a day now, as soon as I take care of some real issues,  
and as long as my son with the flu doesn't throw up again. Sorry,  
this is really frustrating, and really silly. Reality sucks, but we  
all have to live with it.

If people want to help, then help. Don't just ask for help. Start by  
being a giver, not a taker.

If this sounds a bit harsh, great! Go for a walk and think about how  
things work in real life, then read it again. If you're still upset,  
read it again. Then go read all of the documents referenced. Then if  
you still have a question, send it on in, but PLEASE try to look at  
it from the point of a MEMBER of the OFBiz community, and not a user  
of OFBiz who really doesn't want to get involved.

If you're asking "how are you going to solve this problem" then  
you're asking the wrong question. If you want to participate as "how  
can I solve this problem", if "I" can't, then do with "how can we  
solve this problem". I don't mean that is what should be in your  
email, I mean that is what should be in your head. If you can't find  
an answer yourself that is 100% okay, just start a discussion and  
accept what you asked for.

If you don't like the answer explain why it doesn't work for you,  
which brings us back to the beginning of this email...

-David


On Jan 25, 2007, at 6:10 PM, Daniel Kunkel wrote:

> David
>
> Can you explain your reticence to adding an Apache OFBiz sandbox where
> more members of the community could share their work?
>
> I can see this section possibly getting a disorganized over time with
> *junk*... but it can be deleted easily enough. As a top level project
> would it possible and better to organize a sub project for this?
>
> Thanks
>
> Daniel
>
>
>
> On Thu, 2007-01-25 at 12:41 -0800, Chris Howe wrote:
>> I think we're talking about two different things.  You're talking  
>> about
>> developing and I'm talking about legal issues.  The manner of
>> developing was already discussed in OFBIZ-499.  The only legal way to
>> use JIRA to collaborate this type of thing is to keep sending updated
>> patches to JIRA or to have a committer review and add it to a
>> specialized application.  Neither one of these is speed of  
>> development
>> friendly.
>>
>> Legal concerns wouldn't have been one of the primary driving  
>> forces of
>> moving to the ASF if it were true that "we've done fine for years".
>> The project still has technical exposure to a C & D order as the CLA
>> only covered works the copyright holder gave directly to the ASF not
>> the works the copyright holder gave to the OFBIZ project prior to
>> incubation.  IANAL, and I don't think there is significant exposure,
>> but it is still there. That opinion isn't based on the vehicle  
>> used to
>> create Apache OFBiz, but on the impression of kindheartedness from  
>> the
>> members of the community prior to incubation.
>>
>> I don't want to speculate on the legal relationship the group that
>> worked on the anon checkout had, but I would suspect that it  
>> generated
>> some negative legal exposure as well and that the proposed setup of
>> Developers Conference will add to that.
>>
>> The only feedback that I've received from the general incubator list
>> are speculations, all with the caveat that the poster is not a lawyer
>> either and no one has been willing to post it to the legal-discuss
>> list.
>>
>> This issue is one of the MAJOR reasons for the existence of non- 
>> profit
>> entities like the ASF, FSF, and SPI.  So again, I ask you to  
>> reconsider
>> the need of a more public sandbox where this kind of community
>> collaboration can be done without the complications of copyright
>> infringement, or at the very least pose the question to legal-discuss
>> for a formal opinion from those representing the ASF's interests.  It
>> is my understanding that when it's added to Apache owned SVN, ASF is
>> the copyright holder of the collective work instead of an impromptu
>> partnership where the individuals have no legal authority to offer a
>> collective work.
>>
>> Regards,
>> Chris
>> --- "David E. Jones" <jo...@hotwaxmedia.com> wrote:
>>
>>>
>>> I REALLY don't think you need a sandbox for this. We've done fine  
>>> for
>>>
>>> years without one, even with the recently re-done ecommerce  
>>> anonymous
>>>
>>> checkout process and alternative checkout processes which were
>>> developed entirely outside of OFBiz.
>>>
>>> Getting this stuff done is mostly a matter of knowing what you're
>>> doing and having a clear goal to work towards, a design of sorts if
>>> you will. A sandbox won't help that.
>>>
>>> Once you have a design you can start building it without touching  
>>> the
>>>
>>> current stuff, just make it an alternate path and don't break
>>> anything existing along the way. Once it is complete, then another
>>> patch can go in to remove the old code.
>>>
>>> It's that simple. That process has been followed well over a hundred
>>>
>>> times over the life of OFBiz and even for those with commit access
>>> it's the only way to go. If you don't have commit access, it's even
>>> better because you can develop until you're stuck or out of time,
>>> then throw in a patch and have it committed without breaking  
>>> anything
>>>
>>> else, even if the new thing isn't working 100%.
>>>
>>> -David
>>>
>>>
>>> On Jan 25, 2007, at 12:05 PM, Chris Howe wrote:
>>>
>>>> Hey Anil,
>>>>
>>>> I've begun some of this already.  I'm taking the approach of
>>> passing
>>>> the cart to a simple method that first checks the order type and
>>> then
>>>> calls a method or service that is focused on that order type.  Each
>>>> order type service will call a multitude of methods/services that
>>>> prepare the cart data to be entered into the datasource.
>>>>
>>>> I would love to collaborate on this, but because of the size, it's
>>>> rather difficult to do by passing patches back and forth through
>>> JIRA
>>>> without having a reference point that SVN provides.  This is one of
>>>> those things that the ofbiz-sandbox project would be good for, but
>>> it
>>>> still has a legal issue that will prevent it from being entered
>>> back
>>>> into the project.  I can as an individual grant Apache the license
>>> it
>>>> needs for the work I do, you as an individual can grant Apache the
>>>> license it needs for the work you do, but without each of us
>>> assuming
>>>> the liability of a partnership we cannot grant a license for the
>>> work
>>>> as a whole.  The only way around this is to use ofbiz-sandbox SVN
>>> and
>>>> make patches for each commit and each of us resubmit our own patch
>>> to
>>>> OFBiz JIRA with the order they need to be applied in.
>>>>
>>>> This would be sooooo much easier if the members of OFBiz PMC would
>>>> respond on including a public sandbox in Apache OFBiz as each SVN
>>>> commit will be licensed to Apache, and Apache will be the owner of
>>> the
>>>> work as a whole instead of an impromptu partnership being the
>>> owner.
>>>>
>>>>
>>>> --- Anil Patel <to...@gmail.com> wrote:
>>>>
>>>>> I planning to participate in this developer conference. I am
>>>>> interested in
>>>>> contributing towards making Order Entry process more flexible. If
>>>>> there are
>>>>> Others who will be interested we can start some ground work. I
>>>>> request one
>>>>> of the commiters who has interest in this to Please lead this
>>> effort.
>>>>>
>>>>> The anonymous checkout process in Ecommerce component provides
>>> some
>>>>> high
>>>>> level guiding principals. Few things that I can think of are
>>>>> 1) moving some code that's embedded in Java classes into small
>>> simple
>>>>> methods.
>>>>> 2) Moving process control logic from event handlers to Controller
>>>>> file.
>>>>>
>>>>> Any Ideas
>>>>>
>>>>> Regards
>>>>> Anil Patel
>>>>>
>>>>> On 1/16/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>>>>>>
>>>>>>
>>>>>> NOTE: I'm just sending this to the dev list as this event is
>>> meant
>>>>>> mainly for those who want to be involved with development of
>>> OFBiz
>>>>>> itself. There will be a variety of projects going on and we hope
>>>>>> everyone will be able to work on both paid and fun stuff, but the
>>>>>> results will all be going right back into OFBiz. Still, everyone
>>> is
>>>>>> welcome to attend and join the "party" so if you know of someone
>>>>> who
>>>>>> might be interested but isn't subscribed to the dev mailing list,
>>>>>> please forward it on to them.
>>>>>>
>>>>>> NOTE2: While most of this conference will be centered around
>>>>>> development, if you aren't a developer it doesn't mean you can't
>>>>>> come. It would be great to have, for example, people like
>>> business
>>>>>> analysts and technical writers to help with requirements, design,
>>>>> and
>>>>>> documentation and such would be great!
>>>>>>
>>>>>> Included below is the original email about this, and most of the
>>>>>> information there is still applicable. Here are a few decisions,
>>>>>> based on feedback:
>>>>>>
>>>>>> 1. the conference dates will be 5-9 March 2007 (Monday - Friday),
>>>>> and
>>>>>> may spill over into Sat the 10th
>>>>>>
>>>>>> 2. you don't have to come for the entire conference, but we
>>>>> recommend
>>>>>> coming for at least Mon-Wed or Wed-Fri as we'll schedule
>>> big-group
>>>>>> meetings and any presentations for Wednesday; if you can come for
>>>>> the
>>>>>> whole week, please do, it'll be great!
>>>>>>
>>>>>> 3. people are welcome to come and enjoy local attractions for the
>>>>>> weekend before and/or after (it will still be cool in the area
>>>>> here,
>>>>>> snowy in the mountains for skiing/boarding/snowmobiling, and
>>>>>> depending on weather it can be a great time for visiting the
>>>>> deserts
>>>>>> and canyons south of here)
>>>>>>
>>>>>> 4. the cost to cover the meeting rooms, snacks, infra stuff, etc
>>>>> will
>>>>>> be $175 for the week (or $35/day) per person; we will have
>>> wireless
>>>>>> internet access, and I have a bridge if anyone needs wired
>>> access;
>>>>> we
>>>>>> will have at least 2 projectors and perhaps other large monitors
>>> to
>>>>>> facilitate group development and discussion
>>>>>>
>>>>>> 5. meals, lodging, etc are not included in the main price, but
>>>>> we'll
>>>>>> have 5-9 rooms available in the building (for $20-30 per night,
>>>>> first
>>>>>> come first serve); there is a decent hotel in town as well for
>>>>> around
>>>>>> $80 per night (contact me for details); for meals there are
>>> various
>>>>>> restaurants within walking distance
>>>>>>
>>>>>> 6. the attendance cap is initially 20 people; there seems to be a
>>>>> lot
>>>>>> of interest in this, so if we go over that we'll raise it by
>>>>> perhaps
>>>>>> 5-10 more people and convert some other adjacent rooms in the
>>>>>> building to be for group meeting use as well (we're planning on 2
>>>>> big
>>>>>> rooms, plus a fairly big room with a small kitchen in it)
>>>>>>
>>>>>> 7. the actual development goals are not finalized, but there is
>>>>> quite
>>>>>> a bit of interest in various things on the original list I
>>> included
>>>>>> (below), the big things seem to be testing infrastructure and
>>>>> project
>>>>>> management functionality
>>>>>>
>>>>>> To register (ASAP please, to make my job of planning easier!),
>>>>> please
>>>>>> contact me by email (jonesde@hotwaxmedia.com) with the following
>>>>>> information:
>>>>>>
>>>>>> 1. your name, company name, contact info (phone, email if
>>> different
>>>>>> than from address)
>>>>>> 2. how many in your group (if more than one, their names too)
>>>>>> 3. plans (as much as known) for how many days and which days
>>>>>> 4. lodging preference - in the building (private rooms, shared
>>>>>> toilets/showers) how many rooms, or nearby hotel (I'll respond
>>> with
>>>>>> contact info for the nice place close by, or there is a "fleabag"
>>>>>> motel place too though not sure if I'd recommend it)
>>>>>> 5. snack/diet preferences
>>>>>> 6. local travel plans: do you need a ride, or do you plan to
>>> rent/
>>>
>> === message truncated ===
>>
> -- 
> Daniel
>
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
> Have a GREAT Day!
>
> Daniel Kunkel           DanielKunkel@BioWaves.com
> BioWaves, LLC           http://www.BioWaves.com
> 14150 NE 20th St. Suite F1
> Bellevue, WA 98007
> 800-734-3588    425-895-0050
> http://www.Apartment-Pets.com  http://www.Illusion-Optical.com
> http://www.Card-Offer.com      http://www.RackWine.com
> http://www.JokesBlonde.com     http://www.Brain-Fun.com
> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>