Licensing considerations / recommendations for the Smart Columbus OS

[bilsch]

As part of the Smart Columbus Program Management Plan under section 13.4 titled "Partner Awards" the "USDOT strongly prefers that the Recipient acquire and develop open source technologies throughout the course of the SCC Demonstration and that any code developed for the project is, via contract or equivalent mechanism, open source and available for license-free use and enhancement by third parties"

Full quote:

Preference for open source tools

The USDOT strongly prefers that the Recipient acquire and develop open source technologies throughout the course of the SCC Demonstration and that any code developed for the project is, via contract or equivalent mechanism, open source and available for license-free use and enhancement by third parties. Data rights under the Award shall be in accordance with 2 CFR 200.315, Intangible property.

The platform developed is already considering open source technologies and tools. We must also research and evaluate the various open source / free software licenses. We should end with choosing at least 1 license for the software produced but also allow for different licenses to be utilized. The primary concern / thought on multiple licenses is if, for instance, we are extending or linking against software which has restrictions for doing so.

A non-exhaustive list of possible licenses we should be evaluating:

1. The GNU General Public License
   • Linking against v3, we could look at older editions
2. The GNU Lesser General Public License
3. The GNU Affero General Public License
   • We will need to be cautious here. Licenses of existing in-use software as well as many other issues needs to be considered.
4. MIT
5. Apache
   • Likely we would want to evaluate V2
6. Mozilla Public License
   • likely just using V2
7. Eclipse public license
8. BSD
   • 3-Clause
   • 2-Clause
9. ISC
   • Ref the wikipedia page for highlights

We could look at the creative commons however these are not really geared towards software and more towards documents and artistic creations ( drawings, graphics, audio and the like)

[jdenen]

We may or may not create graphics as part of this effort. I think creative commons is a good call out. It shouldn't be a primary objective, but we should evaluate it, too, if we have the bandwidth.

[rubberduck203]

I’m happy to see that list.
It aligns closely with the OSI’s list of “popular” licenses here.
https://opensource.org/licenses

I think it makes sense to limit our evaluation to those.

[bilsch]

I think it makes sense to limit our evaluation to those.

Yea many of them were either linked directly to opensource.org or I followed to the original source and linked there. They do a nice job at collecting the various open source licenses.

I'm not against at least considering additional licenses but I suspect for our own sanity we will likely narrow down to just a few licenses. That said, if anyone feels strongly about a license not being included here please comment so we can add to the list.

[jdenen]

We should also be differentiating between the type of software we're building. We build a few different things:

1. General tools that could be used in any context (like a testing library)
2. The general platform that another city could pick up and use to implement their own Operating System
3. The Columbus-specific implementation of the OS
4. Configurations of the Columbus-specific implementation that we probably don't want to be public

To me, it makes sense for those things to fall under different licenses. I would prefer something like:

Software	License
General tool	Apache2
General platform	Apache2 or GPL3
Columbus platform	GPL3
Columbus private	N/A

These are the licenses that I'm most familiar with, so maybe there are better fits. But the general idea is that the more generic stuff is built with licenses that allow anyone to pick them up and use them, and the Columbus-specific stuff has to be open downstream.

[rubberduck203]

You just made this hard for me @jdenen. That is pretty much exactly the recommendation I would make, but now I have to retroactively justify that opinion.

s/General tool/library
s/General platform/application

and I'm completely on board with that recommendation.

Probably need to ask this out loud though....
A lot of companies/organizations are still (unjustly) allergic to the GPL.
How does that factor into our recommendation (if at all)?

Also, if we're going to recommend GPL for application/platform level code, should we be recommending the LGPL for libraries?

[rubberduck203]

I updated the wiki page to reflect some of the conversation here.
Please feel free to make further edits.

https://github.com/SmartColumbusOS/TechnicalWorkingGroup/wiki/Licensing-Models

[skpy]

Have folks here read the Debian Social Contract? It's a good end-user friendly document that articulates Debian's positions on licensing, which may be useful to this discussion.

I am not keen on employing different licenses for different aspects of this work. What, exactly, does that gain us? What, exactly, does it gain any future users of our work?

Regarding GPL phobia, do we care? Do we think that a company will contribute something to our work only if our work is not copyleft? Does anyone have first hand knowledge of this kind of thing, or is this just hypothetical?

any code developed for the project is, via contract or equivalent mechanism, open source and available for license-free use and enhancement by third parties

The enhancement bit there is a surprise. That does suggest that something like SQLite's example is not a good model for our work here. It doesn't advocate specifically for a GPL solution, but it's more forward-thinking than it reads at first blush.

For our deliverable, we are asked to identify risks associated with open source licenses, and potential mitigations. What risks do folks see with each of ASL, BSD, and GPL?

[bilsch]

Have folks here read the Debian Social Contract? It's a good end-user friendly document that articulates Debian's positions on licensing, which may be useful to this discussion.

I really like this idea of a social contract! Reading over the Debian contract right now and this feels very much like what we should be working towards

[jdenen]

Does anyone have first hand knowledge of this kind of thing, or is this just hypothetical?

I've seen companies be averse to using GPL licensed software. I've seen other open source projects be averse to incorporating GPL licensed projects because companies would then be averse to using the original project. For example, tomas-abrahamsson/gpb#152.

Regarding GPL phobia, do we care?

I'm not sure. I certainly don't care when it comes to our applications.

But I'd like the libraries we build to be reusable by all, as that's (IMO) the best way for them to garner contributions and be the best libraries they can be.

If GPL phobia causes a company to not use one of our libraries, that seems like a miss.

From #1:

The Apache license has been the one I've been favoring the most for the last several years.

I'm cool if all our software is licensed under Apache.

[joelgerber]

I agree with the Apache License. I think that's the one that most organizations will be both familiar and comfortable with.

[rubberduck203]

Just so we’re clear on this, the discussion in #1 suggests people want a Free (Libre) license. Apache is an Open license, not Libre.

I’m ok with that. I’m just getting conflicting signals here.

[joelgerber]

I still favor the Apache license but I'm open to discussion.

[skpy]

@rubberduck203 can you provide a link showing that ASL is not a free-as-in-freedom license?

Apache claims otherwise:

Is Apache software open source?

Yes. The Apache License meets both the Open Source Initiative's (OSI) Open Source Definition, and the Free Software Foundation's definition of "free software".

These definitions ensure that the Apache license provides certain key freedoms to users of Apache software in terms of what you as a user may do with or use Apache source code or software