Most (if not all) of the Slackware scripts use the BSD licence, which essentially says "If it kills you, it's your fault for using it. Other than that, take it and do what you want with it but you need to keep the original references (the licence) in your additions".
It's _isn't_ about trying to demonstrate that something that really is trivial isn't.

You don't have to be a hypocrite to express and continue to hold on to your your view, but you don't need to present your view as if it's actually *correct* and anybody else's is wrong.

10 members found this post helpful.

Well, was some time until I posted again there because I was curious to consult the lawyers of the Company where I work. I said, no one time, that part of my job is to be Slackware "Observer", and beyond my fun argues with our Very Important Person and my personal Frenemy, usually resident there with the username ReaperXXL, like anyone understand, Slackware licensing is a sensible subject considering that That Company develop right on Slackware-based solutions.

And they, those lawyers, would like to argue that preserving the original references, as in license and as authors reference, while you publish your software source code, is specific to XFree86 (last) license and to GPL v3. And to remember that while GPL3 is avoided even by Linus Torvalds, also everyone know what happened with XFree86 Project. Practically, X.org what we use now, appeared because the original XFree86 developers chooses to use a strong hand in that very sensible problem, as the original authors to be always noticed.

In other hand, they, the lawyers, noticed that there is no clear Copyright notice, as in MIT/BSD, GPL v2 or GPL v3, etc... Just some source code notes and a sum of Applications Source Code included Copyright notices. So, from Law POV, the Slackware (Source Code?) Licensing looks like a can of worms.

While you claim as publishing the Source Code (aka Slackbuilds) under BSD license, you made claims specific only to GPL3 and (last, as in last-wish) Xfree86 license and they want kindly remember to Slackware Team that MIT/BSD license have as principal target to limit the (legal) liability so the right "few words" resume of MIT/BSD license is:

"If it kills you, it's your fault for using it. Other than that, take it and do what you want with it"

So, in the MIT/BSD License spirit, our friend don't made any mistake. It is his right to do what he want with those Slackbuilds, to strip the license headers, to sell them as commercial product, etc... But Slackware Team is not responsible about any lose.

IF your software is REALLY under MIT/BSD License, is perfectly legal for me to grab the entire Slackware 14.1 distribution, including its updates, to patch every SlackBuild to say:

Copyright 2015-2415 The Galactic Corporation,
All Rights Reserved.

And to binary patch the packages, then to sell it as Imperial Linux (eventually even without SlackBuilds source code).

So, please kindly reconsider your License Politics, MIT/BSD or Xfree86/GPL3?

Have you actually read the MIT/BSD license?

Sure, which part you don't understand?

Just asking. Why Apple can sell its MACOS/X leopards without a long notice about the brave (Free)BSD authors, while this OS is almost entirely licensed on MIT/BSD?

Just because the MIT/BSD License say in few words: "If it kills you, it's your fault for using it. Other than that, take it and do what you want with it", but let's do not start there a BSD Licensing Thread, even the dedicated BSD Forums are full (enough) of them...

Clearly at least one of us doesn't understand the part where it says you must retain the copyright notice.

Nice try!

But, the MIT/BSD License do not say where you should retain that License Notice... Can be somewhere in your installation toolkit, maybe in some archive, hundred level directory. The bad mouths say that even MacOS/X Leopard ship a BSD Notice, but no one find it yet...

Note the License Notice. There is no Owner Copyright in the BSD World.

Then be a Man and understand that until XFree86 last wish, err... license and, later, GPL3, no one talked about preserving The Copyright, as in Author. Much more, they was very afraid to not be sued in base of their published software, and later, under GPL, to preserve it to being Open Source.

No...

Under BSD/MIT the creator has full copyright control. The license clearly states any usage requires the original license holder be cited still, but any changes do not need to be contributed back. Under GPL the copyright belongs to the maintainer(s) of the project which is subject to change with each contribution made. All persons involved share an equal claim on the software and any forks made thereof must adhere to the original source license unless all contributors agree to relicense the project.

