# BSD licensing



## jcizzo (Apr 14, 2022)

Hey folks,

i'm an absolute novice when it comes to freebsd.  never installed the base OS.  my experience with it is through pfsense.  that will change in time however (meaning, when resources become available, i will set up a freebsd box to learn on).

that being said.  BSD is incredible.  Hats off to the engineers.

here's my question; if the xBSD's are open source, in an effort to protect it, why isnt the BSD license amended to be more like the gnu gpl?  my reasoning is that there are companies like netgate and opnsense that, while it's great they're huge contributors, they're ultimately creating a product to profit from the work of the original design.  Yes, FreeBSD is available to all, however products like pfsense are slowly and quietly going down the path of making it proprietary.  I would still want to see Berkley as the custodian and engineer behind it, and to continually scrutinize the source to maintain its excellence, however no one should have the right to take said source and hijack it to be sold as their own for profit.  again, it hasn't happened yet, but it's quietly going down that path..

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+..  

sorry, very long winded question/rant by a concerned citizen of this community.

comment?


----------



## SirDice (Apr 14, 2022)

jcizzo said:


> if the xBSD's are open source, in an effort to protect it, why isnt the BSD license amended to be more like the gnu gpl?


Why do you think only the GPL can protect it? The BSD license protects it just fine. 



jcizzo said:


> they're ultimately creating a product to profit from the work of the original design.


Yes, and they have every right to do that because the BSD license allows this.



jcizzo said:


> I would still want to see Berkley as the custodian and engineer behind it,


Berkeley hasn't been involved in the development of BSD (Free, Open or Net) for many, many years. The FreeBSD foundation owns and maintains FreeBSD; 



jcizzo said:


> and to continually scrutinize the source to maintain its excellence








						About the Foundation | FreeBSD Foundation
					

What is the FreeBSD Foundation? The FreeBSD Foundation is a 501(c)(3), US based, non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage projects, fund...




					freebsdfoundation.org
				






jcizzo said:


> however no one should have the right to take said source and hijack it to be sold as their own for profit.


Kind of limiting isn't it? You know what the cool thing about freedom is? To do whatever you want with it, including taking the code, building a product with it and then selling it. 



jcizzo said:


> it hasn't happened yet


Are you sure? Because JunOS (Juniper firewalls/routers) is based on BSD. Cisco's original IOS was based on BSD. Citrix Netscalers are based on BSD. OS-X borrowed many parts from BSD. I can probably name a whole bunch of other products that are (at least partially) based on BSD. 



jcizzo said:


> 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.


The FreeBSD foundation has a different opinion.


----------



## jbo (Apr 14, 2022)

Hello & Welcome to this FreeBSD community!

I think SirDice covered this pretty well. I'll just leave a few more remarks here.



jcizzo said:


> 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.


I'd say exactly the opposite is the case. As far as I can tell (personal opinion), what you're describing is what's happening over in the Linux world. Due to the more restrictive licensing, commercial entities have to resort to other means to gain influence and control. This is heavily showing in both the direction Linux is heading as well as the trend of quality over time.
In the meantime, BSD licensed products remain unaffected by these corporate measures because they are allowed to just use it for whatever purpose they see fit. There's no need for commercial entities to resort to those measures.

I'd also like to add that plenty of commercial entities which take part(s) of (Free)BSD are heavily contributing back to the code base. Just have a look at the various direct financial sponsorings/fundings and contributed code. Based on my business experience it's also easier for larger entities to put resources back into a BSD licensed project than an (L)GPL licensed project (partly due to legal reasons, partly due to business politics).
The list is quite long but these include entities like Sony, Nintendo, Netflilx, CISCO, Juniper Networks, iXsystems and many, many more including also many smaller commercial entities.

Using BSD licensed software for commercial aspects is something I'd consider to be endorsed. It helps to keep projects alive, omits the need for "questionable measures" to be employed by commerical/corporate entities and makes the software/projects more stable as a result.

The day when (Free)BSD changes the licensing to something more restrictive _might_ actually be the day when (Free)BSD is dying for real.


----------



## Deleted member 70435 (Apr 14, 2022)

jcizzo said:


> Hey folks,
> i'm an absolute novice when it comes to freebsd.  never installed the base OS.  my experience with it is through pfsense.  that will change in time however (meaning, when resources become available, i will set up a freebsd box to learn on).
> 
> that being said.  BSD is incredible.  Hats off to the engineers.


