Are you sure about the "Unlicense"?

[rishikeshsjoshi]

That was just a temporary file which got added automatically while creating the Repo. We planned to change the licence to: https://creativecommons.org/licenses/by/4.0/deed.en

[mwakok]

The TU Delft guidelines on choosing a license mentions that all Creative Commons licenses are unsuitable for software. The only exception is CC0. TU Delft has pre-approved the following licenses: Apache, MIT, BSD, EUPL, LGPL, GPL and CC0.

In general they recommend:

• Use a license that is common in the community
• If feasible, maintain coherence by using the same license as the dependencies your software derives from.
• If there is absolute freedom:
  • Apache 2.0, which works well with industrial partners
  • GPL, which ensures that any software that uses your code will automatically be covered by the same GPL license.

[rschmehl]

In most of our software we are now using the MIT license (which I understand is quite similar to the Apache 2.0 license). The issue with GPL is that it has the potential to scare off users from industry, because these will in most cases not want that their derivative code needs to be published under the same GPL license and published. On the other hand, we depend a lot on industry and the purpose of this code is to get industry involved.

[mwakok]

Indeed, in that case the GPL license might not be a suitable option. With regards to the difference between MIT and Apache, the guides state:

The Apache licence is sterner in protecting the access rights [with respect to MIT and BSD]. The licence agreement also contains a “retaliation” clause, which does not allow filing of patent infringement proceedings against people using the Apache covered code. It means that if someone files infringement proceedings (in court) on a software, which was itself a derivative of code under an Apache licence, then they infringe the licence itself. As a result, they automatically lose the licence and the right to use the software (and therefore their infringement claim is void and they become the perpetrator). The Apache licence is still considered a “permissive” licence because it can co-exist with other licences. For example, a basic package can be made freely available under Apache licence, whilst the add-ons and special features are made available (e.g. for a fee) under a proprietary licence.

And regarding industry involvement:

In general, at the Valorisation Centre -in dealing with start-ups and corporately funded research- we observe that the Apache licence works well for all the different interests at play between university and corporate headquarters (or garage-box in case of a start-up). It tends not to raise a red flag from companies investing in R&D projects at the universities and does protect the “open” character of the software. Apache was the first to embed a “patent-retaliation” clause that allows the software to stay open, even when under a patent. The main drawback associated with Apache is that it does not enforce openness on derivative programs.

[mwakok]

One other difference between the MIT and Apache license, is that Apache licenced software cannot be reused in GPL covered software (which is likely why the Apache license does not raise many red flags with industry):

[rishikeshsjoshi]

If I understand correctly, we still need to make a choice between our two most preferred ones: MIT and Apache? Also, we have TU Delft and Polimi, both since Filippo our coauthor is from Polimi. How does the License holder work in this case?