BSD licensing

i'm just someone who really appreciates BSD and the engineering that goes into it..

?

i don't know what an OP is

OP is opening post or, in this case, opening poster – the person who makes the first post to open (begin) a conversation.

XenForo (the software that's used for FreeBSD Forums) uses the abbreviation OP for a different phrase with a similar meaning: thread starter

1650034402302.png


XenForo terminology is quite strange.

It's more traditional to use the word topic, then there might be off-topic threads.

In FreeBSD Forums (with XenForo) things begin as a thread then often go wildly off-topic.
 
XenForo (the software that's used for FreeBSD Forums) uses the abbreviation OP for a different phrase with a similar meaning: thread starter
A thread is defined by a title, an additional description that may summarize the intended discussion, and an opening or original post (common abbreviation OP, which can also be used to refer to the original poster), which opens whatever dialogue or makes whatever announcement the poster wished.

It's more traditional to use the word topic,
Ehm. No. It's the other way around.
A thread (sometimes called a topic) is a collection of posts
 
A thread (sometimes called a topic)

I guess, in the past, I most often used forums that use the word topic. It's not unusual:

1650038207666.png 1650036647007.png 1650037713681.png

– plus <{link removed}>, <{link removed}>, <{link removed}>, <{link removed}> and so on.

On topic, off-topic, and so on …

1650037036704.png

The word topic makes more sense. Start a topic, stay on topic.
 
Last edited:
On topic, off-topic, and so on …
I doubt that this is directly related to calling a thread a thread or a topic but rather the content of the posts contained within a thread/topic. Posts in a thread can be off-topic ;-) The irony is real in this one.

So please lets just stop discussing non BSD-licensing related content here. Do your part.
Obviously, feel free to create a different/dedicated thread/topic if you feel the need to.
 
There are many folks (like me) in the community who are concerned that the xBSDs will ultimately be commandeered by 3rd parties and we'll lose the base product. apparently it's a known fact that microsoft took much of the source of the freeBSD tcp/ip stack and used it in windows NT+..
And then again the problem with this is - what? It's not a bug, it's a feature and maybe the most important one why so many people do love the BSD license!
 
That it's maintained by a foundation, the code is safe. I'm worried that when someone adds something and slaps a GPL license on it, that an obvious fix may be taken away from BSD's base to use with the original free license. But, there may be many ways to do something, that it may be a worry and a way could always be available. At least the code will be available to use as GPL. I also don't like that it's a one way street, GPL can take in a viral way, but doesn't give back. Some say, GPL products are better, though they're taking a lot of BSD code, so they're not better.
 
That it's maintained by a foundation, the code is safe. I'm worried that when someone adds something and slaps a GPL license on it, that an obvious fix may be taken away from BSD's base to use with the original free license. But, there may be many ways to do something, that it may be a worry and a way could always be available. At least the code will be available to use as GPL. I also don't like that it's a one way street, GPL can take in a viral way, but doesn't give back. Some say, GPL products are better, though they're taking a lot of BSD code, so they're not better.
So when you said "GPL products are better, though they're taking a lot of BSD code, so they're not better." it sounds like you're slightly in agreement with me, in that programmers are hijacking bsd code to use in their own projects without having to give back.. I dunno.

Truthfully, this is all very new to me.. without going on and on, i think back to my days in college 20+ years ago and how revered xBSD has been. it bothers me that companies like MS and apple have taken the source code and used it in their own products to profit and not donated back, either financially or with their own engineering.. it's good that they can't automatically commit the changes because God knows they'd probably make a mess of things, but i'm sure in some ways, some things might be done differently that are worthy of review and consideration.
 
Free means free. I don't understand why you are worried that somebody will use BSD code in his/her own project. What is the problem? The programmer will get free module and will sell final software for profit? The only possible problem in my opinion is when somebody get free software and pretend that software is his/her and want to forbid original author to distribute the software. This is a real hijacking. In case with BSD this is not possible (the license does not allow it). For other usage it is "do whatever you want".
 
one thing that Linux makes is the mistakes it has always been making as many CVE have already been posted. many of us learn from history, history teaches us a very good lesson, FreeBSD is too mature because it cares about its history, and keeps the code consistent enough for us students and programmers from all areas to look at and say wow what a system with its amazing philosophy. the code is free to work and if you want to put it to the whole community, available to go improve who knows in the future it doesn't become something big and it is today, FreeBSD is powering all servers today big data.

I have nothing to say about Linux last time I told the whole truth about this kernel, and what I heard was just cursing and things that don't exist, nothing Linus Torvalds he is only advised by his Lieutenants. a secure base would be, every community committed to listening to suggestions. what I find ridiculous is the Debian community, which claimed to be Free Software, is trying to make proprietary software common. and nobody does anything about it and this has already made many users nervous because they don't respect their ideas and put something they don't put on a community. only developers take advantage of this.
 
Some say, GPL products are better, though they're taking a lot of BSD code, so they're not better.
I didn't say it was better. IMO, It depends on what it is. For a game, or well maintained project, GPL can be. Asterisk, Opensource Dos, some messaging programs are just as good whether they are under GPL and being under a BSD license wouldn't make a difference in those product's qualities, except maybe BSD like dependencies would make them better, because they tend to be simpler for function. They already use these benefits of BSD licensed dependencies anyway.

For something like Apache OpenOffice vs LibreOffice, many say LibreOffice is better, but it's only because improvements to Apache OpenOffice can only go one way. I found it distasteful when I read about how a group of GPL followers were encouraging Apache OpenOffice to shut down, so people can flock to LibreOffice. They have different purposes based on the license. Apache OpenOffice should always remain there, as it is model-wise, because that license may suit an application where companies or organizations can pick it up, and redistribute it still under the Apache license. What if a company or organization wants a free word processor, and wants to keep changes, while contributing some changes to the public. The FreeBSD Foundation maintains FreeBSD, and the Apache project maintains Apache OpenOffice as well as other projects. Sure, FreeBSD has more resources, but what's stopping companies/organizations from giving back to Apache the way they do to FreeBSD. I would use LibreOffice and Apache OpenOffice. However, I would support Apache OpenOffice, as LibreOffice has more maintenance and gets contributions to Apache OpenOffice. Also, the dependencies to LibreOffice were cleaned up. Apache OpenOffice still relies on some Jakarta dependencies. LibreOffice is a good product; it shouldn't take away that Apache OpenOffice is still great in principle.

One thing that I read about was, that how there were small programs written under BSD like licenses, and they were taken for granted by big companies who used them. A small program stopped working, such as a command line Internet program, then a company would complain such a program didn't work. The source of it was that a BSD licensed program maintained by a programmer had a bug that came about. Then, it was that those programmers who offered something for free had leverage. It was about leverage for all open source licenses, including GPL.
 
many say LibreOffice is better, but it's only because improvements to Apache OpenOffice can only go one way
That's not my way of thinking: the primary reason LibreOffice is better is that much more people have been working on it and constantly improving it, while OpenOffice has been mostly in maintenance mode since the fork. This has little to do with licenses. By the time OpenOffice was ceded by Oracle to Apache, most contributors had already moved to LibreOffice and stayed there. By the way, LibreOffice isn't GPL but MPL.
 
By the time OpenOffice was ceded by Oracle to Apache, most contributors had already moved to LibreOffice and stayed there. By the way, LibreOffice isn't GPL but MPL.
I was reading about MPL 2.0, and it's a great license. In my limited ability to think everything out, it may just have what else was desired by many in additions to the Apache License. MPL 2.0 is similar to LGPL, but less restrictive. It's compatible with Apache, LGPL and GPL, unlike MPL 1.1. However, software under previous MPL licenses can be upgraded without permission to MPL 2.0.

Legally MPL 2.0 makes the most sense. It seems like they at GPL, and then we make justifications around GPL. It shouldn't be able to eat up code. That's not supposed to be done, then we make a justification how when it eats up code, it's still available under the original BSD license. It should be like that without the justification. I really think the GPL isn't legal, but they made up an interpretation everyone bought, then others have to undo it with justifying that it shouldn't eat into other open code. Any license has a right to restrict what it can't be used with, though how can it determine terms of improvements to freer code used with the GPL? Before, I thought, if it was BSD first or GPL first. If it was GPL first, it can't be made BSD.

I think of a BSD license like that on a PVC pipe, someone makes an improvement to it, everyone gets it, unless that was absorbed by a GPL piece. Now, when that piece of PVC pipe is used in an intricate machine, what goes into that machine shouldn't have to be given up, only the fixes to improve the piece of PVC.

One thing wrong with MPL, is that it's compatible with GPL. However, it's a necessity, because such a bad license exists that is popularly used. LGPL is better than GPL, but essentially, it's a one way street to GPL, but so is nearly every other permissive license. Another issue I found is that code to MPL 2.0 is required to be dual licensed to LGPL, which is ok, but makes it complex, and the LGPL shoudln't be forced on it, except when it's incorporated by LGPL. [I initially misread section Q14, that was specific about the option to use dual licenses, so wasn't a requirement] https://www.mozilla.org/en-US/MPL/2.0/FAQ/

