Re: License violations for dependencies of Rust and Go programs?
On Wed, 2023-09-27 at 08:36 +0800, Paul Wise wrote: > This more general problem is very hard to impossible to solve, > since it would mean patching every single build toolchain and > source package [...] Are the upstream developers not already legally required to include all this information into various places including their “Help-About” menu? Regards Stephan signature.asc Description: This is a digitally signed message part
Re: Questions about spacet cadet reverse engineering
They clearly state that they decompiled binaries from Windows XP. This means it is a /fork/ and *not* a /clone/. Since I have not heard that Microsoft has put a permissive license on those binaries, I would expect that the restrictions of the original binary apply. Regards
Re: Store Wikimedia Commons picture of the day and description
First of all, the program itself should be legal in any case as long as you are not distributing any pictures with Debian. Secondly, it is probably a good idea to save the author and license information with the description. Regards signature.asc Description: This is a digitally signed message part
Re: Is the APSL 2.0 DFSG-compliant?
On Fri, 2022-08-05 at 10:31 +0100, Steve McIntyre wrote: > > That's not a restriction, though. It's *not* saying "you may not use > this software for XXX", it's saying "this software is not intended > for XXX". There's quite a difference there IMHO. To me it sounds like a more explicit “No Warranty” clause for critical applications. Regards
Re: Is the APSL 2.0 DFSG-compliant?
On Fri, 2022-08-05 at 08:25 +0800, Paul Wise wrote: > I wouldn't put any weight on the presence of the APSL 2.0 license > text > in the archive, probably it got into Debian in those packages due to > lack of copyright/license review rather than deliberate acceptance, > especially since it is in one of the many code copies in both of > them. There could also be cases of dual-licensing. Regards
Re: Is the APSL 2.0 DFSG-compliant?
> Interesting, the APSL 2.0 is seen in some relatively important > packages like Chromium and QtWebEngine. What code is exactly under that license? As far as I know, WebKit itself (which Chromium is a fork of) is licensed under LGPL (KDE code) and 2-clause BSD (Apple code). In your example of Chromium, it appears to be “XNU” and “Cross-Platform Mach Interface Generator (mig)”. https://sources.debian.org/src/chromium/103.0.5060.134-1/third_party/mig/README.chromium/ So for Debian GNU/Linux, it could be easily removed and ignored. However, Debian GNU/Darwin might want to have those libraries. Regards
Re: Binary file inside fruit package
On Mon, 2022-06-27 at 07:27 +0200, Tobias Frost wrote: > No, that is not how it works. It is not only nice to have. > We want the "preferred form of modification" in the package and a > binary > blob is often not. > > > For example, a program might contain a picture, but not the project > > files from the image editor that created it. > > Actually, if we have that infortmation, We'd ask for the project file > to be included. I agree that this is absolutely desirable to have those files included, not only for computer programs. However, has there ever been a case where software was excluded (or patched) because it did not include the “project files” for its data files? Regards
Re: Binary file inside fruit package
Is it really an executabe binary, i.e. a computer program for any real or virtual programming or machine language? I don't think that (non-executable) binary data is a problem. If the data is produced/generated with some tools, the “source” would be nice to have though, because it helps to make modifications. For example, a program might contain a picture, but not the project files from the image editor that created it. Regards On Sun, 2022-06-26 at 15:22 -0300, Marcos Talau wrote: > Hi there! > > The fruit package [1] comes with a binary file named > `book_small.bin'. This > binary file does not have a source code. > > Reading the documentation and checking the source code of the > package, the > binary file appears to contain chess openings, and I believe it is > used by > default by the program. > > Should this binary file be removed from this package? > > [1] https://tracker.debian.org/pkg/fruit > > > Best Regards, > mt > > >
