We’re developing the new lens for looking at models, open source, equipment for visual close study (VCS) of models, for implementation in all modeling apps, platforms, and formats.
Message me if you want to participate, help develop, implement, or use TGN OPEN CODE in your favorite model-based app, platform, or format.
I asked on LinkedIn for advice about open source licensing, which license is best for open source development of this kind, for a project like ours.
I had been interested mostly in the LGPL license. Here’s the thinking:
The TGN VCS open source development volunteer team is expanding already but this means we need to choose an open source license to organize the growing interest.
So I’m asking here for opinions and experience regarding the choice among these open source licenses: https://choosealicense.com/licenses/
If you have experience and/or an opinion regarding these, we’re interested in hearing your thoughts.
Our intention is to pick the correct license that:
- allows anyone to implement in any app, platform, or format the 8 core features of TGN OPEN CODE described here https://tangerinefocus.com/visual-engagement-with-modeled-worlds/
- that requires TGN OPEN CODE to remain open when implemented by others
- but that allows TGN OPEN CODE implementation in larger works that are licensed differently
It looks to me like GNU LGPLv3 is a good choice https://choosealicense.com/licenses/lgpl-3.0/
But I’m new to this kind of decision so all opinions are welcome. And…
I’m starting to change my opinion because of feedback so far.
Antonio González Viegas replied:
For That Open Company, the license chosen was MIT because our number 1 priority was mass adoption, even for commercial purposes of proprietary applications. The reason is that if you don’t get a lot of users, what else matters?
I’d rather have 100 startups using my tech without opening anything up, than 2 following more strict licensing terms. Licenses that force you to open source part of your code may sound sexy, but if your project’s biggest challenge is adoption, choosing such licenses can be like shooting yourself in the foot.
Of course, permissive licenses are not the only reason why someone might use your project. If your technology saves them time, money and headaches, you might get them to jump through the hoops. But it’s going to be another “but” in the conversations you might have with your users.
We went for full freedom, and it’s working great for us so far. Maybe other people running other projects can give you another perspective. Cheers! 🙂

Antonio makes a great argument. And, I don’t know what I don’t know, so I keep thinking…
It seems that many (most, all?) larger works, commercial products, include open libraries, some with an MIT license that allows closing, and some that require keeping the covered library open, like LGPL.

Either way, MIT or LGPL, the licensing of the larger work is unaffected.
I guess there will be some developers who consume open source libraries that they are free to make closed source after they fork them from an open source project, as if they are at an endless all-you-can-eat buffet. They’ll just keep taking whatever everyone else keeps giving and never give anything back.
I’m open to LGPL for TGN OPEN CODE because the core of TGN seems like the kind of thing that should always be open and developing openly for everyone.
Extensions and additions are expected to be beyond the core and unique to every developer, licensed as each developer wants as part of their larger work.
But, probably Antonio is right that MIT is the most direct path to attracting the most good actors, the best developers to the TGN core, and those will more than make up for any bad actors at the buffet.
Another friend said:
LPGL is a great choice, but it makes it harder for collaborators to profit on the project later, cuz they have to keep it open.
It’s a fair tradeoff, it’s just a bit harder to get people onboard. But not impossible!
Oh. Now that’s two.
Now I’m really starting to have a doubt.
I tried to defend my position:
LPGL is only for the core 8 features of TGN. VCS is so much bigger than those 8 features. My argument is that anyone who wants to commercialize VCS apps will benefit nicely from the open core. Anyone can do TGN extensions and additions starting from the open core. And they can keep those extensions and additions CLOSED if they want to. But the open core helps everyone, including those who want to profit from their own proprietary VCS apps.
But it’s kind of a weak argument because, practically speaking, the distinction I try to make between a core feature and its extension might be too fuzzy a difference to mean anything in the real world. And choosing MIT would remove all such potential friction.
So is it MIT then?

I picked cherries from the low hanging branches of a very large very old cherry tree. The seagulls pick from the top.

Have a piece of pie!

All arguments are welcome!