An open license shouldn't restrict linking, whether static or dynamic. If the interpretations I read about MPL 2.0 are true, this is what it is.

In theory, I wonder if it would have any effect of a cloned FreeBSD, where everything compatibly licensed with MPL 2.0 (BSD, Apache) was shifted to MPL 2.0. Of course, don't do that, bc it needs to stay as is, and no risks need to be taken. Perhaps those that use it with other code would have to go back and do a lot of work to keep the MPL parts separate from their own additions or combinations with more restrictive licenses.

Though, if I were to use a license based on these findings, I'd use MPL 2.0. If I were going to make my own license, I'd fork the MPL, to where it would be restricted for use with a more restrictive open license, IE. GPL licensed code. However, this would defeat the purpose of using it for a common library or dependency. MPL already has a clear separation between the code under this license, and other more restrictively licensed code. That, by defacto would make GPL not absorb the code into theirs. There are a few MPL 1.1 forks, including by big companies, so such a license could possibly already exist.

What I see as not legal, is when an exact clone of BSD code has a GPL license slapped on it, as if it was always GPL. Sure, any open license should be able to use the BSD code, and restrict what it's used with, but the part I see as not legal, is slapping a license on what's BSD, Apache or otherwise. Mainly that there's no clear separation and all gets interpreted as being GPL. GPL is viral in how it treats the code, not in what it restricts use with. This is where not allowing dynamic and static linking is faulty.

