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
>

_______________________________________________
License-discuss mailing list
License-discuss@lists.opensource.org
http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org

Reply via email to