Python, xorg and others with GPL dependencies.

I really love in what FreeBSD is converting in, and it's license philosophy which I personally share, I'm not an expert though, so I might be talking nonsense.

From the ports point of view, I understand that not all the software that we load in should be BSD, MIT, etc. this is the exact benefit from BSD. But I noticed when installing Python which is NOT GPL, that there are some GPL dependencies to it, like gettext, and others... so finally the FreeBSD port of Python behaves as a GPL Python. The same for xorg, it is not GPL, but in order to use it in FreeBSD, you must abide to GPL due to dependencies... Again, I can understand that some applications are and should be GPL, the thing that bothers me is why Python which I can install in my Windows 10 machine is more liberal than FreeBSD. So finally, if I want to to build a machine with FreeBSD and Python to run a server, I must abide to GPL... Please prove me wrong, but I think that the whole point of FreeBSD and Python is to avoid that.

Sorry to the admins if this post is not supposed to be here.
 
Well, i am not exactly deep in the code structure or rather dependency structure of the mentioned projects but i know what you are talking about and i've ran into similar situations before. I also share your point of view in that i'd rather avoid GPL code. From my experience the chances of "liberating" applications from GPL dependencies is mixed. Sometimes the feature is minor enough and the configure has a switch so disabling it solves the problem, sometimes a drop in replacement exists, sometimes configure is kind enough to allow for an alternate library to be use but sometimes the code is not made to support alternatives or there simply is no equivalent to the GPL library at all. The amount of code under the GPL is massive and finding someone capable and willing to rewrite functionally fine code just for philosophical reasons is hard so there bound to be situations where there is no way around the GPL "infection". It's unfortunate but that's the way things are right now and to be honest it does not look like this is going to change any time soon even if i'd welcome such a change a lot.

Practically i guess the most productive way to deal with this would be to examine the build setup of the relevant applications. I figure you have at least some programming background and most of the time running the configure and build scripts for any sane application is not particularly hard so a first step would be to examine if the build configuration of the target application supports any kind of reasonable GPL free setting. If they exist i am quite sure your findings would find open ears with if not the port maintainers themselves but at least interested third parties and could be used to either improve existing ports or be the base for some new alternate non GPL port. Even if there aren't any useful settings to the build configuration an analysis of what exactly is blocking the removal of GPL dependencies would be helpful for potential patch writers to asses the amount of work needed to remove the dependency.

While this would be all good and beneficial on a general level it likely wont affect you in any noticeable way while running servers. Unless you are dealing with an Afero GPL license or you are distributing some form of GPL based binaries (i.e. binaries based on sources including GPL code or linking to GPL libraries) you don't have any obligations anyways. You can patch your server software as much as like and still keep the sources to yourself as you are merely running the modified GPL software but not distributing it.
 
Quit trolling. Dependencies are chosen by upstream projects, not by FreeBSD.

Now that you say it i also get kind of a strange feeling about this one...

It's not entirely up to the upstream projects though. Sometimes it comes down to build options. If i remember correctly TCL is such a case (can be build with GNU readline or without) but i don't know how the FreeBSD port handles this and i have a feeling there actually is a setting in the port configuration so the user can choose if they want it or not.
 
It's not entirely up to the upstream projects though. Sometimes it comes down to build options.

In the Python case gettext dependency is controlled by the NLS option. My assumption that it is likely required by some popular Python applications.
 
In the Python case gettext dependency is controlled by the NLS option. My assumption that it is likely required by some popular Python applications.

That's true. Besides i would generally call NLS a sane default (i disable it personally but a lot of people actually want it) and as far as i know there is no serious non GPL gettext alternative either. At least not one that could even remotely be used as a drop in replacement so tough luck i guess.
 
Quit trolling. Dependencies are chosen by upstream projects, not by FreeBSD.
If the forums has accepted answer feature, this should be chosen as the accepted answer. FreeBSD can only try to make the base system GPL-free, all of his mentioned software is somewhere else ported there (in the ports system). We have no power and no reason to make them GPL-free.
 
Quit trolling. Dependencies are chosen by upstream projects, not by FreeBSD.
I'm not Trolling, I'm not a kid also and I don't have time to troll really, I know that these packages are not maintained directly by FreeBSD staff.... But there are some packages that strategically are not convenient IMHO to let them just be, like Python, Xorg, and many others. IMHO Trolling is that a package that is meant to be BSD like, is linked with some GPL glue to make it GPL. This is a comment and also and advice, you need to keep your project guidelines straight, and perhaps the license policy that FreeBSD uses could extend to some strategic ports.
 
