I've also been involved with some fairly small projects that had fewer than 10 developers over the life of the project, that were stuck with a license that was causing problems because one of the original core developers had disappeared. Legally the license could not be changed on the project without contacting the MIA developers which pretty much killed a bunch of new development that was hoping to incorporate code from a project with an incompatible license.
-Eric Gary Weaver wrote:
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 typedin their name on a form and clicked "I Agree" was actually that person? Someday when everyone has Shibboleth running this will be easy, but fornow 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 havingthe contributor agreements, which are briefly addressed in the FAQ. Just to better illustrate, here is the one line of thinking that I findto 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 convinceinstitutions 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 thecommunity, 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 followthe lead of other bodies that have worked in this space much longer andmore 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 acceptpatches from people who are not committers (and who are not necessarily interested in attaining committer status), we still want to accept thesepatches, 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 thatare 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 wereoriginally managed at Jasig under the New BSD license (like uPortal andCAS), 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'tjust 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 wehave 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
smime.p7s
Description: S/MIME Cryptographic Signature
