Gary,

I definitely appreciate the thoughts and I take seriously what you are
saying.  I think there are a few issues here that are worth exploring.

I agree that getting a form and a database up and running is pretty
simple.  But I think that approach is problematic for a number of
reasons.  1. We are trying to have less infrastructure around, since
maintaining it is difficult in an all-volunteer organization -- this
would create new, permanent infrastructure.  A minor point, but a valid
one.  2. If we ever had to, how can we prove that the person who typed
in their name on a form and clicked "I Agree" was actually that person? 
Someday when everyone has Shibboleth running this will be easy, but for
now we would either have to go to a lot of electronic trouble to have a
more rigorous authoritative digital identity, or we would have something
that was no real proof to begin with and wasn't worth doing. Not that a
signature on a faxed or scanned piece of paper is massively better, but
certainly it is a stronger legal position and is still the accepted
standard in this area.  3. It's interesting that you say you would be
perfectly willing to click to agree to a policy but are hesitant to sign
a contract.  The legal commitment on your part should theoretically be
the same, and yet you feel different about it -- I agree with that
feeling and I think it has something to do with point 2.  So, in trying
to provide good governance for Jasig, that reaction actually makes me
want the signed form.  We do want people to think carefully about
whether they are legally able and willing to make the contributions they
are making.  That pause over signing a contract is a good thing, in my
opinion.

But I agree that the process of signing and returning some paperwork is
more of a logistical hassle than I would like and I would love to do
anything we can to reduce the friction it causes, but not by lowering
the level of the legal value of the process.  I welcome any ideas on how
we can make this better and still preserve the process.  I do think we
want our project committers to be committed (no pun intended) to the
project, and if this logistical hassle if enough to scare them away,
then they probably weren't really serious to begin with.  I've worked in
a number of other communities that use these kinds of agreements
(including Apache, Spring, and Sakai) and require them to be submitted
in the same way and I haven't seen it be a barrier that is driving away
valuable committers from the project.

I agree that lawsuits aren't really the issue here.  There has never
been one in Jasig history and there probably never will be.  We are more
likely to have trademark issues than we are to have copyright or patent
issues.  However, there are a number of other good reasons for having
the contributor agreements, which are briefly addressed in the FAQ. 
Just to better illustrate, here is the one line of thinking that I find
to be the most compelling reason: We want to move to a more rigorous
software license, something like Apache or GPL (for a number of reasons
mentioned in the FAQ).  If we change to one of those licenses and
continue to accept contributions without any other legal mechanism in
place, then Jasig itself is accepting those contributions under the
terms of the selected distribution license (Apache, in our case).  That
means that Jasig itself is forever bound to the terms of that license
for its own handling of the project.  Which then really restricts
Jasig's ability to govern the project effectively and makes logistically
difficult/impossible to ever adjust the licensing again (see the
cautionary Mozilla tale also mentioned in the FAQ).

One other thing I'll mention about the value I see in this new process: 
As someone working for a company that is routinely trying to convince
institutions to adopt these Jasig projects, we have had cases where the
potential client has asked about the licensing and intellectual property
policy.  It doesn't happen often, but it does happen.  In those cases,
the way Jasig has operated in the past has been a barrier to adoption. 
For the sustainability of these projects and the health of the
community, we need to continue to draw in new adopters -- I believe this
policy will help with that.

I understand that your feelings are not strong on these issues and that
your comments are more of an intellectual interest.  I appreciate that
and I think the dialog is valuable in order to help get everyone to a
greater level of common understanding.  I hope you will continue to ask
questions as you have them.

Thanks!
John