If the forums has accepted answer feature, this should be chosen as the accepted answer. FreeBSD can only try to make the base system GPL-free, all of his mentioned software is somewhere else ported there (in the ports system). We have no power and no reason to make them GPL-free.
I respectfully disagree that you don't have a reason to make them GPL-free, and certainly you don't need to exert power to provide some GPL free ports that follows your own license guidelines (copy - paste from your website), you can have 2 (or any) versions so no one gets offended. The thing is that IMHO there is a port baseline that should adhere to these policies, so you can have a basic platform from which you can develop, not all ports, but the common use cases. I gave the example of Python, because is not a minor one, SDL in example is in version 1.x.x. in FreeBSD, which is GPL, but version 2.x is already BSD like, xorg is MIT but it has GPLV3+ dependencies or alike. So finally for the standard user, it is almost impossible to build a usable platform that adheres at your declared own policies unless he develops everything else from scratch. I'm trying to be constructive here, I really like your project, I'm concerned that in the future you will end up with a lower and ancient version of GNU Linux which has no added value over it because all the libraries and ports are GPL. Also I don't hate GPL BTW, I only think that this project is different and have a different target and that's why it exists.
 
I respectfully disagree that you don't have a reason to make them GPL-free, and certainly you don't need to exert power to provide some GPL free ports that follows your own license guidelines (copy - paste from your website), you can have 2 (or any) versions so no one gets offended. The thing is that IMHO there is a port baseline that should adhere to these policies, so you can have a basic platform from which you can develop, not all ports, but the common use cases. I gave the example of Python, because is not a minor one, SDL in example is in version 1.x.x. in FreeBSD, which is GPL, but version 2.x is already BSD like, xorg is MIT but it has GPLV3+ dependencies or alike. So finally for the standard user, it is almost impossible to build a usable platform that adheres at your declared own policies unless he develops everything else from scratch. I'm trying to be constructive here, I really like your project, I'm concerned that in the future you will end up with a lower and ancient version of GNU Linux which has no added value over it because all the libraries and ports are GPL. Also I don't hate GPL BTW, I only think that this project is different and have a different target and that's why it exists.
You should discuss such a problem in the mailing lists. We are all users here, the developers are not there. IMHO, your proposal will not work. It's completely impossible to build any GPL-free working system nowadays, especially a working desktop system.

The GPL-free principle is only apply for the base system. It doesn't cover the ports system. And it needn't be/shouldn't be so. BTW, they did replace pkg-config with pkgconf, though.

p/s: I quit this debate. It's out of my concerns.
 
the thing that bothers me is why Python which I can install in my Windows 10 machine is more liberal than FreeBSD.

I think this is where you may be mistaken. You are limited by the same license. It is in no way more liberal on either platform compared to the other.

