C#•4y ago

Choosing a license for a software specification

We are writing a specification for a programming language and we'd like to pick a license for the specs (not the compiler). There are two major goals we want to achieve:

The specs should stay free forever
It should be impossible for anyone to close off the sources to the specification

This almost yells GPL, but since we are targeting a platform where there is a huge potential for languages to interop, we don't want such an invasive license. If another compiler team wants to do anything related to something they have to read our specs for, they are technically doing derivative work, which forces GPL on them, which we'd like to avoid. While it's desirable to enforce same license when forking the specs itself, this case is wildly different and we wouldn't like to enforce that.

What would be the recommendations for our situation?

Angius•9/10/22, 8:54 PM

Maybe LGPL or MPL?

LPeter1997OP•9/10/22, 8:57 PM

Will take a look at these 2

LLPeter1997 We are writing a specification for a programming language and we'd like to pick ...

Up•9/10/22, 9:00 PM

honestly I'd go CC0

UUp honestly I'd go CC0

LPeter1997OP•9/10/22, 9:02 PM

that's a super definite no

Up•9/10/22, 9:02 PM

why

LPeter1997OP•9/10/22, 9:03 PM

CC0 puts no restrictions on the licensed material that I've mentioned as goals

Up•9/10/22, 9:03 PM

correct

LPeter1997OP•9/10/22, 9:03 PM

We want to keep those restrictions

LPeter1997OP•9/10/22, 9:03 PM

Hence that's a super definite no

Up•9/10/22, 9:04 PM

still the best thing to use for specifications, imho.

what you want is adoption, and people to be able to use your lang freely.

LPeter1997OP•9/10/22, 9:04 PM

People can freely read the specs

Up•9/10/22, 9:04 PM

no.

LPeter1997OP•9/10/22, 9:04 PM

They don't need to clone and close off the sources of the specs

Up•9/10/22, 9:04 PM

I mean.. they couldn't anyway, since they don't control your repo?

LLPeter1997 People can freely read the specs

Up•9/10/22, 9:04 PM

not with any GPL family license, they cannot

LPeter1997OP•9/10/22, 9:05 PM

These specs are for compiler implementers

Up•9/10/22, 9:05 PM

yes

LPeter1997OP•9/10/22, 9:05 PM

(So us currently)

Up•9/10/22, 9:05 PM

and if I were to want to make my own implementation, the spec being GPL would effectively prevent me from doing that

LPeter1997OP•9/10/22, 9:05 PM

And I don't want anyone copying the specs without any consequences

LPeter1997OP•9/10/22, 9:05 PM

Hence wanting restriction on the license

LPeter1997OP•9/10/22, 9:06 PM

and if I were to want to make my own implementation, the spec being GPL would effectively prevent me from doing that

That's not true

LPeter1997OP•9/10/22, 9:06 PM

Your compiler would have to be GPL simply

LPeter1997OP•9/10/22, 9:06 PM

We don't want GPL, we want to be way less restrictive about derivative work

Up•9/10/22, 9:08 PM

ok, so, given your original goals, CC0 still is a pretty good choice

LPeter1997OP•9/10/22, 9:09 PM

The idea of Apache v2 came up as well, that's not a horrible choice. Non-copyleft, requires state changes documentation.

LPeter1997OP•9/10/22, 9:11 PM

Looked at LGPL, sadly suffers the same from derivative work.
MPL also looks like a solid choice

Up•9/10/22, 9:12 PM

It should be impossible for anyone to close off the sources to the specification

so.. just leave your repo up indefinitely. again, others don't control your own repo.
and with a permissive license that allows redistribution, people can make their own backup copies of it, incase yours is taken down.

The specs should stay free forever

publish your version as CC0, encourage people to redistribute it.
if you have enough adoption, it'll be impossible to shut that down again.

--- YES, people would be able to make their own derivative specs, and have them be proprietary. but these would NOT be the same as your specs, anyway, so why do you care?

LPeter1997OP•9/10/22, 9:13 PM

so.. just leave your repo up indefinitely. again, others don't control your own repo.

If you don't want to understand what I mean, sure

(but just to be clear, I'd prefer people not creating closed-source derivatives of the specs)

LPeter1997OP•9/10/22, 9:15 PM

YES, people would be able to make their own derivative specs, and have them be proprietary. but these would NOT be the same as your specs, anyway, so why do you care?

Because if others want to base their work off of ours, we want certain things in return. Pretty simple. The price you pay for taking our work is accepting the conditions of our license

LPeter1997OP•9/10/22, 9:17 PM

And I have no intentions to lift this restriction

Up•9/10/22, 9:17 PM

so you do want GPL then RikoShrug

LPeter1997OP•9/10/22, 9:17 PM

We might, with some modifications to the license

LPeter1997OP•9/10/22, 9:17 PM

We do want to protect our work

LPeter1997OP•9/10/22, 9:21 PM

But again, GPL is a bit too restrictive

Original message was deleted

LPeter1997OP•9/11/22, 7:27 AM

Preferably all copies should be publicly available, modifications should at least document changes. Ideally, all other specs that copied this one and then modified it should be public and other kinds of derivative work should be less restricted (to allow for the scenario in the OP), but that's really hard to properly specify in a license I think

LPeter1997OP•9/11/22, 7:40 AM

What about MPL then?

LPeter1997OP•9/11/22, 7:41 AM

My law jargon knowledge is horrific, but to me it seems like it's same license that contains one-to-one copy of MPL code or one that is copied then modified

jcotton42•9/11/22, 4:19 PM

@LPeter1997 GFDL maybe?

jcotton42•9/11/22, 4:20 PM

https://www.gnu.org/licenses/fdl-1.3.html

jcotton42•9/11/22, 4:20 PM

It's the GPL, but for technical writing

LPeter1997OP•9/12/22, 12:45 PM

Sadly that suffers from the same limitations as GPL in general. After a lot of discussion and headaches, so far it looks like we'll go with Apache v2