[License-discuss] Mixed 5yr non-open then fully open license

John Dupuy john at cattailcreek9.com
Mon Jul 30 21:33:11 UTC 2018


Fantastic references!

>    - TGGPL https://github.com/zooko/tgppl  (not OSI approved)
>    - BSL  https://mariadb.com/bsl11 (not OSI approved)

Looked at them both.

The TGGPL was very difficult to read and follow. But appears to be a wild GPL mixed with dynamic short term exceptions.

The BSL was better, but also dynamic in nature. There is no "drop dead date" where everything without exception or restriction becomes open source, including all changes made up until the very moment of the drop dead date.

IMO, the fixed date is critical, otherwise, it never really becomes open source. The open source "version" is always behind the current branch.

> This approach is deeply flawed as it (at best) hinders collaboration[1] and
> prevents innovate alternate uses of parts of the code by unknown others[2].

I agree in that it is not my intent to have any collaboration or alternate uses during the proprietary period.

For example, for my "Kalah Mancala" game, the open source date is February 10, 2022. After that, the game is essentially on a MIT License. Even if put up more code on February 9, 2022, it still all goes to MIT on Feb 10th. Before then it is fully locked down other than for casual viewing.

Just thinking: perhaps if the "casual viewing" part was removed. That would make the license even shorter and simpler. Essentially "MIT" with a start date.

(It is my understanding that if I put fully proprietary software up on GitHub (with no license at all) and make it viewable by the public, that does not give way any rights per se anyway. Other than the implicit ability for outsiders to see it. So having the "casual viewing" period is kind of redundant.)

John

ref:  https://github.com/PurpleSquirrelGames/MancalaGameApp

> How about:
> 
>    - TGGPL https://github.com/zooko/tgppl  (not OSI approved)
>    - BSL  https://mariadb.com/bsl11 (not OSI approved)
>    - Discussion on Wikipedia
>    https://en.wikipedia.org/wiki/Business_models_for_open-source_software#Delayed_open-sourcing
> 
> This approach is deeply flawed as it (at best) hinders collaboration[1] and
> prevents innovate alternate uses of parts of the code by unknown others[2].
> 
> Cheers,
> 
> Simon
>



More information about the License-discuss mailing list