Re: Expat + exception = DFSG-compatible?
* Dmitry Smirnov: > I'm seeking second opinion regarding mutation of the Expat license that can > be found in [1]. In particular, author added the following clause: > > The Software shall not be used nor made available to TESTTailor or any > individual or organization related or operated by Adarsh Mehta from > Germany; some people just don't deserve free work to be made available > to them. > > Do we consider this as DFSG compatible license? > > IMHO it is a DFSG-compatible license because added clause is not a > restriction for field of endeavour but a termination clause similar to GPL > ones except that is is explicitly added to the license in order to blacklist > a known offender. The restriction you cited violates DFSG §5 (“No Discrimination Against Persons or Groups”).
Re: Expat + exception = DFSG-compatible?
On Tuesday 13 October 2015 09:10:10 Florian Weimer wrote: > The restriction you cited violates DFSG §5 (“No Discrimination Against > Persons or Groups”). Well yes, but then how GPL termination clause is not a violation? Consider hypothetical situation when a known offender of the license have it revoked as per GPL-3 §8 or any other clause of the any other license. (For Expat an obvious violation would be removing copyright and/or notice). Listing known offenders in addition to the text of the license wouldn't be violation of DFSG §5, right? Discrimination is not the same as Termination so I wonder if it is possible to list license revocations in a DFSG-compliant manner... -- Best wishes, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: Source files
Walter Landry writes: > Ole Streicher wrote: >> What are the general guidelines here? Somewhere in written form? The >> DFSG does not contain a hint here. > > The rule of thumb that I have seen applied is that 'source' is the > preferred form of modification for the people making modifications. > If a person really prefers editing 1400 character lines, then that is > the source. However, you can not just state that you prefer that. I'd prefer just to ignore the line: it is a comment line that is not needed for the functionality, so I see no reason to touch it at all. The only reason to touch it for me would be to delete it. > So if a file is generated mechanically, whatever scripts that generate > the file are the 'source'. However, if someone actually edited the > 1400 character line, then it could become 'source'. Similarly, one could patch a binary executable with a hex editor :-) > I have not seen the example of CVS status lines before. I think > Debian generally ignores that kind of technical violation because > > 1) CVS is free software > 2) Those lines are not critical to functionality. > 3) The lines are very short and not difficult to modify. If you want to keep consistency, it is actually difficult to impossible: The $ Id: $ line is created from the RCS file from the CVS server which is usually missing in the sources. Generally, one would "prefer" not to touch this line at all, but to interact with the CVS server -- which is not possible since the CVS tree is not included. So, there is no difference to the long line from the questioned file: without keeping consistency, editing is simple (and both have no influence on the functionality), but if you want to keep the consistency (and some people would *prefer* that), it is difficult to impossible. So, strictly speaking, CVS (or RCS, or SVN) autogenerated lines are not source and should not exist in Debian sources, right? Best regards Ole
Re: Source files
Ben Finney writes: > Ole Streicher writes: >> However, it contains one line >> /*globals $, jQuery,define,_fnExternApiFunc,[...] >> which is ~1400 characters long and may be automatically inserted. > > I would say the test of whether a file is source is whether it can be > described as “the preferred form of the work for making modifications to > it”. > > If the preferred form for making modifications is to edit some *other* > file, then re-generate, the generated file is no IMO source for the > purpose of the DFSG. This is the case for the CVS/RCS $ Id: $ line, which is actually generated by committing the edited file to an RCS (,v) file (which is /different/ from the actual file). >> The "preferred" in the definition is a bit ambitious -- some people >> may prefer a different form than others. > > Do you mean “ambiguous”? If so, I agree. But that ambiguity does not > prevent the definition from being quite useful for deciding cases like > this. I meant ambigous, sorry. In this case (as in the case of the CVS/RCS Id line), it is not helping, since some people may prefer not to edit this line at all: I f.e. would just ignore the line in the Javascript source, since it does not have a functional influence, and I do not care about the line at all. Others would like to keep the consistency, as I would like to do in the case of the CVS/RCS Id. Who is right then? >> If someone copies a files from somewhere else, and then patches is to >> fits the local needs: Is the patched file a "source"? > > Patching results in a *different* work (and, according to your described > provenance, the patches result in a derived work of the prior one). > > Is the resulting file still one which would be preferred for making > modifications to that new work? Not in all cases. One use case would be to bring the file in sync with the current developments of the original file. For this, I would prefer patches instead of just the changed file. > If so, that file is the source for whatever automatically-generated > form of the work (e.g. compiled binaries) they then produce from that > source. The example is not about whether the changes were made manually or automatically, but about what is preferred to work with. And there are use cases which would require to have the patches separated (being them manually generated or not), so by the GPL definition the patched file is not a source. >> Someone would probably prefer to have the original file and the patch >> instead > > That would not be the source form of the later (derived) work. You have > created, in this scenario, two separate works, each of which has a > distinct source form. Anyway, I have a use case for the derived work where I would prefer to have the modifications in form of patches -- which makes the derived work itself a non-source (since for this use case it is not the preferred form of modification). >> What are the general guidelines here? Somewhere in written form? The >> DFSG does not contain a hint here. > > You're right. They're guidelines, and (as you know) the DFSG doesn't > actually refer to the GPL's definition of source. > > The current state of copyright law doesn't allow firm, clearly-defined > specifications of what is or is not legal; the law is in many ways > incoherent from a logical perspective. The question here is not about what is legal, but about what we accept in Debian. If a file is licenses by BSD, it does not matter whether it complies to a specific "source" definition to obey this copyright. Best regards Ole
Re: Source files
Charles Plessy writes: > Maybe the long line was machine-generated at the beginning, but it does not > matter anymore. Why not? If I take the GPL definition, the question is not whether it is actual (and, BTW, also not whether it is automatically generated) but what "is preferred" (holy passive) for modification. > And by the way, while anybody is free to disbelieve that a file is a real > source file, the only persons whose judgement really matter on that subject > are > the members of the FTP team. I would guess that the FTP team should have guidelines here, which would be nice to presented in this discussion. > So you are free to disagree with random bug reporters, and they are > free to escalate it if they are not convinced by your arguments, which is one of the purposes of this discussion. > but in the meantime, Debian's point of view is that the file is source > unless the contrary has been demonstrated, given that it has passed > the screening of the FTP team when it entered our archive. You can > also add Lintian overrides if the Lintian maintainers are uncooperative. Sure. Actually, I added an overrides here. However, lintian sets some standards, and they need to be discussed. Best regards Ole
Re: Source files
> Charles Plessy writes: > > > > Maybe the long line was machine-generated at the beginning, but it does not > > matter anymore. Le Tue, Oct 13, 2015 at 10:12:07AM +0200, Ole Streicher a écrit : > > Why not? If I take the GPL definition, the question is not whether it is > actual (and, BTW, also not whether it is automatically generated) but > what "is preferred" (holy passive) for modification. Yes, that what I wanted to mean :) To me, it looks like the file that we are discussing is the preferred form for modification. -- Charles
Re: Expat + exception = DFSG-compatible?
On 10/13/15 08:50, Dmitry Smirnov wrote: > On Tuesday 13 October 2015 09:10:10 Florian Weimer wrote: >> The restriction you cited violates DFSG §5 (“No Discrimination Against >> Persons or Groups”). > > Well yes, but then how GPL termination clause is not a violation? Because it is a clause explaining what happens if someone behaves in a way which isn't allowed under most copyright laws anyway and mainly sets out how that person can gain a new licence by ceasing violation. > Listing known offenders in addition to the text of the license wouldn't be > violation of DFSG §5, right? Yes, it probably would - how would the listed people ever gain a new valid licence? Hope that explains, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op http://people.debian.org/~mjr/legal/ In My Opinion Only: see http://mjr.towers.org.uk/email.html
Re: Expat + exception = DFSG-compatible?
This is not a DFSG free license, and it will be rejected from NEW if it's sent there :) Cheers, Paul On Tue, Oct 13, 2015 at 2:54 AM, Dmitry Smirnov wrote: > Hi everyone, > > I'm seeking second opinion regarding mutation of the Expat license that can > be found in [1]. In particular, author added the following clause: > > The Software shall not be used nor made available to TESTTailor or any > individual or organization related or operated by Adarsh Mehta from > Germany; some people just don't deserve free work to be made available > to them. > > Do we consider this as DFSG compatible license? > > IMHO it is a DFSG-compatible license because added clause is not a > restriction for field of endeavour but a termination clause similar to GPL > ones except that is is explicitly added to the license in order to > blacklist > a known offender. > > Any thoughts? > > Thanks. > > [1]: https://github.com/martin-denizet/redmine_login_audit#license > > -- > Cheers, > Dmitry Smirnov. > > --- > > The great enemy of the truth is very often not the lie -- deliberate, > contrived and dishonest, but the myth, persistent, persuasive, and > unrealistic. Belief in myths allows the comfort of opinion without the > discomfort of thought. > -- John F Kennedy > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq
Re: Expat + exception = DFSG-compatible?
On Tuesday 13 October 2015 09:31:03 Paul Tagliamonte wrote: > This is not a DFSG free license, and it will be rejected from NEW if it's > sent there :) Understood, thanks. But my question really is whether it can be re-phrased to blacklist/mention known offender(s) in a DFSG-compatible manner and how... -- Regards, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Re: Expat + exception = DFSG-compatible?
It can not. Thanks, Paul On Tue, Oct 13, 2015 at 10:16 AM, Dmitry Smirnov wrote: > On Tuesday 13 October 2015 09:31:03 Paul Tagliamonte wrote: > > This is not a DFSG free license, and it will be rejected from NEW if it's > > sent there :) > > Understood, thanks. But my question really is whether it can be re-phrased > to > blacklist/mention known offender(s) in a DFSG-compatible manner and how... > > -- > Regards, > Dmitry Smirnov. > > --- > > Truth — Something somehow discreditable to someone. > -- H. L. Mencken, 1949 > -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq
Re: Expat + exception = DFSG-compatible?
On Tuesday 13 October 2015 12:50:55 MJ Ray wrote: > On 10/13/15 08:50, Dmitry Smirnov wrote: > > Listing known offenders in addition to the text of the license wouldn't > > be violation of DFSG §5, right? > > Yes, it probably would - how would the listed people ever gain a new > valid licence? I think it is entirely different question how they can get a new license. Forgiveness of the license is not a DFSG criteria. But let's entertain this idea. How about time period? What if license revoked for 20 years and offenders listed with date after which they can use the software again? -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: Expat + exception = DFSG-compatible?
Dmitry Smirnov writes: > But my question really is whether it can be re-phrased to > blacklist/mention known offender(s) in a DFSG-compatible manner and > how... The goal of excluding specific people, or groups of people, is not compatible with software freedom. It's also not compatible with the DFSG. Such a goal cannot be met in a free software license. So, the resolution would entail getting at *why* They want to exclude certain people, and see whether that underlying goal can be met. The way the existing wording seems to spitefully target named individuals does not make me hopeful of that, but at least there's a chance something can be found. -- \ “When I get new information, I change my position. What, sir, | `\ do you do with new information?” —John Maynard Keynes | _o__) | Ben Finney
Re: Source files
Ole Streicher wrote: > Walter Landry writes: >> Ole Streicher wrote: >>> What are the general guidelines here? Somewhere in written form? The >>> DFSG does not contain a hint here. >> >> The rule of thumb that I have seen applied is that 'source' is the >> preferred form of modification for the people making modifications. >> If a person really prefers editing 1400 character lines, then that is >> the source. However, you can not just state that you prefer that. > > I'd prefer just to ignore the line: it is a comment line that is not > needed for the functionality, so I see no reason to touch it at all. The > only reason to touch it for me would be to delete it. Sorry, I had not noticed that it was a comment. I am confused as to why it is there. Do you know why? Could you get upstream to delete this seemingly useless line? That would solve your immediate problem and clean up the code. Cheers, Walter Landry
Re: Expat + exception = DFSG-compatible?
El 13/10/15 21:53, Ben Finney escribió: Dmitry Smirnov writes: But my question really is whether it can be re-phrased to blacklist/mention known offender(s) in a DFSG-compatible manner and how... The goal of excluding specific people, or groups of people, is not compatible with software freedom. It's also not compatible with the DFSG. Such a goal cannot be met in a free software license. So, the resolution would entail getting at *why* They want to exclude certain people, and see whether that underlying goal can be met. That's the real point. I guess something similar to what you wanted could be achieved by a wording like: «This license does not provide any new rights to LitWare Inc. over the code for which they were terminated pursuing GPL §8 after they failed to comply with the license terms after being repeatedly notified since 2005.» which is quite different than: «The company Coho Winery cannot use this work, since when the founder filed for divorce [from me], it said very nasty things» or «Blue Yonder Airlines is not allowed to use this software, since planes are dangerous and nobody should operate them» "some people just don't deserve free work to be made available to them." could mean anything.
Re: Expat + exception = DFSG-compatible?
> IMHO it is a DFSG-compatible license because added clause is not a > restriction for field of endeavour but a termination clause similar to GPL > ones except that is is explicitly added to the license in order to blacklist > a known offender. Are you sure that Adarsh Mehta is a known offender? From what I can tell, Adarsh Mehta and Martin Denizet co-founded TESTTailor.[1] Presumably something happened between them. Because of this, I don't think that it is necessary to consider the question of known offenders unless it can be proven that Adarsh Mehta is one. [1] www.unitednetworker.com/testtailor-crowdtesting-plattform/ pgp7r_TrsDcMx.pgp Description: PGP signature
