I am back porting a bunch of code to run on older kernels. (gcc 4.9 dependencies, x11, vlc etc.) as *.deb files. In this process, ( I am new to packaging) I need to create a copyright file. I can have a blank one, I know, but I would like to know, what is the copyright format?
Do i take the license of the software I am packaging? Or can I give the package a different license than the source licence?
I have been reading:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
but I am still confused about license and copyright, and whether or not license and copyrights are different for the *.deb file I am making.
Can someone clarify this?
First, according to Debian policy, it's not necessary to use any particular format for the debian/copyright file, as long as the reader can easily tell what copyrights and license terms apply to the package or to individual files (and, of course, as long as those license terms are actually met). I personally appreciate it when a packager uses the copyright-format/1.0, though; it's usually much clearer to read.
The license information in debian/copyright should cover the copyright(s) and licensing of the package you're distributing, as well as any additional copyright and licensing you want to apply to your packaging.
You can't give the package a different license than the source license unless you have permission to do so (nothing gives you automatic permission to license someone else's property on your own terms). Some open source licenses imply that it's ok to redistribute the source or derivatives of the source under a different license, as long as the copyright notice and a disclaimer are kept intact.
It's fairly common, for example, for code licensed under an MIT/X11-style license to be incorporated into code under a BSD-style or GPL license. The resulting combined work is then distributable as long as the terms of both licenses are met (this is not a very onerous requirement in the case of MIT/X11/BSD), and both copyright notices are included. If it's possible to meet the terms of two or more licenses at the same time, we say those licenses are "compatible".
Some works meticulously keep track of what copyrights and licenses apply to each particular file when combining source from multiple origins. Some instead apply all licenses and all copyrights of component parts to the entire combined work. Both are generally accepted by the open source community, as long as it's clear that an effort is being made to identify and comply with the original licenses. Both of those are easily representable in the copyright-format/1.0 syntax.
(I am not a lawyer, this is not legal advice, consult a real lawyer if you are worried about actual legality of relicensing, etc.)
Related
Some open-source projects make combined releases where the version number of each package(library) is increased to the same version.
Examples in Java are:
org.springframework
com.fasterxml.jackson
org.hamcrest
This implies that some packages may get a new version even though they have not changed (nor their dependencies). I don't think this violates semantic versioning.
Benefits I see is that:
Users can use a single version to monitor and upgrade
All users likely to use the same combination of libraries
Drawbacks:
Users using just one out of many libraries might be notified about an "update" though the package to download has not changed
If many users use just a sub-package, then all bug reports for one version are equally for a range of versions, which is difficult to track. Reverting to the previous "different" version to avoid a bug becomes more complex.
One alternative to single-versioning is to use a BOM (Bill-of-materials).
Different concepts of BOMs exist:
A BOM can list several dependencies to include in their versions (e.g. Linux apt Meta-packages)
A BOM can define versions (and other restrictions) for dependencies to be used if the dependency is included (e.g. Java Maven dependencyManagement section of BOM)
The BOM allows to declare which configuration(combination) of library-versions have been tested together, and allows separate groups of users to all use the same configuration, helping with bug reports and reproducibility.
Not all software distribution and buildsystems support the BOM concept equally well, though.
I am interested in how the binary utilities of Linux are coded and how do they work. Where can I find the source code for them?
Strings is usually part of the binutils and since they are maintained by the Free Software Foundation and licensed under the GNU Public License, the source code is available here:
http://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git
or packages of version related snapshots here:
ftp://sourceware.org/pub/binutils/snapshots
If you want to start with a general overview, try the Wikipedia page for binutils or this explanation of the toolchain (more a general description)
I am using Haskell, which reported to be great and easy for parallelism. Unfortunately, I have no way to test this claim, as my computer has a single processor. Does anyone know of a utility that will make it appear as if my computer as 2 or 4(obviously slower than the real one) processors, and would let me track there performance. It should also let me test one imaginary processor at a time, so I could see how parallel to nonparallel would compare on such a computer. Although it would be better to the comunity for a more universal app, I will take answers even if they only work with haskell.
P.S. I am running Ubuntu 13.10.
The search keywords you are looking for are "simulate multiple cores"
Here's one: sniper
It is not open source. From the FAQ:
Q: What are the license terms for using Sniper?
A: In short, the interval core model is protected under a US patent
application. We automatically grant you a free license for using the
interval model inside Sniper for academic purposes. For commercial
use, please contact Lieven Eeckhout. All other code is licensed under
the very liberal MIT license. You can view the full details on our
License page.
I have been looking into MeeGo, maemo, Android architecture.
They all have Linux Kernel, build some libraries on it, then build middle layer libraries [e.g telephony, media etc...].
Suppose i wana build my own system, say Linux Kernel, with some binariers like glibc, Dbus,.... UI toolkit like GTK+ and its binaries.
I want to compile every project from source to customize my own linux system for desktop, netbook and handheld devices. [starting from netbook first :)]
How can i build my own customize system from kernel to UI.
I apologize in advance for a very long winded answer to what you thought would be a very simple question. Unfortunately, piecing together an entire operating system from many different bits in a coherent and unified manner is not exactly a trivial task. I'm currently working on my own Xen based distribution, I'll share my experience thus far (beyond Linux From Scratch):
1 - Decide on a scope and stick to it
If you have any hope of actually completing this project, you need write an explanation of what your new OS will be and do once its completed in a single paragraph. Print that out and tape it to your wall, directly in front of you. Read it, chant it, practice saying it backwards and whatever else may help you to keep it directly in front of any urge to succumb to feature creep.
2 - Decide on a package manager
This may be the single most important decision that you will make. You need to decide how you will maintain your operating system in regards to updates and new releases, even if you are the only subscriber. Anyone, including you who uses the new OS will surely find a need to install something that was not included in the base distribution. Even if you are pushing out an OS to power a kiosk, its critical for all deployments to keep themselves up to date in a sane and consistent manner.
I ended up going with apt-rpm because it offered the flexibility of the popular .rpm package format while leveraging apt's known sanity when it comes to dependencies. You may prefer using yum, apt with .deb packages, slackware style .tgz packages or your own format.
Decide on this quickly, because its going to dictate how you structure your build. Keep track of dependencies in each component so that its easy to roll packages later.
3 - Re-read your scope then configure your kernel
Avoid the kitchen sink syndrome when making a kernel. Look at what you want to accomplish and then decide what the kernel has to support. You will probably want full gadget support, compatibility with file systems from other popular operating systems, security hooks appropriate for people who do a lot of browsing, etc. You don't need to support crazy RAID configurations, advanced netfilter targets and minixfs, but wifi better work. You don't need 10GBE or infiniband support. Go through the kernel configuration carefully. If you can't justify including a module by its potential use, don't check it.
Avoid pulling in out of tree patches unless you absolutely need them. From time to time, people come up with new scheduling algorithms, experimental file systems, etc. It is very, very difficult to maintain a kernel that consumes from anything else but mainline.
There are exceptions, of course. If going out of tree is the only way to meet one of your goals stated in your scope. Just remain conscious of how much additional work you'll be making for yourself in the future.
4 - Re-read your scope then select your base userland
At the very minimum, you'll need a shell, the core utilities and an editor that works without an window manager. Paying attention to dependencies will tell you that you also need a C library and whatever else is needed to make the base commands work. As Eli answered, Linux From Scratch is a good resource to check. I also strongly suggest looking at the LSB (Linux standard base), this is a specification that lists common packages and components that are 'expected' to be included with any distribution. Don't follow the LSB as a standard, compare its suggestions against your scope. If the purpose of your OS does not necessitate inclusion of something and nothing you install will depend on it, don't include it.
5 - Re-read your scope and decide on a window system
Again, referring to the everything including the kitchen sink syndrome, try and resist the urge to just slap a stock install of KDE or GNOME on top of your base OS and call it done. Another common pitfall is to install a full blown version of either and work backwards by removing things that aren't needed. For the sake of sane dependencies, its really better to work on this from bottom up rather than top down.
Decide quickly on the UI toolkit that your distribution is going to favor and get it (with supporting libraries) in place. Define consistency in UIs quickly and stick to it. Nothing is more annoying than having 10 windows open that behave completely differently as far as controls go. When I see this, I diagnose the OS with multiple personality disorder and want to medicate its developer. There was just an uproar regarding Ubuntu moving window controls around, and they were doing it consistently .. the inconsistency was the behavior changing between versions. People get very upset if they can't immediately find a button or have to increase their mouse mileage.
6 - Re-read your scope and pick your applications
Avoid kitchen sink syndrome here as well. Choose your applications not only based on your scope and their popularity, but how easy they will be for you to maintain. Its very likely that you will be applying your own patches to them (even simple ones like messengers updating a blinking light on the toolbar).
Its important to keep every architecture that you want to support in mind as you select what you want to include. For instance, if Valgrind is your best friend, be aware that you won't be able to use it to debug issues on certain ARM platforms.
Pretend you are a company and will be an employee there. Does your company pass the Joel test? Consider a continuous integration system like Hudson, as well. It will save you lots of hair pulling as you progress.
As you begin unifying all of these components, you'll naturally be establishing your own SDK. Document it as you go, avoid breaking it on a whim (refer to your scope, always). Its perfectly acceptable to just let linux be linux, which turns your SDK more into formal guidelines than anything else.
In my case, I'm rather fortunate to be working on something that is designed strictly as a server OS. I don't have to deal with desktop caveats and I don't envy anyone who does.
7 - Additional suggestions
These are in random order, but noting them might save you some time:
Maintain patch sets to every line of upstream code that you modify, in numbered sequence. An example might be 00-make-bash-clairvoyant.patch, this allows you to maintain patches instead of entire forked repositories of upstream code. You'll thank yourself for this later.
If a component has a testing suite, make sure you add tests for anything that you introduce. Its easy to just say "great, it works!" and leave it at that, keep in mind that you'll likely be adding even more later, which may break what you added previously.
Use whatever version control system is in use by the authors when pulling in upstream code. This makes merging of new code much, much simpler and shaves hours off of re-basing your patches.
Even if you think upstream authors won't be interested in your changes, at least alert them to the fact that they exist. Coordination is essential, even if you simply learn that a feature you just put in is already in planning and will be implemented differently in the future.
You may be convinced that you will be the only person to ever use your OS. Design it as though millions will use it, you never know. This kind of thinking helps avoid kludges.
Don't pull upstream alpha code, no matter what the temptation may be. Red Hat tried that, it did not work out well. Stick to stable releases unless you are pulling in bug fixes. Major bug fixes usually result in upstream releases, so make sure you watch and coordinate.
Remember that it's supposed to be fun.
Finally, realize that rolling an entire from-scratch distribution is exponentially more complex than forking an existing distribution and simply adding whatever you feel that it lacks. You need to reward yourself often by booting your OS and actually using it productively. If you get too frustrated, consistently confused or find yourself putting off work on it, consider making a lightweight fork of Debian or Ubuntu. You can then go back and duplicate it entirely from scratch. Its no different than prototyping an application in a simpler / rapid language first before writing it for real in something more difficult. If you want to go this route (first), gNewSense offers utilities to fork your own OS directly from Ubuntu. Note, by default, their utilities will strip any non free bits (including binary kernel blobs) from the resulting distro.
I strongly suggest going the completely from scratch route (first) because the experience that you will gain is far greater than making yet another fork. However, its also important that you actually complete your project. Best is subjective, do what works for you.
Good luck on your project, see you on distrowatch.
Check out Linux From Scratch:
Linux From Scratch (LFS) is a project
that provides you with step-by-step
instructions for building your own
customized Linux system entirely from
source.
Use Gentoo Linux. It is a compile from source distribution, very customizable. I like it a lot.
What is the best practice for releasing a simple software? Suppose I created a very small simple and useful program or a tool and would like to share it with everyone by uploading it to my web-site.
Do I need a license and which one? (I read http://www.gnu.org/ and http://www.fsf.org/ but still cannot decide - there are too many of them.)
Do I need to put somewhere a copyright and what is the basic principles of creating "Copyright" string?
How can I make a user, who is going to download and install my program, to believe that my program doesn't contain viruses or a malicious code?
Since this is a "very small simple and useful program" (e.g. someone could recreate it easily), I would not worry too much about the details and choose a simple license, something you can include in about 20 lines at the top of every file:
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
There's really nothing you can say to the pessimistic user to convince them it doesn't contain a virus, and I would not even go into detail about that. Scan the file with a virus scanner and simply state which one you used, if you want, but nothing more. Providing the source code so someone can read, understand, and compile themselves should alleviate most users' concerns about you intentionally trying to sabotage them. (And this works even without people actually reading the source, because most people are trusting.)
These answers are just my own opinions, not some widely established best practices
Go for one of the permissive free software licenses, such as BSD license, they are short, simple and as the name states, permissive.
Copyright 2010 Your Legal Name should be enough - I would put it as a comment in all source files and in "credits screen" / help menu / whatever of the GUI. Also put a pointer to the license there too.
That is what the user uses antivirus for :) - perhaps host your software on some reputable site (like sourceforge), not on a suspicious site (like rapidshare). Also, just releasing your source code hints this (as anyone can take a look and see for themselves)
You need a license if you want to make it open source. If so, the license will specify a copyright, and by publishing the source code users can feel safe that it doesn't contain a virus.
If you don't open source the app, just upload it to one of those shareware sites (download.com, tucows.com) - they will take care of scanning for viruses.
If you are using any kind of .NET language there is a publish option in the properties file where you can specify the FTP location, and it automatically does a sufficient enough distribution system.
Also, you can have the program check for updates if any has been released, and it will develop the release before each run. Look trough that properties thing for copyright and support URL and what not fields. For the copyright thing, check Creative Commons if you want redistribution, but as soon as you put that magic c in circle thing, that's all you have to do to have copyright of your IP and no applications are necessary as far as I know.