Re: "freenginx" open source package and "nginx" from F5 open source, potential conflict?
On Mon, 26 Feb 2024 14:59:48 -0600 Richard Laager wrote: > On 2024-02-26 11:49, Thomas Ward wrote: > [...] > > So, in effect, Maxim seems to have wanted F5 to either NOT publish a > security vulnerability for their commercial product, knowing their > customers/users had this code in production, or to issue a CVE for the > commercial product but not the underlying OSS project with the exact > same code. Neither of those makes any sense to me. > I wanted to believe there was something deeper going on that would eventually be exposed, but this really seems to be the root of it. One particular developer was expecting that they'd get to say what is and is not a vulnerability and they didn't like that reality was different. In this particular case, the policy that was being followed was extremely clear and there was very little room for interpretation. > > So, before I follow through with Debian packaging (which would be > > synced to Ubuntu downstream), may I get the opinion of debian-legal on > > whether there’s any copyright or trademark violation concerns that > > exist before I pursue getting this into Debian? > > > I'm not a lawyer, but it sure seems like an obvious trademark problem to > me. In my opinion, Maxim really should pick a brand new name if he's > serious about this as an ongoing project. Everything I've seen so far screams copyright violation. The website even started as a verbatim copy/paste of the original, with just the logo and name changed in only a few places. Even now, it's basically just a copy/paste with a reset feed ... heck, it still has "nginx news" up in the title on the front page. At this point, even if they were to find/replace, the proper copyright holder will have a claim to be made against the squatting that took place. From my perspective, it sure looks like they're trying to hostilely squat the name for as long as they can while pushing out a replacement with a similar name, currently offering nothing but the assurance of fewer CVEs. This is one hot potato I would recommend staying far away from. -- Michael Lustfield
Re: Technical requirements for upstream license specification
(forgive the phone formatting) This project is clearly stating that the intended license is GPLv2+. It might be specified in just the one file, but that file is also clearly intended to represent the project. It's fine as-is, but still worth chatting with upstream. The "LICENSE" file is a standard that comes with unexpected benefits--like automatic compliance with some trickier (unread) clauses is some licenses. It's also worth validating that test data can be reproduced. On Wed, Oct 19, 2022, 15:10 Marcin Owsiany wrote: > Hello, > > I'd like to package [1] a program which is GPLv2+ licensed, but as far as > I can tell, this fact is only stated in a couple [2] of [3] lines of its > setup.py build script. This is a bit of an obscure way to state the license > for my taste. However before I bother the upstream maintainer about this, I > would like to double check that the Debian project actually has > requirements for something more explicit to be present in the upstream > source. It's been a while since I packaged something, and I only have vague > recollection that there were such rules, but maybe I'm confusing them with > GNU packaging rules... Is it written down anywhere? > > regards, > Marcin > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022074 > [2] > https://github.com/Rudd-O/ledgerhelpers/blob/4d30fa43a99dc9f98b46d805480b120218c377aa/setup.py#L26 > [3] > https://github.com/Rudd-O/ledgerhelpers/blob/4d30fa43a99dc9f98b46d805480b120218c377aa/setup.py#L57 >
Re: Declaring license for autogenerated file (W3C)
On Fri, 18 Jun 2021 12:53:37 +0200 "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? > > > Suggestion --> [...] In that case, you can just use the correct path for unicode.xml, drop the comment from the second paragraph, and simplify the paragraph in the first. Both still appear to have a unique copyright/license from each other, as well as the rest of the project, so they should still both be represented separately. > :: would it be preferable from the legal side? I'm a bit confused by this. It's always preferable to follow upstream releases when generating packages. Building packages from projects that don't create releases (see golang...) is a bit of a headache and helps result in some truly horrific version numbers. [1] If the upstream project provides releases, then definitely use them. What matters from a legal perspective is that you follow what is spelled out in the license. (That's also the primary concern behind packages passing through the NEW queue.) [1] 1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1 -- Michael Lustfield
Re: Declaring license for autogenerated file (W3C)
Please forgive any screwy formatting; I'm trying out evolution again... On Thu, 2021-06-17 at 14:28 +0200, Diego M. Rodriguez wrote: > Hello, > > as part of packaging "pylatexenc" [1], I'm unsure on how to properly > declare the license attribution of one of the files in the upstream package. > [...] > However, I'm not familiar with the W3C license (nor with d/copyright > finer points). Would it be possible to have advise on whether the > assumptions and the current d/copyright is suitable - and help on > correcting otherwise? > [...] > [4] > https://salsa.debian.org/python-team/packages/python-pylatexenc/-/blob/105ecb9bb8f96b8d253bf8244fd17617af6ea9d2/debian/copyright#L14 From my perspective, you did a relatively adequate job documenting the oddity in d/copyright. It seems that this file rarely ever (never) changes, so dropping a copy into d/missing_sources/unicode.xml should definitely happen. Observations: - Phillipe might have a copyright on _uni2latexmap_xml.py, but I see no evidence they have one on unicode.xml. - I also don't see any evidence that Expat is a valid license for unicode.xml. - Trying to explain that all in one paragraph is messy, confusing, and difficult. Suggestion --> Files: pylatexenc/latexencode/_uni2latexmap_xml.py Copyright: 2015-2019 Philippe Faist 2015 World Wide Web Consortium 1999-2015 David Carlise License: Expat and W3C Comment: The file 'unicode.xml' (d/missing_sources/unicode.xml) is used to generate this file during release tarball creation. Files: debian/missing_sources/unicode.xml Copyright: 2015 World Wide Web Consortium 1999-2015 David Carlise License: W3C Comment: This file was copied from w3.org, is used to generate source, and is then dropped from the final release tarball. The source header contains additional information about the origins and history of this file. -- Michael Lustfield signature.asc Description: This is a digitally signed message part
Re: FreeMedForms projet
It looks like this bug went from "Qt4->Qt5" to "no longer DFSG-free." On Fri, 10 Jan 2020 17:34:35 +0100 Eric Maeker wrote: > Oh! There is a misunderstanding here! > Let me correct my words: > -> full code of each stable released version is packaged and freely > available (but undocumented since v1.0.0). From: https://freemedforms.com/en/downloads/root "Downloads are 100% compatible with the Debian social contract." From: https://freemedforms.com/fr/downloads/root (translated) "Since v1.1.0, some files are available under a license incompatible with the social contract of Debian . If you are looking for software 100% compatible with this contract, please refer to v1.0.0." Without digging in too deep... - You mentioned documentation removal in 1.0.0 - This page mentions DFSG-freeness was broken in 1.1.0 If these were two distinct periods of time, that would lead me to suspect additional files were added that broke compatibility with the DFSG. > 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. This could definitely be a language barrier problem, but I don't follow. Why are you concerned about forks? If you have quality open source software, then people will fork it. Sometimes patches will be sent back upstream, other times they won't be. Take a look here: https://people.debian.org/~bap/dfsg-faq.html Particularly at 9a (The Desert Island Test) Demanding that all modifications be shared with you very clearly fails this test, and is not actually part of the license you applied to the software. > In consequence, we decide that our git repository will not be freely > accessible. Approval does only concern the FreeMedForms' git and the > ability to join the project as member (coder, tester, communication > manager...). It's probably worth noting, a public repository is recommended, but not required for inclusion in Debian repositories. However, inclusion of source is an absolute requirement. This "documentation" that was removed seems to be much more than just developer docs; I'm unable to find any non-header comments in any file. If you look at how javascript is handled, any minified version is considered compiled source. You are essentially doing the exact same to your source when you release it. It's not the actual source... it's just some partial version of it. In this case, with intentional obfuscation. This could still make it into non-free, however, I'd urge you to reconsider your motivations for releasing obfuscated source and refusing to share. Is it really your desire to make software that's (per DFSG) not free? -- Michael Lustfield
Re: Licensing of jeuclid
On Tue, 14 Nov 2017 15:55:40 +0100 Julien Puydt <julien.pu...@laposte.net> wrote: > Hi, > > according to bug #876733, there is a licensing problem with jeuclid : > - the LICENSE.txt file [1] says Apache 2.0 ; LICENSE.txt showed up in revision b9d5f518ae61 (61) as a rename of LICENSE. LICENSE showed up in revision 7a11e25aacfa (0) during a CVS import. support/LICENSE.txt shows up in revision 472677a11fef (683).. and is Apache-2.0. > - the NOTICE file [2] looks like an Apache 1.0. NOTICE also showed up in revision 7a11e25aacfa (0). NOTICE seems to be Apache-1.1 with word replacements. (not Apache-1.0) > My interpretation of the issue is that if there are two licenses on the > code, then as long as the necessary DFSG-rights are given, there is no > problem. I would argue that the Author's clear intention was to license this work under Apache-2.0. This is where the full license text is correctly copied. A LICENSE file is typically the authority to a project, so much so that many tools ignore a NOTICE file when checking licenses if a LICENSE file is present. Additionally, Apache-2.0 invalidates a contradicting license by paragraph 4(d). What's in NOTICE violates the license terms of what's in LICENSE. > Notice that upstream seems unreactive since years now, so even though > I'm also opening a ticket there [3], moving forward not expecting an > answer seems the most reasonable course of action. Considering the last commit was in 2012, a lack of response is not in any way surprising. You opened that ticket less than a day ago. > What do you think about the matter? I'd start by making an attempt to contact maxberger directly, and then definitely have some patience. They may be on vacation, experiencing health/family/existential problems, or prefer checking email infrequently. If you don't get a response, I would argue that the author's clear intent was to license the work under the Apache-2.0 license and believed the NOTICE file was meant for a more brief form of the file. I would make that argument based on the assumption that they didn't read the license, or the portion where it tells you what the brief form looks like. IANAL -- Michael Lustfield
Re: Are golang-github-facebookgo-* DFSG compliant?
> So I agree. Without any objections, I'll go ahead and ignore patents files that match this text. Thanks!
Are golang-github-facebookgo-* DFSG compliant?
First up, I'll apologize for not having caught this sooner. I've uploaded three packages in the NEW queue with this mistake (sorry): golang-github-facebookgo-freeport - https://github.com/facebookgo/freeport golang-github-facebookgo-stack - https://github.com/facebookgo/stack golang-github-facebookgo-subset - https://github.com/facebookgo/subset In the source of each repository is a "patents" file that didn't catch my eye until now. I'm not familiar with grant of patent rights and not sure if this is an issue for accepting the package into Debian. I would really love some expert review/advice on this one. Thanks! -- Michael Lustfield pgpihJ1rGT0ip.pgp Description: OpenPGP digital signature
