Please clarify Ohana API licensing

[NeilMcKLogic]

I pinged Greg asking about licensing for the Ohana API and he indicated: "I've noticed that the License seems to be copyright of Code for America. But I'd been told by Code for America when I was working with them that their licenses default to GPL."

If CfA still owns this project, can someone in authority there please clarify what the licensing is? Anyone using it (or considering using it, like us) should know under what licensing terms they are operating if using the Ohana API.

[monfresh]

The license is clearly stated right here: https://github.com/codeforamerica/ohana-api/blob/master/LICENSE.md

If CfA is no longer using that license, then someone at CfA should update the license. I did a quick random check of a few CfA repos, and many of them use the same license as the one here. I found some repos that used the MIT license.

[monfresh]

Also, note that the presence of a copyright doesn't mean that you can't use the software. Many licenses, including GPL, require the presence of a copyright notice.

[greggish]

Thanks, @monfresh. We'll ask CfA about this. To be clear in the meantime: does the erstwhile Ohana team have a position on the license? If Ohana users ask for it to be specified as an open source license, do you support that?

[NeilMcKLogic]

Thanks for the responses. In addition to Greg's request of the Ohana team, the license makes no mention about someone creating a compatible (either partially or fully) implementation that might use just some or maybe none of the Ohana code.

We're considering that option as the documentation shows Ohana has a nice clean implementation for exposing HSDS-formatted data (kudos, @monfresh), but our technology stack is completely different from what Ohana is built with. Plus we might go further with other endpoints than what Ohana has,

From a legal perspective we think we'd probably be fine proceeding with or without permission (does the Ohana team assert otherwise?) but to have it better spelled out in the license would be comforting to us and anyone else contemplating doing something similar. And if all of our implementations are compatible then that should overall be better for the industry.

[monfresh]

What do you mean by "open source license"? What part of the current license do Ohana users not like? Is it the copyright notice? The most common license used in open source projects, at least the Ruby ones I use, is the MIT license, which includes a copyright notice. See the one Rails uses for example: https://github.com/rails/rails/blob/master/MIT-LICENSE

If it were my personal project, I would most likely use the MIT license.

http://choosealicense.com/ helps you choose an open source license for your project, and it recommends MIT since it is simple and permissive:

It lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable.

I believe that is what the current Ohana API license does as well:

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

I'm not sure why CfA went with their own license as opposed to a standard one. Given that some of the newer CfA repos have the MIT license, I would imagine they would be OK with Ohana changing its license to MIT.

[greggish]

Sounds like we are on good footing here, one way or another.

As for concerns about the current license, I hope Neil can chime in himself. I will say that at first glance (tho IANAL) it kinda seems like the third bullet in CfA's license is in tension with the first two:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• Neither the name of Code for America nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

My interpretation of this is that people can redeploy and adapt the code as long as the code retains the license and attributes CfA, but they can't associate the resulting product with CfA (without permission).

Assuming basic attribution =/= 'endorsement' or 'promotion,' it seems like folks like Neil should feel confident that they can adopt the Ohana code + protocols without running afoul of IP. (Though I also think there may be some lingering confusion as to why it's licensed to CfA "All Rights Reserved" instead of just GPL.)