John,
Thanks much for the time that you spent on that reply! It is definitely
helpful for everyone I think to see the reasoning behind this decision.
I can agree that if one of the primary intents are to deter people from
contributing (that aren't as serious or committed as others), then
requiring a signed and faxed contributor agreement will help.
I can also agree that using a standard license instead of a "JASIG
license" is a good idea (people are more apt to feel comfortable with
those things that they understand).
I think that if Apache's rules on loss of patent rights if you sue are
part of the objective, then it might be a good reason to switch to the
Apache license as well, as patent related issues appear to be one of the
main differences between Apache and BSD, MIT licenses.
From experience, I don't agree with "that means that Jasig itself is
forever bound to the terms of that license for its own handling of the
project." I personally have worked on a small project (Shibboleth
Authenticator for Confluence) that was originally under the Apache
license for the original version written by Chad LaJoie of Georgetown
University. Through a simple email to him and others involved (iirc), I
asked if he didn't mind as we migrated the code into Atlassian's
developer repository and to modify the project to use the BSD license.
He agreed, so we converted the project to use that license. In addition,
the Confluence Space User Management plugin project I assisted with went
through a similar license change at one point where the team agreed on a
license change. Neither I nor other developers on either of these
projects ever touched pen to paper on any contracts, however those
changes of licenses happened by consent. Since then, I've considered
talking to the those two dev teams about the possibility of migrating
our projects to the MIT license as suggested by a coworker (Jeremy
Bandini) who used it in a project he developed. At some point, we might.
The reason I mention any of this is that I'm don't think that code
licenses are always that difficult to change later. Also, I'm not
absolutely sure, but my guess is that you are on similar legal footing
by changing the entire license for all of the code the people have
contributed after you've switched to Apache's license and process as you
would before you switched, mostly because I think in the end it would
come down to the situation (was there some sort of malicious intent, is
it obvious that something was stolen, how able are the lawyers, etc.).
Hope this helps, and good luck!
Gary
John A. Lewis wrote:
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