Luckily though the license in both cases is fairly liberal (https://en.wikipedia.org/wiki/Python_Software_Foundation_License)
Seems to be BSD based.

"allows modified versions to be distributed without source code."

Regardless, any code you write in Python can be closed-source. Not even the GPL could prevent that because you are not "linking" against Python. Python is simply a C program that executes instructions based on input text files (python scripts).
 
[...] Regardless, any code you write in Python can be closed-source. Not even the GPL could prevent that because you are not "linking" against Python. Python is simply a C program that executes instructions based on input text files (python scripts).
Python translates to bytecode by default. It depends on the meaning of the term "to link". While we have a very technical understanding of that (linking to a module in machine-readable notation, executable directly by the CPU), a lawyer might be able to convince a court to apply a wider definition.
 
I think this is where you may be mistaken. You are limited by the same license. It is in no way more liberal on either platform compared to the other.

Luckily though the license in both cases is fairly liberal (https://en.wikipedia.org/wiki/Python_Software_Foundation_License)
Seems to be BSD based.

"allows modified versions to be distributed without source code."

Regardless, any code you write in Python can be closed-source. Not even the GPL could prevent that because you are not "linking" against Python. Python is simply a C program that executes instructions based on input text files (python scripts).
As an example, I have used and bought Routers that have Python as an embedded script language, they don't use GPL code inside, and is good that it is that way, because they have certificates and protections for someone using a non certified firmware on it, so GPL will make these routers out of business (for security reasons). In this scenario this company will not be able to sell their routers if using FreeBSD with Python, as I understood that was one of the advantages of FreeBSD OS, its BSD license and freedom. Using FreeBSD in embedded products is very appealing, most appealing for small developers than large companies, you can theoretically buy a Raspberry Pi, load FreeBSD and develop your application and sell it as a commercial product. You are correct about Windows 10, my comment was oriented in the same way you mentioned it, why using Python with FreeBSD if you can, at the end, have the same rights on Windows 10 or Linux desktops, well there is a difference.
 
Regardless, any code you write in Python can be closed-source. Not even the GPL could prevent that because you are not "linking" against Python. Python is simply a C program that executes instructions based on input text files (python scripts).

The difficulty of determining what is and what isn't a derivative work is precisely why GPL is widely disliked in the enterprise context. In my personal opinion, if you are using the aforementioned gettext bindings you are definitely in the "danger" zone. Otherwise probably not.
 
You are selling some unique text. If people decide to pass that text through a specific implementation of Python that is restricted by a license, then that is surely their problem.

If your text happens to contain someone elses text that was released under the GPL, then that would be another matter.

Traditionally compiled languages are a little different in that even when linking against a library (non-statically) you still make use of a small amount of lib code that you didn't write to make the link. if you link entirely dynamically, you can get round this. Compilers under restrictive licenses may be a little different because even a simple hello world program outputs binary instructions that you didn't explicitly write. There is a fair amount of initialization code, especially in C++ before you hit main().

Python translates to bytecode by default.
Software using Python isn't typically distributed as bytecode. I don't think this bytecode has a stable "ABI" either. It is distributed as text file scripts (perhaps obfuscated like Javascript). The bytecode is something the C program (CPython) generates and uses.
 
In this scenario this company will not be able to sell their routers if using FreeBSD with Python

OK, you are discussing trying to sell something that *includes* the Python interpreter. Yes, this all depends on how it is implemented / which compile time flags were used. For example you will *not* be able to sell the device running Windows and ActivePython (https://www.activestate.com/products/python/) unless you pay a fee.

Just grab the Python source and compile it yourself. You can even use the FreeBSD port makefile as a reference.

... besides, by the time you have stripped Python enough to run on router hardware, I am fairly sure the GPL components will be gone. Actually they are usually the first things to go for performance reasons ;)
 
And you might want to find a platform that is more stable than Python. I find myself scrambling to replace the few Python-based Web applications I used as the 2.x Armageddon looms. I'm excluding Python-based applications in this process. Fool me once and all that.
 
And you might want to find a platform that is more stable than Python. I find myself scrambling to replace the few Python-based Web applications I used as the 2.x Armageddon looms. I'm excluding Python-based applications in this process. Fool me once and all that.
Do you mean the stability of the "ABI" or of the Python engine, or of certain applications & modules written in it?
 
This topic would certainly be a concern to someone willing to distribute a packaged OS containing FreeBSD ports, but certainly not to a user of a FreeBSD system.
So if the OP stands from a user's perspective, this thread should be moved to Off-Topic as it would then just be one more helpless religious discussion.
Otherwise, there is a business case behind and the Foundation would probably be a more appropriate contact than the developers (or the forum members).
 
OK, you are discussing trying to sell something that *includes* the Python interpreter. Yes, this all depends on how it is implemented / which compile time flags were used. For example you will *not* be able to sell the device running Windows and ActivePython (https://www.activestate.com/products/python/) unless you pay a fee.

Just grab the Python source and compile it yourself. You can even use the FreeBSD port makefile as a reference.

... besides, by the time you have stripped Python enough to run on router hardware, I am fairly sure the GPL components will be gone. Actually they are usually the first things to go for performance reasons ;)
As you suggested, I downloaded the sources for Python 3.8 from their site into a clean FreeBSD installation using fetch, then:

./configure
make
make test
make install

And as contrary as I expected, it works without any extra port dependency, of course there will be missing functionality, but the core works.

Then I installed also the libffi (MIT) package for the ctypes library, and reinstalled, for PIP to work properly, as a test I installed numpy with pip, imported it and then run a sample program successfully.
So looks that the bare minimal is libffi (MIT) ( and indexinfo (BSD2CLAUSE ) which comes with libffi in the port), with the source from Python.

Thanks.
 
Back
Top