ArcThemALL!

[Lupo73]

OK. So I could create a "Plugins" tab in Options for external freeware compressors, allowing to enable them from that window (downloading the exe during enabling). The entire software could become open source and I could update the software description, removing MPRESS as main feature, but reporting a new line like "Support of external compressors MPRESS, Mew, Upack..." Than I could also add an alert in Plugins tab to report that are closed source apps.

In alternative I could or to remove MPRESS support at all or to keep it as Freeware with Open Source components. I added MPRESS for an user request and I understood that could be interesting to have support also for other executable compressors (obviously releasing them externally from the main package). Also these solutions are possible, I'd like to know some opinions to decide how to proceed.

[JohnTHaller]

You could keep it as-is and just call it Freeware with mostly open source components, too. It's not a huge deal if your tool isn't 100% open source, it's just important to be fully upfront about it.

If you don't care about MPRESS much, you could leave it as an advanced option where if the user downloads it and places it in that directory, it'll show up in the interface (but won't otherwise) since I'd wager the downloader may fail on systems with proxies and other things anyway. Or maybe put an 'advanced' option to enable MPRESS in the options dropdown or something. I really doubt MPRESS will be of much use for many people and it could definitely trip up regular users (since it can't be unpacked).

[guinness]

I do think most users will opt for the well known UPX and not MPRESS, I know I would! Plus, after John said that the license with MPRESS will cause problems for the distribution of the application, maybe it's best to consider look at dropping MPRESS and opting for if a user adds the EXE to a certain folder.

[webfork]

License: Freeware with open source components

I recommend following the long-standing convention set by Universal Extractor and many other programs here on the site. List whatever the main program is, then make a note about open and closed internals. For example, "Main program: GPL, Components: Various open and closed". If necessary, include a disclaimer in the program description or link to the actual licenses.

[JohnTHaller]

License: Freeware with open source components

I recommend following the long-standing convention set by Universal Extractor and many other programs here on the site. List whatever the main program is, then make a note about open and closed internals. For example, "Main program: GPL, Components: Various open and closed". If necessary, include a disclaimer in the program description or link to the actual licenses.

I'm inclined to disagree. Universal Extractor, as a whole app, is definitely 'Freeware with open source components' and not 'open source'. It has multiple closed source components without which it won't fully work. Just because a GUI is open source doesn't mean the whole app is. The reasoning behind this is that if an app is fully open source, it can be redistributed under an open source license. If even one component is not open source, the app can not be redistributed under an open source license (though it may be redistributed under a permissive freeware license).

The standard of what constitutes an open source app is pretty widely accepted. All components of the app must be under an open source license, though exceptions are made for runtimes normally distributed with an operating system (example: newer VC++ runtime version that ships with Windows 7 is allowed to be included in the package so that the app also works out of the box on Windows XP as well). [Aside: Linux/UNIX/BSD there are generally no such exceptions.] Both Google Code and SourceForge use this definition. I believe other open source hosting sites do as well.

[webfork]

The reasoning behind this is that if an app is fully open source, it can be redistributed under an open source license. If even one component is not open source, the app can not be redistributed under an open source license (though it may be redistributed under a permissive freeware license).

So in the future, if we have a big, complex program that includes just one closed library, that program should be listed as "Freeware with open source components"? That may be fine as a matter of some legal issue for SourceForge, Google Code, or other sites, but its not accurate. Part of the reason I asked Andrew to implement linking inside the "License" field was to provide specifics where "Freeware/Open Source" wasn't clear.

Edit: I may have found an example of what I'm describing: PortableApps Chrome is listed as BSD-licensed with a GPL launcher. Wikipedia however lists some components as proprietary due to integration with Adobe Flash.

Assuming this is correct, how should we describe Portable Chrome's license when all but a small amount of code is open?

[SYSTEM]

Just because a GUI is open source doesn't mean the whole app is. The reasoning behind this is that if an app is fully open source, it can be redistributed under an open source license. If even one component is not open source, the app can not be redistributed under an open source license (though it may be redistributed under a permissive freeware license).

While we are at it...

Can Mozilla Firefox, Portable Edition be called open source? One can't legally edit it and redistribute the edited copy after that.[*] The restriction directly defeats one of the objectives of free software. ("None of the users can adapt or fix the program.")

[*] The name and logo of Firefox are registered trademarks of Mozilla Foundation, and a permission is required in order to distribute custom builds carrying the name or logo.

(Sorry, couldn't resist a chance to attack Firefox. )

[webfork]

Can Mozilla Firefox, Portable Edition be called open source?

Right. This is a real division between the Free Software Foundation's definition and the Open Source Initiative definition. However, while neither group would allow an open license to be applied to closed software, both groups are fine with the use of closed-source software running along side open, properly attributed.

[JohnTHaller]

Edit: I may have found an example of what I'm describing: PortableApps Chrome is listed as BSD-licensed with a GPL launcher. Wikipedia however lists some components as proprietary due to integration with Adobe Flash.

Assuming this is correct, how should we describe Portable Chrome's license when all but a small amount of code is open?

If you check, you'll see we list it as "Freeware / Partially Open Source" with the launcher described as GPL and chromium (on which Chrome is based) described as BSD. The whole package, once installed, is freeware, though, due to the inclusion of Flash. You'll find that our front page stories about Chrome are categorized as "Freeware" as well (we have 2 categories for software stories: Freeware Release and Open Source Release)

I'm debating between "Freeware / Partially Open Source" and "Freeware with open source components" for that field at the moment for our new app directory update, so you may see some apps with one or the other or a slight variant.

[JohnTHaller]

While we are at it...

Can Mozilla Firefox, Portable Edition be called open source? One can't legally edit it and redistribute the edited copy after that.[*] The restriction directly defeats one of the objectives of free software. ("None of the users can adapt or fix the program.")

[*] The name and logo of Firefox are registered trademarks of Mozilla Foundation, and a permission is required in order to distribute custom builds carrying the name or logo.

(Sorry, couldn't resist a chance to attack Firefox. )

Yes. Because you can take the source of the app, recompile it as your own version (sans someone else's trademarks) and release it with all the exact functionality of Firefox without needing to worry about any additional closed source licenses. Same way Debian is open source and you can take it and recompile it (sans someone else's trademarks) and have the same functionality with your own name. In either case, though, you can't use someone else's trademarks, Debian's or Mozilla's, without their permission. The same applies to software like OpenOffice.org, AbiWord, Songbird, etc, all of which are trademarks of someone else and can only be used in specific ways with specific permissions.

A trademark is just a name and branding. It's not the app itself. Nor is it the code. As such, open source licenses do not apply to trademarks.

[SYSTEM]

OK, I can move on closer to my actual point...

Quoting you again:

License: Freeware with open source components

I recommend following the long-standing convention set by Universal Extractor and many other programs here on the site. List whatever the main program is, then make a note about open and closed internals. For example, "Main program: GPL, Components: Various open and closed". If necessary, include a disclaimer in the program description or link to the actual licenses.

I'm inclined to disagree. Universal Extractor, as a whole app, is definitely 'Freeware with open source components' and not 'open source'. It has multiple closed source components without which it won't fully work.

Why exactly do you disagree with webfork? The current content of the license field of the Universal Extractor entry is perfectly accurate ("Main program: GPL, Included libraries: various"). What advantages "Freeware with open source components" would have?

(I was planning to answer my question above and refer to my previous post at the end, but I felt I was attacking a straw man. )

[JohnTHaller]

Why exactly do you disagree with webfork? The current content of the license field of the Universal Extractor entry is perfectly accurate ("Main program: GPL, Included libraries: various"). What advantages "Freeware with open source components" would have?

(I was planning to answer my question above and refer to my previous post at the end, but I felt I was attacking a straw man. )

Because the overall license of an app with both open source and closed source components falls to the most-restrictive license of them all, which would be the closed source components with freeware licenses. So, the license of the whole package in terms of distribution and legal issues is freeware, not open source. That's why I think it makes more sense to list it as freeware first. In terms of distribution, it doesn't matter that the Universal Extractor GUI is GPL as the package includes freeware under more-restrictive licenses, so you can only redistribute or modify it if you follow those more-restrictive licenses.

It's the same reason we list Google Chrome as freeware first. Even though the entire browser is open source (including Google Update when you install it locally now), it includes flash, which is under a freeware license. Thus, the package itself is freeware that also includes open source components.

[SYSTEM]

Why exactly do you disagree with webfork? The current content of the license field of the Universal Extractor entry is perfectly accurate ("Main program: GPL, Included libraries: various"). What advantages "Freeware with open source components" would have?

(I was planning to answer my question above and refer to my previous post at the end, but I felt I was attacking a straw man. )

Because the overall license of an app with both open source and closed source components falls to the most-restrictive license of them all, which would be the closed source components with freeware licenses. So, the license of the whole package in terms of distribution and legal issues is freeware, not open source. That's why I think it makes more sense to list it as freeware first.

I can continue from here: you seem to think that "Freeware with open source components" is more simple. That is, when the first word of the license field is "freeware", the visitor immediately knows that the application isn't entirely open source. Correct?

Another question: why the user should know that immediately? With a little expansion ("Main program: GPL, Included libraries: various open and closed"), the visitor will know that the application is not fully open source when he/she has read the entire license field. Reading it is the least the user should do before redistributing an application!

The problem with "Freeware with open source components" is that it doesn't do justice for the application. Google Chrome Portable is a perfect example: IMHO, Google Chrome Portable should be called "Open source with freeware components" because it is mostly open source.

[webfork]

Well said -- I agree completely.

I can continue from here: you seem to think that "Freeware with open source components" is more simple. That is, when the first word of the license field is "freeware", the visitor immediately knows that the application isn't entirely open source. Correct?

Another question: why the user should know that immediately? With a little expansion ("Main program: GPL, Included libraries: various open and closed"), the visitor will know that the application is not fully open source when he/she has read the entire license field. Reading it is the least the user should do before redistributing an application!

The problem with "Freeware with open source components" is that it doesn't do justice for the application. Google Chrome Portable is a perfect example: IMHO, Google Chrome Portable should be called "Open source with freeware components" because it is mostly open source.

[JohnTHaller]

The problem with "Freeware with open source components" is that it doesn't do justice for the application. Google Chrome Portable is a perfect example: IMHO, Google Chrome Portable should be called "Open source with freeware components" because it is mostly open source.

The percentages actually don't matter at all from a licensing, distribution or legal standpoint, though. The app, as a whole, is still freeware in the overall product. You can't redistribute the whole app under an open source license. You can't use the whole app under an open source license. You can only use and redistribute it under the freeware license. The same applies in apps with multiple open source licenses. If there are portions that are GPLed (more restrictive) and portions that are BSDed (less restrictive), the package as a whole can be redistributed under the GPL. If you had a huge software package that was all BSD binaries and then a single 10k DLL within it that was licensed "for personal use only", the package would not be usable by a business, and it would be important to mention that first. Even if 99.9% of the app could be used by anybody.

If you're interested in classifying ones that are more open source vs less, you could use things like "Freeware / Mostly Open Source" and "Freeware / Partially Open Source". The field used here on PFC is called license, so the first thing that appears should be the overall license. Since it doesn't have to be a set thing, it could even be unique to the app. So Chrome Portable could be "Freeware (Chrome Browser: BSD, Launcher: GPL, Flash: Freeware)". That would be the most accurate as it starts with the license of the overall package and then breaks it down in terms of overall functionality of the pieces of the package.