Back

@msw >naturally, FreeBSD uses a BSD license
Which one? There are at least 5 different versions by now.

Okay, it's the 2-clause BSD - finding that information took me ages.

I found a huge amount of proprietary software in the "Free"BSD base install not under the 2-clause mind you.

>bsdl-gpl
It's incredible the lies and false claims that article makes that people take at face value.

TLDR: It's an article pushing the interests of the proprietary masters above the users and humanity at a whole with false claims and false premises.

>charged IBM with destroying businesses by bundling free software with IBM hardware
As far as I can tell, that's wrong, as that software was proprietary and was provided without source code and the cost was included as part of the monthly hardware rent.

The article then proceeds to conveniently leave out how Berkeley initially distributed software under propriety terms and only adopted a free software license afterwards.

Then it refers to ad-hoc per-software copyleft licenses prior to the GPLv1 as "GPL".

>you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself.
Wrong - you may sell the software for any price, you just cannot sublicense it.

>This enables the gcc compiler to be used in commercial environments without legal problems.
Confuses commercial and proprietary.

>since the Linux kernel is under the GPL
Wrong, it's GPLv2-only.

>any code statically linked with the Linux kernel must be GPLed. This requirement can be circumvented by dynamically linking loadable kernel modules. This permits companies to distribute binary drivers, but often has the disadvantage that they will only work for particular versions of the Linux kernel.
Proprietary kernel modules developed for Linux's specific interface are derivative works - it's just that most Linux developers are too spineless to enforce their license.

>Dynamic linking, however, is not considered a violation of the GPL
Another unsourced claim.

GNU developers do indeed consider proprietary software dynamical linking to GPLv[1-3] libraries to be a violation of the GPLv[1-3].

>Pressure to put proprietary applications on Linux became overwhelming.
From who?

>Both the GPL and LGPL require any modifications to the code directly under the license to be released.
Incorrect.

Any modifications to distributed versions need to be distributed to all the users, but to anyone else is optional.

>The GPL attempts to prevent orphaning by severing the link to proprietary intellectual property.
Yet another incredibly stupid claim: https://www.gnu.org/philosophy/not-ipr.html

>A BSD license gives a small company the equivalent of software-in-escrow without any legal complications or costs.
Imagine doing work for a company without getting paid who are too cheap to handle basic legal requirements.

>The GPL explicitly disallows revoking the license. It has occurred >there is also some confusion regarding whether the software was really under the GPL.
11/10 contradiction.

Obviously the software wasn't under say the GPLv2 if a court determined that the license could be revoked.

>As Donald Rosenberg states "projects using licenses like the GPL…​live under constant threat of having someone take over the project by producing a better version of the code and doing it faster than the original owners."
I don't see how that's a bad thing, as everyone gets the better version if they wish, but of course the article tries to portray that it is.

>for the GPLed intellectual property world.
The complete balderdash made up is incredible.

>In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior.
Yet another false unsourced claim.

All licenses in the GPL family are designed to eliminate monopolistic behavior, as most, if not all those behaviors become legally forbidden (i.e. refusing to release the source code for the binary).

>The GPL can present a real problem for those wishing to commercialize and profit from software. For example, the GPL adds to the difficulty a graduate student will have in directly forming a company to commercialize his research results, or the difficulty a student will have in joining a company on the assumption that a promising research project will be commercialized.
Yet another confusion of proprietization and commercialization.

The claims may be true for proprietization, but are false for commercialization.

>For those who must work with statically-linked implementations of multiple software standards, the GPL is often a poor license, because it precludes using proprietary implementations of the standards.
Proprietary implementations of any standards should not exist, so that's the whole idea.

>The GPL thus minimizes the number of programs that can be built using a GPLed standard. The GPL was intended to not provide a mechanism to develop a standard on which one engineers proprietary products.
Proprietary products should not exist.

>The GPL attempts to make programmers contribute to an evolving suite of programs, then to compete in the distribution and support of this suite. This situation is unrealistic for many required core system standards, which may be applied in widely varying environments which require commercial customization or integration with legacy standards under existing (non-GPL) licenses.
It's hardly unrealistic considering how many freedom-respecting standards exist.

Literally any business can go and get commercial customization done by anyone and they can even not share the customizations with anyone else.

>The GPL is an attempt to keep efforts, regardless of demand, at the research and development stages. This maximizes the benefits to researchers and developers, at an unknown cost to those who would benefit from wider distribution.
Incredible - good natured work done out of goodwill, done at no charge, or at an agreed price, has a COST to non-researchers and non-developers - if you believe that, you'll believe anything.

>The GPL was designed to keep research results from transitioning to proprietary products. This step is often assumed to be the last step in the traditional technology transfer pipeline and it is usually difficult enough under the best of circumstances; the GPL was intended to make it impossible.
The last step to proprietary degeneracy is indeed something that should not happen, but of course that's meant to be a bad thing...

