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

[skpy]

The point of a software license is to explicitly declare what a user can and cannot do with the software and source code. Are there any considerations or assumptions within the SCOS that have not been declared here?

• Are there specific things that users of SCOS should be restricted from doing?
• Can a company use the code for for-profit efforts?
• Can a community add additional functionality without sharing that back to the main project?
• What pieces of the SCOS suite of software would benefit from different licenses?

If GPL is selected, what benefits and drawbacks does that introduce for adoption of the software?

If LGPL is selected, what benefits and drawbacks does that introduce for adoption of the software?

[skpy]

Also, are there specific pieces of existing code that are desirable to use for SCOS? If so, that may greatly influence the decision.

[PhilNorman2]

We should also explicitly state the need (or not) for patent and copyright grants and trademark restrictions - which are included in the Apache and GPL licenses but not the MIT license. These are legal issues but have an impact on selection.

[jdenen]

I believe we should close this issue in favor of answering the questions posed in #9, #10, #11, and #12.

Let's talk about each license independently. When necessary, we can reconvene the debate of choosing one. And we'll have the benefit of listed pros/cons/considerations when that time comes.

[bilsch]

I prefer to actually not close this issue. The issues you created ( thank you, great idea! ) inform the over-all result.

There are possibly a few additional issues. For sure we should discuss the idea expressed in #3 (comment) and what logic / reasoning we would want to apply there

[jdenen]

For sure we should discuss the idea expressed in #3 (comment) and what logic / reasoning we would want to apply there

Then lets open an issue to answer a question around that.

These open-ended discussions are useful up and to the point of generating more concrete questions to answer. If we believe this discussion has more questions to generate, then we should keep it open.

But let's not conflate generating questions and answering them all in this issue.

[bilsch]

I disagree. I view this issue like an epic with a number of dependent issues / items which we then come back here to aggregate and possibly continue a with additional issues.

I view the definition of done on this issue to be consolidation into the wiki document.

[PhilNorman2]

If #3 is the overarching issue, what is missing for me is the concise criteria to compare the license attributes, e.g., our preferences on permissiveness , commercial and government uptake, contributor agreements including copyright and patent grants, etc. independent of the licenses themselves. Such a document, clearly stated, should help clarify the pros and cons. Perhaps a short issue pointing to a wiki page, “Open Source Licensing Criteria” that we could edit would help us out. I am happy to work on that if others feel it is helpful.

…

On Wed, Nov 14, 2018 at 2:56 PM Bill Schwanitz ***@***.***> wrote: I disagree. I view this issue like an epic with a number of dependent issues / items which we then come back here to aggregate and possibly continue a with additional issues — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeOsMDOj8VkUIJbSVinDrO7G5qHIAofzks5uvHVPgaJpZM4X9uPy> .

[jdenen]

I view this issue like an epic

I can buy into that analogy. But that means almost no discussion should happen in this issue, yes? All the discussion should be happening in sub-issues. This issue should just be a list of child issues with check boxes.

My problem with this issue is that it is too open ended. Nothing definitive is (currently) going to come of it, IMO. That said, I'm not opposed to repurposing it to track sub-decisions.

[bilsch]

I think @PhilNorman2 's comment about the criteria we should evaluate each license against is the first step to do here before we discuss each license individually. Thoughts?

I can buy into that analogy. But that means almost no discussion should happen in this issue, yes? All the discussion should be happening in sub-issues. This issue should just be a list of child issues with check boxes.

Agreed lets try to focus on ^^ to come up with our criteria to them focus on the individual licenses and then consolidate / make the wiki doc and recommendation

[rubberduck203]

what is missing for me is the concise criteria to compare the license attributes, e.g., our preferences on permissiveness , commercial and government uptake, contributor agreements including copyright and patent grants, etc. independent of the licenses themselves. Such a document, clearly stated, should help clarify the pros and cons. Perhaps a short issue pointing to a wiki page, “Open Source Licensing Criteria” that we could edit would help us out. I am happy to work on that if others feel it is helpful.

@PhilNorman2 yes. Please do!

[warnerAWESOMEmoore]

If folks haven't seen, useful reference: https://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses

[PhilNorman2]

@warnerAWESOMEmoore That is a great starting point. I seeded a table of TWG preferences based on these criteria at:

https://www.dropbox.com/home/TWG/Segment%203/Technical%20Track/TechnicalWorkingGroup.wiki?preview=Open+Source+License+Criteria.docx

I also added a Copyright Grant critieria as I understand the MIT license is not as explicit on this. I started with dropbox as I didn't want to do the wiki markup if this is not what folks are looking for.

[PhilNorman2]

On second thought, the Copyright Grant criteria is not needed, as the Copyright components of use, modification and distribution are called out as separate critieria.

[PhilNorman2]

I bit the bullet an added the table markup for a new github page.

https://github.com/SmartColumbusOS/TechnicalWorkingGroup/wiki/Open-Source-Licensing-Criteria

This replaces the dropbox page above (now deleted). Feel free to comment or make changes. I plan to share this with the slack channel to get more feedback.

[rubberduck203]

Whether modified code may be licensed under a different license (for example a copyright) or must retain the same license under which it was provided

I’m not certain that’s what sub-licensing means. I’m pretty sure sub-licensing means a person granted rights under a license may grant those rights to others. This snippet is talking about “relicensing”, which no FLOSS license I know of allows.

https://softwareengineering.stackexchange.com/a/189704/142319

[bilsch]

I'm still curious what the thinking is behind a comment from @jdenen regarding choosing different licenses based on the type of repo as discussed in #3 (comment) ( and I think elsewhere ).

Has the thinking behind this been captured anywhere?

[bilsch]

Reading over #3 (comment) and the wiki Open Source Licensing Criteria I really like the table created.

One item which struck out at me a little bit has to do with patents. Below is a copy of the content. Each line is a column from the row on patents:

Patent Grant
Protection of licensees from patent claims made by code contributors regarding their contribution, and protection of contributors from patent claims made by licensees
Patent Grant is required
Could be accomplished through add-on Contributor License Agreement.

While at rubyconf I had a very interesting conversation with someone who works on government funded scientific research. He mentioned something really interesting that I was not aware of. I had always held the opinion that government funded research was not able to be patented but he mentioned there is a specific requirement for it to not be patent-able.

I'm far from a legal expert but are the works created for this subject to the Bayh-Dole Act or equivalent?