License

[lrvick]

As the person who did initial implementation work and submitted the RFC that helped inform the design of the current spec, I politely request that the license file be pulled from the repo until we can reach some consensus.

GDFL will very probably make this spec a total non starter for commercial use in many companies. Just to pick on Google, their legal teams actively block use of code/specs that are encumbered by viral licenses. Sometimes they are allowed for some projects, but it is a fight many engineers at large companies don't like to bother with, and will just make up their own clean-room solutions (then sometimes legal teams patent them!).

If the goal of this project is to further security we can and should allow this spec to be used by anyone for any reason, and make private use or forks of it as they see fit. The only protection we should seek is against patents that would prevent us from using our own spec and tools as -we- see fit.

TL;DR:

I am very confident sure GDFL will seriously inhibit wide adoption of this spec. I propose Apache 2.0 or MIT (or dual license as both) which are far more liberal and Corporate America™ approved.

[Ekleog]

Did you read the IETF license? It's, from my reading, worse than the GFDL from a “viral” point of view: you're not even allowed to modify the text. I don't think that has prevented any company from having an SMTP server, an HTTP server, or a TCP/IP stack. And I'm pretty sure the legal teams were not even notified of it. (oh, and wikipedia was GFDL only until ~2008, now it's dual-licensed GFDL/CC-BY-SA… contacts I have at google didn't tell me wikipedia was blacklisted there)

For the code, I completely understand you. For the spec, it's a non-issue.

Also, having the spec GFDL does not prevent tools from being MIT/Apache2. Tools could then be modified internally by companies.

Overall, I don't see the issue.

Then, I really don't care. When adding a license (for the sole purpose of initializing the repository) I tried to guess which license @oxij would prefer, and went with it (sounds like I picked it right :p). Now, if you really want to remove the GFDL now (despite my points above), then it means removing the current RFC text too, as @oxij has full copyright on it, until they say whether they accept to re-license it under another license.

[lrvick]

Obviously big companies use well established specs like SMTP, and are allowed to -consume- things like wikipedia. Or even the GPLed linux kernel and toolchain.

A lot of things like that, in my experience, are regarded as "grandfathered" and any new use of viral licensing must get approval from legal teams.

I just don't see any reason to license it in any way that would give any legal teams pause. Also I have no problem with a big company forking the spec internally to take advantage of internal tooling. MIT/Apache2 would allow this.

I don't have some Stallman ideal that licensing must force things to stay open source. Imo everyone should be able to do whatever they want, so long as the original authors can continue doing whatever they want without conflict.

IANAL and think all of this is silly personally, but I am mostly coming from a position of having personally had to argue with legal teams at multiple companies now over viral licensing for trivial things. I have also had multiple Googlers steer me away from anything stronger than MIT for the reasons I outlined.

[Ekleog]

Did you have experience with people steering you away from anything stronger than MIT for a specification (as opposed to for a program)?

I mean, almost all specifications are made by the IETF, and thus almost all specifications are under their more-restrictive-than-GFDL license. A lot of those that aren't are made by the ISO, which is even worse. Basically, when thinking about it I can't easily remember of any specification that'd be released under lighter-than-GFDL terms.

[Ekleog]

Also, companies wouldn't need to even see the specification to use the tools, and assuming the tool is MIT/Apache2, this would mean that all they would ever need to know is they're using a MIT/Apache2 tool. Never even making the spec enter the corporate network :)

[lrvick]

I suppose I can fight for this harder if we ever hear that it becomes a problem. I do agree code and documentation have different implications.

I don't really see any good reason to prevent people from distributing private internal forks of documentation though (which this license disallows from my understanding)

[Ekleog]

Hmm… My understanding of the GFDL (or of the GPL for that matter) is that it does not require you to make your changes public, only to allow people to which you give the derived work to make the changes public.

In the case of a company, I'm not really sure how that would be resolved, because employees are both humans by themselves but also part of the company… so I don't really know whether the company would be allowed to force employees not to redistribute the modified spec outside. I would guess it could (by giving only itself a license of the derived works and having employees work off its own license), but I'm completely uncertain (and not a lawyer).

Now… well, I guess if that ever becomes a problem in practice you'll have a really good argument in favor of changing the license? I would suggest closing this issue until then :)

[oxij]

Yes, both GFDL and all versions of GPL allow for private changes to stay private. However, if you want to distribute your private changes, you must publish them under the same license. Which is kinda the point if we want the different tools implementing this to stay inter-operable.