Is there a way to re-compile ALL visual C++ open source applications with an open source compiler to get rid of external dependencies from closed source DLL's.
I think this is legally the only real way to create real portable apps.
New: streamWriter (Jun 28, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
As John said in his previous post, in the recently locked topic, the MS dll files are NOT the issue. The author included OTHER closed source dlls, and those are the ones that are the problem.
While it is perfectly within the rights of the author to link his open source code to the closed source DLLs within Visual Basic (he owns the copyright, so he can do that) he's using other closed source DLLs that are not part of the Visual Basic runtime
If i'm understanding this incorrectly, please let me know. But my understanding was that it is fine to include the VB runtimes or VC runtimes in an open source project, and that redistribution is still allowed.
The developer formerly known as ZGitRDun8705
Almost right. If the author owns the code, then he is perfectly within his rights to license his code as GPL *AND* still link it to closed source DLLs. It's just that the resulting package isn't open source... it's partially open source.
SourceForge and Google Code make exceptions for hosting to allow projects to include smaller runtime libraries normally included with the operating system. So, ClamWin, which uses the Visual C++ 8.0 runtimes, can include them so it will still work on an older Windows OS that doesn't have it installed (all newer Windows OSes do).
The post we're referring to was for a project that includes multiple closed-source Microsoft copyrighted components that are not part of the Microsoft Visual Basic 6 Runtime Library. So, while the author is perfectly within his legal rights to link to them (provided he owns the copyright to all the code or is using code with similar permission), it can't be hosted on SourceForge or Google Code and, thus, can't be promoted here.
Make sense?
Sometimes, the impossible can become possible, if you're awesome!
Yes, that makes sense. Thanks for the clarification.
The developer formerly known as ZGitRDun8705
Makes perfect sense. Only the reason one could not post anything concerning the app on a forum is a bit sketchy as for the reason you don't want to link to or discuss these applications. This makes it harder for these apps to change something in their source so they eventually will be completely legal (on the Open Source way of things).
But I sorta understand you want to keep the competition for your menu from this website...
I'm not clear on the distinction of issues between linking (to a DLL that is already on the computer) versus distribution of said DLL, or if they are both problematic.
If linking is the problem, what level of linking is acceptable, or at what point does it become unacceptable?
Are there web pages that explain the difference without going into a lot of polemic or dogma?
MC
What we are discussing is not license related. It's related to hosting (SourceForge, Google Code, etc don't allow closed source binaries) and self promotion (we follow the same guidelines in the forums... fully open source under an OSI license only). As a copyright owner, you can link your code to whatever you want.
If you don't own the copyright on GPLed code, you can't link it to closed source binaries that aren't a part of the operating system without permission from the copyright holders.
Sometimes, the impossible can become possible, if you're awesome!
Okay, let me summarize what I think you are saying:
1) Closed source binaries cannot be hosted on SourceForge (with the possible exception of a vc runtime distributable that is probably on the machine anyway?). (This is related to terms of use for the hosting service, right?)
2) GPL'd code cannot be linked to a closed source binary. (This is related to the terms of the license, right? If so, then it is license-related.)
Where can we find more information about what it means to "link" -- how we can tell if a file is part of the OS or not (especially since there are optional parts of the OS), and how can we tell whether a program is "linking" to it as opposed to, well, using a library in the operating system? Or is it an arbitrary decision made by the owner of the GPL'd code?
MC
1. This is correct. SourceForge is for open source software only. An exception is made for smaller (size/bandwidth wise) runtimes normally included with the operating system. According to SourceForge staff: Visual C++ and Visual Basic runtimes qualify, Java and .NET do not.
2. This is correct if you are using code licensed under the GPL. You can't call functions in closed source DLLs (except within the OS itself). Specifically, the FSF refers to it as sharing memory structures or something like that. So, an open source EXE can instantiate or start up a closed source EXE without issue. But it can't call a function in a closed source DLL to do something (unless that DLL is part of the OS).
If you are the copyright holder, you can do otherwise with it, though... since, as the copyright holder, you can relicense the code as you see fit. So, you could release it as GPL with exceptions for certain closed source DLLs. You just can't host that package with those closed source DLLs on SourceForge, Google Code, etc.
Sometimes, the impossible can become possible, if you're awesome!
Maybe he meant: MSCOMCTL.OCX and MSINET.OCX. I don't know. I don't think he specific named the closed source components that caused the problem, or if there is a way to fix that.
I still think it's useful to stay away from all Microsoft and other so called 'closed source' dependencies for Open Source applications to avoid having these strange problems of what is allowed and what not. I'm not an expert in what files are not allowed and which are allowed. But if even many open source applications have some 'legal' issue that makes links to be removed from this forum it might be worth it to look for a better solution that will make open source really independent from restrictions like these.
I'm just afraid this is a case of 'MicroSoft Lock-In'.
I agree that staying away from the MS dependencies would make things fully open source, but at the same time, is it realistic to attempt to re-compile EVERY MSVC app with a different compiler? And for Visual Basic (what the app in question was written in) it's an MS language, so there's no way around that one.
The developer formerly known as ZGitRDun8705
Big problem, yes... Maybe switching to another basic and start over again would be a good thing.. I don't know. I only hope that open source eventually will switch to use open source for development of applications so people like me can also compile the source without needing some costly or free tool to re-compile and maybe in the future supply additions.
For example, I really wish that PAM was compiled using some open source tool so I could re-compile myself without needing to buy an expensive development platform. And the source code is not compatible with the free versions of delphi (Turbo Delphi) available.
But that's a bit off-topic maybe.
Point is, Windows is set up in a way that it encourages people to use the shared files and if they are missing, they need to be installed onto the system. And that is one of the strong points of Windows and also the flaw. Portable apps assume to be completely be stand alone and that's the strong point of Portable apps, and a long time wish I had. But Open Source has come to a point that sometimes it requires dependencies that need to be installed on the system that make it incompatible as being stand alone.
And sometimes it feels using closed source and open source together will hinder Open Source.
Just seen the post of John on SF
MSCOMCTL.OCX
MSINET.OCX
scrrun.dll
shdocvw.dll
VB6STKIT.DLL
These Visual Basic controls are included. Hmm, that would mean that the menu doesn't actually doesn't need these? (Else it would be useless to have an app compiled which depends on these files without being allowed to put them with your app).
The app does need those..which is why they are there. Linking to a dll requires the dll to be present, so the code can be accessed.
The developer formerly known as ZGitRDun8705
Yeah, but thats what I find weird. If the app needs them (like the MSVB DLL) and wont work without, and they are part of the VB, why can the VB DLL be put with the app while these cannot. What advantage has it to allow the MSVB dll then...
But I guess it's all technical. But it would be worth having imput that would make this app work without these dependencies.
I have compiled PAM with the free version of Delphi.
What version and where to get it?
I tried several already and it didn't work.
Also, some free delphi's don't have the option for 3rd party plug ins. With the new version coming with PNG support.. how would that impact the use of the free Delphi?
I already was thinking to create a kind of menu with C++ somehow...
Delphi version 2006. I downloaded it about 5 weeks ago from Codegear's website. I'm reading a book on it now.
how do you figure theres a free version. I can see only a 30 days limited time trail.
The price of it is very high...
http://cc.codegear.com/free/delphi