I downloaded the latest release (1.3.7) and noticed it only included the copyright notice and a link to the main site in the quill.js and quill.css file.
Do I need to append the BSD-3 license information to the file(s) since I might intend on doing short-term modifications?
Related
Some time ago (some years) my company purchased a license for the library called LibXL.
Previously the application was built on CentOS 6.5 without troubles.
I have currently set up a new system (Ubuntu 16.04) but LibXL returns a warning:
Created by LibXL trial version. Please buy the LibXL full version for removing this message.
Version of this library is exactly the same - I just copied .so file.
Application is built using C language.
License setting code:
xlBookSetKey(book,"<name>", "linux-<characters>");
Do we need to buy a new license key?
Maybe some operating system settings are wrong? or maybe I missed some configuration file? (I just copied the libxl.so file to the right place).
There is a note in http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Other_tags, which states:
Do NOT use these tags
Packager
Vendor
Copyright
With no explanation given. Packager is quite commonly seen, so, when I am creating a new spec file to distribute software, why should I not include that tag (or any of the named tags)?
Copyright has been deprecated in 2000. Rpmbuild refuse to accept it since 2005. It was poorly named initially and should have been named License from the very start. Nowadays everyone uses License tag.
Vendor is usually set by build system (Koji, Copr, OBS) so you should not override it. I.e. every package in Fedora has Vendor set to "Fedora Project".
The same for Packager. But this one is a little bit relaxed. E.g., Koji set it, but Copr not.
I have one library using one function in the PnP configuration manager library. Therefor, the cfgmgr32.lib is included in our build.
But I don't know where it came from, nor do I know what license is attached to it. I assume it was in the DDK.
Could one label this as "Proprietary" software?
First I assume that you are talking about a lib that is part of the windows driver kit:
http://msdn.microsoft.com/en-us/windows/hardware/gg487428
Per: http://msdn.microsoft.com/en-us/windows/hardware/gg487463 "How to get the Windows DDK"
I end up there http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff and a download url of: http://download.microsoft.com/download/4/A/2/4A25C7D5-EFBE-4182-B6A9-AE6850409A78/GRMWDK_EN_7600_1.ISO ...
This is a large ISO image.
Once you have that, the terms of the license should be detailed in the ISO somewhere.
Per: http://www.microsoft.com/taiwan/whdc/devtools/wdk/RelNotesW7.mspx#EPD
"The contents included in the Windows Driver Kit (WDK) are licensed to you, the end user. Your use of the WDK is subject to the terms of an End User License Agreement (EULA) that accompanies the WDK and is located in the WDK installation directory. The name of the file is License.rtf. Before you access or use the WDK, you must read and accept the terms of the EULA. If you do not agree to the terms of the EULA, you are not authorized to use the WDK."
So get the ISO, install and get the exact license.
Also the doc is there:
http://msdn.microsoft.com/en-us/windows/hardware/gg487458
this is smaller and should also contain license terms.
Redhat 5.5
gcc version 4.1.2
I have a directory call lib, and in that directory I have all the shared libraries (about 30) that we get from our customer as we use their API. We link with this API.
directory structure:
/usr/CSAPI/lib
However, our customer will update their API so we get new libraries, normally about 3 or 4.
What I have been doing is when I get new libraries. Is to remove the old one and put in another directory. And replace them with the new libaries in the lib directory.
/usr/CSAPI/Old_libs
The new and old will have the same name. i.e.
libcs.so < old
libcs.so < new
Is there a better way to manage this? I was thinking of creating a soft line, but as the names are the same, I am not sure that this will work.
Many thanks,
Usually libraries are versioned, not just "the same name".
You'll have a file in your /usr/lib directory for each version:
/usr/lib/libFLAC.so.8.2.0
/usr/lib/libFLAC.so.8.2.1
/usr/lib/libFLAC.so.8.2.2
Then you symlink the major library versions to the latest minor version:
/usr/lib/libFLAC.so.8 -> /usr/lib/libFLAC.so.8.2.2
The benefit of this is that API changes will add new files and update the symlinks, but if I need to specify a specific API version number, the file is still right there.
This isn't set in stone, so do whatever works for your release process :)
Symlinks are a very good way to handle this. I would do something slightly differently. I would create a directory structure like:
/usr/CSAPI/lib_v1
/usr/CSAPI/lib_v2
and in each of these I would put the actual files. I would then create a separate directory:
/usr/CSAPI/lib
which only contains symlinks to the actual files in lib_v1, lib_v2, etc.
This way lib has the most current version, but if you need, you can use a previous version by simply changing your LD_LIBRARY_PATH.
I am trying to get license information of uninstalled deb packages.
dpkg --info <package-name>.deb does not give that information.
Is there any command in ubuntu which will give this info?
(In rpm world rpm -qpi gives that info)
There's no simple command that I know of. You can do something like this:
dpkg-deb --fsys-tarfile foo.deb |tar -xvO ./usr/share/doc/foo/copyright
This prints the file to standard output.
Edit Hmm, that sounds hard. After a quick perusal of the apt cache on my Debian system, I found some phrases that might be useful:
"GNU General Public License"
"the above copyright notice and this permission notice", making sure you unwrap lines first
"/usr/share/common-licenses/*"
This seems to be the closest to a standard license you'll get, but be careful since often the packaging is under a common-license, but the package contents are under a separate license.
^License: MPL-1.1 | GPL-2+ | Apache-2.0
However, some packages (ImageMagick) simply have a free-form license in the copyright file that doesn't really conform to any stock license, except that someone considered it DFSG-approved.
Update 2012: This is beginning to change, as the debian/copyright file is now required to be machine-interpretable, so you can look forward to this in the future.