Re: TrueType/OpenType and anti-circumvention laws
On Mon, 2024-01-15 at 06:05 -0500, P. J. McDermott wrote:
> Paul Wise mentioned[8] on the fonts team list in 2021 a couple programs
> ("embed"[9], a derivative "ttembed"[10], and "ttfpatch"[11]) that unset
> the DRM/TPM bits, enabling full use of the fonts. "embed" was written
> by a font designer who noticed that his fonts had restrictive embedding
> permissions and that a tool he used (which was intended for font users,
> not designers) didn't allow lowering the restrictions.
PS: for thread completeness, I note the embed author recieved DMCA
legal threats, but did not remove the tool from their website:
http://carnage-melon.tom7.org/embed/dmca.html
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Re: TrueType/OpenType and anti-circumvention laws
On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote: > [Resending to the list, as it apparently didn't go through earlier.] It did go through. > Ping? Any thoughts on whether a font DRM modification tool would be > legal to distribute and use in Debian given that the DRM is a simple bit > field rather than an "effective" TPM such as scrambling or encryption? Probably best to consult a lawyer there, but ISTR even trivial things are supposed to count under the DMCA. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: d/copyright entries for licenses and copyright data
On Fri, 2024-01-05 at 22:31 -0800, Ross Vandegrift wrote: > Imagine I take some code from a freely licensed reference implementation and > customize it. The result is a derived work. But this embedding isn't > removable - the reference implementation shouldn't accept changes to integrate > it into a specific project. The reference implementation should be flexible enough to work as a library imported/loaded/linked by any project that wants to use it. If it isn't then that is an issue that should be fixed upstream. Once it is then the removal can happen and Debian can use depends. > It'd be reasonable to include the original license and copyright statements. Right. > If I do, Debian requires packagers to describe the license and copyright on > those embedded license/copyright files. And I'm puzzled about how to do that > best. Same as for any other file in the source package, list in the debian/copyright which files have which copyrights and licenses. > Maybe the answer is to repack it away? But that seems weird. It's freely > redistributable, and that'd be *obscuring* license/copyright details. We > usually like that. :) Repacking it away sounds like removing it from the source package, which would mean it could no longer be used, or never was used, in both cases there isn't any point having it in the upstream VCS then. > The same issue arises for disabled conveience copies. The wiki suggests > Files-Excluded, but also alternatives that involve Debian redistributing the > convenience copy (and so probably it's license/copyright files) in source > packages. Unless there are DFSG or size reasons to remove the unused copy, generally Debian suggests either forwarding the removal upstream, or keeping the unused copy, not repacking to remove the copy. Some folks repack anyway to avoid the work needed documenting copyrights and licenses, although there are tools to automate that process now. https://wiki.debian.org/CopyrightReviewTools > (I realize not much hangs on this - but cme/licensecheck raised the issue to > me. I can ignore it, but also got curious and tried to figure out what to > do.) What issue did it print? Which package/code is this about BTW? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: d/copyright entries for licenses and copyright data
On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote: > Suppose project A includes code from project B. The best option would be to talk to upstream about removing the copy, further advice about embedded copies is on the wiki: https://wiki.debian.org/EmbeddedCopies > How should these files appear in d/copyright? > (Please CC me, I'm not subscribed.) Richard Laager responded but forgot to CC you, I bounced the message: I document them the same, except that I also add use the DEP-5 "Comment" field to indicate that it came from "B". -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1053672: Apple copyright notices in test .xlsx files
On Sun, 2023-10-08 at 15:04 +0100, Rebecca N. Palmer wrote: > Given this, why is that copyright notice there, and what does it imply > that we should do? (E.g. does Apple Numbers automatically copy > Apple-owned items (e.g. fonts) into files it creates? If so, is there a > way to remove these items to get a Free file?) *.xlsx files are actually just *.zip files containing XML and other files. The Apple copyright for both of the files you mention comes from the Apple copyright listed for the ICC profile embedded in the EXIF data in the JPEG file that was saved as a thumbnail of the spreadsheet. I am not sure what that means for the license of the test cases in openpyxl and but it would be easy to fix by either deleting the thumbnail, or removing the ICC profile, but that would alter the test cases, probably that wouldn't affect the tests passing/failing though. $ unzip conditional-formatting.xlsx Archive: conditional-formatting.xlsx inflating: [Content_Types].xml inflating: _rels/.rels inflating: xl/_rels/workbook.xml.rels inflating: xl/workbook.xml extracting: docProps/thumbnail.jpeg inflating: xl/theme/theme1.xml inflating: xl/styles.xml inflating: xl/worksheets/sheet1.xml inflating: docProps/core.xml inflating: docProps/app.xml $ grep -ri apple grep: conditional-formatting.xlsx: binary file matches grep: docProps/thumbnail.jpeg: binary file matches $ exiftool docProps/thumbnail.jpeg | grep -i apple Profile CMM Type: Apple Computer Inc. Primary Platform: Apple Computer Inc. Device Manufacturer : Apple Computer Inc. Profile Creator : Apple Computer Inc. Profile Copyright : Copyright 2007 Apple Inc., all rights reserved. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: License violations for dependencies of Rust and Go programs?
On Wed, 2023-09-27 at 10:41 -0400, John Thorvald Wodder II wrote: > So was this problem previously known but under-acknowledged, or was it simply > not brought up before now? I find it surprising that Debian would allow so > many license violations to get this far. Is fixing the tooling to handle this > considered a priority? If the author of an uncredited dependency were to > complain, would Debian be more likely to focus on fixing the tooling posthaste > or to just pull whatever packages use the dependency in question? This is the first time this problem was brought up in Debian AFAICT. Likely no-one thought about it because we are used to dynamic linking, which doesn't have this problem. Several folks on different IRC channels discussed the problem yesterday and it is possible the Rust or Go teams might work on a debhelper addon to solve it. In theory it could be possible to solve by copying the copyright files of static libraries into the binary packages they are linked into, probably using the Built-Using and Static-Build-Using fields. It will also further bloat the binary packages of Rust/Go/etc based binaries. We also noted that this is not just a Debian problem, but a problem with every distro packaging statically linked stuff and with even the upstream ecosystems, any project using static linking must deal with this problem, so every single Rust/Go developer must deal with it. These links point to some efforts to handle it in the Rust community: https://github.com/rust-lang/cargo/issues/12053 https://lib.rs/crates/cargo-bundle-licenses https://lib.rs/crates/cargo-about -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: License violations for dependencies of Rust and Go programs?
On Wed, 2023-09-27 at 11:03 -0400, John Thorvald Wodder II wrote: > On further inspection, it turns out that bat itself compiles the text > of its NOTICE file into the binary, and the text is displayed when > running `batcat --acknowledgements`, so bat's Apache 2.0 license is > being followed. If it's Debian policy to include the NOTICE file in > the .deb anyway, let me know so I can file a more appropriate bug > report. Yes, I think we should include the NOTICE as a file too, so that users who are looking at the Debian copyright file can find it easily. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: License violations for dependencies of Rust and Go programs?
On Wed, 2023-09-27 at 05:24 +, Stephan Verbücheln wrote: > Are the upstream developers not already legally required to include all > this information into various places including their “Help-About” menu? It is definitely not common practice to document the copyright/license info of dependencies in about dialogs. Sometimes it happens in the build documentation in the source package but not always and that usually isn't distributed in the binary package. In distributions like Debian, usually programs dynamically link their dependencies so the copyright/license info of dependencies accompanies the binaries of the dependencies instead of the programs. Then the dependency information plus the individual package copyright info ensures that the license information for all components is present. It is only because of static linking that the issue you mention arises. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: License violations for dependencies of Rust and Go programs?
On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote: > - bat (In addition to the type of problem discussed above, the source code for > bat has an Apache 2.0 `NOTICE` file, yet this is not included in the .deb > package.) Please file a severity serious bug report against bat about the NOTICE issue, I've mentioned it on the #debian-rust IRC channel though. https://www.debian.org/Bugs/Reporting I note that lintian detects the NOTICE issue, so I have requested that the ftp-master team turn on auto-rejections for the lintian tag. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: License violations for dependencies of Rust and Go programs?
On Tue, 2023-09-26 at 14:20 -0400, John Thorvald Wodder II wrote: > I suspect that this problem applies to all programs written in Go or Rust that > Debian distributes. Is Debian handling dependency licenses for these packages > incorrectly, or is there something I'm missing? Your analysis is correct, some extra context for this problem: The problem you have identified applies to other statically linked languages too, so I have updated the wiki page to link to it. https://wiki.debian.org/StaticLinking The problem can be more generally stated as; Debian aggregates the copyright and license of source files we distribute but does not trace the path from source files to compiled files, and therefore does not trace which source files each generated file was created from and as a subset of that problem, does therefore not trace the flow of copyright and license information and does not aggregate that information and does not discover license incompatibilities in the generated files. This more general problem is very hard to impossible to solve, since it would mean patching every single build toolchain and source package to provide traces of the path from source files to compiled files and then processing those traces to generate copyright info for binary packages. The specific problem with Rust/Go/etc static linking might be solvable by a new debhelper command that would read the Built-Using and related fields and then append each of them to the DEBIAN/copyright files. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: NetData violating DFSG, nonfree?
On Thu, 2023-08-24 at 13:56 +, Marius Gripsgard wrote: > Could someone review this? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145 On the question of missing source code, looking at the Debian source package, all the CSS and JavaScript (except that embedded in the HTML) is minified and there is evidence that some of the minified JavaScript is from dependencies, under various licenses, including GPLv3. The same applies to the v1 web gui too. In addition there is this ominous notice in the v2 README.md file: # Do not edit any files in this directory! If you spot any errors or bugs in these files please open a bug report at https://github.com/netdata/netdata/issues/new/choose. These files are maintained in a seprate private repository and copied here when they are updated there, so any changes made in this directory will eventually be overwritten. Similarly the v1 README.md says this: # Do not edit any files in this directory! If you spot any errors or bugs in these files and wish to fix them, please submit your changes at https://github.com/netdata/dashboard instead. These files are copied from the most recent release of that repository, and any changes you make here will be overwritten the next time there’s a new release there. I think that the netdata web guis should not be in Debian like this. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: NetData violating DFSG, nonfree?
On Fri, 2023-08-25 at 11:35 +0800, Paul Wise wrote: > ## Acceptance > By using the software, you agree to all of the terms and conditions > below. This is icky, not sure about DFSG compliance. > ## Copyright License > The licensor grants you a non-exclusive, royalty-free, worldwide, non- > sublicensable, non-transferable license to use, copy, distribute, make > available the software, in each case subject to the limitations, > restrictions and conditions below. Does not allow modifications, fails DFSG item 3. > ## Limitations > This license allows you to use the Software only to interface with the > licensor's other software components, such as Netdata Agents and > Netdata Cloud. Any use with replacements for these components is not > permitted. Discriminates against Netdata competitors, fails DFSG item 6. > ## Restrictions > The Software is provided in a binary form for use by end-users. You may > not reverse engineer, decompile, disassemble, or modify the Software. > The Software is licensed as a single product and its component parts > may not be separated. Not distributing source code, fails DFSG item 2. The restrictions seem like they fail DFSG item 6. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: NetData violating DFSG, nonfree?
On Thu, 2023-08-24 at 13:56 +, Marius Gripsgard wrote: > Could someone review this? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1045145 Here is a copy of the license for the list archives: # Netdata Cloud UI License v1.0 (NCUL1) ## Acceptance By using the software, you agree to all of the terms and conditions below. ## Copyright License The licensor grants you a non-exclusive, royalty-free, worldwide, non- sublicensable, non-transferable license to use, copy, distribute, make available the software, in each case subject to the limitations, restrictions and conditions below. ## Limitations This license allows you to use the Software only to interface with the licensor's other software components, such as Netdata Agents and Netdata Cloud. Any use with replacements for these components is not permitted. ## Restrictions The Software is provided in a binary form for use by end-users. You may not reverse engineer, decompile, disassemble, or modify the Software. The Software is licensed as a single product and its component parts may not be separated. ## Patents If you or your company make any written claim that the software infringes or contributes to infringement of any patent, your license for the software granted under these terms ends immediately. If your company makes such a claim, your license ends immediately for work on behalf of your company. ## Notices You must ensure that anyone who gets a copy of the Software from you also gets a copy of these terms. ## No Other Rights These terms do not imply any licenses other than those expressly granted in these terms. ## Termination If you use the Software in violation of any of these terms, such use is not licensed, and your licenses will automatically terminate. If the licensor provides you with a notice of your violation, and you cease all violations of this license no later than 30 days after you receive that notice, your licenses will be reinstated retroactively. However, if you violate these terms after such reinstatement, any additional violation of these terms will cause your licenses to terminate automatically and permanently. ## No Warranties and No Liability The software comes "As Is", without any express or implied warranties of any kind, including but not limited to any warranties of merchantability, non-infringement, or fitness for a particular purpose. The licensor will not be liable to you for any damages arising out of these terms or the use or nature of the Software, under any kind of legal claim. ## Open Source Components The software includes certain third party open source components. Each of these components is subject to its own license. The list of open- source components used by Netdata Cloud UI is [here](https://app.netdata.cloud/3D_PARTY_LICENSES.txt). ## Definitions The "licensor" is Netdata Inc., the entity offering these terms, and the "**software**" is the Netdata Cloud UI software the licensor makes available under these terms, including any portion of it. "**you**" refers to the individual or entity agreeing to these terms. "**your company**" is any legal entity, sole proprietorship, or other kind of organization that you work for, plus all organizations that have control over, are under the control of, or are under common control with that organization. "**Control**" means ownership of substantially all the assets of an entity, or the power to direct its management and policies by vote, contract, or otherwise. Control can be direct or indirect. "**your licenses**" are all the licenses granted to you for the software under these terms. "**use**" means anything you do with the software requiring one of your licenses. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: python-sepaxml questions
On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote: > I was working on packaging sepaxml [1] when I ran into an issue > where I'd appreciate some legal guidance. The source contains .xsd > SEPA files [2] distributed by the iso committee [3] under what I > believe to be DFSG-compliant licensing [4]. > > Is this indeed adhering to the DFSG ? I don't believe that this is DFSG compliant. None of the terms I found seem to include the right to modifications. In addition the SWIFT IPR policy document does not let you sell the SWIFT standard. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: python-sepaxml questions
On Fri, 2023-06-02 at 10:42 +0800, Paul Wise wrote: > Although the material on this site is intended to be used and reproduced > freely > by all interested users under the ISO 20022 Intellectual Property Right > Policy, Here is a copy of that policy: https://www.iso20022.org/intellectual-property-rights Intellectual Property Rights Policy Organizations that contribute information to be incorporated into the ISO 20022 Financial Repository shall keep any Intellectual Property Rights (IPR) they have on this information. A contributing organization warrants that it has sufficient rights on the contributed information to have it published in the ISO 20022 Repository through the Registration Authority in accordance with the rules set in the ISO 20022 standard. To ascertain a widespread, public and uniform use of the Financial Repository information, the contributing organisation grants third parties a non-exclusive, royalty-free license to use the published information. Contributing organizations can communicate their IPR policies to the RA for publication on this website. Received IPR policies are available for download hereafter. • CBI • SWIFT Disclaimer: Although the Registration Authority has used all reasonable efforts to ensure accuracy of the contents of this website and the information published thereon, the Registration Authority assumes no liability whatsoever for any inadvertent errors or omissions that may appear thereon. Moreover, the information is provided on an "as is" basis. The Registration Authority disclaims all warranties and conditions, either express or implied, including but not limited to implied warranties of merchantability, title, non-infringement and fitness for a particular purpose. The Registration Authority shall not be liable for any direct, indirect, special or consequential damages arising out of the use of the information published on this website, even if the Registration Authority has been advised of the possibility of such damages. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: python-sepaxml questions
On Thu, 2023-06-01 at 15:54 +0200, Matthias Geiger wrote: > I was working on packaging sepaxml [1] when I ran into an issue > where I'd appreciate some legal guidance. The source contains .xsd > SEPA files [2] distributed by the iso committee [3] under what I > believe to be DFSG-compliant licensing [4]. ... > [4] https://www.iso20022.org/terms-use Here is a copy of the license for posterity: Terms of use This is the official ISO 20022 Website under a grant of authority and agreement with the ISO Central Secretariat. Warning: Although the material on this site is intended to be used and reproduced freely by all interested users under the ISO 20022 Intellectual Property Right Policy, all visitors of the site are hereby notified that the material contained on the site changes, is maintained and kept up to date frequently and should be the sole source for such information. Any replication of this site should make the statement that theirs is not the official site and that the sole source of up-to-date materials and information on ISO 20022 message standards and Repository is https://www.iso20022.org/. Disclaimer: Although the Registration Authority has used all reasonable efforts to ensure accuracy of the contents of this website and the information published thereon, the Registration Authority assumes no liability whatsoever for any inadvertent errors or omissions that may appear thereon. Moreover, the information is provided on an "as is" basis. The Registration Authority disclaims all warranties and conditions, either express or implied, including but not limited to implied warranties of merchantability, title, non-infringement and fitness for a particular purpose. Neither the Registration Authority, nor ISO nor any of its members shall be liable for any direct, indirect, special or consequential damages arising out of the use of the information published on this website, even if the Registration Authority, ISO or any of its members have been advised of the possibility of such damages. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is GeneralUser soundfont's license suitable for Debian main?
On Thu, 2023-03-23 at 14:13 +0300, undef wrote: > Also I found this soundfont in the existing Debian package minuet-data by path > /usr/share/minuet/soundfonts/GeneralUser-v1.47.sf2. [1] I suggest you bring this to the attention of minuet-data upstream and also file a bug about it in Debian if you didn't already. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is GeneralUser soundfont's license suitable for Debian main?
On Wed, 2023-03-22 at 23:47 +0300, undef wrote: > ** License of the complete work ** > You may use GeneralUser GS without restriction for your own music > creation, private or commercial. This SoundFont bank is provided to the > community free of charge. Please feel free to use it in your software > projects, and to modify the SoundFont bank or its packaging to suit your > needs. I'm not comfortable with how this mentions specific ways the soundfont can be used; "your own music creation", "in your software". What about other people's music or other people's software? This is especially problematic for collaboratively produced open source software. > ** License of contained samples ** ... > I cannot be 100% sure where all of the samples originated ... > Could you say, is "License of contained samples" allowable for Debian or > such files are fully non-allowed? I don't think this license would pass ftp-master review, there is too much uncertainty about the provenance and license of the samples. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: About debian/patches/* licenses
On Fri, 2022-12-02 at 15:59 +0900, 野崎耕平 wrote: > In researching the licenses of the dependent libraries of the programs I > created, > I noticed that some packages could be non-GPL library become GPL library by > patch. Generally Debian encourages maintainers to license their packaging under the same license as upstream, so we can contribute back. This applies to both GPL projects and non-GPL projects. > So far I have found heimdal and libsqlite packages. It might be a good idea to try and contact the patch authors for these to ask them to relicense their patches and submit them upstream. > I feel that this is an unintended license change due to the addition of the > license description for debian/*. Agreed. > * The original project is not GPL > * There is a mention in the copyright that debian/* is GPL > * Patches to the library source code exist under debian/patches This license mismatch issue should apply to all licenses not just the GPL. A good way to detect future instances of this issue and report them to package maintainers would be if the lintian tool were to automatically check for it. Please file a bug report against lintian asking for license mismatch detection to be implemented. https://www.debian.org/Bugs/Reporting -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Which parts do we need to open source if we use Debian on our robotics products
On Wed, 2022-09-21 at 12:15 +0800, Zhikang Pan wrote: > This is zhikang Pan, our company wants to use Debian on our robot > product, which will be sold. So do we need open source for the > kernel, Robot Operating System framework, and applications on this > robot product? We actually don't want open source core code because > there might be commercial benefits involved. Since you will be redistributing Debian within your robots, you will need to comply with the licenses of all the software on your robots, including both Debian and any other software you install on the robots. Most open source licenses are easy to comply with, you will need to read them to find out their individual requirements though. Every Debian source package has a copy of the copyright/license info in debian/copyright and installing Debian binary packages adds the info to the filesystem at /usr/share/doc/$packagename/copyright. One of the main aims of open source licenses is to give the owners of devices equal access to the software running on them as the owners of the software have. Everything the open source software authors can do, the owners of the devices should have the access needed to do too. If you preserve/present license info, distribute source code and allow robot owners to modify/rebuild/reinstall the software, this will put you in compliance with the vast majority of open source licenses. The most common requirement is to preserve copyright/license info and present the copyright/license info along with the product, such as in the documentation or on the screen or on the relevant website. Some licenses (such as the copyleft family of licenses, including the GNU GPL) also require that you distribute the source code and allow people to rebuild the software and reinstall it on your robots. This applies to the Linux kernel and a lot of other parts of Debian, so it is easier to just distribute all of the Debian source packages for the software you use than to distribute source only for copyleft packages. The other thing to be aware of with copyleft licenses are the requirements around derivative works. Often derivative works must be entirely licensed under the same license as the original work, or entirely licensed under licenses compatible with the original license. The boundary between a derivative work and two separate works is usually (but not always) when the two parts are in separate processes. As long as your proprietary code is in a separate process to any copyleft code and only communicates with copyleft code through well defined public interfaces, this part should not be an issue. PS: some links related to the GNU GPL copyleft licenses: https://copyleft.org/guide/ https://www.gnu.org/licenses/gpl-faq.html PS: if you modify any open source packages, especially the Linux kernel, we recommend you send your modifications back to the software projects that you modified. You can also send those modifications back to Debian so we can integrate them if the upstream projects are busy. It is also recommended that your software engineers get involved in and support Debian and the upstream projects more generally. These aren't license requirements, but are open source best practices. https://www.debian.org/intro/help#organizations -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is the APSL 2.0 DFSG-compliant?
On Thu, 2022-08-04 at 19:09 -0400, Ben Westover wrote: > Those are based on conversations that are almost a decade old, and some > things have changed since then. I just wanted a re-review of the license > in 2022 to see if the complaints from before still hold up today. What would have changed since the 2004 review of APSL 2.0? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is the APSL 2.0 DFSG-compliant?
On Thu, 2022-08-04 at 19:15 -0400, Ben Westover wrote: > Interesting, the APSL 2.0 is seen in some relatively important > packages like Chromium and QtWebEngine. 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. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Is the APSL 2.0 DFSG-compliant?
On Wed, 2022-08-03 at 23:00 -0400, Ben Westover wrote: > I was wondering if the Apple Public Source License (version 2.0) > complies with the DFSG. The Free Software Foundation considers it to be > a free software license (https://www.gnu.org/philosophy/apsl.en.html), > but I just wanted to make sure it's compatible with the DFSG. Below is > the full text of the license. I don't know about that, but I note some things: The wiki describes it as being non-free and cites two threads: https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29 https://lists.debian.org/msgid-search/20010928105424z@physics.utah.edu https://lists.debian.org/msgid-search/20040626225314.5da7f9da@firenze.linux.it There are recent challenges to it being non-free in these threads: https://lists.debian.org/msgid-search/d2119303-b470-9ebe-138e-1b57deb8c...@physik.fu-berlin.de https://lists.debian.org/msgid-search/eff03d85-7990-af04-caac-57b076cc9...@physik.fu-berlin.de There are copies of the license in Debian main: https://codesearch.debian.net/search?q=APPLE+PUBLIC+SOURCE+LICENSE=1 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Need license clarification
https://github.com/BrunoLevy/geogram wrote: > If you modify this software, you should include a notice giving the > name of the person performing the modification, the date of modification, > and the reason for such modification. The word "should" seems to imply this might be optional, since the verbatim BSD sections use "must" for the mandatory parts. The GPL has similar requirements for notices of modification. On Sat, 2022-07-30 at 12:40 -0700, Dima Kogan wrote: > The leading sections are just a vanilla 3-clause BSD license, but the > last paragraph is custom for this project. Is this non-free? Looking at the DFSG, I can't think of any conflicts between the items in it and this custom license clause. https://www.debian.org/social_contract#guidelines All that said, this is license proliferation, which isn't really good, so you might want to consider asking upstream to drop the clause. https://en.wikipedia.org/wiki/License_proliferation -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Expat-like license - DFSG-ok?
On Fri, 2022-07-15 at 18:08 +0200, Julien Puydt wrote: > * This copyright and license shall be included in all copies or > substantial portions of the Software. > > and the last line worries me a little: is it a DFSG-ok license? > I prefer asking around since I'm not really confortable with it. The requirement to include copyright and license info is in many DFSG-free licenses, including the MIT, BSD and GPL licenses. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Binary file inside fruit package
On Mon, 2022-06-27 at 08:32 -0600, Sam Hartman wrote: > Major factors in making that decision include what data is actually > available to the upstream author as well as how upstream has generally > chosen to make modifications. > If data is available to upstream but not to Debian that's a good sign > that we have a DFSG problem we cannot resolve. Indeed, since the FSD/OSD/DFSG are primarily about providing equality of access to a work between upstream and everyone who receives a work. Adding gigabytes of PGN files to Debian probably wouldn't be accepted by ftp-master, so I think we can rule out including that. I think that a link to a publicly available archive of the full set of game records should replace the large set of PGN files for Debian and everything else should be included in Debian. So add the filter rules, the reduced set of recorded chess games and the tools for converting PGN files to polyglot bin files to Debian. Since the polyglot bin file would be able to be generated solely from source and binary packages available in Debian, it should not be present in any source package and should always be generated at build time, so that Debian can prove that it can still generate the file using a rebuild. End users who want to modify it using their chess programs can use the file in the binary package. This approach would deliver the maximum possible freedom for everyone. The only people inconvenienced are folks who want to choose a different set of games; they are only inconvenienced due to the storage usage being prohibitively large for Debian. If they have enough storage they can still download the full game archive themselves and filter it too. If they don't then maybe they can send their new filter rules to the game archive and have the archive apply them and return a new game set. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: MIT + explicit "Don't sell this code." - DFSG compliant?
On Tue, 2022-03-01 at 14:52 +0100, David Given wrote: > The usual recommendations are to pick a standard OSI compliant > license and not customise it. Using a standard license makes life > easier for users because they don't have to think about the > implications --- everyone already knows what BSD licenses, GPL > licenses etc mean. My usual analogy is to suggest thinking about it > like an API. These are good recommendations. > https://choosealicense.com/ is a good resource here and gives > reasonable advice. I feel like the framing on this site is slightly incorrect, copyleft licenses are not about "sharing improvements" with developers, but about ensuring software freedom for downstream users. It is only the cultural aspects of the FLOSS community that lead to sharing improvements, not copyleft licenses. Any license that mandated sharing improvements probably would not meet the DFSG/OSD/FSD. > I'd suggest that if the author is concerned about people using their > work commercially, then the author should look at the LGPL The LGPL does not preclude using the library commercially and indeed a license that did this would not meet the DFSG/OSD/FSD. > this will make it easy to for users to use the library in another > program, but will require that if the user modifies it or base work > on it, they have to distribute the modified source. Indeed. Note the LGPL also requires that it has to be easy for users to use a modified version of LGPL library with things linked against the original version of the LGPL library, either through dynamic linking or by making it possible to re-link applications using the library. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question about Debian redistribution
On Wed, 2022-01-05 at 16:08 -0600, Navtej Bhatti wrote: > If I want Debian to boot with the stock firmware, I need a specific > partition layout that is completely foreign to UEFI systems. I don't > think this would integrate well in Linux distributions. I note that the depthcharge-tools author attempted to get it into Debian, in the process giving the standard Debian installer support for booting on Chromebook stock firmware and creating Debian installations that boot with the Chromebook stock firmware. Looking at the RFS it seems that more work is needed on the packaging. I suggest that if anyone is interested in getting this work into Debian then they could offer Alper Nebi Yasak their assistance. https://bugs.debian.org/950687 https://bugs.debian.org/950718 PS: IMO when possible stock firmware should always be overwritten with libre firmware packaged by the distro. Debian doesn't yet have a coreboot package, but there is some work in progress: https://wiki.debian.org/Firmware/Open https://bugs.debian.org/381727 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Question about Debian redistribution
Navtej Bhatti wrote: > I have a project to get Linux (specifically Debian, Ubuntu, Fedora, > and Arch) working on chromebooks. This sounds like something that should be done within those distributions themselves, rather than outside them in a separate project. General distros want to be able to support Chromebooks too. Navtej Bhatti wrote on https://milkydeveloper.github.io/cb-linux/: > Depthcharge does not have the ability of using an initramfs This is an unsupported configuration for booting Debian, and I bet for every other Linux distro, since they rely on the initramfs to contain software needed to load the rootfs. This requirement could probably be worked around by adding an initramfs post-build hook that would unpack the built initramfs to the partition (and copy the Linux kernel) that Depthcharge boots from, the unpacked initramfs would mount the real rootfs and boot as normal. The Debian installer could have images containing similarly repacked installer initramfs for use by Chromebook users. > the same forked Linux kernel as ChromeOS Debian and most other distros generally only support the mainline Linux kernel, so it would be good if those patches could get sent upstream. Eventually the installed ChromeOS kernel will get too old to run Debian userland as glibc and systemd Linux kernel requirements increase. PS: your project reminds me of the various chroot-on-Android projects: https://wiki.debian.org/ChrootOnAndroid PS: there are some Debian wiki pages about chromebooks: https://wiki.debian.org/?action=fullsearch=180=chromebook=Titles https://wiki.debian.org/?action=fullsearch=0=chromebook=180 -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Fwd: RNNoise's model and DFSG
On Sun, 2021-10-17 at 13:08 +0300, Nicholas Guriev wrote: > I still have suspicions about RNNoise and its probable non-free model. I'm the pabs3 in the HN thread you referenced. I think that RNNoise does not meet my personal standards for Free Software and also for machine learning. I think that under the Debian Deep Learning Team's Machine Learning Policy, it should be classified as a ToxicCandy Model. There isn't an official Debian position on this and there are other similar machine learning models in Debian; the threads about tesseract and Japanese text analysis come to mind for example: https://lists.debian.org/msgid-search/33417ce2bcf9b6a0efaf4771b83c6...@debian.org https://lists.debian.org/msgid-search/20190608184309.ga10...@goofy.osamu.debian.net > What is the current consensus on this library in Debian community? Several maintainers have added it to Debian so it seems accepted: mumble, chromium, qtwebengine-opensource-src, obs-studio > I already asked on debian-ai@ but nobody answered ever since. I suggest you bring this up again. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Advice on licenses with "funny" amendments
On Thu, Oct 7, 2021 at 10:48 PM Francesco Poli wrote: > What do other debian-legal participants think? While they are fairly obviously worded in plain English like an optional request, since they are part of a legal document, they are supposed to use legal language, and IANAL, so I don't know how a lawyer or the courts would interpret them. As such they are ambiguous to me, and I would personally avoid relying on legal ambiguity. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Advice needed for licensing in modus-themes
On Tue, Sep 14, 2021 at 6:51 AM Protesilaos Stavrou wrote: > As for the Front- and Back- Cover texts, my understanding is that Debian > does not consider those free because the project cannot patch them > either, correct? Correct, the cover texts aren't accepted in Debian main. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Legal status of Audacity in releases newer than Bullseye
On Mon, Jul 5, 2021 at 1:15 AM wrote: > there have been a series of changes impacting Audacity. This sounds like something that should be reported as a bug against the Debian package requesting to switch to the fork. https://www.debian.org/Bugs/Reporting -- bye, pabs https://wiki.debian.org/PaulWise
Re: Declaring license for autogenerated file (W3C)
On Fri, Jun 18, 2021 at 11:09 AM Diego M. Rodriguez wrote: > Actually, while the upstream tarball (from PyPI) does not include the > unicode.xml file, upon closer inspection upstream does include it in > their GitHub releases. If using the release for packaging is technically > viable (looks like it will be), would it be preferable from the legal side? The upstream source (from GitHub in your case) should always be preferred over the downstream packaging (on PyPI in your case). Missing files, generated files, extra cruft and other things are common problems with the downstream redistributions. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Copyright notice gives info on source files, not the packaged binaries -is that correct?
On Mon, May 10, 2021 at 2:18 PM Alexander Mazuruk wrote: > I'm writing this as I've noticed that some packages have copyright file > filled with records for source code, while the package contains binaries. Essentially all packages in Debian do this, with a couple of exceptions where the maintainer thought about this problem already. For example, for src:libicns I installed different copyright files in each binary package since the license is different for the library vs the utilities. > Shouldn't those package's COPYRIGHT contain info about final license > that those binaries are distributed with? In theory yes, in practice, no. >* yes. -> should I file a bug report for such packages? The problem is an archive-wide one that is just left unsolved, not one to be solved in individual packages. >* no -> how can I know what license a package actually has in such > case? Are there some officially recommended tools? It is in theory possible to trace the translation from source to binary, but in practice it is mostly impossible. Even if you ptrace the full build process (making it much slower), there is no general way to determine what file is generated from what other file. Fixing this would involve adding instrumentation to every compiler, build system, many different tools and probably lots of Debian packaging and upstream projects. This is a project on the order of magnitude of Bootstrappable Builds or Reproducible Builds; a multi-decade-long effort by many different people. There are potentially benefits to this beyond copyright/license info correctness for binaries too, so it would be an interesting project, but it would be hard to convince entire communities of people to work on this. In practice, shipping the relevant source for the binaries is likely enough to achieve license compliance, so shipping pedantically correct copyright/license info for the binaries is not necessary and shipping source is much easier to do, so that is what Debian tends to do. > We are trying to do start license compliance for Docker images and are a > bit stumped on how to proceed with such packages in Debian-based containers. I suggest you ship source for all the binary packages used, then add source for all the packages installed during each of their build processes. Or just ship a full Debian archive containing every source package. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#979101: Legally problematic GPL-3+ readline dependency
On Mon, Mar 29, 2021 at 1:12 AM Carlos Henrique Lima Melara wrote: > He (Alec) is the creator and main contributor to devtodo, occasionally he > had help from other as noted in the AUTHORS files, though no copyright > statements were added by these occasional contributors. For this license > change, does he have to contact everyone that sent a patch or PR, or can > he change the license as creator and main (95% of the code) contributor? If their contributions are considered copyrightable, then their permission will be needed to relicense their contributions. If their contributions are removed then the remaining codebase could be relicensed without their permission. The other suggestions by Francesco might also be good options. -- bye, pabs https://wiki.debian.org/PaulWise
Re: tomboy-ng package with non standard license.
On Mon, 2020-11-16 at 15:52 +1100, David Bannon wrote: > Hunspell to Pascal Bindings, the saga continues > > OK, I have now separated out the Hunspell 'bindings' from my hunspell > unit. Excellent, I think that concludes the legal proportion of the saga :) -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tomboy-ng package with non standard license.
On Thu, 2020-11-12 at 09:25 +1100, David Bannon wrote: > Are there any further thoughts on this topic ? It sounds like FreePascal wiki user Graham created parts of the spelling.pas file, is presumably the copyright holder (unless their employer owns it), released it without specifying a license, which means it was "all rights reserved" and then various other people modified and re-released it, in violation of copyright law (since they presumably did not have a license to do so) and eventually it ended up in the tomboy-ng project, also in violation of copyright law. There is the additional wrinkle that hunspell is licensed under the MPL and GPL licenses, presumably the header Graham started with was under the same licenses and what Graham released was clearly a derivative work of the hunspell headers, with the additional work copyright by Graham, so the result would have to comply with one of those licenses, but as far as I can tell, Graham stripped the licenses off and also did not include the "source code", in violation of both of these licenses. I think the solution here would be for you to strip out the code you copied from Graham and other's work and then repeat the h2pas process, bearing in mind the requirements of both the GPL and the MPL, the important ones here are to preserve the license, preserve copyright holder information and to preserve the "source code". What the source code is for this work depends on how you would modify the hunspell Pascal bindings. If (for example when updating to a new hunspell API) you modify the bindings by updating the C headers and then re-running h2pas, then you need to preserve the C headers in your source code alongside spelling.pas but if you would only ever modify the bindings by editing spelling.pas directly, then you can discard the C headers but you still need to use the same licenses in the hunspell bindings. In the latter case it would be a good idea to keep the bindings in a separate file so it can have a separate license header. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tomboy-ng package with non standard license.
On Sun, 2020-11-01 at 18:17 +1100, David Bannon wrote: > It is possible to build C style Libraries with FeePascal units but it > not efficient with time, space or performance in practice. Thanks for the info. > also wanting to use KControls but there is not. The KControls README and issues shows there are several users, but of course it is unlikely they would want their software in Debian. https://github.com/kryslt/KControls#important-info-for-contributors ... the package is already heavily used by me and others! https://github.com/kryslt/KControls/issues BTW: Debian's information about "vendoring" or embedded copies is here: https://wiki.debian.org/EmbeddedCopies > Just the bindings to the hunspell library. Every Lazarus install > includes a tool, h2pas, that will generate such a set of bindings from > the relevant .h files with little effort. As such, I would not expect > anyone to claim copyright to the result. Since the hunspell library headers can change over time, adding support for new functions, constants etc, that sounds like something that should be generated at build time rather than copied into the source, can Lazarus convert the installed headers into .pas at build time? Or does the generated .pas file need editing in order to work properly? Generating the bindings at build time that would enable you to more easily support other spelling libraries like nuspell too. https://nuspell.github.io/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tomboy-ng package with non standard license.
On Fri, Oct 30, 2020 at 7:24 AM David Bannon wrote: > OK folks, reminding Paul, Daniel, Tobias and Philipp of the discussion > that took place over the last couple of months about getting tomboy-ng > into the Debian repos. The issue at that stage was that, of necessity, > the source package contains some third party code called KControls, the > license of which was deemed to be unsuitable for Debian. I'd like to hear more about what "of necessity" means. I assume it is related to the comment on the static linking wiki page about FreePascal. Normally I would assume that static linking doesn't mean embedded code copies, but perhaps it also means that FreePascal doesn't support the concept of static libraries like C does (.a files)? In that case, the solution would be something like what the Rust/Golang packages in Debian do, .deb packages that contain source code, which other packages can then build-dep on and use the source code from. https://wiki.debian.org/StaticLinking#FreePascal OTOH, from my research it seems like FreePascal supports writing a dynamic library in Pascal and loading it from a Pascal or non-Pascal programs at runtime. https://wiki.freepascal.org/macOS_Dynamic_Libraries https://wiki.freepascal.org/shared_library > TK has completely changed the license to now be the BSD 3-Clause Clear > License. All (relevant) files are so marked. I have changed the license > of my code to match (to simplify things). Excellent outcome, thanks for all your work on this. > source/libnotify.pas (bindings to libnotify) is GPL2, thats documented > in debian/copyright, this is, I believe a non-issue. Correct. > source/spelling.pas, has some code that is, again, pascal libary > bindings, this time to hunspell. This code has been pasted in several > forums etc, over a number of years without attribution. As such, I > consider it public domain. It makes up only a small part of the file. I > have therefore stamped that file too as BSD Clear. As far as I know the public domain doesn't work this way. Code that is floating around is still under copyright (since that lasts a long time by default), people are just ignoring that fact and pretending they are allowed to use it. In some jurisdictions it is possible to explicitly release code into the public domain but in many that isn't possible. The CC0 license was created as a way to release things into the public domain where possible and give a very permissive license where that is not possible. https://creativecommons.org/share-your-work/public-domain/cc0 Which part of the file are you talking about here? -- bye, pabs https://wiki.debian.org/PaulWise
Re: tomboy-ng package with non standard license.
On Fri, 2020-09-25 at 09:10 +1000, David Bannon wrote: > However, I don't believe it will help. I think TK is concerned about > conventional licenses allowing someone to remove his name from the > package, ship it as its own. Near as I can tell, thats permitted if some > changes are made. Happened to me... FTR, conventional Free Software licenses don't allow removal of information about copyright holders. BSD 3-clause license requires (clause 1) retaining info about copyright holders, so does the Apache 2.0 license (clause 4a) and the GNU GPLv3 (clause 4). So I don't know enough about your situation, but I doubt that what happened to you was allowed by the license. Of course, enforcing the license against violators is costly in modern societies, especially if they are have more economic power than you. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tomboy-ng package with non standard license.
On Sat, 2020-09-12 at 15:44 +1000, David Bannon wrote: > Yes, I understand that. However, LCL Packages usually have no existence > outside the Lazarus IDE. IIRC the Lazarus IDE has a way to do command-line builds, this came up in the TomboyReborn RFS #964087. Is TomboyReborn the same thing as tomboy-ng? Do we need multiple Tomboy rewrites in Debian? > Sorry, unsure of what you mean here. Depending on how you read it (strictly or with implications), the license either does or does not allow modifications (DFSG item 3). A license that depends on how you read it is an unclear license. An unclear license is dangerous since you cannot know what the author meant to allow. If you cannot know what the author meant then you cannot be sure you are allowed to do what the unclear parts say. If you think you are allowed to modify the code but the author does not and then you modify the code, the author could sue. Personally I would be fairly uncomfortable with relying on such a license. There are such unclear licenses in packages in Debian, but usually they come with a clarification via email about the intent of the clauses. https://www.debian.org/social_contract#guidelines In a recent case of this sort of thing that I discovered, I concluded that the license was intended to cover modification, but only after one of RedHat's lawyers clarified how they dealt with this case. https://bugs.debian.org/963103 https://lists.debian.org/msgid-search/a8259f8fb4348c790076ffcaf8721ecba7c714a3.ca...@debian.org https://lists.debian.org/msgid-search/caktje6gyyvhyvo0rvo-4bslcoofr2zn3e-0sgmtegr7+j7w...@mail.gmail.com Also, based on Daniel Hakimi's mail, it sounds like the KControls author may have illegally changed the license, since there is no indication in the commit message that they got approval from all the copyright holders and looking at the git history there are a couple of other contributors other than Tomas Krysl, but OTOH their contributions don't appear to be large so maybe they aren't copyrightable. > Paul, I wonder if we can talk about the "should"s and the "must"s ? I > really have no control over TK's license. If its unacceptable, then > thats what it is. At some time in the future, its just possible i will > use RichMemo instead but until then, this approach is the only one open > to me. When it comes to unclear licenses, there is no should vs must, there is only a murky zone where you cannot know anything correctly. Which way to go really depends on the interpretation of the person reading the license. I'm not a member of the Debian ftp-master team so I cannot really predict which way they will go as the reject FAQ does not mention unclear licenses. https://ftp-master.debian.org/REJECT-FAQ.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: tomboy-ng package with non standard license.
On Sat, Sep 12, 2020 at 1:21 AM David Bannon wrote: > Unusually, I will be adding code from another repository into the Debian > Source package. Dependencies should be packaged separately, not copied into the package that depends on them. > This code is distributed as a freeware. You are free to use it as part of > your application for any purpose including freeware, commercial and > shareware applications. The origin of this source code must not be > misrepresented; you must not claim your authorship. All redistributions of > the original or modified source code must retain the original copyright > notice. The Author accepts no liability for any damage that may result from > using this code. This license contains an implicit permission to modify, but it would be much better to make it explicit. If you are going to go to the trouble of asking upstream to get permission from all the copyright holders to change the license, it would be much better to just switch to a standard license (GPL, MIT or BSD) though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: BSDish licenses without explicit modification permission
On Sat, Jul 6, 2019 at 1:55 AM Paul Wise wrote: > conserver package is in non-free because of this issue but it appears a > lot of people did not notice the lack of modification permission. ... > https://www.conserver.com/pipermail/users/2019-July/msg1.html Due to the interpretation provided by RedHat's lawyer and some clarifications provided by Conserver upstream, I have filed a request for Conserver to move from non-free to Debian main. https://bugs.debian.org/963103 -- bye, pabs https://wiki.debian.org/PaulWise
Re: BSDish licenses without explicit modification permission
On Sat, Jul 6, 2019 at 1:55 AM Paul Wise wrote: > Does anyone have any thoughts about this? I talked to one of RedHat's lawyers and they mentioned that they have dealt with this problem too and concluded that these licenses were intended to cover modification. The current wording of the initial part of the BSD license reflects an attempt to correct an earlier mistake (i.e. someone pointed out the error and Berkeley added "with or without modification"). Also note that the anti-endorsement clause implies a right to modify. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Is this BSD-3-Clause Variant DFSG-compliant?
On Sun, May 24, 2020 at 4:34 PM Eriberto Mota wrote: > For me it is not DFSG-compatible because I can't see a clause about > allowing modifications in source code. I brought this up on debian-legal a while ago: https://lists.debian.org/msgid-search/a8259f8fb4348c790076ffcaf8721ecba7c714a3.ca...@debian.org Since then I talked to one of RedHat's lawyers and they mentioned that they have dealt with this problem too and concluded that these licenses were intended to cover modification. The current wording of the initial part of the BSD license reflects an attempt to correct an earlier mistake (i.e. someone pointed out the error and Berkeley added "with or without modification"). Also note that the anti-endorsement clause implies a right to modify. -- bye, pabs https://wiki.debian.org/PaulWise
Re: UEFI Revocation List being distributed by Debian
On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote: > It also has to be optional and disabled by default because a future > dbx update may be specifically designed to stop Debian systems from > booting. No Debian user will want to install such an update. Isn't the point of these updates to fix security issues, not to block systems from booting? Presumably fwupd can be made to not install dbx updates that would block use of the shim binary currently in use. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: UEFI Revocation List being distributed by Debian
On Thu, May 7, 2020 at 3:06 AM Mario Limonciello wrote: > there are concerns if this would fit within the DFSG > > https://uefi.org/revocationlistfile Since it does not include modification permission and several restrictions on redistribution, this license is unlikely to meet the DFSG requirements. I suggest contacting the UEFI folks to ask why these restrictions are needed at all. A regular BSD/MIT license should be enough to meet their purposes. OTOH, I'm not sure if the data meets the requirements for copyrightability, in which case the license would not need to be complied with at all. https://www.debian.org/social_contract#guidelines https://en.wikipedia.org/wiki/Threshold_of_originality > Recently there has been a discussion within upstream fwupd to start including > the UEFI dbx revocation list directly with the fwupd package. This sort of data is liable to be out of date if included in the source code of fwupd, I think this should be separate to fwupd in the same way that tzdata is separate to glibc and DNSSEC root keys are separate to DNS servers and the web PKI CAs should be separate to web browsers. I suggest that fwupd download it directly from the UEFI website and update the copy within the boot firmware that way. > Furthermore, if it is not acceptable to distribute this raw data in Debian, > one of the options being considered is to programmatically re-generate a list > of invalid hashes but without the signatures in the original file. Would > that be acceptable to distribute in Debian instead? I don't think that is meaningfully different to the original files, since it would be derived from the original files? -- bye, pabs https://wiki.debian.org/PaulWise
Re: UEFI Revocation List being distributed by Debian
On Thu, May 7, 2020 at 3:06 AM Mario Limonciello wrote:
> https://uefi.org/revocationlistfile
For the benefit of the mailing list archive, here is a copy of that
page in plain text form:
UEFI Revocation List File
ACCESS TO THE UEFI REVOCATION LIST FILE
This file is used to update the Secure Boot Forbidden Signature
Database, dbx. It contains the raw bytes passed in *Data to
SetVariable()... an EFI_VARIABLE_AUTHENTICATION_2 concatenated with
the new variable value. Example usage: SetVariable( "dbx",
EFI_IMAGE_SECURITY_DATABASE_GUID, NV+BS+RT+AT+AppendWrite,
dbxUpdateDotBin_sizeInBytes, *dbxUpdateDotBin_bytes). dbxupdate.bin
already contains a Microsoft KEK signature (encoded as specified by
the UEFI spec).
UEFI Revocation List File - available for download here (last updated
on August 8, 2016).
http://www.uefi.org/sites/default/files/resources/dbxupdate.zip
UEFI Download Page Terms of Use for Microsoft Corporation's UEFI
Revocation List file ("UEFI Revocation List")
By downloading the UEFI Revocation List file ("UEFI Revocation List")
from this website (www.uefi.org), you agree to the following terms.
If you do not accept them, do not download or use the UEFI Revocation
List.
These terms do not provide you with any legal rights to any
intellectual property in any Microsoft product.
You may copy and use the UEFI Revocation List for your internal,
reference purposes and to design, develop, and test your software,
firmware or hardware, as applicable; and you may distribute the UEFI
Revocation List to end users solely as part of the distribution of an
operating system software product, or as part of the distribution of
updates to an operating system product; and you may distribute the
UEFI Revocation List to end users or through your distribution
channels solely as embodied in a firmware product or hardware product
that embodies nontrivial additional functionality. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
If you are engaged in the business of developing and commercializing
hardware products that include the UEFI standard, you may copy and use
the UEFI Revocation List for your internal, reference purposes and to
design, develop, and test your software; and you may distribute the
UEFI Revocation List end users solely as part of the distribution of
an operation system software product, or as part of the distribution
of updates to an operation system software product. Without limiting
the foregoing, copying or reproduction of the UEFI Revocation List to
any other server or location for further reproduction or
redistribution on a standalone basis is expressly prohibited.
The UEFI Revocation List is provided “as-is.” The information
contained in the UEFI Revocation List may change without notice.
Microsoft does not represent that the UEFI Revocation List is error
free and you bear the entire risk of using it. NEITHER MICROSOFT NOR
UEFI MAKES ANY WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE
UEFI REVOCATION LIST, AND MICROSOFT AND UEFI EACH EXPRESSLY DISCLAIMS
ALL OTHER EXPRESS, IMPLIED, OR STATUTORY WARRANTIES. THIS INCLUDES
THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
TITLE AND NON-INFRINGEMENT.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL
MICROSOFT OR UEFI BE LIABLE FOR ANY SPECIAL, INDIRECT OR SONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER ARISING OUT OF OR IN CONNECTION WITH
THE USE OR DISTRIBUTION OF THE UEFI REVOCATION LIST, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION.
YOU AGREE TO RELEASE MICROSOFT (INCLUDING ITS AFFLIATES, CONTRACTORS,
AGENTS, EMPLOYEES, LICENSEES AND ASSIGNEES) AND UEFI (INCLUDING ITS
AFFILIATES, CONTRACTORS, AGENTS, EMPLOYEES, LICENSEES AND SUCCESSORS)
FROM ANY AND ALL CLAIMS OR LIABILITY ARISING OUT OF YOUR USE OR
DISTRIBUTION OF THE UEFI REVOCATION LIST AND ANY RELATED INFORMATION.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: FreeMedForms projet
On Sat, 2020-01-11 at 17:08 +0100, Eric Maeker wrote: > I'm really sorry, but I can not answer to everyone and all your > questions. I feel a bit flooded. Sorry about that, I hope one final email is not too much. > About the website and the DFSG compliance, please consider that the > website translations are out of sync. FreeMedForms integrates now one > extra content : code128.ttf, that is not clearly licenced ( > https://grandzebu.net/informatique/codbar/code128.ttf / > https://www.dafont.com/fr/code-128.font). This is required for all > user who wants to print bar codes (see > https://freemedforms.com/fr/news/versions/110#codes_barres)... This > is why the package is mentioned "not 100% DSFG compatible". But may > be we made an error (that anyone can correct) ? According to the font metadata and the font website, the Code 128 font is licensed under the GPL so is probably free. Since it is a separate project to yours though, it should be packaged separately in Debian and your package should then depend on it. https://grandzebu.net/informatique/codbar-en/code128.htm -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: FreeMedForms projet
On Fri, 2020-01-10 at 17:34 +0100, Eric Maeker wrote: > We know that at least two forks exists (this is what our private data > server's log tells us). We do not receive any patch, invitation to > git repos, or any kind of official informations or queries. Having multiple forks and having folks not bother to send feedback is normal in Free Software, especially for software that uses github. There was a blog post about this recently but I'm unable to find it. I would not worry about there being forks available, instead focus on the feedback that you do get and try to build a community around the code. > we decide that our git repository will not be freely accessible. I encourage you to consider changing back to an open repository; as Andreas has pointed out, this is already affecting other potential contributors and affecting potential redistribution of your software. > Approval does only concern ... the ability to join the project as > member (coder, tester, communication manager...). This is normally how things work, you build up trust through your contributions to a project and then they invite you to join. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: FreeMedForms projet
On Fri, 2020-01-10 at 13:01 +0100, Eric Maeker wrote: > Sounds like we are travelling to "contrib" or "non-free" package ? Or > may be "non-debian" ? The section of Debian a package is added to depends solely on the DFSG compliance of the software (freely licensed and released source code). Whether software is classed as non-Debian depends on the quality of the software and on Debian having permission to redistribute the software. https://www.debian.org/social_contract#guidelines It sounds like your software is probably DFSG compliant but that you have some organisational issues that are not best practice for a proper Free Software project. While I would encourage you to fix those issues, they are by no means a requirement for your software to enter Debian. The bigger problem for entering Debian is what Andreas mentions, that the software uses Qt4 instead of Qt5. Once you have released a new version that uses Qt5 it could potentially enter Debian. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: FreeMedForms projet
On Fri, Jan 10, 2020 at 2:02 AM Paul Wise wrote: > I don't like this, people seeking source code should not have to get > approval first. That said, I note that the source code is available > directly from the site without approval. I missed seeing that the git repository containing the source is private. I don't like that, development versions and the development process should be public and allow external people to participate. -- bye, pabs https://wiki.debian.org/PaulWise
Re: FreeMedForms projet
On Thu, Jan 9, 2020 at 8:00 PM Eric Maeker wrote: > Free Source code is provided to any demander approved by the NPO, code > licence is still the same. I don't like this, people seeking source code should not have to get approval first. That said, I note that the source code is available directly from the site without approval. > But, the code documentation is only reserved to approved developers by this > NPO. I definitely don't like this, it would be much better to publish the code documentation to everyone under a free license. > We do encourage new dev to apply to our NPO and to sign a CLA (which is still > a draft piece of text actually). I don't like this either, it would be much better for devs to release their contributions under the same license that you do, then you can incorporate their changes, preserving their copyright over their changes and passing on their license to you to downstream users. So the whole of the software is then owned by a variety of copyright holders, each of whom also have to abide by the license given to them by the other contributors. The license on the software then cannot be changed without contributor consensus, so it becomes a much more solid project from a user perspective. Single-owner projects are much more easy to turn proprietary. http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html > The problem is that FreeMedForms EHR needs access to private data Could you explain why this data needs to be private? It would be much better to release it publicly under a free license. > The private data are only available to paying partners to the NPO. Is this the only form of income that the NPO has available to it? It sounds like the NPO is seeking what is called an "Open Core" business model, where the core part of the project is public and freely licensed but addons are proprietary. The incentives here can be quite perverse, often companies seek to prevent outside contributions to the core or even remove features from the core so that more people start paying them for the proprietary addons. So I encourage you to consider alternative income streams. I think the best option for the would be to consult with as many of the practices, clinics, hospitals and emergency departments that you know about that use the software and find out the best way for the NPO to have enough resources to continue development consistent with the interests of the community of folks who use the software. Examples of potential income models could include: large grants/sponsorships that cover development and other costs, a membership subscriber base that pays for all maintenance and development costs, or more of a crowd-funding model where folks interested in specific features pay for their development, or a community of consultants that do all work on the project as requested by their customers or possibly a combination of these and other options. > Forks trie to access our private data using the open sourced server protocol > (query to a php script). I would suggest to just make the data public and under a free license, but if you don't want to do that, the way to go would be to setup an e-commerce site where people have to pay before they can download the private data and then have in the software a way to load the locally saved data that has been downloaded from the site. I believe there are some freely licensed e-commerce tools in Debian and the consultants that offer support for Debian in your area might be able to help with finding, installing and configuring them. https://www.debian.org/consultants/ https://lists.debian.org/debian-consultants/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: BSD license + should
On Mon, Nov 25, 2019 at 3:40 AM Michael Banck wrote: > (please CC me on replies) Done. > |4. Every use of I'm not sure copyright restricts mere use of software so this clause might be unenforceable? > |should acknowledge the following publication: It sounds like license drafters should not use the word "should" because of its legal ambiguity :) https://legal-dictionary.thefreedictionary.com/should https://www.faa.gov/about/initiatives/plain_language/articles/mandatory/ https://definitions.uslegal.com/s/shall/ > I am wondering whether this is DFSG-free as this fourth clause is a > should, not a must (and it is good academic practise to cite anyway)? It all rests on the interpretation of "should". I lean towards interpreting should as optional but I lean towards treating ambiguity as non-free :) > If not, can you suggest a rephrasing of this clause that would make it > DFSG-free, but be similar in spirit (i.e. nudge the user to cite the > package if they publish results based on its use)? No matter what the DFSG status is, I would suggest rewording and moving the clause to the software description or documentation, simply because people using the software aren't necessarily likely to be reading the license, especially users of redistributors like Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: MIBs from RFCs
On Thu, Oct 3, 2019 at 6:45 AM Craig Small wrote: > I'm the Debian Developer for net-snmp. This package includes MIB files that > translate human-readable SNMP parameters into numbers computers can > understand. Sort of like a DNS hosts file for SNMP. These sound like things that should not be copyrightable, I guess due to the inclusion of descriptions that they are though. > * MIB files created from RFCs dated March 2005 to 10 November 2008 might be > OK, depending on what people think of the clauses in 3.3.C in RFC 3978[5] This RFC appears to be only about what contributors to RFCs grant to the IETF, not the general public? -- bye, pabs https://wiki.debian.org/PaulWise
BSDish licenses without explicit modification permission
Hi all, There are several packages (including GCC and Linux) in Debian that contain files released under several different BSDish licenses that are missing the explicit modification permission. Many of these files contain comments indicating that they likely have been modified. I think that these files are non-free and that their license is being violated by both Debian and the corresponding upstream projects. The conserver package is in non-free because of this issue but it appears a lot of people did not notice the lack of modification permission. Does anyone have any thoughts about this? * Is there some aspect of the situation that I have missed? * Should we ignore it as we seem to have done since 1989? * Should we add a lintian warning about this? * Should we file lots of RC bugs about this? * Should I be discussing this elsewhere? https://codesearch.debian.net/search?perpkg=1=Redistribution+and+use+in+source+and+binary+forms+%28are%7Cis%29+permitted https://www.conserver.com/pipermail/users/2019-July/msg1.html Examples of the licenses: --- Redistribution and use in source and binary forms are permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other materials related to such distribution and use acknowledge that the software was developed by the University of California, Berkeley. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. --- Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of California at Berkeley. The name of the University may not be used to endorse or promote products derived from this software without specific written prior permission. This software is provided ``as is'' without express or implied warranty. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Missing source in firefox-esr: EME module
On Sat, Jul 6, 2019 at 5:41 AM Francesco Poli wrote: > Then, the strategy could be similar to [flashplugin-nonfree]: > a package (in Debian contrib) that automatically downloads and install > the non-free module from the upstream distributor, and installs it... IIRC the Debian maintainers of Firefox are now Mozilla employees. I speculate that Mozilla has a contract with Google about how they bring Widevine to Firefox users. I speculate that a downloader package might not comply with that contract. I speculate that Mozilla would not be willing to deviate from that contract for Firefox upstream since Firefox users worldwide would lose access to Widevine and to content they expect to work. I speculate that, due to the contract, modifying Firefox in Debian to use a downloader package for Widevine might not be allowed under Firefox's trademark license. That said, it sounds like a download package could divert the Firefox binaries to a script that sets the MOZ_GMP_PATH environment variable to the location for Widevine. That might conflict with the gcm-sources I mentioned in an earlier mail though, depends on what order the environment variable and the gcm-sources are loaded in. https://wiki.mozilla.org/GeckoMediaPlugins -- bye, pabs https://wiki.debian.org/PaulWise
Re: Missing source in firefox-esr: EME module
On Wed, Jul 3, 2019 at 9:38 AM Mihai Moldovan wrote:
> I wonder why no one brought it up yet, but here we go: IMHO, downloading
> pre-defined proprietary software should completely be disabled/removed in
> Firefox and the proprietary Widevine module be properly packaged as a package
> in non-free - with at most a Suggests dependency in the firefox(-esr)
> package. The nag bar might tell people to install this additional package.
The Widevine license does not allow redistribution.
https://sources.debian.org/src/firefox-esr/60.7.2esr-1/toolkit/content/gmp-sources/widevinecdm.json
"Linux_x86_64-gcc3": {
"fileUrl":
"https://redirector.gvt1.com/edgedl/widevine-cdm/4.10.1196.0-linux-x64.zip;,
LICENSE.txt from the zip contains this:
"Google Inc. and its affiliates ("Google") own all legal right, title and
interest in and to the content decryption module software ("Software") and
related documentation, including any intellectual property rights in the
Software. You may not use, modify, sell, or otherwise distribute the Software
without a separate license agreement with Google. The Software is not open
source software.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: Custom license conditions and grant for Wordplay package
On Sun, Apr 28, 2019 at 12:40 PM Moshe Piekarski wrote: > The copyright holder made a statement on Facebook chat that he considers > the code to be in the public domain. Is that enough for me to consider > it such? Unfortunately dedicating code to the public domain is not feasible world-wide so a license is needed for areas where it does not exist or cannot be contributed to before death. The Creative Commons Zero (CC0) license aims to come as close as possible to a world-wide public domain dedication so the copyright holder might want to use that instead. Personally I would choose a copyleft license instead like the GNU General Public License so that people using the software are likely to also get a buildable copy of the code. https://creativecommons.org/share-your-work/public-domain/cc0/ https://creativecommons.org/choose/zero/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Free Software Guidelines Question
On Thu, Apr 4, 2019 at 2:15 PM Wade Pinkston wrote: > My company manufactures high-end IR sensors, IR Quadrant detectors, IR PSDs, > and associated electronics. ... > Is there a way to release a free software package for Debian, but maintain IP > rights to it? >From the perspective of your end users, I expect the best option would be a standard interface that works with all the hardware of this kind made by your company and its competitors and a library of FLOSS code that supports that interface. Failing that, a library of FLOSS code that abstracts all the vendor-specific interfaces would be acceptable but more effort to maintain. New entrants would likely have to either copy one of the other existing interfaces or add their own interface to the library. That perspective leads to an ecosystem of vendors focussing on various niches based on price, quality etc rather than one vendor monopolising most of the market through lock-in. That might not be desirable to your company, but if it makes things easier for your potential end users, it might end up growing the market. At some point you might find that your end users will, since they are technical folks, reverse engineer your code and that of your competitors and write the second solution I suggested above. Then you might end up spending time and money maintaining code that none of your end users are using. -- bye, pabs https://wiki.debian.org/PaulWise
Re: FRR package in Debian violates the GPL
On Mon, Mar 18, 2019 at 7:36 PM David Lamparter wrote: > Huh. This is slightly surprising to me, I thought binaries always need > a license attached too. But now that I think about it, indeed I don't > even know how I would get a license "label" for a random binary .deb... > (as you say, the shipped copyright file documents its sources...) There is a debhelper feature that lets you put different copyright files into each binary package. I've used it in the past where a utils package had a different license to the library package. We certainly don't systematically do this, as there is simply no way to determine what file in the binary package is derived from what file(s) in the source package and what command produced them. -- bye, pabs https://wiki.debian.org/PaulWise
Re: redistribution of the ARIN TAL
On Thu, Feb 28, 2019 at 11:17 AM Paul Wise wrote: > On Thu, Feb 28, 2019 at 6:36 AM Marco d'Itri wrote: > > > Contractual law would apply to entities downloading the TAL from the > > ARIN web site, but I cannot see how they could apply to a Debian > > maintainer who received anonymously the TAL by email... > > IANAL, so I wonder how one could be subject to a contract when > downloading a file that doesn't even require a click-through agreement > form? So far we have come up with possible DMCA & contractual law issues related to redistributing this file. I think we should get actual lawyers on the case to figure this out and I suggest you contact the DPL in order to proceed with that, IIRC Debian has access to lawyers at Conservancy or the SFLC, I forget which. -- bye, pabs https://wiki.debian.org/PaulWise
Re: redistribution of the ARIN TAL
On Thu, Feb 28, 2019 at 6:36 AM Marco d'Itri wrote: > Contractual law would apply to entities downloading the TAL from the > ARIN web site, but I cannot see how they could apply to a Debian > maintainer who received anonymously the TAL by email... IANAL, so I wonder how one could be subject to a contract when downloading a file that doesn't even require a click-through agreement form? -- bye, pabs https://wiki.debian.org/PaulWise
Re: redistribution of the ARIN TAL
iction, then to the extent necessary to make such provision and/or this Agreement legal, valid, or otherwise enforceable, such provision will be limited, construed, or severed and deleted from this Agreement, and the remaining portion of such provision and the remaining other provisions hereof will survive, remain in full force and effect, and continue to be binding, and will be interpreted to give effect to the intention of the parties insofar as possible. -- bye, pabs https://wiki.debian.org/PaulWise On Thu, Feb 28, 2019 at 6:36 AM Marco d'Itri wrote: > > (Please Cc me on replies.) > > On Feb 16, Paul Wise wrote: > > > > And they are arguing that people cannot download this file from > > > a well-known location without first agreeing to some conditions. > > Do you have any info on the conditions? > Here they are: > https://www.arin.net/resources/rpki/tal.html > > > IANAL, but it doesn't seem copyrightable to me. I guess there could be > > other laws affecting this though. > Contractual law would apply to entities downloading the TAL from the > ARIN web site, but I cannot see how they could apply to a Debian > maintainer who received anonymously the TAL by email... > > Some background: > https://pc.nanog.org/static/published/meetings/NANOG75/1900/20190219_Yoo_Rpki_Legal_Barriers_v1.pdf > > -- > ciao, > Marco -- bye, pabs https://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/
Re: redistribution of the ARIN TAL
On Fri, Feb 15, 2019 at 7:00 PM Marco d'Itri wrote: > And they are arguing that people cannot download this file from > a well-known location without first agreeing to some conditions. Do you have any info on the conditions? > Does everybody agree that this is bullshit and that we can distribute > this data in Debian packages as much as we like? IANAL, but it doesn't seem copyrightable to me. I guess there could be other laws affecting this though. > (Please Cc: me on replies.) Done. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Hacking License
On Tue, Dec 11, 2018 at 1:45 AM Paul Jakma wrote: > There is an issue with the GPL style copyleft of abuse by corporates. In > particular, abusing the ability to discharge source distribution > privately, and then using various forms of side-contracts to > (indirectly) "discourage" recipients from exercising their GPL rights. > > As this all happens in private, it makes it hard for copyright holders > to take action. It can be hard to gather basic facts (e.g. the side > contracts). The recipients - who are potentially having their GPL > rights impinged - are not necessarily willing to even tell the > copyright holders about this, never mind co-operate. Etc. If you are talking about grsecurity, the contract from 2017 was on their website, is now on archive.org but the current version is not public: https://web.archive.org/web/20170805231029/https://grsecurity.net/agree/agreement.php https://grsecurity.net/agree/agreement.php https://grsecurity.net/agree/agreement_faq.php > Then there's the more general issue that the AGPL doesn't really work > for non-interactive distributed-system software, should you want your > distributed-system software to have its source be made available to > anyone operating other bits (or implementations of) the distributed > system. I think that would depend on the protocol used and that many of them would have room for extensions that could include instructions for obtaining source code. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Compatibility of GPLv2 and Apache v2 (OpenSSL again)
On Sat, Dec 8, 2018 at 2:53 AM Sebastian Andrzej Siewior wrote: > On December 7, 2018 6:34:39 PM UTC, Francesco Poli wrote: > > > >It was a long ongoing process. > >The news is that it seems to have finally come to an end... This appears to be the commit where it happened: https://github.com/openssl/openssl/commit/151333164ece49fdba3fe5c4bbdccd9ae66d Subsequent commits changed mention of the license in various locations. > Yes. It is okay for "GPLv2 or later" but I'm curious if it is still okay for > GPLv2 only projects with the exception I mentioned to link against libssl > once it is Apache v2 licensed. It depends on the wording of the particular exception used, but IIRC the standard one allows linking with OpenSSL regardless of license. -- bye, pabs https://wiki.debian.org/PaulWise http://bonedaddy.net/pabs3/
Re: [Fedora-legal-list] The license of OpenMotif (Open Group Public License)
On Sat, Oct 27, 2018 at 3:36 AM Florian Weimer wrote: > Is it necessary that an open source license must allow porting to > proprietary systems? I don't think so today. But based on what I > found out about the OpenMotif license, people actually thought that > back then. This surprises me. Has this changed? If I am stuck on a proprietary platform because the available libre platforms do not support my hardware (or for other reasons), I don't think it is appropriate to disconnect me from the FLOSS world and force me to only use proprietary software on top of the proprietary platform. That would only *reduce* the amount of software freedom in the universe, not increase it. As I understand it, the system library exception is a way to work around the license incompatibility between copyleft projects and the proprietary platforms they might be able to run on, in order to *increase* the places Free Software can be used. -- bye, pabs https://wiki.debian.org/PaulWise
Re: MongoDB Server Side Public License, Version 1 (SSPL v1)
On Tue, Oct 16, 2018 at 10:04 PM Paul Wise wrote: > I noticed MongoDB are pushing a new license that tries to be like the > AGPL but more expansive in what software it covers and more expansive > in what activities trigger the clauses within it. These changes seem to be designed to create an unfair advantage for their proprietary MongoDB Atlas tool for cloud hosting of MongoDB. They are essentially trying to force one of a few possible actions out of Amazon: 1) publish part of its proprietary infrastructure 2) stop providing mongodb 3) pay mongodb for a different license 4) fork it and continue providing an old version 5) purchase MongoDB Inc and use it against MS/Google -- bye, pabs https://wiki.debian.org/PaulWise
MongoDB Server Side Public License, Version 1 (SSPL v1)
Hi all, I noticed MongoDB are pushing a new license that tries to be like the AGPL but more expansive in what software it covers and more expansive in what activities trigger the clauses within it. They have posted to the OSI license review mailing list: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html For your convenience, I have included a full copy of the mail below, which includes a justification section as well as full license terms. From: Eliot Horowitz Date: Tue Oct 16 13:03:02 UTC 2018 Subject: [License-review] Approval: Server Side Public License, Version 1 (SSPL v1) This license is being submitted for approval by its steward, MongoDB, Inc. Rationale: Clearly state rationale for a new license Today, Affero GPL 3.0 uses the broadest scope of copyleft, among the commonly used open source licenses. MongoDB has been making its database software available under AGPL for many years now. AGPL was written to close the “SaaS loophole” by requiring those offering software as a service to make source code available. However, for some kinds of software that is popular for cloud deployment, AGPL has not resulted in sufficient legal incentives for some of the largest users of infrastructure software, such as international cloud providers, to participate in the community. Many open source developers are struggling with a similar reality, and some of our competitors have moved to proprietary licensing models. The alternative, to be blunt, is for us to be that last standing unpaid open source database developer for cloud providers, who sell access to our software for significant fees, but may not adequately contribute back to our community. Faced with the choice of moving to a proprietary model by applying licensing restrictions to our software, we prefer instead to continue using the copyleft model to create a workable incentive for cloud providers to share with the rest of the community. The Remote Network Interaction provision of AGPL has not provided enough incentive to change the behavior of cloud providers for several reasons: ·It is not clear that it extends to software that controls the functionality of the database software, such as management, automation, monitoring, storage and hosting software. ·It only applies if the software is modified, and the definition of a modification references back to copyright principles that are not settled law. We have addressed each of these concerns in the Server Side Public License, by (i) clarifying that the copyleft obligation applies to those who make the functionality of the software available to third parties, (ii) expressly including management, automation, monitoring, storage and hosting software that is integrated with the functionality of the database software, and (iii) removing the modification requirement. Distinguish: Compare to and contrast with the most similar OSI-approved license(s) This license is based on GPL 3.0, with the addition of a new Section 13 (Offering the Program as a Service) and other minor conforming changes. The text of the new Section 13 appears below, and we have submitted the entire document in plain text as well. “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version. “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.” Legal review: Describe any legal review the license has been through, and provide results of any legal analysis if available. This new clause for the license was drafted with input from the business and legal team at MongoDB, Inc., with assistance from outside counsel Heather Meeker, and with input from certain outside community members. Its drafting has been the subject of significant internal discussion, including as to its compliance with the requirements of the Open Source Definition, and the efficacy of
Re: dual licensed + build generated png (GPL-2+ or CC-BY-SA-4.0+)
On Fri, Sep 14, 2018 at 2:30 PM, Samuel Henrique wrote: > Looking at the files of the software, Example of that is that some > files like .sh ones are GPL-2+ and some .svg are CC-BY-SA-4.0+. > > I'm assuming this can be solved by: > > Files: * > Copyright: YEARS NAME > License: GPL-2+ > > Files: *.svg > Copyright: YEARS NAME > License: CC-BY-SA-4.0+ Correct. > Although part of the build process consists of generating some png > files from the svg ones, and by using the above I would be licensing > them as GPL-2+, so... debian/copyright only documents the license of the source, not any license for build products. If you want to document the license for the contents of the binary package, you can add a debian/foobinpkg.copyright that represents the built binary package. There are no standards in Debian for what binary package copyright/license information should look like. Generally Debian does not care about accurately representing the copyright information for binary packages and just copies the source package copyright file into the binary package. > Considering that the d/copyright above is ok, there's still one thing > missing, upstream don't explicitly mentions any license for png files, > so am I correct that as long as we respect the svg license, we can > chose the one we want to for the pngs and upstream doesn't have to > care about that? And in that case, the license would obviously be the > same as of the svg. I assume that the png files are the result of mechanical conversion from svg. If so the SVG copyright holders and license are transferred to the PNG files. So the SVG and PNG files are CC-BY-SA-4.0+ and IIRC CC-SA licenses do not allow relicensing (similar to the GPL). > Oh, there is another thing, upstream does not mention its name on any > of the svg files, it don't even mention the proper license on the > file[2], the only place where there's [kinda] clearly attribution of > license to svg files is on the README.md[3]. This is not true. I only looked at one file and found a license declaration: ... http://creativecommons.org/licenses/by-sa/4.0/; /> https://salsa.debian.org/debian/adapta-gtk-theme/raw/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/wm/asset/assets-metacity/button_close.svg > Considering only this aspect, I would like advice on what I should > suggest upstream to change in order to explicitly license its svgs (I > would be glad to see examples on other softwares), it looks like > upstream could be using other RDF fields on the svg for that[4]. They seem to be using that RDF for the SVG you linked to: ... http://creativecommons.org/licenses/by-sa/4.0/; />https://creativecommons.org/choose/#metadata https://salsa.debian.org/debian/adapta-gtk-theme/raw/6aa1f96171de5c8a3a45795c5153ade4e995a3fa/wm/asset/assets-xfwm/hide-inactive.svg > And now considering that upstream still didn't made this changes, I > could upload the package to Debian, right? I understand that the > license could be more explicit but having it that way on README.md and > on the other files seems like enough for a first upload, what do you > think? I think that if the RDF license information mentioned above was actually missing and you made sure to comment on that and the note in the README in debian/copyright, ftp-master would probably accept it. -- bye, pabs https://wiki.debian.org/PaulWise
Re: DFSG compatibility of OASIS Open Document Format schema licenses
On Mon, Aug 20, 2018 at 2:58 AM, Rob Browning wrote: > # However, this document itself may not be modified in any way This part is fairly clearly non-free. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Font-Awesome 5 no build system DFSG compatibility
On Thu, Jul 19, 2018 at 6:38 AM, Alexis Murzeau wrote: > I have a question regarding the font-awesome v5 [0] and the DFSG. > > Since version 5, font-awesome upstream repository contains both source > files and generated files but not the build system [1]. I would like to point out here that the build system exists, but is both secret and proprietary, because upstream have a proprietary version of the fonts that they are selling: "Because Font Awesome sales a Pro version our build system will for the time being remain private (we've got all of our for-pay icons in there)." > So it is not possible to regenerate generated files from source files > without guessing which file are generated and which are sources. > I've asked upstream about that [2] (but no response yet). Personally, I don't consider things proper Free Software unless they are built using an automatic, repeatable and reproducible/deterministic mechanism from freely licensed source using only tools that are themselves proper Free Software. Modification of that source also must be possible using only tools that are themselves proper Free Software. In addition I don't accept something as proper Free Software if upstream has created one form of data from another, truer, source form, thrown away the source form (or never saved it) and then distributes only the prebuilt form, which they use as if it were source but in truth intend to keep it read-only. Debian's standards are somewhat lower, we require source be available and DFSG-freely licensed. In addition the ftp-master policy (not sure about the rest of Debian) has a policy that packages be buildable (but not necessarily built) using tools only in main. We don't yet require an automated build process, we don't yet require rebuilding from source by Debian, we don't yet require reproducible/deterministic builds, we don't have a policy about tools to modify the source, we err on the side of taking upstream's word for it about source and we don't have any policy about what counts as proper source. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Logos in Dask documentation
On Wed, Jun 6, 2018 at 1:01 PM, Diane Trout wrote: > Several logos are linked to in the Dask documentation, and > I was wondering how I should resolve them. Are they present in the source package or are you concerned about privacy violations from browsers downloading remote images when loading the local documentation? In either case, having upstream remove the logos and replace them with plain text will solve the issue. > Here' is the list of logos and what I found for their terms of use. I wouldn't recommend it, but one other solution is to just ignore the logos and their licensing and keep them as-is. This is what Debian's firefox packages do for the search engine logos. -- bye, pabs https://wiki.debian.org/PaulWise
Re: legal implications of linking to libssl/openssl
On Sun, May 6, 2018 at 8:39 AM, Sandro Tosi wrote: > I know there were issues linking with openssl, but i dont know if it's > still accurate, so i would like to ask the list: is it ok from a legal pov > to switch from gnutls to openssl for transmission? The situation is currently unchanged, the OpenSSL license is incompatible with the GNU GPL family of licenses and an exception is needed to allow combining code under those licenses and OpenSSL in the same work. https://people.gnome.org/~markmc/openssl-and-the-gpl.html In the (very) near future, OpenSSL is planning to switch to the Apache 2 license, which is compatible with GPLv3 but not GPLv2. So code under GPLv3-only, GPLv3+ and GPLv2+ licenses will be compatible with the new license but GPLv2-only code will require an exception as before. The standard exception used for the current license looks like it will also be fine under the new license. https://www.openssl.org/blog/blog/2017/03/22/license/ https://license.openssl.org/ https://www.openssl.org/blog/blog/2018/03/01/last-license/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: clearing the use of a QP solver, and example code posted to a mailing list
On Wed, May 2, 2018 at 10:08 PM, Stephen Sinclair wrote: > I am preparing a package for Siconos: http://siconos.gforge.inria.fr/ > > This software contains several 3rd-party sources used for numerical > solutions etc. In general, Debian and other distributions do not like it when projects embed copies of their dependencies or other 3rd-party sources in their own source repository or tarballs. Please talk to upstream about removing them, or only adding them to their binary packages. https://wiki.debian.org/EmbeddedCodeCopies > with the exception of the QP solver, ql0001.f. As far as I > can tell this comes originally from > http://www.klaus-schittkowski.de/ql.htm and, therefore, it has a > non-DSFG license (free for educational use), which, as an upstream > contributor, I have documented here: > https://github.com/siconos/siconos/blob/master/externals/optim_misc/copyright I agree with your assessment that this is not DFSG-free. Since the QL author is easily contactable you might want to ask for relicensing to something DFSG-free, like GPLv3+. > [1] > https://github.com/ScilabOrg/scilab/blob/master/scilab/modules/optimization/src/fortran/ql0001.f I quote the license from that URL for posterity: c NOTICE c c 1. The routines contained in this file are due to Prof. K.Schittkowski c of the University of Bayreuth, Germany (modification of routines c due to Prof. MJD Powell at the University of Cambridge). They can c be freely distributed. c c 2. A minor modification was performed at the University of Maryland. c It is marked in the code by "c umd". c c A.L. Tits and J.L. Zhou c University of Maryland Personally, I do not believe this text constitutes a DFSG-free license grant. > Now, due to this I have made sure that Siconos compiles and runs > without this file, but it implies significantly disabling the software > as the QP solver is important to its functionality. Given that this > code (ql0001.f) is just an updated (and slightly modified by Siconos > authors) version of the code found in Scilab [1], already packaged in > Debian, I am wondering whether it really needs to be removed from the > archive for the Siconos package to be DSFG-friendly. The authors of > Siconos consider it free specifically because it is already used by > Scilab, but I cannot tell whether the version in Scilab was released > under a different license. It is also hard to tell since the upstream > author does not host the source code as far as I can tell, but only a > usage example and a license. I believe that Scilab folks didn't consider the implications of the original licensing when including the file into Scilab, nor when modifying it. I don't think the code can be considered DFSG-free. I think it should be removed from both Scilab and Siconos upstream. I don't believe the license above even allows distributing copies of the file. It allows transferring the code to someone else (making a copy and deleting your copy), but not giving out copies. > A second issue: one header file [2] used in the project contains code > that was taken from a mailing list post [3] from 2008, and does not > have a license. However, it consists merely of a function > demonstrating how to use the lu_factorize function from BOOST uBLAS to > compute a determinant. Although I have emailed the original author, > it was posted many years ago, and I have not received a reply after a > few weeks. It seems silly to worry about a license for, basically, > example code posted to a list with the clear intention of being used, > but the function is not 100% trivial. Does fair use or something play > in here? How to deal with this? Debian is distributed in locations where fair use does not exist so we cannot rely on fair use defences to copyright infringement. I'm not sure if the function can be considered copyrightable but I think the best approach here would be to delete the function from the code and then have someone reimplement it. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Are register names and locations under copyright?
On Thu, Jan 11, 2018 at 5:13 PM, Philipp Klaus Krause wrote: > The source file would be pic16f1320.inc, which is part of gputils (which > is packaged in Debian, the .inc file gets installed to > /usr/share/gputils/header/pic16f1320.inc). Hmm, I'm not sure these files should be in Debian main, a lot of them say "Copyright 1999-2014 Microchip Technology, All rights reserved" without specifying any license. > For the future (i.e. post 3.7.0 release), SDCC plans to no longer ship > the .h files for PIC in the tarball. Instead they would be generated at > build-time from the .inc source files in the installed gputils. That sounds like a reasonable plan, except it runs into the above problem. The current situation also runs into that problem though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Are register names and locations under copyright?
On Wed, Jan 10, 2018 at 9:11 PM, Philipp Klaus Krause wrote: > Problem: Hardware vendors want to impose non-free terms on the header > files (via a copyright claim on the files that the headers were > generated from). I think we need more details. Are the files the headers were generated from publicly available? Do they list any copyright/license information? > Are the register names and locations under copyright? Is the generated > header file under copyright? If yes, who are the owners of the > copyright? Does the situation vary across jurisdictions? > > SDCC developers are currently unsure about this. I would strongly suggest SDCC developers obtain legal advice on this topic, especially in light of Oracle v Google. Software Freedom Conservancy may be able to help with this: https://sfconservancy.org/ > For some targets, SDCC already has such files (e.g. > https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/include/pic16/pic18f1320.h). I note this in the file you mention: * This file is generated automatically by the cinc2h.pl, 2016-04-13 17:23:42 UTC. In addition to the hardware vendors copyright issue, clearly this header is not the source form under the GPL's "preferred form for modification" requirements, nor under DFSG item 2 and therefore Debian cannot distribute it without the source. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Are register names and locations under copyright?
On Thu, Jan 11, 2018 at 1:13 AM, Milan Kupcevic wrote: > It is widely held in the IT industry, and in technical industries in > general, that interface descriptions and definitions can not be legally > protected as that would stop development and production of compatible > replacement parts by third parties. This widely held belief could be > changed by a court decision or a new law in any given jurisdiction at > any time. As we saw in the Oracle v Google case over the Java APIs, this widely held belief is not necessarily correct. https://en.wikipedia.org/wiki/Oracle_America%2C_Inc._v._Google%2C_Inc. The result of the case was that the Java APIs are copyrightable, but that Google's use of them was fair use. Unfortunately fair use is not internationally widespread and not the same everywhere it is implemented. https://en.wikipedia.org/wiki/Fair_use#Influence_internationally -- bye, pabs https://wiki.debian.org/PaulWise
Re: Inquire about ECCN for Debian GNU/Linux and how to deal with revised EAR
On Thu, 2017-12-21 at 17:22 +0900, Ikeda Yuichi wrote: > Thank you for reply, it has helped me to discuss with experts. If you reach a conclusion, please let us know the results. > I have shared this announcements to some engineers > who has related work about Linux and embedded systems. Excellent, thank you for that. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Inquire about ECCN for Debian GNU/Linux and how to deal with revised EAR
On Tue, Dec 12, 2017 at 8:57 PM, Ikeda Yuichi wrote: > I like excellent package system of Debian operating system. > I have been using for a long time. Thank you. You might like to have your company listed as a commercial user of Debian on our website. https://www.debian.org/users/ > Therefore, please let me ask questions about the following. The last time we had any interaction with the BIS/EAR/ECCN was a very long time ago, so it isn't surprising that the regulations have changed. I don't think people on this mailing list have any more information than what is listed on the USExportControl wiki page and legal web page.. PS: based on your email address your company seems to be located in Japan? Next year the annual Debian conference will be in Asia for the first time and it will be held in Hsinchu, Taiwan. We welcome sponsorship, volunteers and attendees, hopefully your company is interested in sponsoring and can send some developers to Taiwan next year. https://debconf18.debconf.org/ https://debconf18.debconf.org/sponsors/ https://wiki.debconf.org/wiki/DebConf18 -- bye, pabs https://wiki.debian.org/PaulWise
Re: Preinstall slightly modified Debian on laptops for sale
On Thu, Dec 7, 2017 at 8:27 PM, Kumar Appaiah wrote: > I am working with a team that is working on a low-cost laptop that > would be GNU/Linux based. When it comes to choice of distribution that > would be preinstalled on the laptop, Debian is among them. When that happens, please ensure you get added to our list of preinstallers: https://www.debian.org/distrib/pre-installed -- bye, pabs https://wiki.debian.org/PaulWise
Re: configure.in is missing but...
On Fri, Nov 24, 2017 at 9:33 PM, Ian Jackson wrote: > Can't you find a copy of the configure.ac somewhere ? If not, you may > be able to reconstruct one. Skimreading the configure script suggests > that wouldn't be too hard. It looks like the jpeg-6b-steg is a modified embedded code copy of libjpeg6b. outguess upstream really should send their patches in jpeg-6b-steg.diff to libjpeg upstream and remove the copy. I expect that outguess is probably vulnerable to the various libjpeg CVEs that have been released over the years. Looking at the unmodified source code, libjpeg upstream didn't release their configure.ac file until libjpeg7: http://ijg.org/files/jpegsrc.v6b.tar.gz http://ijg.org/files/jpegsrc.v7.tar.gz So I think what needs to happen here is that outguess needs a proper upstream project to exist and be active, remove the embedded code copy and port the diff to a newer libjpeg and upstream that and then get that uploaded to Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: EULA vs BSL
On Fri, Nov 17, 2017 at 10:24 PM, IOhannes m zmölnig (Debian/GNU) wrote: > i was playing with the idea about packaging the Decklink SDK by > Blackmagic (this is an SDK to access digital video grabbing cards). It might be better to invest in more Free Software friendly cards that are supported by v4l/etc. I have no idea about this field, but I believe the DebConf video team is now using this board: https://hdmi2usb.tv/numato-opsis/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Can a license be "DFSG approved"?
On Thu, Oct 26, 2017 at 9:53 PM, David Seaward wrote: > I suggested DFSG flagging, and SPDX are interested in a machine- > readable status list. [2] Is there such a thing? There is not such a thing. > I was also reminded of the comment below, and wondered in retrospect if > a flagging licenses as "DFSG approved" actually makes sense? The DFSG is not a body that can approve things. You could say "DFSG compatible", or "foo version X under license Y was approved by the Debian ftp-masters". > It is possible to have a package containing software under a "free" > license with some other aspect that makes it non-free. Yes, the DFSG covers more than just licensing. > debian-legal comments on a license in abstract, not applied to any > particular software. While these discussion can suggest possible > problems, often no firm answers can be reached until some specific > software is examined. [3] debian-legal is just a discussion forum, not any official Debian body. Often folks here try to avoid discussion in the abstract because discussions without details can lead to incorrect or poor-fit conclusions and suggestions. We can of course try to suggest possible problems even without full details. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Is there a list contains all debian packages and it's license ?
On Sat, Sep 23, 2017 at 8:38 AM, Yanhao Mo wrote: > but what I really want to know is that is there such a list that display > all debian packages with their licenses, just like the following link > about rhel[1]. There is no single list of licenses for each Debian package, just the individual copyright files in each source/binary package. What are you doing that requires a single list for all packages? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Do i need to purchase any License
On Tue, Jul 18, 2017 at 1:33 AM, ardavan izadi wrote: > I’m not sure about Debian licensing and don’t understand very well as it’s > long and confusing to me. A fairly good introduction to Free Software licensing is available here: https://www.debian.org/intro/free The FAQ Walter Landry sent a link to is good too. > I would like to use Debian on a single board computer for commercial use. > We’re going to produce an IoT gadget and eventually sell to the market. Since you are going to distribute Debian to users, and Debian includes a lot of copyleft-licensed software, you might be interested in this guide to GPL license compliance: http://compliance.guide/ This section offers an example of a product that meets the GPL requirements: http://compliance.guide/pristine Some more background on copyleft is available here: https://copyleft.org/ > Change the log screen during booting and display our logo This is perfectly acceptable to do. If you intend to also show the Debian logo, please note our trademark policy: https://www.debian.org/trademark > Run our custom software (written in Python & C) instead of OS desktop > environment If appropriate, I would encourage you to release this under a Free Software license and have your developers package it for Debian. > Do I need to purchase any license for my product from Debian? The Debian project does not sell any licenses. -- bye, pabs https://wiki.debian.org/PaulWise
Re: advice for free software package named almost identically to non-free software
On Sun, Jun 11, 2017 at 7:42 AM, Nicholas D Steeves wrote: > Do you think it's ok to internally provide backwards compatibility? > eg, for a library, newname provides/fulfils oldname, for a long period > of time...perhaps a year. I'm trying to think of all the non-Debian > users who would also be affected by this change. That would be a decision for upstream but I guess it would probably be OK. -- bye, pabs https://wiki.debian.org/PaulWise
Re: advice for free software package named almost identically to non-free software
On Fri, Jun 9, 2017 at 6:29 AM, Nicholas D Steeves wrote: > An upstream has named their GPL software almost identically to a > proprietary piece of software. I think it would be best to pro-actively rename the software now rather than wait until renaming the software would be more painful. Even if the proprietary software developer gives their permission, they could always sell the software to someone else, who might not be as forgiving of the naming similarity. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [licence] specific licenses for backdoor-factory software
On Tue, May 30, 2017 at 8:45 PM, Philippe THIERRY wrote: > The main tool is based on the following license file (LICENSE.txt) : This is almost identical to the 3-clause BSD license, the only change is s/university|regents/copyright holder/ > You may not redistribute aPLib without all of the files. May violate DFSG item 3. > You may not edit or reverse engineer any of the files (except the header > files and the decompression code, which you may edit as long as you do not > remove > the copyright notice). May violate DFSG item 5. > You may not sell aPLib, or any part of it, for money (except for charging > for the media). May violate DFSG item 6. > - Is the main software legaly acceptable for Debian ? The 3-clause BSD license is a very common DFSG-free license. > - Do i need to clean the upstream (deleting aPlib dir) making a dfsg package > or the upstream can be kept in the source package untouched if the aPlib is > not installed in the bin packages ? If you want the source package in Debian main, it must be fully DFSG-free. So your options are to either put the whole thing in non-free, strip the aPlib dir or convince the aPlib copyright holders to release it under a DFSG-free license. -- bye, pabs https://wiki.debian.org/PaulWise
Re: License Issue about Distributing NVIDIA's cuDNN library via Debian
On Thu, May 25, 2017 at 10:51 AM, Paul Wise wrote: > Personally I would like to see the amount of proprietary nVidia stuff > in Debian reduced, not increased. I would suggest focussing your > efforts on OpenCL/Vulkan based and open source deep learning libraries > instead of proprietary stuff that only acts as lock-in for other > proprietary nVidia technologies (CUDA). For example, Intel's just released clDNN: https://github.com/01org/cldnn -- bye, pabs https://wiki.debian.org/PaulWise
Re: License Issue about Distributing NVIDIA's cuDNN library via Debian
On Wed, May 24, 2017 at 2:42 PM, lumin wrote: > Hi Debian Legal Team, debian-legal are not Debian's legal advisors, just a bunch of people subscribed to a mailing list. > I intend to package[1] a proprietary deep learning > library named "cuDNN"[2], which is definitely useful > to deep learning researchers. Personally I would like to see the amount of proprietary nVidia stuff in Debian reduced, not increased. I would suggest focussing your efforts on OpenCL/Vulkan based and open source deep learning libraries instead of proprietary stuff that only acts as lock-in for other proprietary nVidia technologies (CUDA). > @lyeager kindly provided some help[3] on this but I'm > not really good at these legal terms. > > Generally, to download the cudnn library, one needs > to fist register or login at nvidia's website. Next, > the user is required to click "I agree ..."[4] to continue. > Now the secured library download link is exposed to the user.[5] The license you linked to both allows and disallows redistribution, seems like it needs a rewrite to be less bizarre. The allowance of distribution is time-limited. Personally I would not be comfortable distributing this and I do not think that Debian should do so either. > Initially I don't think such a well-protected proprietary > can be distributed by Debian, untill I find this package > in Archlinux's community repo[6]. They may be relying on the clauses allowing time-limited redistribution, or they may have simply not read the EULA. > I don't know how the Arch guys achieved this but in their > PKGBUILD file (arch packaging script) there is a anonymously > downloadable link to the cudnn library[7]. What is notable > is the "redist" keyword in the URL. I can't find this "redist" > URL in nvidia's website. Probably nVidia need to remove this redist directory from their website, since it is supposed to be only distributed behind a click-wrap license. > What makes me more confused is nvidia legal guy's word conveyed > by @lyeager [8]. Once a package is uploaded to the Archive, isn't > the distributor (legally) the Debian Organization? It's so weird > for an individual to take the role of distributor for a package > in Archive and I think it's impossible. There is a long chain of many distributors: firstly you distribute it to mentors.d.n, then mentors.d.n distributes it to your sponsor, then your sponsor distributes it to Debian ftpmasters, then Debian ftpmasters distribute it to Debian mirrors and CD vendors, then Debian mirrors and CD vendors distribute it to Debian users, then Debian derivatives (Ubuntu etc) distribute it to their mirrors and users. Every one of those is potentially liable if they have been found to do something illegal. -- bye, pabs https://wiki.debian.org/PaulWise
Re: GPL compliance for commercial hardware product running Debian
On Wed, Feb 22, 2017 at 10:29 PM, kevin anthoney wrote:
> Would we need to provide source code for all the GPL software running on the
> PC? Assuming the answer is "yes", is there a sensible method of collating
> all the necessary source code?
Yes, you would. I would encourage you to ship source for all the
software you are shipping instead of just for the GPL software.
This command will download the corresponding source packages for all
binary packages installed on a Debian system:
dpkg -l | tail -n+6 | awk '{ print $2 "=" $3 }' | xargs apt-get source
--download-only --
I'd encourage you to take a look at this example of a device with GPL
compliance:
https://compliance.guide/pristine
I would discourage you from using the "offer-of-source" provisions of
the GPL, they have various downsides:
https://compliance.guide/offer-for-source
More here:
https://copyleft.org/
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: what to think of these patents grants (from facebook, google) ?
On Mon, Dec 5, 2016 at 10:04 PM, Jérémy Lal wrote: > what to think of these patents grants? https://www.debian.org/legal/patent https://www.debian.org/reports/patent-faq -- bye, pabs https://wiki.debian.org/PaulWise
Re: Updating CIDER's Research Software Agreement License For Use in Ngspice
On Fri, Oct 21, 2016 at 12:45 PM, Eric Kuzmenko wrote: > Curt, who is an Associate Director of the Office of Technology Licensing for > University of California, Berkeley, has stated that UCB is willing to > relicense CIDER1b1 (1994) under the modified BSD license. Excellent. > Curt has also stated that he and his team are unable to modify the page and > associated tarball which are used to distribute CIDER1b1 at > https://embedded.eecs.berkeley.edu/pubs/downloads/cider/index.htm Have they tried contacting the EECS department? > They are requesting advice as to how they should handle the change in > license, particularly with respect to their current technical restriction. If the EECS department can't put a statement on the web page, I would go with something similar to what was done for the BSD Unix license change; IIRC that was a press release, a statement on the main UCB FTP server and a new copy of the tarball on the FTP server with updated license notices. -- bye, pabs https://wiki.debian.org/PaulWise
Re: would this custom license considered DFSG-free/GPL-compatible
On Tue, Oct 4, 2016 at 9:45 PM, Yaroslav Halchenko wrote: > On Tue, 04 Oct 2016, Paul Wise wrote: >> On Tue, Oct 4, 2016 at 8:56 PM, Yaroslav Halchenko wrote: > >> > // 4. If anything other than configuration, indentation or comments have >> > been >> > //altered in the code, the modified code must be made accessible to the >> > //original author(s). > >> This is impossible to comply with for those who do not have Internet >> access so I think it would fail DFSG item 5; No Discrimination Against >> Persons or Groups. > > ok -- playing devil's advocate (just a phrase, I am not of that opinion > about the upstream ;)) -- nothing there states about connectivity > (Internet) or media (digitized, printed) how they must be made > accessible. Could be via mail, bottle in the ocean, ... ... telepathy might be another option ;) -- bye, pabs https://wiki.debian.org/PaulWise
Re: would this custom license considered DFSG-free/GPL-compatible
On Tue, Oct 4, 2016 at 8:56 PM, Yaroslav Halchenko wrote: > // 4. If anything other than configuration, indentation or comments have been > //altered in the code, the modified code must be made accessible to the > //original author(s). This is impossible to comply with for those who do not have Internet access so I think it would fail DFSG item 5; No Discrimination Against Persons or Groups. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Can "rockyou" wordlist be packaged in Debian?
On Mon, Oct 3, 2016 at 5:09 AM, Florian Weimer wrote: > And a password database can be protected as a database in the EU. Some recent interesting articles on this topic: http://lu.is/blog/2016/09/12/copyleft-and-data-database-law-as-poor-platform/ http://lu.is/blog/2016/09/14/copyleft-and-data-databases-as-poor-subject/ http://lu.is/blog/2016/09/21/copyleft-attribution-and-data-other-considerations/ http://lu.is/blog/2016/09/26/public-licenses-and-data-so-what-to-do-instead/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Can "rockyou" wordlist be packaged in Debian?
On Wed, Sep 21, 2016 at 8:00 PM, Eriberto Mota wrote: > It is also a list about what don't to use for security. For security, don't use passwords unless you are forced to. If you must use passwords, use Diceware or similar: https://en.wikipedia.org/wiki/Diceware https://packages.debian.org/unstable/diceware https://packages.debian.org/unstable/xkcdpass -- bye, pabs https://wiki.debian.org/PaulWise
