On Tue, 2014-05-27 at 23:59 +0200, Leopold Palomo-Avellaneda wrote: > El Dimarts, 27 de maig de 2014, a les 19:37:52, Tobias Frost va escriure: > [...] > > > > > > I have bug [1] and therefore I asked to upstream about this files. Hi > > > kindly reported me the licenses, but I have some files (for instance > > > javascripts gen_validatorv31.js) that I have not found any information > > > about the license. > > Actually you can find it by just following the URL given in the > > gen_validatorv31.js file itself. (Granted, this link points to the right > > homepage, but to a newer version of the file. However with the help of > > archive.org you can find the version "31" and actually the license terms > > did not change since then: > > https://web.archive.org/web/20081230025946/http://www.javascript-coder.com/h > > tml-form/javascript-form-validation.phtml > > https://web.archive.org/web/20081230025946/http://www.javascript-coder.com/ > > html-form/javascript_form.zip > > > > Unfortunatly neigther the license in the file nor the EULA* file in the > > zip file grants you explictily the rights for distribution. So I fear > > you cannot. > > (Additionally -- but this does not really matter without the right for > > distribution -- the file is not dfsg-free, as e.g commercial use is > > prohibited) > > I must repack sources... > > > > Also, in the test directory, not in any deb file, I have two shell script > > > with no license in the header, and I have just a sentence in a private > > > mail from upstream. > > > > What does that sentence tell? Was this the "not licensesd" answer you > > referred to earlier? > > Sorry for not be clear, in a second mail I understood it: they are covered > under the same license that the rest. > > > (Well IMHO as the main directory has a LICENSE file telling of a > > 3-clause-BSD license for the whole thing, I would expect that this shell > > scripts are covered by this licenses without explicitly having a header > > in it. Of course having a license header is always clearer/preferred, > > but at least its a base IMHO you can safely assume that licensing is ok) > > Yes, ... > > > So, then, as I have the package in a git [1], I understand that just unpack > the original sources, delete the conflictive files, repack it with dfsg sufix > and > add with import-orig, no?
Other way round: First implement get-orig-source, remove the file in get-orig-source to create the tarball (the target should regenerate the source-tarball in the archives bit-wise, so if you reinvoke the target you end up with a file having the same hash). I think this article on the Wiki is good to get started: https://wiki.debian.org/onlyjob/get-orig-source (I see as you package git snapshot you probably have a get-orig-source taget anyway (didn't check), so that's your way. Otherwise, when you're using uscan, you can use the new feature to remove files as described here: https://wiki.debian.org/UscanEnhancements) -- Tobi > thanks in advance, > > Leopold > > > > [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/ompl.git >
signature.asc
Description: This is a digitally signed message part
