Apache license and godoc

[matt (Matt Holt)]

Is there a way to apply the Apache license properly without it appearing in godoc?

Apache requires boilerplate to appear at the top of every single source code file (which I hate, but whatever), something like this:

//   Copyright {yyyy} {name of copyright owner}
//
//   Licensed under the Apache License, Version 2.0 (the "License");
//   you may not use this file except in compliance with the License.
//   You may obtain a copy of the License at
//
//       http://www.apache.org/licenses/LICENSE-2.0
//
//   Unless required by applicable law or agreed to in writing, software
//   distributed under the License is distributed on an "AS IS" BASIS,
//   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//   See the License for the specific language governing permissions and
//   limitations under the License.

What’s a good way to do this without having it clutter the godoc?

[tucnak (Ilya Kowalewski)]

Invent your own license, let’s say Mattache license 1.0, based on Apache 2.0, which doesn’t require that and that’s it.

[dfc (Dave Cheney)]

Make sure there is a blank line between the copyright blob and the package declaration.

Self promotional blog post

[billhathaway]

If you desire people working for other organizations to use your libraries easily, be careful about creating one-off licenses. In many organizations the legal teams will restrict their developers to using open-source components licensed under a specific set of licenses and if you create a “special license” that even has just a subtle and well-intentioned change, it may require an exception from the legal team to use it.

[dfc (Dave Cheney)]

@billhathaway

If you desire people working for other organizations to use your libraries easily, be careful about creating one-off licenses. In many organizations the legal teams will restrict their developers to using open-source components licensed under a specific set of licenses and if you create a “special license” that even has just a subtle and well-intentioned change, it may require an exception from the legal team to use it.

Having worked for one of “those” organisations, I cannot recommend Bill’s advice highly enough.

The goal of an in house legal department is to protect their employer from risk, and saying no to something new is a very easy way to reduce risk. Don’t make it harder for organisations by writing your own version of GNU/Snowflake-2.0. It’s not worth the cost of being slightly different.