you come here to tell us how we should run our system man if i were you. would really analyze the GNU GPL license is not something I would adopt in a software development, the engineers don't like this license very much that's why today in Linux you are manipulated, as if it were something normal.

I'm against some issues of the GNU GPL license, a form that involves a lot of politics on how you should develop your software. today systemd takes half of your linux distributions, and you still come here. criticizes us for our BSD license.

systemd is in most of your linux distributions, and the most rated by the community Debian, Arch Linux and others


----------



## mer (Apr 14, 2022)

It almost feels like the OP is trolling....
Software.  Patents.  Copyright.  Licensing.  All discussed for a long time.  Some folks have absolute stances:  all software is free.  Others have:  I own what I wrote but can freely give it away. 
Difficult to get a consensus at time.

Now, me personally, I like the BSD license (and others that are similar).  No legal hook "you must make your modifications available to the community"  (simplistically what the GPL is), but "Heres the code, no support from me, you can use it, make products to sell, just make sure you don't claim it as your own" (simplistically the BSD).
My experience has been that companies will freely push changes upstream when they can sell product based on it.


----------



## sidetone (Apr 14, 2022)

GPL takes over BSD licensed code all the time, then it becomes locked from companies to profit off of.

The whole thing about opensource licenses seems to be a paradox to me. GPL is too viral, and it contributes to piling on, because there's less motivation to improve things. I also understand the argument that a lot of companies take, but give back very little. I have to think about BSD, ISCL or MIT licenses like water, it's free for everyone, and anyone can drink it, make their own juice out of it, or a company can make a proprietary drink or brand out of it. It makes sense for libraries, backends, small programs, moderately sized programs, software foundations and common applications.

One problem where GPL isn't how it's made out to be is, a company dual licenses software in GPL, and they are allowed to get all contributions from that piece of code, while others can't. In some cases, that's beneficial to the opensource community, as the company wrote most of it from the beginning, and has a business model that helps other companies. This exception is in the spirit of opensource when a code is dual licensed to be both opensource and proprietary, but other cases aren't in the spirit of GPL-like arguments relating to how companies shouldn't benefit. Another company can dual license an addition to that GPL code which wouldn't be dualy owned by another company. They would benefit from the common GPL code, but keep their own sets which can be used together, to be improved without giving it away.

It seems like the Apache license is good. I was thinking what if there a clone of LGPL for libraries compatible with LGPL, for the purposes of it be not named containing the acronym "GPL". This would be necessary to make it fully compatible with LGPL to not have to have duplicate code which provides the same function for GPL, BSD and other opensource code which relies on it as dependencies. Then, have another license like LGPL, except that it's restricted to be taken over by more restrictive licenses like the GPL, intended for software even parts of software that aren't libraries. It could be linked to by proprietary and opensource code that allows it, but can't be taken over by any of them.

One thing that was lacking in many opensource licenses was a clause to prevent software from being taken into more restrictive opensource licenses. There were clauses for how to address proprietary: whether to fully allow, restrict it, or to focus on protecting opensource from patent trolls.

I have this worry that there's opensource code, which is in BSD, MIT or ISC, that a proprietary company or GPL will take it, add a literal exclamation point inside the code, and say, opp, you can't use this for the less restrictive opensource license anymore. I realize that they can't really restrict it, because ad minimis can't be copyrighted nor patented. The worry is still there for me, for what's an obvious improvement made under a more restrictive code will prevent the original code license from using.


jcizzo said:


> no one should have the right to take said source and hijack it to be sold as their own for profit


It seems like BSD-like licensed code gets hijacked a lot by GPL as well as the obvious, proprietary companies. Someone could remind me of an argument that BSD/MIT licenses are made for that, which I somewhat agree on but don't fully agree with. The closet I can come up with allowing free code is in what I wrote above.

Edits: BSD, MIT, ISC licenses make sense for libraries, backends, small programs, moderately sized programs, software foundations and common applications. It also makes sense for programs which aren't too big that 1, 2 or a small group of people are able to write and maintain it. Or also for organizations like Xorg or FreeBSD. Big projects like complex games, they make sense as GPL.


----------



## mer (Apr 14, 2022)

In the case of BSD license hijacking by GPL, isn't it only the additions covered by GPL?  Otherwise the new GPL licensees would need to get approval from all the BSD copyright owners/licensees to switch everything over to GPL.


----------



## sidetone (Apr 14, 2022)