As for Asterisk, where one company put a lot into it, I can see something identical to the GPL even if close to AGPL being used, but not the GPL terms of cloning other licensed code itself.

I used to read the GPL narrative that other particular licenses are bad. Many aren't, they just don't fit GPL's agenda. CDDL, for instance, was based on an earlier MPL, which both were incompatible with GPL. It seems like pieces of CDDL code help keep a GPL license from too conveniently being slapped on the base, sure, it's easy to compile out.

MPL 2.0 may nearly be perfect. It has more protections than the Apache license. It's not viral, and it has the proper separations of MPL code from other code. It can be used staticly and dynamically for both open and proprietary code, without mixing in the code.
 
That's not my way of thinking: the primary reason LibreOffice is better is that much more people have been working on it and constantly improving it, while OpenOffice has been mostly in maintenance mode since the fork. This has little to do with licenses. By the time OpenOffice was ceded by Oracle to Apache, most contributors had already moved to LibreOffice and stayed there. By the way, LibreOffice isn't GPL but MPL.
You've got to look at the history back then: why is there a LibreOffice? Because when Sun was merged by Oracle development on OpenOffice became very, very slow with an uncertain future. So people did that thing which is one of the defining traits of open source: they've forked OpenOffice, started to setup their own project infrastructure around it and never looked back. This is why most developers moved over to that camp.

OpenOffice was later transferred to Apache. And since then it's basically in slow maintenance mode, it hasn't had a major release since at least 8 years. Basically it's more or less a dead piece of software.
 
Sun apparently had a CLA which allowed them to be able to re-license the software to anything at any time, which was another reason for the fork since this power was given to Oracle.
 
Indeed, and also LibreOffice is miles away in terms of commits compared to OpenOffice. LO got over 15.000 commits in 2019 while OO saw around 595.

This is why the organization behind LibreOffice, The Document Foundation (TDF) appealed in 2019 to the Apache project to just give up on OO and hand over the name rights to TDF, because that's the more known brand and LO has much more development speed and momentum behind it than OO. It just lacks the original name. As its obvious so far the ASF didn't comply with that appeal.
 
What they need to do, is allow LibreOffice to use derivatives of OpenOffice IP, in return for LibreOffice code to Apache's OO. Then rename theirs ApacheOffice, while still retaining the IP and art of "Apache OpenOffice". Retain OO IP rights, because Apache OpenOffice was once the official OO fork. Also, get an agreement on a license study collaboration before doing so. Any license collaboration regarding Mozilla and Apache would have to do with that, rather than TDF.

MPL2.0 is a good license. Apache License 2.0 is well intentioned and has many strengths of MPL 2.0. They need to work on making a joint license where similar compatibility is retained to other open source licenses (ie LGPL2). Apache 2.0 isn't compatible with GPL2. While (L)GPL2 is obsolete, many programs still use (L)GPL2. There's programs dependent on mixed compatible and incompatible licenses. For LibreOffice, maybe it's allowed bc the incompatible code isn't directly tied together, and/or because the project asks for contributions to be dual licensed to include LGPL3.



I believe MPL and Apache can be used side by side though as they are. It's other combinations of opensource licenses incompatible with either, I'm unsure about.

Maybe a updated Apache or joint license where code can be used with the same licensing terms as MPL 2.0, except, it would be retained that Apache licensed files would be allowed to have different code within the otherwise Apache licensed file provided those are indicated. The current licenses of Mozilla and Apache are compatible for use with each other, but not in this way. Also, there needs to be a joint study where, they look at the best terms of a license for common dependencies, the closest once that exist may be BSD or MIT licenses. Apache would fit, except it's incompatible with code under (L)GPL2, but any license with a patent clause, that's not dual licensed, would be.
 
Those that use (L)GPL2, including Linus, could fork a version that's compatible with Apache License 2.0. To have a different modification forks for GPL2 and LGPL2, and code would have to be otherwise compatible to be used with it aside from the modifications. To make only the patent clause of LGPL2 not viral, that only this part doesn't extend beyond files under its license. For the modified GPL2, make it so the patent clause only extends to code which doesn't include a patent clause. Only open licenses that the modified (L)GPL2 licenses otherwise accepts can be used with it. Then, in order to include Apache License 2.0 code, the forked (L)GPL2 license would require that those files have to be marked and kept separate per file. This way, the modified (L)GPL2 patent clause will do, or Apache's will do, which ever is applicable per file. Also, it wouldn't be specific to Apache, but to licenses like it. LGPL2 definitely needs a simple fork with such modifications.

Perhaps they should also make a modification of LGPL2, so that it can be used with both dynamic linking and static linking, at least to outside of its directory.
 
Back
Top