You should go read up on why BSD/MIT is better suited for controller oriented licensing than GPL. A project under BSD/MIT does not have to be contributed back to, but can be controlled because the original author can make all claims on it. Once it is (re)licensed under GPL, you lose all control if anyone contributes because now they have equal claim in your project.

When it comes to actual software GPL, BSD, and MIT all work as well as the intention of the project remains, however, scripts are of a different nature and if the author feels they desire full control of their work then a BSD or MIT license is appropriate.

The reason Patrick's official scripts are BSD/MIT licensed, is because they are his official scripts for the project, and he retains full active control regardless if any changes to them are submitted in or not.

I think it's pretty clear in the scripts what the redistribution terms are.
I recall back in 2004 when I submitted to the ARM Kernel maintainer an IDE driver for the StrongARM RiscPC that had been put together by a friend who was working on the Debian ARM port at the same time as me doing the Slackware one. He'd based the driver on the NetBSD driver and RISC OS sources but wasn't much of an upstreaming person. It had a BSD licence and was rejected because the original author could not be contacted to agree a re-licence.
The BSD licence was identical to the one below, apart from it had additional restrictions regarding binary re-distributions.

1 members found this post helpful.

" * Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution."

Source retains it in the source. Binary may list it in documentation.

Are you sure it doesn't?

From the BSD license:

If Apple sticks the text of the license in a text file somewhere (anywhere), say on the installation DVD that comes with the system, then the requirements of the license have been met. There is no requirement to make the text prominent.

ETA: Oops, I type slow. NeoMetal said it better.

As far as the OP is concerned, it makes sense from a branding perspective that "Slack" would want to encourage their users to respect the brand, and within their own domain they are well within their rights to enforce that. I can see how, for example, the "Slackware team" on Slack could be confusing and potentially in violation of the company's guidelines. Really, it only matters if Slackware wanted to integrate the Slack service into their website in some public fashion.
At least, as far as I can see...
The rest of the argument here is rather confusing at this point, but
Really doesn't make any sense. If a particular package has a particular license, that does not override the licensing of other, differently or similarly licensed, packages within a bundle.

Just a side note about apple, they definitely do make those licenses available:
eg. http://www.opensource.apple.com/sour...ile-35/LICENSE
http://www.opensource.apple.com/sour...61/zsh/LICENCE

1 members found this post helpful.

You can take the entire Slackware source but you can not remove the existing BSD/MIT license from the scripts and relicense it as anything official on any level. You can remake them as your own, but it won't be anything relative to Slackware. Plus, nothing you would do would be classified as official, nor could be as part of Slackware.

In short, your, or anyone's, own attempt at being petty and condescending immediately backfires because Patrick controls everything in Slackware as a distribution officially and the BSD/MIT license allows him and him alone to say what is or isn't official even if you clone, duplicate, or steal the official and original sources, or choose to contribute back, or not.

The reason the BSD/MIT license is used is to allow a general template to be easily used by anyone for public and private works, but allow Slackbuilds.org to have a point of control per package on who was the first contributor. This way nobody can duplicate existing work and take credit without the original contributor and contribution, and you must get permission to have the official SBO released work transferred to another contributor.

2 members found this post helpful.

You can do whatever you want to Slackware and distribute it as you see fit as long as the original copyright notice remains intact. Pat can assert no 'control' over derivatives except to ensure that the copyright notice is still there, regardless of how far it strays from upstream. As for modifications being 'official', the only thing that prevents you from calling your derivative Slackware (and thus making it 'official' if that has any meaning) is the Slackware trademark that Pat owns, which has nothing at all to do with any open source license.
The BSD/MIT license says nothing about what is or isn't 'official'. It does not allow a single entity to retain control over its distribution; it does just the opposite, by saying anyone can do anything with the sources, including redistributing in binary form, as long as a license with the original copyright notice is intact. Again, the only thing keeping Slackware 'official' is a registered trademark which has nothing whatever to do with the BSD/MIT license.
The BSD/MIT license was designed to indemnify the creator against lawsuits arising from redistributed works. As a side effect it also enforces giving credit. That's it.

1 members found this post helpful.