They obviously don't take the rights away from the original. Though, they did release the exact same code under the GPL. This is easy to get lost, as they preserve the exact code as GPL. The original with the original more free licenses have to be preserved. Many authors already do that, and copyright or maintain the whole code. They hijack the movement to putting everything into some shit SystemD pile. It's still hijacking, and in the form of what was written about in the first post.


sidetone said:


> I have this worry that there's opensource code, which is in BSD, MIT or ISC, that a proprietary company or GPL will take it, add a literal exclamation point inside the code, and say, opp, you can't use this for the less restrictive opensource license anymore. I realize that they can't really restrict it, because ad minimis can't be copyrighted nor patented. The worry is still there for me, for what's an obvious improvement made under a more restrictive code will prevent the original code license from using.


No one said, they are allowed to prevent, someone from using the BSD code as it was last written. But in effect, what I said above, is like them doing that, and that will happen if the last original isn't preserved as BSD, which I haven't noticed GPL do for what they use. Maybe they do, but it doesn't seem prioritized at all. Also, they do hijack it in the sense of pulling it in and making it into a SystemD system or other convoluted shit. I feel like you respond to what stands out, and end up ignoring everything else.


----------



## sidetone (Apr 14, 2022)

Now, it seems that, if GPL is allowed to take BSD-like licensed code, which for many cases I agree with, they should be required to preserve or link to a copy for public access of all of pieces of original BSD code they used. In a customized license, if that copy of sourcecode gets lost by them or the link they use, then that BSD-like code is void for them. In spirit, the BSD license is there, but there's hardly preservation of what wasn't non-GPL by them. It seems like, the BSD stamp gets replaced by the GPL stamp, and the assumption is that because it's opensource, it's ok to not preserve the first stamp as the differentation of the original and the GPL code. The adjusted license can take over all of MIT/BSD/ISC code, just as GPL takes over other code. GPL can use it, but if it's inconvenient, so taking BSD code was convenient.

It seems like major GPL projects need to have the responsibility of having a GIT repository of all BSD code ever incorporated into GPL code. Github seems to do some of this already, when forks are preserved. GPL isn't required to, but it seems like preserving the last BSD licensed code should be forced by a new license or they'll plainly abandon it, as GPL abandoned/discouraged CDDL, even though it's BSD-like, that they just didn't like it because it was too open for GPL. Such a license couldn't be forced retroactively, however.


----------



## grahamperrin@ (Apr 15, 2022)

jcizzo said:


> … sorry, very long winded question …



Welcome to FreeBSD Forums … where long-winded is not unusual 

FreeBSD Foundation​


SirDice said:


> … The FreeBSD foundation owns and maintains FreeBSD; …



I never thought of the Foundation as owning or maintaining _FreeBSD_, in that FreeBSD source code is open source.

Instead:

the Foundation owns the FreeBSD _trademarks_ (and protects FreeBSD IP (intellectual property), and so on) <https://freebsdfoundation.org/legal/>
also, according to Wikipedia, the Foundation holds related domain names.
From 2001: The FreeBSD Foundation -- an introduction

FreeBSD Project​Beyond the obvious <https://www.freebsd.org/about/>, there's this:









						FreeBSD Project Administration and Management
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					www.freebsd.org
				












						FreeBSD Project organisation
					

Spun off from   From FreeBSD source code:    I'll probably overwrite the chart above with an updated version in due course.  FreeBSD bug 263300 – FreeBSD administration: update the organization.dot organisational chart




					forums.freebsd.org


----------



## mark_j (Apr 15, 2022)

jcizzo said:


> however no one should have the right to take said source and hijack it to be sold as their own for profit.



First off, I'm not attacking your beliefs, just challenging them.

This sentiment you hold seems endemic in the *linux community, at least from afar. This is primarily because they believe their licensing system is perfection itself; it is not. Why?

The idea that you can be affronted by a licence for code you did not write baffles me. Truly.

If I want to release source code in the public domain then why can't I? If someone exploits that code, isn't it purely my choice?
Similarly, if I want to release the code with a "all rights reserved" I could easily do it.

A licence is just that, a licence and BSD-style licences are just permissive in their downstream usage. No matter what someone does with my code, the code belongs to ME. You can take it, put it with some proprietary code but you never own the code. You cannot remove the licence from it because it says not to. Ultimately, people trust others to do the correct thing. They may not, but ultimately, we don't really care because it's BSD-style.





jcizzo said:


> again, it hasn't happened yet, but it's quietly going down that path..



It has happened. There's plenty of examples, some not public, where software from FreeBSD (and indeed Net and Open) have been used to make everything from customised server platforms to embedded systems. Often code is not returned upstream, but, this is part of having a permissive licence.

