View source for RFCs not related to any release, or not yet planned

=== [RFC-6] Application of Remi Cresson to PSC ===

==== RFC status ====
* Submitted by Julien Michel (07/08/2015 10:06)
* Accepted by PSC +3 / 0 (12/08/2015 16:33)

=== [RFC] [WIP] Changing licence to Apache v2.0 ===

==== RFC status ====
* Not submitted yet

==== RFC content ==== 
===== What changes will be made and why they will make a better Orfeo ToolBox =====


The goal is to change of licence for OTB, Monteverdi, Monteverdi2 and ice to adopt the Apache v2.0 licence. The rational for this change is as follows :

Copyleft is a very good protection for open-source software in general, since it ensures that it will remain open, but in our remote sensing world it can also lesser the dissemination of our software. Many time we heard of situations were OTB was considered by institutions or private companies for their projects and has been wiped off the table because they (or their clients or partners) wanted to distribute the resulting software under different terms. Sometimes, costly ad-hoc technical designs are used so as to include OTB in the project while distributing it under those required terms. We could argue that this is a matter of convincing everyone that copyleft is not harmful and that OTB is worth the price, but in the mean time OTB get less audience than deserved ... From a practical point of view it could do no harm to simply change the licence to a more permissive one. This might help to develop OTB usage and eventually get more people involved in contributions.

====== Roadmap ======

* Check compatibility of OTB projects third party
** List external third-part 
** List internal third-part

* Contributors agreement
** Signed agreement of contributors for license modification (adaptated from Apache Software Grant)

* Apply changes to OTB source code
** Change headers
** Change copyright file?
** Add notice
** Update documentation 
** Update info about otb license on: otb website, sourceforge, openhub,...

=====  When will those changes be available (target release or date) =====

These changes will be available for next release (OTB 5.0)

=== [RFC] [WIP] Bash completion for command line OTB Applications ===

==== RFC status ====
* Submitted by Guillaume Pasero (16/09/15 15:11)
* Open for comments

==== RFC content ==== 
===== What changes will be made and why they will make a better Orfeo ToolBox =====
The OTB Applications are a simple way to use the Orfeo Toolbox library. They offer at least 2 types of interface : a command line interface and a graphical interface. The command line interface requires to know the different keys to set the parameters (for instance : '-in' , '-out' , '-classifier.svm.type' ). This is displayed by the help message, but it would be very convenient to use bash completion to set the keys faster.

The bash completion doesn't impact the OTB library, it relies on external shell scripts, deployed usually in /etc/bash_completion.d (or a similar path). They impact the packaging of OTB. However, using the library to produce the completion scripts would be simple :
* create an executable that loads each OTB application
* for each application, get its keys
* produce the completion script of this application in the build directory
* optionnaly, when a choice parameter is detected, it is possible to use completion on the following token among the possible choice values (see example below)

I have made a small test for one application : Convert.
The completion script is the following :
<pre>
_otbcli_Convert()
{
  local cur prev
  
  COMPREPLY=()
  _get_comp_words_by_ref cur prev
  
  case "$cur" in
    -*)
      key_list="-in -type -type.none -type.linear -type.log2 -type.linear.gamma -out -hcp -hcp.low -hcp.high -progress -ram -inxml"
      COMPREPLY=( $( compgen -W '$key_list' -- $cur) )
      return 0
      ;;
  esac
  
  case "$prev" in
    -type)
    key_list="none linear log2"
    COMPREPLY=( $( compgen -W '$key_list' -- $cur) )
    ;;
  esac

  return 0
}

complete -o default -F _otbcli_Convert otbcli_Convert
</pre>

'cur' is the current token to be guessed, 'prev' is the previous token. 

I have tested this script successfully. Its generation can be automated without much efforts. It is also possible to use only one file to store the scripts for all the applications (to avoid flooding the bash_completion folder).

=====  When will those changes be available (target release or date) =====

No planned release, but development effort is small.