[SOLVED] Chances of getting sued-fined for editing slackbuilds?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Chances of getting sued-fined for editing slackbuilds?
Noticed in v4l-utils.SlackBuild, there is no indication of the right to modify the SlackBuild in any way. It only says it's ok to redistribute it, but no indication of anything beyond.
So what are the chances of getting sued-fined if someone wishes to change things in Slackware's official SlackBuilds? What if someone hosts modified SlackBuilds, or SlackBuilds derived from the originals (with Patrick, Eric or others still in the credits)?
# Copyright 2009 Eric Hameleers, Eindhoven, NL
# Copyright 2009, 2010, 2011, 2013 Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
# 1. Redistributions of this script must retain the above copyright
# notice, this list of conditions and the following disclaimer.
what do you mean there is no indication ?
"...with or without modification,..."
A SlackBuild is simply a script used to build and install packages. Example: if GCC vanished tomorrow and all we were left with was LLVM/Clang, the SlackBuild would have to be modified to switch the compiler and add any needed patches. If it wasn't able to be modified, we'd be screwed.
Plain and simple, outside the source or binary shareware package, a SlackBuild is completely separate and free open source.
Some of my scripts I've posted over in the LFS section are open source licensed. I don't care what you do to them, just acknowledge the original source and author.
Wonder if Patrick accepts slackbuild updates from anyone; some slackbuilds are very outdated like dev86.
To the extent that those updates are useful, yes. Let's just say that dev86 gets all the attention it requires.
Originally Posted by Holering
What if a fork of the slackware-current slackbuilds tree existed?
The Slackware-derived distributions are legally and technically pretty much in that situation already. It all adds to the world's majesty. It's fine.
You should understand how Slackware got started. AIUI, Patrick was producing fixed-up versions of SLS, and trying to feed the fixes back upstream. Instead, upstream chose to be un-cooperative. The laid-back give-and-take of the Slackware project is the obvious consequence. Patrick is not suddenly going to get heavy with terms and conditions, unless some total knobhead comes along and completely takes the piss in an unforeseen and innovative way.