Gary Weaver wrote:
> John,
>
> Thanks for the response! You've obviously spent a good deal of time
> thinking about this and are a good bit more knowledgeable than I am on
> the subject. Just for the heck of it, I'll explain my thoughts and
> questions a little bit better, but feel free to disregard, as it is
> not a big deal.
>
> I am not sure what you mean by "We'd have to adopt/build some real
> infrastructure to have something like this be believable." A simple
> online form with a legal agreement takes very little infrastructure
> I'd think. It does take a tad bit of dev time to put a form together
> and have it save to the database, but it's not much in the grand
> scheme I suspect. By an online agreement, it would not only serve to
> remind contributors that they are entering into an agreement, but they
> would respect the fact that you respect their time enough not to
> require them to sign and fax in a contract.
>
> I'm also guessing that JASIG (former JA-SIG) has done well enough
> already without such agreements (I've not heard of any lawsuits at
> least). And my guess is that contributor agreements are probably of
> less meaning in courts than NDAs, which are hardly of much good except
> to strike fear in those that believe in them from what I read. Am I
> off in thinking that?
>
> Finally, I for one don't like to sign my name on contracts if I don't
> have to. If many other developers feel the same way, I think that
> having contributors sign and fax agreements is just going to make
> developers either less likely to contribute (or want to contribute) or
> more likely to just submit patches (causing additional work for the
> existing contributors). If you don't believe me, you might email the
> user and dev lists (both comprised of those submitting patches) for
> major Apache projects, state that JASIG is considering adopting this
> practice, and ask them whether they would be more likely to become a
> contributor if they didn't have to do anything (or only had to submit
> an online form) or if they had to sign and fax in an agreement, and
> see what kind of response you get.
>
> Again, even though I'm taking the time to write this, I have no strong
> feelings about it. I am just trying to do what I can to help JASIG
> attract more developers, and hopefully this insight will help.
>
> Thanks again for taking the time to respond, and best of luck!
>
> Gary
>
>
> John A. Lewis wrote:
>> Gary,
>>
>> Thanks for posting your thoughts and questions.  Sorry for not
>> responding sooner.
>>
>> I agree that signing paper docs is a bit archaic, but the legal world
>> moves very slowly.  If we ever needed to "audit" the contributor
>> agreements, claiming that someone clicked something agreeing to it is
>> dubious.  We'd have to adopt/build some real infrastructure to have
>> something like this be believable.  I also feel like we should follow
>> the lead of other bodies that have worked in this space much longer and
>> more broadly than we have.  Both the Apache Foundation and the Free
>> Software Foundation still recommend and use actual signed documents.
>>
>> We have talked about adding legal notices to things like JIRA and
>> Confluence regarding patches.  Since we will still want to accept
>> patches from people who are not committers (and who are not necessarily
>> interested in attaining committer status), we still want to accept these
>> patches, but we will want them to be clear on the broader terms under
>> which they are submitting them.  Doing something in this area is still
>> on my "to do" list for licensing.  I agree we want to avoid signed
>> agreements for patch submissions.
>>
>> The licensing policy does not necessarily need to apply to projects that
>> are in a "sandbox" state, but any project that wants to graduate from
>> incubation and be considered a Jasig sponsored project will need to
>> comply with the policy to reach that state.  As long as projects were
>> originally managed at Jasig under the New BSD license (like uPortal and
>> CAS), going forward we can release them under the Apache License and
>> don't have to make prior contributors do anything.  There are a lot of
>> notes on this in the policy writeup.
>>
>> We think of Jasig much more like Apache than Sourceforge.  We aren't
>> just hosting infrastructure for any project that wants it.  Sourceforge
>> and Google Code are already fine options for that.  Apache does require
>> signed contributor agreements for all of its sponsored projects, and we
>> have modeled our policy closely after theirs.
>>
>> I hope that addresses your concerns.  Thanks!
>>
>> John
>>
>>
>>
>>
>> Gary Weaver wrote:
>>  
>>> Cris said that this might be a more appropriate place to send my
>>> comments below.
>>>
>>> Thanks!
>>> Gary
>>>
>>> -------- Original Message --------
>>> Subject:     Re: [uportal-dev] Jasig/uPortal Licensing Policy Update
>>> Date:     Wed, 29 Jul 2009 09:50:48 -0400
>>> From:     Gary Weaver <[email protected]>
>>> Reply-To:     [email protected]
>>> To:     [email protected]
>>> References:     <c695348c.2555b%[email protected]>
>>> <[email protected]> <[email protected]>
>>>
>>>
>>>
>>> BTW- I noticed that JASIG was actually using Apache's process which
>>> involves signing this: http://www.apache.org/licenses/icla.txt - I
>>> guess maybe the committers have needed to sign actual forms, but
>>> that those submitting patches didn't. But, I think don't completely
>>> understand why a signed document is needed vs. agreement via
>>> submitting form on the web. Handsigning and faxing seems pretty
>>> old-school, and I think is mostly there as a deterrent to
>>> involvement by developers, which I don't think JASIG needs imo.
>>>
>>>
>>> Gary Weaver wrote:
>>>      
>>>> Something else I thought of if it helps is that Sourceforge, Apache
>>>> (although it was several years ago and my patch was integrated by
>>>> someone else), and Atlassian community projects that I've
>>>> contributed to have not required actual hand-signed
>>>> statements/contracts (that I remember at least- RPI was the only
>>>> one that required a signed agreement for Bedework iirc).
>>>>
>>>> Couldn't there just be an online form to submit a request for
>>>> access to contribute that doesn't require printing/signing/faxing
>>>> or mailing? I'm pretty sure that I had to agree to something when
>>>> signing up with sourceforge. Then whenever changes came about,
>>>> they've just sent an email to state the changes to the agreement
>>>> (and maybe how to contact them or opt-out if they disagree) iirc.
>>>>
>>>> License changes for uPortal and other top-level JASIG projects
>>>> could then just be handled by an email out to the group stating
>>>> that everything under the JASIG umbrella in the code had a proposed
>>>> license change and it could be voted on like any other changes.
>>>>
>>>> Thanks!
>>>> Gary
>>>>
>>>>
>>>> Gary Weaver wrote:
>>>>            
>>>>> Curious- will this also apply to all portlets contributed to sandbox?
>>>>>
>>>>> How feasible is all of this if there is some code here and there
>>>>> (not sure if there is, but if there is) that was contributed under
>>>>> a different license?
>>>>>
>>>>> In open source projects before, I've never been asked to change
>>>>> the license by the person hosting the source control repository
>>>>> (it has usually just been an initiative by the developers on the
>>>>> project itself), so am just curious.
>>>>>
>>>>> Thanks!
>>>>> Gary
>>>>>
>>>>>               
>

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Reply via email to