>and would not have minded in the slightest if Microsoft or Netscape choose to incorporate our HTTP engine or any other component of our code into their products
GNU wouldn't minded in the slightest if microsoft or netscape incorporated any of their software into their products, as long as they followed the licenses.

> In contrast, those who expect primarily to use a system rather than program it, or expect others to evolve the code, or who do not expect to make a living from their work associated with the system (such as government employees), find the GPL attractive, because it forces code developed by others to be given to them and keeps their employer from retaining copyright and thus potentially "burying" or orphaning the software.
No, nothing forces people to develop code and give it to you - they have the OPTION of first writing the code and then second choosing if they want to share it and that code can even be shared to only the users and not to the original developer also.

>If you want to force your competitors to help you, the GPL is attractive.
Competitors aren't forced to do anything, but it does help to prevent them from attacking you.

>A BSD license is not simply a gift.
This is contradictory to what many BSD licenses pushers say.

>Under a BSD license, if one company came to dominate a product niche that others considered strategic, the other companies can, with minimal effort, form a mini-consortium aimed at reestablishing parity by contributing to a competitive BSD variant that increases market competition and fairness. This permits each company to believe that it will be able to profit from some advantage it can provide, while also contributing to economic flexibility and efficiency. The more rapidly and easily the cooperating members can do this, the more successful they will be. A BSD license is essentially a minimally complicated license that enables such behavior.
That's a lot of very dubious claims, that if correct, would apply to freedom-licensed software just as much as pushover-licensed software.

>A key effect of the GPL, making a complete and competitive Open Source system widely available at cost of media, is a reasonable goal.
No, that is NOT THE GOAL.

The goal is to make a fully free system of software available to everyone and also, there is no artificial reason to add artificial costs to the distribution of software, due to the zero marginal cost of copying software.

>A BSD style license, in conjunction with ad-hoc-consortiums of individuals, can achieve this goal without destroying the economic assumptions built around the deployment-end of the technology transfer pipeline.
It's a GOOD THING that proprietary economic assumptions are being absolutely annihilated.

>The BSD license is preferable for transferring research results in a way that will widely be deployed and most benefit an economy.
"Writing proprietary software without getting paid is a good thing, as it'll benefit the economy".

>Government policy should minimize the costs and difficulties in moving from research to deployment. When possible, grants should require results to be available under a commercialization friendly BSD style license.
It is the governments duty to respect the freedom of its citizens, therefore it is their duty to ensure that they aren't friendly to proprietary degeneracy and give it the treatment it deserves.

>Anecdotal evidence exists that universities are financially better rewarded in the long run by releasing research results and then appealing to donations from commercially successful alumni.
Why on Earth should a university be dedicated to "financial rewards"?

>Companies have long recognized that the creation of de facto standards is a key marketing technique. The BSD license serves this role well, if a company really has a unique advantage in evolving the system.
This is pretty much claiming that proprietary things becoming the de-facto standard is a good things.

>There are times when the GPL may be the appropriate vehicle for an attempt to create such a standard, especially when attempting to undermine or co-opt others.
Ah yes, a claim that a freedom-defending license does exactly what the end result of a pushover license allows.

>The GPL, however, penalizes the evolution of that standard, because it promotes a suite rather than a commercially applicable standard. Use of such a suite constantly raises commercialization and legal issues. It may not be possible to mix standards when some are under the GPL and others are not.
These are all good things to happen.

>A true technical standard should not mandate exclusion of other standards for non-technical reasons.
Except this is exactly what the BSD-addled sort do - mandate exclusion of freedom-defending software for non-technical reasons, while there is no sustained effort by the FSF to exclude pushover-licensed software that is free.

>In contrast to the GPL, which is designed to prevent the proprietary commercialization of Open Source code, the BSD license places minimal restrictions on future behavior.
When it comes to restrictions, there are none in any version of the GPL - as they're sets of exceptions to government restrictions, while the 2-clause BSD initially confirms that ALL possible restrictions are in place at the start with "All rights reserved." and then only afterwards gives exceptions.

>This allows BSD code to remain Open Source or become integrated into commercial solutions, as a project’s or company’s needs change.
This is saying that projects or companies needs are the most important thing ever - even more important than "open source".

>In other words, the BSD license does not become a legal time-bomb at any point in the development process.
I would rather call the 2-clause BSD a legal time bomb, as its validity is legally questionable (and legally untested) and it misses many important things like software patents and the DMCA etc, unlike the GPLv3, which is legally well tested and makes sure to handle all of the problems that currently face software.

>In addition, since the BSD license does not come with the legal complexity of the GPL or LGPL licenses, it allows developers and companies to spend their time creating and promoting good code rather than worrying if that code violates licensing.
It's quite trivial if you follow good development practices to not violate the terms of any GPL or LGPL license and the only companies that have problems are the ones that think they know better than to follow best practices.

It is indeed possible, although difficult, to violate the BSD 2-clause and permanently lose your license, while the GPLv3 offers mechanisms for it to be reinstated.

Maybe I should write a blog post destroying the proprietary lies at a much higher level with much more detail.