Cheers

Fynin Hxenvar


----------



## 6502 (Apr 15, 2022)

grahamperrin said:


> I never thought of the Foundation as owning or maintaining _FreeBSD_, in that FreeBSD source code is open source.


Open source does not mean that random people develop FreeBSD and it is out of control.


----------



## mer (Apr 15, 2022)

6502 said:


> develop FreeBSD


They can take the source and develop it but can't call it FreeBSD, because FreeBSD is trademarked and owned by the Foundation.


----------



## grahamperrin@ (Apr 15, 2022)

6502 said:


> Open source does not mean that random people develop FreeBSD and it is out of control.



Did someone suggest randomness or things being out of control? (I didn't.)


*Postscript*: I don't know where _BG_ is (6502's location), but maybe there's a language difference.

To me, _out of control_ implies something intolerable. Like, an out-of-control child might be the result of bad parenting; or a good parent might be close to a nervous breakdown as a result of the child's bad behaviour.


----------



## 6502 (Apr 15, 2022)

If I have understood correctly, the assertion is that Foundation is not owning or maintaining FreeBSD *because* it is open source. I.e. they have no control and FreeBSD is maintained by everybody who wants (random people). It can be modified by everybody for own needs but this is not maintenance of product. And Foundation has copyright on many modules, not only a trademark. Which means it owns FreeBSD.


----------



## grahamperrin@ (Apr 15, 2022)

6502 said:


> If I have understood correctly, the assertion is that Foundation is not owning or maintaining FreeBSD *because* it is open source. …



My comment was essentially to clarify _what_ is owned.


----------



## grahamperrin@ (Apr 15, 2022)

grahamperrin said:


> … the Foundation owns the FreeBSD _trademarks_ (and protects FreeBSD IP, and so on) <https://freebsdfoundation.org/legal/> …





6502 said:


> … Foundation has copyright on many modules, not only a trademark. Which means it owns FreeBSD.



For what it's worth, I should not interpret that as Foundation ownership of _FreeBSD_. I mean, the scope of ownership is not so broad.

jrm@ with your Foundation hat on, please, can you clarify? Thanks.


----------



## 6502 (Apr 15, 2022)

What this means:

Copyright 1992-2022 The FreeBSD Project


----------



## mark_j (Apr 15, 2022)

6502 said:


> If I have understood correctly, the assertion is that Foundation is not owning or maintaining FreeBSD *because* it is open source. I.e. they have no control and FreeBSD is maintained by everybody who wants (random people). It can be modified by everybody for own needs but this is not maintenance of product. And Foundation has copyright on many modules, not only a trademark. Which means it owns FreeBSD.


*alert* *alert* licence confusion... but, well you're sort of correct.
FreeBSD foundation owns the logo, name etc and funds the project with tax dodge exemption. You're right that they have no control, directly as that is the role of Core. 
They do have, however, some control in that they pick the funding, albeit again with Core's direction, for various projects.

Code copyright is that of the authors or, in the case of a lot of old code, like in bin, sbin etc, it's the Regents of UC. FreeBSD Foundation has no copyright of code, to my knowledge. I would be aghast if they did.

Anyone can take the code and create a new OS and call it, say GhostBSD, but if they call it FreeBSD-plus, for example, then they'll have lawyers at their door.


----------



## jbo (Apr 15, 2022)

mark_j said:


> Anyone can take the code and create a new OS and call it, say GhostBSD, but if they call it FreeBSD-plus, for example, then they'll have lawyers at their door.


Clearly you're not familiar with today's marketing wank. It would be: "FreeBSD PRO"


----------



## msplsh (Apr 15, 2022)

jcizzo said:


> 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


I think the problem here is what constitutes "commandeered."  Nobody can just "take" FreeBSD, never release the code, and somehow get everybody to switch to it without constant maintenance or community goodwill.  People have tried to fork FreeBSD and make a "better" version all the time and fail due to lack of manpower, and that's *with* keeping the same license on the new code.  Apple took a bunch of FreeBSD code to slap on to their proprietary OS and it takes a bunch of work on their part to keep it updated, yet FreeBSD hasn't "lost" the base product.


----------



## grahamperrin@ (Apr 15, 2022)

6502 said:


> What this means:
> 
> Copyright 1992-2022 The FreeBSD Project



<https://www.freebsd.org/copyright/freebsd-license/> – *The FreeBSD Copyright* – is one of a number of pages relating to copyright; <https://www.freebsd.org/copyright/>. 

