Item — HN Reader

Be sure to carefully review the license, especially if you're a business user:

https://www.naturaldocs.org/documentation/#File:Engine/Resou...

It's AGLPv3, which is usually OK for development tools because you aren't modifying/shipping them to customers - only the output/artifacts (a la GCC). But NaturalDocs will inject AGPLv3 artifacts (JS, CSS, etc.) into your doc output:

    Portions of Natural Docs are automatically included with generated documentation in order to 
    help it function, such as JavaScript, CSS, and image files.  These included files retain the 
    copyright and licensing terms of Natural Docs, but those terms do not apply to the remainder 
    of the generated documentation.  All other generated documentation files remain under the 
    copyright and distribution terms decided by its author.

So if you're shipping docs generated by NaturalDocs to customers then you are shipping AGPLv3 and need to follow the license requirements.

2 comments

Hi, I'm the author. That language was intended to specifically say that Natural Docs' license doesn't affect the rest of the documentation, let alone the project it's documenting, but without forfeiting my copyright to those particular files. If there's language that I could include to make this even clearer I'd be happy to.

In my opinion shipping code plus documentation generated by Natural Docs does not cause the code to fall under the AGPL, as you are bundling it rather than making a derivation of it. You could argue that the documentation is a derivation of it, but that's what I try to explicitly disavow above.

Just FYI:

This makes total sense. But that’s not how corporate lawyers read it in my experience.

I think it’s a) poor legal understanding of software and b) AGPLv3 signaling litigiousness.

And in some regards, even if the lawyer doesn’t fall in A, they know courts may. Their job is risk management.

If I submit, they’ll tell me to use a MIT, BSD, Apache 2.0, etc alternative or buy something and suck it up.

Also they have a bunch of these to review, plus contracts, etc. so understandably have no time to debate.

Accomodating corporate lawyer intransigence should be solved with them paying you $$$ for a separate license, not picking a different license.

That is a totally valid option. That’s a successful model for things like DataStax, RedisLabs, RedHat, and on and on. If you’re wondering how a company makes money just selling open source, this is it.

And for the record, I think this is dumb. But I’m describing the reality of what I have to deal with so folks making can understand.

There’s 2 basic routes here:

1) offer it for under 1k per seat through a distributor. Then it’s like buying an IDE. You won’t pick up a company-wide deployment, but team by team.

2) Have a commercial offering listed with pricing. Then have sales and legal folks.

The sales will be negotiating the price down by volume. The legal will go back and forth on the contract. Companies will require different language based on their requirements and legal culture. It’s not uncommon for them to require OSS indemnification. That can mean absorbing their risk if you don’t own 100% of the code. You’re basically their insurance policy on OSS violations.

Also, usually this includes some kind of (often useless) support agreement. Pricing can be tiered by response time (24x7, next business day, and so on.). It’s not a big deal on something non operational like this.

For the indemnification, the legal department doesn’t trust their developers (or contract developers) to take a shortcut, not pay attention, or whatever and expose them to a claim.

I should also say, not caring about megacorp adoption is also totally reasonable.

If I didn’t build it from scratch and didn’t want to start a company, that’s the route I would go.

Something that could be helpful and clarify the intention, is to explicitly license those artifacts under a different, more open (Apache/MIT/etc.) license.

Can't touch this now even with a 40 foot pole, back to good old JavaDocs I go :)