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

[jonwimp]

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 <[hidden email]> 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
>>>

[David E Jones]

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 <[hidden email]> 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 <[hidden email]> 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           [hidden email]
>> 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
>> *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-
>>
>>
>

[Tim Ruppert]

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 <[hidden email]> 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 <[hidden email]> 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           [hidden email]

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 

*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

[cjhowe]

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" <[hidden email]> 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 <[hidden email]> 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 ===

[Andrew Sykes]

Surely "entity" covers plurality?

- Andrew

On Sat, 2007-01-27 at 12:03 -0800, Chris Howe wrote:

> 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" <[hidden email]> 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 <[hidden email]> 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 ===
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[cjhowe]

Um, no.

--- Andrew Sykes <[hidden email]> wrote:

> Surely "entity" covers plurality?
>
> - Andrew
>
> On Sat, 2007-01-27 at 12:03 -0800, Chris Howe wrote:
> > 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" <[hidden email]> 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
>

=== message truncated ===

[Jacques Le Roux]

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

[Jacques Le Roux]

> 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

[cjhowe]

I'm sorry Andrew,

What I meant to say is:

AFAIK No, unless the plurality is a partnership.

--- Chris Howe <[hidden email]> wrote:

> Um, no.
>
> --- Andrew Sykes <[hidden email]> wrote:
>
> > Surely "entity" covers plurality?
> >
> > - Andrew
> >
> > On Sat, 2007-01-27 at 12:03 -0800, Chris Howe wrote:
> > > 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" <[hidden email]> 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
>  
>

=== message truncated ===

[Daniel Kunkel]

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           [hidden email]
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 
*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-

[David E Jones]

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

[Daniel Kunkel]

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
>

[Andrew Sykes]

Chris,

I'm no more a lawyer than you are, but generally in accounting and legal
terms the word "entity" is used because it covers all eventualities. I
guess it's the legalese equivalent of "Party".

I'd be quite surprised if "entity" didn't cover the type of informal
group to which you refer.

Perhaps a very general legal dictionary/glossary would help, rather than
something Apache specific for this?

- Andrew


On Sat, 2007-01-27 at 13:52 -0800, Chris Howe wrote:

> I'm sorry Andrew,
>
> What I meant to say is:
>
> AFAIK No, unless the plurality is a partnership.
>
> --- Chris Howe <[hidden email]> wrote:
>
> > Um, no.
> >
> > --- Andrew Sykes <[hidden email]> wrote:
> >
> > > Surely "entity" covers plurality?
> > >
> > > - Andrew
> > >
> > > On Sat, 2007-01-27 at 12:03 -0800, Chris Howe wrote:
> > > > 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" <[hidden email]> 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
> >  
> >
> === message truncated ===
>

--
Kind Regards
Andrew Sykes <[hidden email]>
Sykes Development Ltd
http://www.sykesdevelopment.com

[David E Jones]

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
>>
>