When distributing a binary created with BlitzMax NG, what licenses do we need to follow/include?
Hi,
Bmx-ng is licensed under zlib-license https://github.com/bmx-ng/bcc/blob/master/COPYING.md (https://github.com/bmx-ng/bcc/blob/master/COPYING.md).
If I remember correctly, so was/is the original Bmax after Mark open sourced it.
-Henri
Thanks for the reply. I should have stated that I'm aware BlitzMax NG itself is under the zlib license. I'm concerned about licenses of things used by BlitzMax NG and MinGW. Is there anything in there that requires us to distribute a license/provide credit?
The used (official) modules are either zlib or public domain. So you should not be restricted in the kind of licence for your _binaries_.
bye
Ron
Just to clarify what Ron said: No, you don't need to distribute any license alongside with your executable program/application.
-Henri
Ah, misread the whole thing. Yes, as Henri said no "licence.txt" for 3rd party stuff is required.
I only answered above if there is a need to restrict your binary too (there are licences enfording derivative works, or works using the library, to be of the very same licence, this is _not_ the case here).
In other words: make your binary and do whatever you want with it.
bye
Ron
From what I understand. If you are using MinGW to build applications, you do have to distribute the winpthreads licence. The gcc run-times if I remember, are distributed under a modified GPL that has an exception clause that allows linking to non-open source code without the need to distribute such code as under the unmodified GPL.
If you have any doubt about such matters, you should seek legal advice from those that specialise in software licences.
Edit: I should point out that MinGW-w64 and it's variants come in either posix or win32 threading that if I remember, come with different licence requirements.
Hmmm.
This seems to be an addition done some years ago:
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/5238F91B.7010602@tdragon.net/
Seems you (dawlane) already linked to it:
http://mojolabs.nz/posts.php?topic=212331
Maybe it would be even worth having BMK output a "binaryname.COPYING.txt" including the needed licence stuff...
Even the Bmx-NG-release-packages would need to have this licences-thing in their directory then.
@dawlane
How does Monkey2 handle it?
bye
Ron
Hmm, well, that's frustrating. I have been using BlitzMax all this time because I knew it was under the zlib license itself. I didn't know about this winpthreads thing, though. From reading mojolabs.nz, it seems BlitzMax doesn't even use it, so it's highly annoying to have to distribute a license for code I'm not even using.
My project is a game maker, so I really don't want to get into the mess of requiring my users to distribute a license...especially if they themselves don't use that code. If they don't distribute the license, I worry that I will get the flak for it since the runtime only reads in an external file created by the editor.
Is this the case only on Windows? Can BlitzMax NG be setup to use a different compiler? Is there a way to remove winpthreads from MinGW?
As far as I see it, you can build your Blitzmax apps in non-threaded mode so to not depend on the winpthreads library, then you don't need to include the license.
http://mingw-w64-public.narkive.com/KIW7zzI9/sigh-back-to-microsoft-compiler
NG is threaded in all cases and utilizes TDM MinGW.
Vanilla 1.50 uses precompiled modules (dunno what MinGW was used) and if you do not recompile / use 3rd party modules, you only use FASM instead of MinGW/GCC.
So for vanilla it depends on what was used for the lib/-folder and the module compilation.
bye
Ron
Quote...and utilizes TDM MinGW
Except that it doesn't. Release version has MinGW-w64, which has two different threading models: Posix and Win32. According to the thread provided by Mark, the author says that Win32 version is not baked into final compiled executable, unless specifically included. I know NG uses threading by default, but which threading ? Perhaps not either one ?
Plot thickens...
-Henri
Hmm, seems you are right Henri.
Somewhere in my mind I thought of Brucey stating to use "TDM MinGW" so I did not look closer in the release-packages. On my linux box it does not use TDM - and on my Windows box I still use vanilla BlitzMax - with an pretty old TDM GCC release to compile some c-stuff - and this only because Brucey tested his modules with TDM stuff at that time. Hmm, should consider moving to NG there to avoid licence "issues".
bye
Ron
So, there are NO license requirements for a vanilla BlitzMax game? Need to get this straight, since I am releasing a demo in November.
Also, is there a license requirement for modules used, even if they're not distributed? For example, I believe I am using Brucey's StringBuffer module. Is a license required even though the source is not being distributed?
The situation with BlitzMax NG seems so confusing. If somebody had a copy of Visual C++, could it be changed to use that and avoid these licensing issues? I have no idea about all that.
Quote from: Derron on August 28, 2018, 19:23:06
Hmm, seems you are right Henri.
Somewhere in my mind I thought of Brucey stating to use "TDM MinGW" so I did not look closer in the release-packages. On my linux box it does not use TDM - and on my Windows box I still use vanilla BlitzMax - with an pretty old TDM GCC release to compile some c-stuff - and this only because Brucey tested his modules with TDM stuff at that time. Hmm, should consider moving to NG there to avoid licence "issues".
TDM-GCC includes winpthreads, according to this page (http://tdm-gcc.tdragon.net/quirks) on their website.
Quote from: LT on August 28, 2018, 22:56:46
So, there are NO license requirements for a vanilla BlitzMax game? Need to get this straight, since I am releasing a demo in November.
Also, is there a license requirement for modules used, even if they're not distributed? For example, I believe I am using Brucey's StringBuffer module. Is a license required even though the source is not being distributed?
I can't say for sure about any version of BlitzMax now...I'm finding it very confusing.
I just looked at BaH.StringBuilder and it appears to be under the MIT license, so you will need to follow the requirements of that.
I took a look at bmk_util.bmx and it seems NG links to winpthread (Posix) not pthread (Win32) in Windows, on Linux it's pthread, on Mac there's no link to pthread at all, so maybe Clang adds this by default ?
After the 0.93 release, NG is now threaded by default, as far as I could tell threading can't actually be disabled now, such as with "-h st" ? If you're using the 0.87 release, you can still build single-thread apps.
Here's Brucey's "threads by default" topic:
https://www.syntaxbomb.com/index.php/topic,82.msg764.html
If your using vanilla Blitzmax, it links to pthread (Win32) not winpthread (Posix) so even if you rebuild with threads there's no need for a license there.
We only need to add this license at the distribution stage (ie. final product) not demos or betas, since we do this all the time and nothing happens.
It seems that if you are using TDM-gcc, then winpthreads is compiled into every executable, whether you use it or not. Other distributions have winpthreads as a .dll or linked statically, and are only needed if you use c++11 std::threads class. So it seems that if you use vanilla BMax, you need to distribute the license with every copy you distribute. I don't believe that NG is using TDM. In the version that is bundled with the release version of NG, there is a libwinpthreads.dll file which I don't see in the TDM-GCC directory. Also doing gcc -v produces "gcc version 5.1.0 (tdm-1)" with TDM, but "gcc version 7.2.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project)" with the version included with NG.
In the TDM version, I see this in the README-gcc-tdm64.txt file:
Because of TDM-GCC's continuing goal of minimizing extra DLLs, winpthreads has
been compiled statically. It will be statically linked with every program you
compile, which will increase your baseline executable size.
...
Because every program you compile will now rely on winpthreads, you should make
sure to read and comply with its MIT-style license, included in the file
"COPYING.winpthreads.txt".
This would indicate that every executable contains winpthreads. I see no such statement in any of the documentation included with NG.
As for other licenses, this would be on a module by module case. Most of the standard brl and maxgui modules should be free of any additional requirements, although I'm not sure what changes Brucey has made to NG that might affect that. Any third party modules would have their own license requirements.
Quote from: markcwm on August 29, 2018, 00:07:11
I took a look at bmk_util.bmx and it seems NG links to winpthread (Posix) not pthread (Win32) in Windows, on Linux it's pthread, on Mac there's no link to pthread at all, so maybe Clang adds this by default ?
After the 0.93 release, NG is now threaded by default, as far as I could tell threading can't actually be disabled now, such as with "-h st" ? If you're using the 0.87 release, you can still build single-thread apps.
Here's Brucey's "threads by default" topic:
https://www.syntaxbomb.com/index.php/topic,82.msg764.html
If your using vanilla Blitzmax, it links to pthread (Win32) not winpthread (Posix) so even if you rebuild with threads there's no need for a license there.
We only need to add this license at the distribution stage (ie. final product) not demos or betas, since we do this all the time and nothing happens.
The version of TDM MinGW in the Win32 v0.87 release has winpthreads. If we don't specifically enable threading, can we guarantee winphthreads won't be included?
I'm starting to wonder if BlitzMax is even appropriate for my project anymore, which is a shame because language and feature wise it's perfect. I don't know of any other languages I could use. I worry that my users will balk at the idea of having to distribute a license for something they don't use. Maybe I'm overthinking it, I don't know.
I don't really see it as much of an issue. Just go ahead and copy the winpthreads license in an easily accessible area, such a in the about box, or with the documentation. That's all that winpthreads requires.
Hi TomToad,
well I'm fairly sure that static linking is the process of copying the library code into the exe, so if you're not building NG multi-threaded in Windows you shouldn't actually have winpthread in the exe. I think the text you posted is a bit misleading, and should read:
QuoteIt will be statically linked [upon request] with every program you
compile, which will increase your baseline executable size.
...
Because every program you compile will now rely on winpthreads [instead of pthread-w32]
And that again means vanilla Blitzmax never needs the winpthread license.
wombats, I'm fairly sure winpthreads isn't included but I can't guarantee anything as I'm not an expert on low-level coding. NG 0.87 should work fine, most changes since have been new language features.
wombats, if you do want to use the latest NG you could make including the license really easy. Just Incbin the license and have it print (or write out) the text file when some text or image is selected, then explain this function clearly in your docs to your users and leave it up to them whether they use it. It could even be written to be compatible with any project using Max2d and posted as a code archive...
Quote from: markcwm on August 29, 2018, 04:09:24wombats, I'm fairly sure winpthreads isn't included but I can't guarantee anything as I'm not an expert on low-level coding. NG 0.87 should work fine, most changes since have been new language features.
I'm not bothered about new language features (vanilla BlitzMax language is what I'm used to, anyway...I would actually use it instead of NG if it supported x64), so if NG v0.87 doesn't have winpthreads or including it can be avoided, I think it would work fine for me. I would want to know for sure that it's not in there, but I'm not sure how I would do that.
Quote from: markcwm on August 29, 2018, 04:54:49
wombats, if you do want to use the latest NG you could make including the license really easy. Just Incbin the license and have it print (or write out) the text file when some text or image is selected, then explain this function clearly in your docs to your users and leave it up to them whether they use it. It could even be written to be compatible with any project using Max2d and posted as a code archive...
That's not a bad idea. I would like to avoid the whole situation if I can, though.
@modules
MIT / zlib are liberal. I think you only need to hand out the licence text when providing others the source code. It is there to always keep the information about the original authors.
@ NG 0.93 (or newer)
If it uses MinGW-W64 and not the TDM variant, it should not use the "problematic" library - so that licence-thingy is not an issue.
@ 3rd party end users
So you develop an ".exe" which utilizes stuff enforcing you to add some licence texts. You now skip adding these licences and hand out the application to somebody else who can create new applications with yours. right?
If so: how could these "somebody else" know that they needed to put in the licences? _They_ can't know that easily. It is up to you to put up licences or not.
If you are dumb/brave, skip adding the licences and your end users will never know.
Or just create - as suggested above - a "projectbinaryname.COPYING.txt" when creating/compiling/... stuff. It is up to the end user to package the COPYING.txt file too - or not.
bye
Ron
QuoteIf it uses MinGW-W64 and not the TDM variant, it should not use the "problematic" library - so that licence-thingy is not an issue.
Derron, I think you'll find this is not correct, winpthread is in MinGW w64 GCC v6+, it's a replacement for the older one which lacks certain C++11 features.
wombats, also if you're just sharing module source code you don't have to reproduce the license. I think I would probably go for a logo/image that writes out the license file when you click it.
Ok. Think I got confused by "TDM" author stating something while W64 authors (from which TDM is basing its release on) did not change that (in 2013).
bye
Ron