Re: [uportal-dev] License Switch
It may be too late to bring this up but I would say it is also a good time to switch any portlets that are bundled with the uPortal release to be switched to the new license as well. I am thinking especially of the Web Proxy Portlet. Susan Eric Dalquist wrote: This only affects /uPortal, nothing else is affected which is why it was only announced on the uportal-dev email list. No one's SVN accounts were removed, only commit access to /uPortal was removed for some individuals who have not committed to uPortal in over 18 months. The reason there wasn't more heads up for the uPortal project is we looked at the list of recently active uPortal comitters and everyone that has committed in the last 18 months had an ICLA on file so we weren't going to be cutting anyone off who was active and this change only has an effect on active committers. Most of your other questions are project specific but I'll try to address them generally. Having an ICLA on file for every active committer is a prerequisite for code moving out of the incubation process and becoming a full-fledged project. It is up to each project's lead to determine how and when the license switch happens and how to handle commit access to that project. So there is no way to provide a general timeline for ICLA deadlines and commit access changes, that is completely up to each individual project. The uPortal steering committee hasn't directly discussed if we will change the license for future releases off of existing branches, my gut feeling says they will stay the same but the policy for the uPortal project from this point forward is that a ICLA is needed for commit access to any part of the /uPortal source tree. Again I believe this is a project by project decision. I would hope that any committer that is active enough to actually be making changes in SVN for a project is also active on that project's development email list and would have seen the coordination for the license switch. Again while this may seem sudden for uPortal it did not cut off any active committers nor did it affect anyone outside of the uPortal developers. ICLAs and licensing only pertain to code contributions. I would assume however that developers that don't have SVN access would also be removed from the developers group for that project in Jira and Confluence but again that is up to the lead for that project. One thing we may be looking at adding is a checkbox in Jira for granting license for patches similar to what the Apache Foundation does right now. In their case if someone without a ICLA on file submits a patch they must check a box that states Grant license to ASF for inclusion in ASF works (as per the Apache License http://www.apache.org/licenses/LICENSE-2.0 §5) for that patch to be usable by the project committers. An ICLA on file with Jasig covers any project under the Jasig umbrella. Again for specific projects it is up to that project's developers and lead to determine when to do the licensing switch and how to coordinate it. If you are a project lead or project committer it would be good to read the following pages: http://www.ja-sig.org/wiki/display/LIC/Jasig+Licensing+Policy http://www.ja-sig.org/wiki/display/LIC/Implementing+the+Licensing+Policy http://www.ja-sig.org/wiki/display/LIC/Transition+Process+for+Existing+Projects -Eric On 1/15/10 10:49 AM, Gary Weaver wrote: Eric, Just to clarify, this only affects the uPortal part of Jasig subversion starting with the following directory and all subdirectories, correct?: https://www.ja-sig.org/svn/uPortal/ In other words, those with Jasig subversion access to the following will not be kept from committing to the following, correct?: https://www.ja-sig.org/svn/portlets/ https://www.ja-sig.org/svn/sandbox/ And could you provide a deadline to when you are going to delete/disable svn accounts if agreements are not signed by that date and time? Is there a way to apply for an extension if someone is waiting on the agreement to be approved, and how should that be done, and how would that be handled? And if there are plans to disable access to the other parts of the repositories at a later date, could you provide information on plans and deadlines for those also? And will all previous tags, branches, etc. be converted to the Apache 2.0 license, and if not, does the new agreement permit those to work on older tags and branches that were licensed differently, since I'm assuming that the agreement (iirc) requires all work to be done under the Apache 2.0 license? Also, will there be a message in svn for older committers that try to commit but can't indicating how they can easily (re)apply for access if access is denied? Will access also be changed for the wiki, jira, and other tools provided by Jasig? Will this affect CAS and any other projects in process of being adopted like
Re: [uportal-dev] License Switch
Note that the following might be helpful to use in the pom.xml to include the LICENSE and NOTICE in the war of each portlet: !-- See: http://geronimo.apache.org/maven/genesis/plugins/tools-maven-plugin/usage.html -- plugin groupIdorg.apache.geronimo.genesis.plugins/groupId artifactIdtools-maven-plugin/artifactId executions execution idinstall-legal-files/id phasegenerate-resources/phase goals goalcopy-legal-files/goal /goals /execution /executions /plugin (see https://www.ja-sig.org/svn/sandbox/MailPortlet/tags/rel-2.0.0-alpha-7/pom.xml ) Even though the MailPortlet still probably needs some license cleanup, maybe that will help. Thanks, Gary Susan Bramhall wrote: It may be too late to bring this up but I would say it is also a good time to switch any portlets that are bundled with the uPortal release to be switched to the new license as well. I am thinking especially of the Web Proxy Portlet. Susan Eric Dalquist wrote: This only affects /uPortal, nothing else is affected which is why it was only announced on the uportal-dev email list. No one's SVN accounts were removed, only commit access to /uPortal was removed for some individuals who have not committed to uPortal in over 18 months. The reason there wasn't more heads up for the uPortal project is we looked at the list of recently active uPortal comitters and everyone that has committed in the last 18 months had an ICLA on file so we weren't going to be cutting anyone off who was active and this change only has an effect on active committers. Most of your other questions are project specific but I'll try to address them generally. Having an ICLA on file for every active committer is a prerequisite for code moving out of the incubation process and becoming a full-fledged project. It is up to each project's lead to determine how and when the license switch happens and how to handle commit access to that project. So there is no way to provide a general timeline for ICLA deadlines and commit access changes, that is completely up to each individual project. The uPortal steering committee hasn't directly discussed if we will change the license for future releases off of existing branches, my gut feeling says they will stay the same but the policy for the uPortal project from this point forward is that a ICLA is needed for commit access to any part of the /uPortal source tree. Again I believe this is a project by project decision. I would hope that any committer that is active enough to actually be making changes in SVN for a project is also active on that project's development email list and would have seen the coordination for the license switch. Again while this may seem sudden for uPortal it did not cut off any active committers nor did it affect anyone outside of the uPortal developers. ICLAs and licensing only pertain to code contributions. I would assume however that developers that don't have SVN access would also be removed from the developers group for that project in Jira and Confluence but again that is up to the lead for that project. One thing we may be looking at adding is a checkbox in Jira for granting license for patches similar to what the Apache Foundation does right now. In their case if someone without a ICLA on file submits a patch they must check a box that states Grant license to ASF for inclusion in ASF works (as per the Apache License http://www.apache.org/licenses/LICENSE-2.0 §5) for that patch to be usable by the project committers. An ICLA on file with Jasig covers any project under the Jasig umbrella. Again for specific projects it is up to that project's developers and lead to determine when to do the licensing switch and how to coordinate it. If you are a project lead or project committer it would be good to read the following pages: http://www.ja-sig.org/wiki/display/LIC/Jasig+Licensing+Policy http://www.ja-sig.org/wiki/display/LIC/Implementing+the+Licensing+Policy http://www.ja-sig.org/wiki/display/LIC/Transition+Process+for+Existing+Projects -Eric On 1/15/10 10:49 AM, Gary Weaver wrote: Eric, Just to clarify, this only affects the uPortal part of Jasig subversion starting with the following directory and all subdirectories, correct?: https://www.ja-sig.org/svn/uPortal/ In other words, those with Jasig subversion access to the following will not be kept from committing to the following, correct?: https://www.ja-sig.org/svn/portlets/ https://www.ja-sig.org/svn/sandbox/ And could you provide a deadline to when you are going to delete/disable svn accounts if agreements are not signed by that date and time? Is there a way to apply for an extension if someone is waiting on the agreement to be
Re: [uportal-dev] License Switch
Eric, Just to clarify, this only affects the uPortal part of Jasig subversion starting with the following directory and all subdirectories, correct?: https://www.ja-sig.org/svn/uPortal/ In other words, those with Jasig subversion access to the following will not be kept from committing to the following, correct?: https://www.ja-sig.org/svn/portlets/ https://www.ja-sig.org/svn/sandbox/ And could you provide a deadline to when you are going to delete/disable svn accounts if agreements are not signed by that date and time? Is there a way to apply for an extension if someone is waiting on the agreement to be approved, and how should that be done, and how would that be handled? And if there are plans to disable access to the other parts of the repositories at a later date, could you provide information on plans and deadlines for those also? And will all previous tags, branches, etc. be converted to the Apache 2.0 license, and if not, does the new agreement permit those to work on older tags and branches that were licensed differently, since I'm assuming that the agreement (iirc) requires all work to be done under the Apache 2.0 license? Also, will there be a message in svn for older committers that try to commit but can't indicating how they can easily (re)apply for access if access is denied? Will access also be changed for the wiki, jira, and other tools provided by Jasig? Will this affect CAS and any other projects in process of being adopted like Bedework, and if so, does a single contributor license cover all of those projects? Sorry for all of the questions! Thanks in advance, Gary Eric Dalquist wrote: As part of the ongoing Jasig effort to switch to the Apache 2.0 license uPortal 3.2 will be released under Apache 2.0. As part of that effort Jasig is requiring that all active developers sign an Individual Contributor License Agreement (ICLA). We have a number of developers that have already taken this step but not all. To that end we will be removing commit access to the uPortal project for all developers without an ICLA on file with Jasig. For those developers that are loosing commit access due to this action, access can be easily restored simply by providing the Jasig with the ICLA documentation. The following list are the developers with current SVN accounts, that have previously committed on the uPortal project and have an ICLA on file: apetro arybicki awills bourey bszabo dschultz edalquist gthompson holdorph lfuller sbattaglia sbramhall tuyly For the ICLA form and more information about the Jasig licensing policy: http://www.ja-sig.org/wiki/display/UPC/SVN+Last+Commit+Data For a complete list of developers with completed ICLAs: http://www.ja-sig.org/wiki/display/LIC/Completed+Contributor+Agreements For a complete list of developers that have committed on the uPortal project and the date of their last commit: http://www.ja-sig.org/wiki/display/LIC/Jasig+Licensing+Policy If you have any questions about this change or interest in becoming a committer on the uPortal project please feel free to contact me directly. Thank you, -Eric Dalquist -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] License Switch
As part of the ongoing Jasig effort to switch to the Apache 2.0 license uPortal 3.2 will be released under Apache 2.0. As part of that effort Jasig is requiring that all active developers sign an Individual Contributor License Agreement (ICLA). We have a number of developers that have already taken this step but not all. To that end we will be removing commit access to the uPortal project for all developers without an ICLA on file with Jasig. For those developers that are loosing commit access due to this action, access can be easily restored simply by providing the Jasig with the ICLA documentation. The following list are the developers with current SVN accounts, that have previously committed on the uPortal project and have an ICLA on file: apetro arybicki awills bourey bszabo dschultz edalquist gthompson holdorph lfuller sbattaglia sbramhall tuyly For the ICLA form and more information about the Jasig licensing policy: http://www.ja-sig.org/wiki/display/UPC/SVN+Last+Commit+Data For a complete list of developers with completed ICLAs: http://www.ja-sig.org/wiki/display/LIC/Completed+Contributor+Agreements For a complete list of developers that have committed on the uPortal project and the date of their last commit: http://www.ja-sig.org/wiki/display/LIC/Jasig+Licensing+Policy If you have any questions about this change or interest in becoming a committer on the uPortal project please feel free to contact me directly. Thank you, -Eric Dalquist smime.p7s Description: S/MIME Cryptographic Signature