From the foot of the page: 



> Legal Notices | © 1995-2022 The FreeBSD Project All rights reserved. The mark FreeBSD is a registered trademark of The FreeBSD Foundation and is used by The FreeBSD Project with the permission of  The FreeBSD Foundation. Contact



An example of _FreeBSD Copyright_ in context, in source code: <https://cgit.freebsd.org/src/tree/sys/sys/copyright.h#n4>

`* Copyright (C) 1992-2022 The FreeBSD Project. All rights reserved.`

2022-01-01: Welcome 2022, update copyrights.

2022-02-18: vtfontcvt: update FreeBSD Foundation copyrights

… and so on.


Incidentally 6502 please, where is _BG_ (your location)? The forum takes us from <https://forums.freebsd.org/misc/location-info?location=BG> through Google Maps to nowhere predictable … amusingly, you're currently at a _Microsoft Campus_ bus stop near the River Thames, which is nowhere near me –




 

– and probably nowhere near you 

If you're in Bulgaria, <https://forums.freebsd.org/misc/location-info?location=Bulgaria> will be better (and I'll be somewhere in Bulgaria in August).


----------



## shkhln (Apr 15, 2022)

This should be a FAQ question. It probably already is. The BSD license is specifically designed to provide the shortest possible legal text allowing programmers to dump the source code into whatever good/evil/free/proprietary project they want whenever they feel like it. It's an ultimate "fuck off" license without any agenda whatsoever. That's precisely why we like it here.


----------



## jcizzo (Apr 15, 2022)

mer said:


> It almost feels like the OP is trolling....
> Software.  Patents.  Copyright.  Licensing.  All discussed for a long time.  Some folks have absolute stances:  all software is free.  Others have:  I own what I wrote but can freely give it away.
> Difficult to get a consensus at time.
> 
> ...


----------



## jcizzo (Apr 15, 2022)

trolling?   i don't know what an OP is..  

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


----------



## msplsh (Apr 15, 2022)

Variant 3




__





						List of acronyms: O - Wikipedia
					






					en.wikipedia.org


----------



## grahamperrin@ (Apr 15, 2022)

jcizzo said:


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







jcizzo said:


> 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_






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.


----------



## SirDice (Apr 15, 2022)

grahamperrin said:


> 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.











						Internet forum - Wikipedia
					






					en.wikipedia.org
				






grahamperrin said:


> 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


----------



## grahamperrin@ (Apr 15, 2022)

> 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:

  

– plus <https://forum.nomadbsd.org/>, <https://discourse.mozilla.org/>, <https://github.community/>, <https://www.askwoody.com/> and so on.

On topic, off-topic, and so on …



The word topic makes more sense. Start a topic, stay on topic.


----------



## jbo (Apr 15, 2022)

grahamperrin said:


> 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.


----------



## grahamperrin@ (Apr 15, 2022)

jbodenmann said:


> Do your part.



Fair enough  … it _was_ the opening poster who sought an explanation for 'OP'



> … feel free to create a different/dedicated thread/topic …



Done: 









						FreeBSD Project organisation
					

Spun off from   From FreeBSD source code:    I'll probably overwrite the chart above with an updated version in due course.  FreeBSD bug 263300 – FreeBSD administration: update the organization.dot organisational chart




					forums.freebsd.org


----------



## hardworkingnewbie (Apr 16, 2022)

jcizzo said:


> 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!


----------



## sidetone (Apr 16, 2022)

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.


----------



## jcizzo (Apr 28, 2022)

sidetone said:


> 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.


----------



## 6502 (Apr 28, 2022)

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".


----------



## Deleted member 70435 (Apr 28, 2022)

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.


----------



## sidetone (Apr 28, 2022)

sidetone said:


> 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.


----------



## bsduck (Apr 29, 2022)

sidetone said:


> 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.


----------



## eternal_noob (Apr 29, 2022)

Everything Oracle touches goes down the drain.


----------



## bsduck (Apr 29, 2022)

Fortunately we have OpenZFS


----------



## sidetone (May 1, 2022)

bsduck said:


> 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.


----------



## hardworkingnewbie (May 2, 2022)

bsduck said:


> 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.


----------



## msplsh (May 2, 2022)

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.


----------



## hardworkingnewbie (May 2, 2022)

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.


----------



## sidetone (May 2, 2022)

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.


----------



## sidetone (May 3, 2022)

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.


----------

