Re: Let's stop feeding the NVidia cuckoo
On Fri, Mar 04, 2005 at 06:52:07PM +, Brett Parker wrote: > Matthew Garrett <[EMAIL PROTECTED]> wrote: > > > > > I rephrase: how can you argue that a hand-crafted binary is not > > > sufficiently modifiable to offer the freedom to study and adapt? > > > > How you can argue that a binary output by a compiler is not sufficiently > > modifiable to offer the freedom to study and adapt? > > In that particular case, you've got the output of compiler, therefore > the authors prefered form of modification is the "source", it's *really* > got source, there was a before stage, it wasn't a hand crafted binary. > > I can see where you're coming from though. I think this is very much an > edge case, and I doubt that there are *that many* people that would hand > craft an elf binary without using a compiler chain. Of course, providing > a binary only also limits which archs you can use it on, which you > *might* be able to do given C/C++/ObjC/Fortran/SomethingGoesHere source. > > I wonder if I'm missing something, somewhere? I know of one example, but it's pathological, and in fact exists *as* an example: the various stages of "How small can I make an ELF 'hello world' binary?" that someone went through. Actually, I believe the author of that *did* start with a C source -> ELF binary step, but that became fairly rapidly irrelevant to the example. I also don't think we should package it as a binary (we might care to package the entire documentation of the sequence, since it demonstrates some interesting things about how ELF binaries are built, but that then becomes a separate question). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Let's stop feeding the NVidia cuckoo
On Thu, Mar 03, 2005 at 06:59:44PM -0800, Michael K. Edwards wrote: > On Thu, 3 Mar 2005 17:15:41 -0700, Joel Aelwyn <[EMAIL PROTECTED]> wrote: > [snip] > > Actually, we aim to throw out 100% of closed-source software. But I'm > > assuming you were just being careless with trying to make a point. > > Unfortunately, the point you're trying to make also misses. > > Well, I was a little bit careless, in that I didn't spell out the bit > where 98% < 99.5% implies that closed-source software workflows are > typically even sloppier about retaining editable image formats than > open-source workflows are (unless, of course, regenerating those > images is such a frequent task that it overcomes someone's laziness > threshold). I think that's a useful benchmark for whether passing > JPEGs around is acting in good faith, whether or not you want to throw > out 100% of closed-source software. In other respects, you seem to be > in violent agreement with the scope of the argument in the message you > quoted, which was that the author's actual process is good enough even > if it isn't the way that imaging-industry professionals would do it. > That's not my entire opinion, though, as I discuss below. I would agree it's a useful consideration; whether it's a benchmark, I'm not so certain, but it certainly affects the question "Do we consider the claim that this is the source format insanity?" (or, really, more likely, "is anyone insane enough to want to deal with this source?"). > When what we are being purist about is images, we want the trade-off > chosen by a sophisticated, experienced manipulator of images of that > kind -- which may well not be the earliest machine-parseable source, > and may omit the details of intermediate manipulations which are > obvious to a skilled practitioner and not worth automating. > Similarly, when what we are being purist about is software, we want > the thing that a manipulator of software would use, and sometimes > similar trade-offs are involved. Agreed. > Consider a table of numbers in an approximation algorithm, originally > machine-generated using a Perl one-liner heuristic, massaged by hand > to truncate to integers (mostly alternating between floor and ceiling > but tuned by trial and error), and then embedded in a header file. If > I think there's little point in automating these steps because anyone > skilled enough to create a useful replacement table could do it > themselves easily enough, then it's reasonable for me to call the > header file "source code" when I distribute it. This is true even if > 1) I still have the Perl one-liner in a logbook somewhere and would > look it up if I ever needed to recapitulate the work myself, 2) the > massaging loses information and makes it impractical to do more than a > point fix without redoing the heuristic, and 3) next time around I > would probably write a second Perl one-liner instead of inserting the > syntactic sugar by hand. Agreed. > What would make it unreasonable to call the header file "source code" > is if the idea behind these manipulations is an important part of the > software design and is hidden from recipients in a way that it would > not be if I disclosed the process I followed. If I document the > intention behind the heuristic, and the rest is just aesthetic > judgment and trial and error, then I have acted in good faith, even if > parameterizing and automating all of the steps would show more > professionalism. Still agreed. > Now for a more controversial opinion. If the reason I'm disinclined > to release the heuristic in machine-executable form is that it happens > to be not a Perl one-liner but one of many functions of another piece > of software that I don't want to give away for free, I think the > resulting header file is still acceptable in free software. Just > because I say "solve this numerical integral as a starting point, then > experiment" doesn't mean I owe you a numerical integrator, even if > that's how I got there to begin with and how I personally would go > about subsequent changes. Sometimes the appropriate standard is not > "is it how the author does it" but "does it obstruct access to the > ideas embodied in the software". I think that this is where the judgement call starts to creep in. If the statement is "solve this numerical integral", then the ways of doing that are (fairly) widely known, documented, and there's a good chance that there are tools which will make it practical for the mythical "reasonable person" to accomplish this task sufficiently well to be able to modify things without it being exc
Re: Let's stop feeding the NVidia cuckoo
eferred one; it is my preferred *method* of modification, but not my preferred *format* for modification. Now, if I start saving out layered image data because I want to simplify future modifications, it *would* be my preferred format at that point. However, if my scanner only produced JPEGs, and I kept a copy of that and re-compressed them to be smaller, then the origional JPEG is the preferred format for modification. The other JPEGs still aren't. So I agree that it is not *required* that someone use raw mode and lossless manipulation at every stage (though I find it an offense to my inner purist that they don't), it *is* required that that be provided (at least in the source package), *if* that is how they work on the images. I really haven't ever understood why people find this issue so complicated, except perhaps a willful disbelief that anyone could be so crude as to work only in lossy formats. On a slightly different note: implying that you would need the origional piece of artwork for it to be source is roughly analagous to requiring my physical body and brain as the 'source' of a program I write and distribute. It isn't bits and bytes that Debian can (potentially) distribute, and therefore, it doesn't enter into the equation of "what is source?" in any particularly meaningful fashion. "Source" is shorthand for "Source code", and while the "code" part of that may be better said "format" to be applicable to all things found on Debian CDs, it still implies "bits and bytes". -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: PHP non-free or wrongly named?
On Tue, Feb 22, 2005 at 03:31:22AM +, MJ Ray wrote: > Joel Aelwyn <[EMAIL PROTECTED]> wrote: [...] > > "You may not have any cookies right now". > > > > It's a reflexive negation rewording of "May I " -> "You may not ". > [snip] > > Well, that's fine, but if I don't need your permission in order > to have cookies, it's sort of irrelevant. Also, it doesn't > actually require any action from me to achieve that state > of not having your permission to have cookies and make your > statement true. > > This is a head-strainer and I'm not surprised that anyone is > unfamiliar with it. It's related to old jokes that my school > teachers used to use: "Can I leave the room?" "Not without my > permission." A bit twisted, maybe, but it teaches. Yes; my impression is that it is likely that this is badly written in the same way that it is quite common for people to ask "Can I?" instead of "May I?". Thank goodness nobody tried to use "shall" / "will" or "who" / "whom". > As I wrote earlier, legal interpretation of this sort of > phrase needs someone other than me and if anyone is worried, > please go ask PHP Group about it (if PHP Group is bothering > to accept email yet) and maybe get blanket "PHP for ..." > approval. Indeed, it seems like the standard fallback of "ask for a clarification" is in order. Gotta love TMDA systems, really. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: PHP non-free or wrongly named?
On Mon, Feb 21, 2005 at 10:42:29AM +, MJ Ray wrote: > Lewis Jardine <[EMAIL PROTECTED]> wrote: [...] > > I think the obvious intended meaning is another assertion of > representation norms. The other conditions of this licence use > "must" not "may". To what wording convention do you refer? Are > you claiming that if I wrote "Fred runs; Jane runs; Tom walks; > Belinda runs" then I really mean "Tom runs" because it follows > a similar language pattern as the other clauses? > > If you are troubled by what the licensor means and the limits > of the rights they assert, ask them. "You may not have any cookies right now". It's a reflexive negation rewording of "May I " -> "You may not ". This is not the same usage as "You may, or may not, encounter ". Perhaps this is a quirk of American English; I can't really be bothered enough to go dig up the full history. But it is sufficiently clear that at least some large set of people who are told "You may not" interpret it as an imperative statement, rather than an informational one, that it should be assumed to be a prohibition. I haven't even tried to follow the rest of the thread, it makes my head hurt right now, so what (if any) consequences this triggers in the interpretation, I couldn't tell you. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Maia Mailguard License
On Mon, Feb 14, 2005 at 06:28:56PM -0500, Glenn Maynard wrote: > On Mon, Feb 14, 2005 at 04:17:14PM -0700, Joel Aelwyn wrote: > > The origionally posted license seemed to imply that clauses 3 and 4 were > > alternatives, and you only had to meet one of them; clause 3 appeared to > > more or less be a BSD advertising clause (cross-reference the 'flowc' > > licensing discussion...) > > > > If it's free, then wouldn't that make the license free (by not exercising > > option 4 at all, making it irrelevant)? I agree that trying to invoke > > option 4 wouldn't work. > > You have to satisfy both #3 and #4: you have to do 3 *as well as* one of 4a, > 4b or 4c. > > Maybe you read #4 as part of "Alternatively ...". The "alternatively" is > part of #3, and unrelated to #4. I was, indeed, reading it as making #3 and #4 alternatives. Apparently I'm going blind (or stupid). Anyway. If they really must both be met, then I agree; it is definitely non-free. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: flowc license
On Mon, Feb 14, 2005 at 06:00:17PM -0500, Glenn Maynard wrote: > On Mon, Feb 14, 2005 at 03:45:02PM -0700, Joel Aelwyn wrote: > > And, in practice, a lot of it still boils down to what the copyright holder > > views the *practical* requirements of fufilling the clause to mean. If it > > means "make sure the phrase appears in the debian/copyright file", that's > > not terribly onerous. If it means "Make sure the clause appears on your > > website in a prominent place, and on all flyers promoting Debian's presence > > at a trade show or other event", that could be a lot less practical. > > I don't think "make sure the phrase appears in the debian/copyright > file" follows from the text of the OAC. It's pretty clear: if you > mention the software in your advertising, you have to include a verbatim > piece of text, and that pretty clearly includes things like banner ads > and other places where it's simply not practical. > > If a copyright holder doesn't want to require that, then it should be > pretty easy to convince him to actually change the license, and not just > "clarify" or "interpret" the license (which gets very hairy once you > have more than one copyright holder). I can only tell you what the people I've actually dealt with have said. If it's "not practical", and if DFSG #10 enshrines the 4-clause BSD license as free by fiat, then we have a much larger question looming. One of the reasons I've spent so much time trying to convince various folks holding copyrights and OACs in the NetBSD source tree to relicense under a 3-clause. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Maia Mailguard License
On Mon, Feb 14, 2005 at 05:46:44PM +, Henning Makholm wrote: > Scripsit Chris Sacca <[EMAIL PROTECTED]> > > > I'm not that skilled with legal-speak, and I was wondering > > if someone could clear up if this the DFSG compatible, > > It is not free. We have previously rejected software with similar > functional restrictions (though the name escapes me at the moment). > > Non-free clause from http://www.maiamailguard.com/license.php > reproduced here, for cc'ing to the RFP bug: > > > 4. At least one of the following branding conventions must be used: > > ~a. The Maia Mailguard logo appears in the page-top banner of > > ~ all HTML output pages in an unmodified form, and links > > ~ directly to the Maia Mailguard home page; or > > > > ~b. The "Powered by Maia Mailguard" graphic appears in the HTML > > ~ output of all gateway pages that lead to this software, > > ~ linking directly to the Maia Mailguard home page > > ~ http://www.maiamailguard.com/images/poweredbymaia.gif";> > > > > ~c. Rebranding License > > ~ is obtained from the copyright owner, exempting the Licensee > > ~ from 4(a) and 4(b), subject to the additional conditions laid out > > ~ in that license document. The origionally posted license seemed to imply that clauses 3 and 4 were alternatives, and you only had to meet one of them; clause 3 appeared to more or less be a BSD advertising clause (cross-reference the 'flowc' licensing discussion...) If it's free, then wouldn't that make the license free (by not exercising option 4 at all, making it irrelevant)? I agree that trying to invoke option 4 wouldn't work. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Why UCB dropped the OAC [was: Re: flowc license]
On Sun, Feb 13, 2005 at 12:28:51PM +0100, Francesco Poli wrote: > On Sat, 12 Feb 2005 12:26:24 -0500 Glenn Maynard wrote: > > > > > ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change doesn't > > mention rationale, either. > > This is the relicensing notice and it's useful, but, as you point out, it > lacks the rationale. Anyone know where to read the reason why UCB dropped > the Obnoxious Advertising Clause? Hmmm. I could have sworn I had a URL for some discussion of it (much of which was speculative, but speculation by folks involved with the issue at the time, not just FSF folks), but I don't seem to be able to Google it up any more. > > (I've heard claims that UofC's relicensing was based more on the fact > > that the clause is probably unenforcable than the FSF's practical > > complaints. I don't know if that's true.) > > Well, if that's true, perhaps it could be even more convincing... I've read many varieties of reasoning for it, ranging from "Agreed with the FSF" to "Got tired of the FSF nagging" to "Decided it was probably unenforceable" (often in combination with one or both of the first two) to "wanted to re-incorporate code and not have to publish a list of 50+ people in their advertising". In general, I find the two most persuasive arguments to current licensors, as a rule, are: 1) It becomes cumbersome and difficult to maintain and update a list of every possible clause in every license (and some licensors have as many as 3 or 4 *different* wordings in a single source tree, if they changed how they wrote their license over time). This eventually encourages folks to simply rewrite code under a license that lacks these problems, rather than reuse old code (thus meaning that the intended result - credit for one's work 'in the wild' - is lost anyway). The fact that distributions with extremely widely published source are the rule, more than the exception, these days helps with this - because it means that the copyright notice will normally be present and visible to anyone who wants to go looking for it. 2) It causes gratuitous incompatibility with code under the GPL that is not triggered by the 3-clause version. The strength of this argument can vary a lot; it helps to know your audience (if talking to a serious BSD bigot, this could *hurt* your case, because they often froth at the mouth and consider anything that harms the propagation of the GPL to be a good thing, and don't want their code "infected" by it). ) And, of course, there's always the issue of peer pressure. "Well, the Regents did it, and have all found it a compelling enough argument to do so; really, what do you have to lose?" Along the lines of this last point, it helps if you can expound on it from a position of "I contribute to the BSD project(s), and I use <2/3>-clause BSD because it makes everyone's lives simpler in that context" (me, I use the 3-clause BSD, MIT, or Boost licenses, as a rule, depending on just how much I care about the time I put into the code and what audience and purpose I am publishing it for). People are often happier to follow a good example, and feel less like you're just preaching at them to get something you want out of them. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: flowc license
On Sat, Feb 12, 2005 at 04:49:23PM +0100, Florian Weimer wrote: > * Joel Aelwyn: > > > 4) The DFSG tradition is muddy (at best) on whether it refers to the > > 4-clause or 3-clause variant of the license - > > It's pretty clear: The DFSG are older than the wide-spread adoption of > the 3-clause BSD license. Until UC Berkeley relicensed the Berkeley > Software Distribution under the 3-clause variant, our web pages > reproduced the 4-clause variant. > > Other licenses also contain advertising clauses, and are still deemed > DFSG-free. I know of at least 2 people who were under the impression that it was talking about the 3-clause variant, when they agreed to the Social Contract and DFSG. While both parties accepted the correction with good grace, it is not so self-evident as one might assume (I'm not arguing that it doesn't refer to the 4-clause, but I'm also not going to argue that that might have been based on things that would not, perhaps, be argued the same way today). And, in practice, a lot of it still boils down to what the copyright holder views the *practical* requirements of fufilling the clause to mean. If it means "make sure the phrase appears in the debian/copyright file", that's not terribly onerous. If it means "Make sure the clause appears on your website in a prominent place, and on all flyers promoting Debian's presence at a trade show or other event", that could be a lot less practical. To date, thankfully, I have not run into a licensor that required the latter, and many don't even require the former (though in practice, I try to make a good faith effort to put it there, as the most public place that is guaranteed to be present). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: flowc license
On Mon, Feb 07, 2005 at 08:32:32PM +0100, Florian Weimer wrote: > * Radu Spineanu: > > > I was looking over flowc[1], and wondering if i could package > > it. However i am not sure about the license[2]. It contains some > > restrictions about distribution: > > > > '3. All advertising materials mentioning features or use of this > > software must display the following acknowledgment: "This product > > includes software developed by the Uninet Ltd and Taras Shevchenko Kiev > > University".' is one of them. > > This was part of the original BSD license, which is considered DFSG-free > by tradition. > > > As i understand i have to add that acknowledgment in the description > > field, no ? > > I don't think so. This issue comes up periodically, especially when dealing with ancient BSD-ish code. I'm still in the process of dealing with something like 15,000 files under such licenses (NetBSD source tree). The short summary, as best I can make out from past debian-legal, is: 1) Definitely GPL incompatible. 2) Distasteful to many. 3) Either very trivial or very difficult for Debian to fufill, depending on what the copyright holder considers 'advertising materials mentioning features or use of this software'. 4) The DFSG tradition is muddy (at best) on whether it refers to the 4-clause or 3-clause variant of the license - and what people viewed it as when they agreed to abide by the DFSG may have changed over time. Due to 1-4, whether it's permitted is a hazy question at best, and probably needs *at least* a clarification from the copyright holder about what they consider to be relevant to fufilling clause 3. But in my experience, when contacting authors, a great many of them simply copied boilerplate from an old BSD license, and if you discuss with them the rationale given by the University of California when they mass-retroactively-relicensed from the 4-clause to 3-clause license, they may well be quite happy to relicense. They may not bother to do an update release just for that, but a permission statement saying that it is retroactively relicensed to the 3-clause, more permissive license which goes into the copyright file, and a note that the next release should have the updated copyright notices/licenses, will generally suffice for Debian. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: a right to privacy is not in the DFSG, therfore you don't have one
On Mon, Jan 31, 2005 at 02:08:30PM -0500, Branden Robinson wrote:
> Your papers are not in order, citizen...
*shuffles, represents* Better? :)
> On Fri, Jan 21, 2005 at 10:04:25PM -0700, Joel Aelwyn wrote:
> > All in all, I think that Branden's fifth freedom[1] is important, and
> > should come into play here. Privacy in one's person includes fundamental
> [...]
> > [1] http://lists.debian.org/debian-legal/2003/06/msg00096.html
>
> Ah, but my fifth freedom is not in the DFSG, so under the nouveau scheme
> of license analysis that some would have us apply, we are morally obliged
> to completely disregard it.
Yes, and no. I wasn't arguing that it made it directly and precisely
DFSG-nonfree. However, as has been pointed out many times, the G is for
Guidelines, and debian-legal has rendered opinions about "This seems to
miss the point even while complying with the letter". The fifth freedom may
not yet be enshrined at the same level as other things, but I do find it
a useful guideline for asking "Does this impinge on a freedom many people
seem to value?"
Certainly I wouldn't claim that it is, alone, sufficient to declare a
license wholly non-free, but it might be enough to raise more questions
(such as 'do the upstream authors consider pseudonyms and obviously false
addresses sufficient' - if they do, then at least for this case, it
wouldn't be an issue).
> Thanks for the props, however. I continue to believe that a DFSG analysis
> is the *beginning* of a process of understanding whether something is free
> software or not, not a substitute for the whole thing. Certain well-known
> people in the project have stridently insisted to me, however, that this
> opinion puts me into an extremely small minority.
>
> I think signify[1] has shown artificial intelligence again -- there is
> indeed a tension between the literal-minded DFSG fundamentalists ("if the
> DFSG doesn't mention it, it must be free") and those who actually cogitate
> openly about what the DFSG was written to defend, and how it's going to
> take more than a list propositions recited by rote to uphold our freedoms.
>
> What is the virtue that DFSG strict constructionists are upholding? Low
> mailing list traffic? Developer laziness? Ignorance of legal issues that
> affect the work we do? The spread of Debian main across as many UDFs as
> possible in the next release?
>
> Are these things really more important to us than freedom?
>
> [1] http://packages.debian.org/unstable/mail/signify
Hmm. I must look into signify. Definitely. :)
My personal opinion is that the counter of "should this be reasonable to
expect of people so I don't get more support mail" is worth evaluating; the
question, in this case, may well be "neither is automatically protected,
but which one seems more valuble to protect? And is that important enough
to warrant declaring it non-free?"
I know my answer, but I'm also personally biased in favor of pseudonyms,
since there are STILL documents from my (not-quite-)mis-spent youth
floating around the net that talk about things that might well become
illegal if the US Govt has it's way with the first amendment.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, Jan 21, 2005 at 10:55:13PM -0500, Walter Landry wrote: > Joel Aelwyn <[EMAIL PROTECTED]> wrote: > > > > See above. This is really getting quite silly. We have strong reason to > > believe that the Kaffe folks *do not* interpret the GPL as contaminating > > things which are run within Kaffe (with the possible exception of things > > that use JNI calls to accomplish things which are not possible in other > > JVMs, if any such exist). > > Actually, the problem is that we don't. For some of the authors, we > have that information, but far from all of them. Yes, actually, we do - but perhaps not in the way you're thinking. *) The FAQ, which one would hope they have all read since it's still up, and they're still authoring for it, basically says this. *) The only participant to date, while only a single author, certainly strongly affirms it. *) Nobody has produced any statement from the contrary from any of them. Given that #3 implies that the worst case we know of is 'neutral', and we have one strong indication that they're OK with it and one flat-out statement that they are by someone involved, I fail to see why we should believe that this is not their intent until someone can document otherwise in some suitable fashion. I agree it would be *nice* of them to make it a moot point by updating their licensing, but given that it can be a hassle, and the only one talking considers it a no-op, I can see why they haven't bothered. I do wish they'd reconsider this position, just to make everyone's life easier in the long run. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Need to Identify Contributions and the Dissident Test
On Fri, Jan 21, 2005 at 12:52:45PM -0800, Don Armstrong wrote:
> On Fri, 21 Jan 2005, Joel Aelwyn wrote:
> > As others have pointed out, Dissident vs. Desert Island are somewhat
> > different tests. However, I guess it really depends on what
> > information is required by #3, in the intent of the author.
>
> Yes, they sort of grew out of each other, though.[1] [The weak form
> (no compelled release of information to peopple not in the
> distribution path) of the dissident test is equivalent to the dsert
> island test.]
Hmmm. I would argue that it both is, and isn't - in a strictly denotative
sense, you are quite correct; if it boils down to "No requirement to
notify someone not in the information flow", it's Desert, and if it's "No
requirement to notify anyone at all" it's Dissident.
However, connotatively, they do differ. Look at the names of the tests, and
consider the examples normally given to illustrate them. In the first case
(Desert Island), this is about a practical issue - it may be physically
impossible, in some situations, to notify a third party, even when the
second party is quite accessible (in some cases, such as a corporate
copyright and notification requirement, it may become literally impossible
if the corporation is dissolved; the copyright might be sold off, but that
doesn't automatically change the license terms).
The second, the Dissident test, could be argued to be about practicality as
well ("It isn't practical to get authors killed" - or jailed, or whatever),
but it is far more often (in my experience, anyway) laid out as a moral
or ethical argument based on a presumed right to basic privacy in one's
affairs.
Thus, there is some room to argue that even the 'weak form' of the
Dissident test is not actually the same test as the Desert Island
test, though it is effectively a moot point because, in practice, the
requirements are identical.
> > If, on the other hand, it seeks to establish a valid and useful
> > contact address (as appears, on the face of it, to be the intent,
> > since it says 'for support', and an address which cannot be used for
> > obtaining support is useless for that), I have to think it it fails
> > the Dissident test fairly obviously.
>
> My primary purpose here is lies with the identity part of the
> dissident test. That is, to hash out where the balance lies between
> the interests of free software (ie, a desire to know who is
> contributing what for copyright and licensing purposes) and anonymity.
>
> That this license requires individuals to identify themselves to
> whoever they distribute modifications to, and that this violates the
> strong form of the dissident test, I concur completely.
Speaking from the point of experience which many have (that is, having
had to try to track down authors who are unresponsive, possibly
non-existant, or in at least one case, deceased, for licensing issues),
all I can say is that I still believe the Dissident test is a suitable
requirement.
Requiring that changes be marked and noted is about correct attribution
(in particular, about *not* attributing changed code/docs/etc to the
origional author, who may think they stink, are full of bugs, or
whatever). Requiring that they indicate who *actually* wrote it is, in
so many words, "pretty much useless". After all, outside of Debian
itself (which has the signed-by-a-Debian-Developer web of trust that
tries to establish some basic identity), I have no proof whatsoever that
any given author ever even existed, short of a lot of research (and even
that may not suffice). Would you assume "Copyright 2005 John Smith" was
valid? It could be, my ex-supervisor has that on all of his code,
because that is, in fact, his name. Good luck determining whether it's
his, or that of some other random John Smith who writes software.
Okay, I suppose that isn't true; I've met ESR, RMS, and Larry Wall in
person (if quite briefly), so I'm fairly sure people using those names
who match the publicity photos (such as there are) exist, and quite sure
that whomever was using those names that day espoused opinions that seemed
consistant with those associated with the names I see online. But still.
Print authors have used pen names for hundreds of years, and often for very
good reason. Would you demand that they not do so, simply so that you could
track them down to ask them about licensing a publication of their book in
online form more easily?
I think it would behoove us to never forget one thing - while we may set
the terms on which we distribute software, we are also being given a gift
of someone's time and effort. If they choose not to give more than that,
well, as people have so vehemently pointed out about DDs, "You can't make
a volunteer do anything."
Re: Need to Identify Contributions and the Dissident Test
On Thu, Jan 20, 2005 at 05:09:03PM -0800, Don Armstrong wrote: > On Thu, 20 Jan 2005, Henning Makholm wrote: > > Scripsit Don Armstrong <[EMAIL PROTECTED]> > > > Permission to distribute binaries produced by compiling modified > > > sources is granted, provided you > > >1. distribute the corresponding source modifications from the > > > released version in the form of a patch file along with the > > > binaries, > > >2. add special version identification to distinguish your version > > > in addition to the base release version number, > > >3. provide your name and address as the primary contact for the > > > support of your modified version, and > > >4. retain our contact information in regard to use of the base > > > software. > > > > > > (3) seems to fail the Dissident test. > > This particular extension of the dissident test has always bothered > me, which is one reason why I've never applied it in my own arguments > of why a license is Free or not free. As others have pointed out, Dissident vs. Desert Island are somewhat different tests. However, I guess it really depends on what information is required by #3, in the intent of the author. If I can write in "Joe Q <[EMAIL PROTECTED]>, Erehwon Station, LEO, Terra, Sol, <>" or something similarly non-incriminating, then it passes Dissident (I still think it's stupid, but you'd already have to make up a nom-de-code (?) for the copyright notice, and we allow that, adding a useless address isn't any more onerous a requirement. If, on the other hand, it seeks to establish a valid and useful contact address (as appears, on the face of it, to be the intent, since it says 'for support', and an address which cannot be used for obtaining support is useless for that), I have to think it it fails the Dissident test fairly obviously. A lot of things I may not agree with the FSF about, but "freedom from having to divulge information about possessing a copy" or however it is actually worded seems extremely valuble to my sometimes anarchic sensibilities. If I'd rather have anonymity than credit, nothing should stop me from publishing my changes for the good of all free software. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Wed, Jan 19, 2005 at 01:07:16AM -0500, Brian Thomas Sniffen wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > On Fri, Jan 14, 2005 at 11:41:41PM -0500, Brian Thomas Sniffen wrote: > >> Joel Aelwyn <[EMAIL PROTECTED]> writes: > >> > >> > The user has T installed, and types "apt-get install noteclipse". Since > >> > >> Does this also answer the case of Debian CDs? > > > > It answers it in precisely the same fashion that it answers the main > > archive. If you have something installed which meets the dependancies > > already, our tools do not, by default, install something *else* (say, > > Kaffe) to try to meet them. > > But the Debian CDs have nothing to do with the Depends-based tools. > It's just a work containing copies of Kaffe and (soon) Eclipse in > closer proximity than aggregation. I have yet to see any convincing argument that it is not, in fact, mere aggregation, except for "we provide metadata" - which is exactly what the Depends discussion is about. The metadata we provide says exactly two things: 1) Anything which provides java2-runtime will suffice (this happens to include Kaffe, along with many other things) 2) Because our tools are limited and imperfect, we must give a hint to them about what might be prefferable for resolving the above if more than one thing can do it (as is the case). Kaffe is free, and the packager of Eclipse apparently thinks it's a good choice for a hint. If you'd like to see something else hinted here, file a wishlist bug and provide reasoning, but this is a technical consideration, not a legal one. > > This does depend on the accuracy of the Depends line. If something > > uses native (JNI) library calls that are not standardized across some > > significantly-multiple set of JVMs, that Depends is not going to be correct > > if it just says "kaffe | virtual-package-for-jvms", since most things that > > provide the latter don't provide the necessary JNI calls. > > > > If it *is* accurate, that means the whole damned thing is programmed to an > > API that is *not* owned by Kaffe (namely, the Java language standards), but > > rather, is implemented by Kaffe, and this means it cannot be a derivative > > work of Kaffe. > > It's not about a derivative work or ownership of an API. It's just > about distributing copies of Kaffe with copies of non-GPL'd works. See above. This is really getting quite silly. We have strong reason to believe that the Kaffe folks *do not* interpret the GPL as contaminating things which are run within Kaffe (with the possible exception of things that use JNI calls to accomplish things which are not possible in other JVMs, if any such exist). As such, stretching to try to prove there's a problem where even the copyright holder believes there isn't one, and which is built on tenuous arguments which appear to contradict case law in the country where those arguments origionate, is getting into a state beyond ludicrous. We've gone to plaid. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Sun, Jan 16, 2005 at 03:15:23AM -0500, Brian Thomas Sniffen wrote: > > I think most of those are just aggregation on a medium of > distribution. Only the tree of dependencies has to be checked. So what you're saying is that "Depends: java2-runtime" is fine, but "Depends: kaffe | java2-runtime" is not? Arguing that it triggers and then violates the GPL because of a minor limitation in one of our package retrieval tools, such that it requires hinting to resolve otherwise random situations, seems like something of a stretch to me. Again: Eclipse will install and run just fine with no traces of Kaffe anywhere on the system, using "apt-get install eclipse", at least on my system. All it requires is that there be some other JVM present to run it. Proof by demonstration that neither Eclipse, the Eclipse package, nor Debian as a whole are derivative works of Kaffe... they keep working even if it doesn't appear, anywhere. If it would make you happy, you may feel free to install the following software on your system so that there is an alternative JVM, and Kaffe won't be the only one. #! /bin/sh exit 0 Usefulness not guaranteed, but it *is* capable of interpreting a Java bytecode sequence (for values of 'interpret' equivalent to 'ignore'). Actually, that's probably more closely tied to it than Kaffe would be, because it doesn't attempt to implement the formal API spec, so anything which makes use of it's behavior is relying on non-standard behaviors, and is thus truly dependant on it... -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, Jan 14, 2005 at 11:41:41PM -0500, Brian Thomas Sniffen wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > > > The user has T installed, and types "apt-get install noteclipse". Since > > Does this also answer the case of Debian CDs? It answers it in precisely the same fashion that it answers the main archive. If you have something installed which meets the dependancies already, our tools do not, by default, install something *else* (say, Kaffe) to try to meet them. This does depend on the accuracy of the Depends line. If something uses native (JNI) library calls that are not standardized across some significantly-multiple set of JVMs, that Depends is not going to be correct if it just says "kaffe | virtual-package-for-jvms", since most things that provide the latter don't provide the necessary JNI calls. If it *is* accurate, that means the whole damned thing is programmed to an API that is *not* owned by Kaffe (namely, the Java language standards), but rather, is implemented by Kaffe, and this means it cannot be a derivative work of Kaffe. (I, for one, have never bought the "magical exec() boundary" FSF argument; an API is a natural barrier which can be fairly straightforwardly tested and is covered by fairly well understood precedents already. *Especially* if that API happens to be outside the domain of either of the parts involved.) -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, Jan 14, 2005 at 01:39:09PM -0500, Brian Thomas Sniffen wrote: > > But what ends up on the user's Debian system when he types "apt-get > install eclipse; eclipse" is a program incorporating a JVM and many > libraries. Debian's not just distributing Eclipse or just > distributing Kaffe -- the idea is that we'll be distributing the > Debian OS which includes both, linked together. You keep saying that. I do not think it means what you think it means. Consider, for example, the trivial case as follows: The package 'NotEclipse', with a Depends line 'kaffe | java-thingy', where 'java-thingy' is a virtual package and Kaffee Provides it, but is not the *only* thing which provides it found in main (since contrib and non-free are not, by our own assertions, "part of Debian", we cannot consider them for this purpose); let's say that T (since R is already taken) is also capable of providing the required functionality. The user has T installed, and types "apt-get install noteclipse". Since the java-thingy dependancy is already met, kaffe *is not installed* in this case. So "what ends up on the user's Debian system" does not, in fact, involve Kaffe whatsoever. I'm not going to bother going into the "incorporating a JVM" argument here, others have done it far better already. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Fri, Jan 14, 2005 at 01:39:09PM -0500, Brian Thomas Sniffen wrote: > > But what ends up on the user's Debian system when he types "apt-get > install eclipse; eclipse" is a program incorporating a JVM and many > libraries. Debian's not just distributing Eclipse or just > distributing Kaffe -- the idea is that we'll be distributing the > Debian OS which includes both, linked together. You keep saying that. I do not think it means what you think it means. Consider, for example, the trivial case as follows: The package 'NotEclipse', with a Depends line 'kaffe | java-thingy', where 'java-thingy' is a virtual package and Kaffee Provides it, but is not the *only* thing which provides it found in main (since contrib and non-free are not, by our own assertions, "part of Debian", we cannot consider them for this purpose); let's say that T (since R is already taken) is also capable of providing the required functionality. The user has T installed, and types "apt-get install noteclipse". Since the java-thingy dependancy is already met, kaffe *is not installed* in this case. So "what ends up on the user's Debian system" does not, in fact, involve Kaffe whatsoever. I'm not going to bother going into the "incorporating a JVM" argument here, others have done it far better already. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 12:21:51PM -0500, Brian Thomas Sniffen wrote:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
>
> > The program vim contains a list of function names, all of which are
> > found in the ISO C standard, or in one of POSIX, SuS etc. It also
> > mentions a soname similar to libc.so.6. Please explain how that can
> > form a copy of libc.
>
> That doesn't. The actual copy of libc there on disk and loaded into
> memory does. The fact that the collection of programs {vim, emacs,
> tcsh} has had the common factor libc compressed out has nothing to do
> with it.
You mean libc.so.12, as found on my Nienna system?
(Okay, so I haven't got all the build dependancies for vim completed yet,
but somehow, I have a sneaking suspicion that GNU libc will, oddly enough,
utterly fail to appear anywhere when I get that far; certainly it doesn't
on nvi...)
> > In the case of Java, the binding is even looser. A class might
> > contain references to other classes which the JVM is free to look for
> > anywhere it pleases. AFAIK, Eclipse uses only the standard Java API
> > as published by Sun, and will run equally well with any implementation
> > of said interface.
>
> Great -- which implementation does Debian ship it with? That's all
> that really matters.
Excellent question. See above (for some value of 'ship' and 'Debian'
which is not yet official, but certainly aims to be when complete).
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
Re: Eclipse 3.0 Running ILLEGALY on Kaffe
On Thu, Jan 13, 2005 at 12:21:51PM -0500, Brian Thomas Sniffen wrote:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
>
> > The program vim contains a list of function names, all of which are
> > found in the ISO C standard, or in one of POSIX, SuS etc. It also
> > mentions a soname similar to libc.so.6. Please explain how that can
> > form a copy of libc.
>
> That doesn't. The actual copy of libc there on disk and loaded into
> memory does. The fact that the collection of programs {vim, emacs,
> tcsh} has had the common factor libc compressed out has nothing to do
> with it.
You mean libc.so.12, as found on my Nienna system?
(Okay, so I haven't got all the build dependancies for vim completed yet,
but somehow, I have a sneaking suspicion that GNU libc will, oddly enough,
utterly fail to appear anywhere when I get that far; certainly it doesn't
on nvi...)
> > In the case of Java, the binding is even looser. A class might
> > contain references to other classes which the JVM is free to look for
> > anywhere it pleases. AFAIK, Eclipse uses only the standard Java API
> > as published by Sun, and will run equally well with any implementation
> > of said interface.
>
> Great -- which implementation does Debian ship it with? That's all
> that really matters.
Excellent question. See above (for some value of 'ship' and 'Debian'
which is not yet official, but certainly aims to be when complete).
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
Re: More mmcache concerns
On Thu, Jan 06, 2005 at 11:14:45AM +, Andrew Suffield wrote: > On Wed, Jan 05, 2005 at 07:57:12PM -0800, Elizabeth Fong wrote: > > Jonathan Oxer: > > > The big question though (and this is where legal advice may be required) > > > is what happens to copyright when the copyright owner ceases to exist? > > It is auctioned off by the liquidators, along with all other property > of the defunct company. Somebody probably owns it. Probably somebody > with no conception of what they own (things of little or no value are > usually auctioned in large batches just to get rid of them). You'll > also probably never find out who, unless it gets acquired by a > litigation company (like SCO). > > In the unlikely event that nobody bought it, the details vary with > jurisdiction. For example, in the UK, it would revert to the crown (I > think). > > > > According to copyright law the copyright for works made "for hire" > > > exists for 95 years from the date of publication or 120 years from the > > > date of creation, whichever is shorter. > > > It's considered "work for hire" so unless he had a > > > contract with Turcksoft to the contrary he is *not* the copyright > > > holder. > > > > So... I guess the question is, what _can_ we do? > > Wait about a century for copyright to expire and hope that it doesn't > get extended again. Or convince someone (quite possibly the origional author) that it is worth their time to re-implement it. Doing work for hire means you don't own that copy, but it is in no way a prohibition against you making another copy on your own time, even if it were to look almost completely identical. That whole "origional authorship" defense, after all (which is why so many companies use NDAs, non-compete agreements, the infamous "We own your firstborn and any code you write on your own time" clause, and other such to try to protect themselves from you writing a duplicate work in your own time, at home, based on the experience you gained while they paid you to develop it). Whether it IS worth it or not... that's another question entirely. :) -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: mozilla thunderbird trademark restrictions / still dfsg free?
On Mon, Jan 03, 2005 at 11:56:24PM -0500, Brian Thomas Sniffen wrote: > Gervase Markham <[EMAIL PROTECTED]> writes: > > > We're happy to say that Debian doesn't tend to ship software that > > sucks - but you want the freedom to do so, and let others do so. And I > > understand that. :-) > > Here's an idea: a source package that builds either Thunderbird for > Debian or Lightningferret, a trademark-free version -- and defaults to > the latter, except on Debian autobuilders. The real source to build > the Thunderbird for Debian version is there, and it's a trivial > switch. But the work of producing a free-to-suck version is already > done. > > For reasons I can't fully articulate, I don't think that's a good > idea: source packages should be the plain and simple source of the > binaries produced. But I'm curious whether it would be accepted as > Free by debian-legal. What the package actually does is orthogonal to what rights are available, other than the former being bounded by the latter (at least we hope it is). If those rights are not available - under the same terms - to our downstreams (be they users, custom distros... whatever), then by the spirit of DFSG #8 (at least IMO), we shouldn't be able to make use of them either. Beyond that, alternate package building paths for reasons other than purely technical (debug libraries and the like) are just a Bad Idea. If it isn't of use to build a Debian package - or to let anyone else build the exact same package and distribute it just as we do - then, as a rule, it shouldn't be in the package; it's cruft. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Trademarks: what is the line?
On Sun, Jan 02, 2005 at 12:06:06PM +0100, Francesco Poli wrote: > On Fri, 31 Dec 2004 12:44:33 + Andrew Suffield wrote: > > > It's not a major problem, because you can generate an unarguably free > > work once by stripping it, and then everybody can modify the stripped > > version instead. > > That's true, but... > ...what's the difference between a trademark-encumbered work and a > patent-encumbered one? > > If I take a patent-encumbered work released under a free copyright > license, I can generate an unarguably free work by stripping the > patented algorithms and replacing them with non-patented ones: then > everybody can deal with the stripped version... > > Don't misunderstand me, it's *not* sarcasm: I'm really wondering what's > the difference... The *likely* primary difference is that trademarks are, *almost* always, not relevant to the functionality of the program as a whole. In the cases where they were, somehow (and I'm hard pressed to come up with one) I would expect that the trademark license would be required to be licensed in a sufficiently free manner that it wouldn't be an issue. Patented algorithms, on the other hand, are often the very core of the program involved - and thus, stripping and replacing them is often impractical, or in some cases, impossible (if the patent covers the entire concept of the program's usage, and not just a specific way of accomplishing it). If the patent were on some tertiary function that could be trivially done another way, well, I'd expect we might well strip it and replace it to avoid issues with an actively enforced patent, but this seems unlikely to be the case anytime soon (given how broad software patents often are). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Trademarks: what is the line?
On Sun, Jan 02, 2005 at 12:25:25PM +0100, Francesco Poli wrote:
>
> Yes, but is requiring a global replacing of trademarked strings and
> images acceptable?
>
> I mean: it seems that Mozilla is requiring us
>
> * either to comply with strict modification constraints
>
> * or to replace every and each trademarked reference to the work with
> something else
>
> First option seems unacceptable (we couldn't even patch for security
> reasons before they decide to release a new version, correct me if I'm
> wrong).
>
> Second option would require the Debian package maintainer to dig into
> the source and play "seek & destroy" with all cases in which the work is
> referenced as "Mozilla {thunderbird|firefox}" or in which the official
> logo is used...
> This seems a bit more than requiring a name change (per DFSG 4).
Just as "sweat of the brow" is not copyrightable (in the US), Debian has
not, to the best of my knowledge, ever declared a package "non-free"
because it was too much trouble to do something that was legal and would
render it free. Certainly, the unmodified version may be non-free, and it
may not be *worth our while* to make a free variant, if nobody is willing
to volunteer to do it - but that isn't the same thing as the theoretical
stripped version not being free. It's only "not being worth the trouble"
(and implies that if, say, someone over at Fedora stripped it and published
the stripped tarball, we could potentially start from that point, even if
our maintainer hadn't done the work).
Of course, history has demonstrated that we often can find someone who
cares enough to do the gruntwork. But not having that isn't a matter of
freeness, only a matter of whether it is worth our bother.
--
Joel Aelwyn <[EMAIL PROTECTED]> ,''`.
: :' :
`. `'
`-
signature.asc
Description: Digital signature
Re: Strange restrictions
On Sun, Jan 02, 2005 at 10:41:08AM -0500, Dave Harding wrote: > Andrew Suffield wrote: > > On Sun, Jan 02, 2005 at 12:59:08AM -0700, Joel Aelwyn wrote: > > > Mind you, I don't think I'd necessarily have an issue with "To use > > > this trademark, you must run a publically reviewable bug tracking > > > system and implement some form of version management" (I might > > > still, on a question of practicality, or even a basic question of > > > "Does this make it a required cost of the software, and is that > > > OK?", but it would be a matter of another debate entirely, at that > > > point). > > > > The problem with this sort of clause is usually the same: what the > > hell does it mean? > > Or rather, what does it have to do with Mozilla's requirements? > > Gervase Markham <[EMAIL PROTECTED]> on Sat, 01 Jan 2005 10:06:17 -0500 > said: > > So we have to therefore say "beyond a certain level of change, > please remove our trademarks". > > What purpose is served by Mozilla licensing the trademark under terms > only requiring a BTS and a RCS? Any schmuck can distribute a broken or > otherwise undesirable Mozilla *and* fulfill those terms. > > I believe Gerv states that he has confidence in Debian's commitment to > creating a high-quality mozilla-* packages, not that anyone who has the > same infrastructure as Debian will do the same. > > -Dave I haven't seen Mr. Suffield's message arrive here, but I'll reply to this one for now. What it means is simply "I was trying to come up with an example of a quantifiable requirement that could reasonably be met by our downstream users/distributions". I'm not even certain they *are* reasonable, mind you, or that I'd be OK with them, and I suspect that it is a moot issue for the very reasons you cite - enforcing anything short of complete review by Mozilla is insufficient, and that approval method inherently cannot be transitory or public for others (since others can make arbitrary changes, saying "You started from a Debian base" is useless, even if it's trivially meetable as a requirement in most cases). I become more convinced, each time I go into anything about this, that the simpler part of valor (I'm still unsure about 'best') is going to be the iceweasel route. With all due respect to the Mozilla folks, while I understand their desires regarding their trademark(s), I'm less and less convinced that they are compatible with Debian's core goals, and as such, simply circumventing the issue entirely is liable to produce less convoluted, brain-twisting attempts to both meet their requirements and remain honest to the DFSG. Thankfully, they support the very concept, or seem willing to, and so I have some hope that this need not turn into an ugly fracas with people shouting "Not Free!" "Free!" "Not Free!" "Free!" at each other across picket lines. Or whatever. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Mozilla and Trademarks
On Sat, Jan 01, 2005 at 07:49:15PM +, Gervase Markham wrote:
> Joel Aelwyn wrote:
>
> > First, having such a trademark license establishes the Mozilla project
> > as an arbiter of package quality for a Debian package.
>
> Indeed. With all the caveats that you state, then yes, when it comes
> down to it, it does. It has to, in order for us to claim that we're
> maintaining our trademark as a mark of quality.
At least we agree on the intent; whether or not Debian can accept that is,
of course, a matter for discussion. But I'm glad to establish that bounding
point.
> > Second, with all due respect to the current Mozilla project, even if
> > we trust that they are reasonable enough, today, to not worry about
> > the first point, do we trust that *the holder of the trademark* will
> > be reasonable enough *for as long as we want to distribute the
> > package*? If it somehow got sold, well, the new TM holder could be
> > make life very unpleasant (OK, so this is true for any trademark, but
> > given Mozilla's heritage and the commercial interest in web browsers,
> > I have to consider it more of a risk that this might happen for them,
> > than for JoeBob's AlienKiller game).
>
> Again, a fair point. Although the impact of this event is arguably less
> than the same issue with a code licence. After all, if the code licensor
> (e.g. UWash) goes bad on you, that's the end of the package. If the
> trademark licensor goes bad, you just need to make some modifications to
> the package. (There may be issues with the actual package name here, but
> let's leave that for now.) Said modifications are pretty easy to make in
> our case (Netscape makes them, for example, to rebrand.)
The impact is, indeed, less; the worst case of a copyright license produces
an undistributable package, while the worst case with a trademark (unless
it is somehow tied into other bits) is that we have to purge any relevant
pieces of the package, which may, or may not, render the rest of it "not
terribly useful" (in the case of Mozilla, it seems likely to remain quite
useful, even if that purge could involve a fair bit of effort).
> > Third, to be honest, while I appreciate (and, in fact, am flattered
> > by) the implication that Mr. Markham, and presumably some significant
> > portion of the rest of the Mozilla project,
>
> Well, I speak for myself, insofar as I'm permitted discretion to
> negotiate on trademark issues. I don't speak for any other named people
> in the project in this matter :-)
So noted.
> > feel that Debian's QA track record is
> > sufficiently good to allow us some amount of extra leeway in the
> > question of quality packages, it smacks of a Debian-specific license,
> > something which is explicitly forbidden by the DFSG.
>
> Is DFSG 8 actually a problem here?
>
> "The rights attached to the program must not depend on the program's
> being part of a Debian system. If the program is extracted from Debian
> and used or distributed without Debian but otherwise within the terms of
> the program's license, all parties to whom the program is redistributed
> should have the same rights as those that are granted in conjunction
> with the Debian system."
>
> Is it understood that this applies to all rights which go with the
> program, and not just copyrights? Even if it is, distribution outside
> the Debian system with the trademarks attached would still have to
> conform to all applicable laws, including trademark law - although it's
> not Debian's responsibility to enforce that. In other words,
> distribution both inside and outside of Debian would require equally a
> trademark agreement.
I think the key here is the 'Guidelines' part. Personally, I take a
fairly broad interpretation of what "rights" must be available to those
we distribute to, though it must, of course, always be bounded by common
sense. However, the intent of DFSG #8 is that I, as a member of Debian,
can hand my housemate, a Debian user, a copy of the full distribution, and
he can turn around and do anything with it that the Debian Project did in
the first place - including "make modifications to packages", "establish
a bug tracking service", "translate package names", "compile for other
architectures"... whatever he wants to do, within the same bounds that we
as a project operate.
If there are concrete terms which allow the use of a trademark ("you must
pass this test suite", "you must hop on one foot for 2 hours a day", "your
first name must be Fred") which the project can reasonably meet, and expect
it's users to meet (in practice, thi
Re: Mozilla and Trademarks
I'm going to reply, in some sense, to Gervase Markham's message, but it is in more of a general vein, rather than a point by point discussion. Still my thoughts on the same basic topics, though. While I appreciate Mr. Markham's efforts, and in fact I don't disagree with what I believe are his views overall (that it would be possible, and even a good thing from the Mozilla project's point of view, for Debian to use something along the general lines of the Community Edition standards, possibly with some additional flexibility), and I have no deep and abiding interest in either doing so, or going the iceweasel route, I suspect that the latter may be the only practical answer for a couple of reasons. First, having such a trademark license establishes the Mozilla project as an arbiter of package quality for a Debian package. Any failure to meet these standards, in their sole review, opens the door to allow them to require us to rename the package and strip all trademarks. I am not implying that they would do so lightly, or wouldn't talk to us first to try to resolve it, here; if I thought that was likely, I wouldn't be bothering with all of this, I'd just say iceweasel it. However, the fact that it is even possible is of some concern to me. It leads to some nasty pitfalls, such as "Is it within the trademark license to use the same package name for something that is completely *not* the software, and deliberately attempts to 'trick' users into installing other software when they ask for the Debian Thunderbird Community Edition (DTCE)?" (aka, "a transitional package"). We do have one potential pre-existing case (albeit not a strongly formed one, nor one in active public sight, yet) - the use of the NetBSD trademark under specifically transmittable permissions (IE, to our users), for Debian systems built on top of a kNetBSD kernel. The difference is that the NetBSD folks haven't asked for review powers beyond the right to prevent us from distributing something that would deface their trademark; their only requirement is that it be made clear that we aren't distributing "the NetBSD system", but rather, a Debian system with a NetBSD kernel/core. Even this is rather murky, and got run through SPI's counsel as far as I am aware. Second, with all due respect to the current Mozilla project, even if we trust that they are reasonable enough, today, to not worry about the first point, do we trust that *the holder of the trademark* will be reasonable enough *for as long as we want to distribute the package*? If it somehow got sold, well, the new TM holder could be make life very unpleasant (OK, so this is true for any trademark, but given Mozilla's heritage and the commercial interest in web browsers, I have to consider it more of a risk that this might happen for them, than for JoeBob's AlienKiller game). Even if it remains with the Mozilla project... who would have thought that RMS would have decided documentation doesn't need the same freedoms that software does, putting the FSF and Debian at odds over the question? Or that UWash would have come up with an extremely strange license interpretation years (IIRC) after the initial publication of Pine, in what appears to have been a desire to take the software into a restricted-modification state (oddly similar, in some ways, to what the Mozilla project wants to do, today)? Third, to be honest, while I appreciate (and, in fact, am flattered by) the implication that Mr. Markham, and presumably some significant portion of the rest of the Mozilla project, feel that Debian's QA track record is sufficiently good to allow us some amount of extra leeway in the question of quality packages, it smacks of a Debian-specific license, something which is explicitly forbidden by the DFSG. After all, "our users" can and do include people making other distributions (just look at the CDD stuff). If we, as Debian, can do something that our users can't, with the software in our archive, then it can go, at best, into non-free. Now, again, I don't think that this really needs to happen; I think we should either abide by the available licenses (possibly including one not yet written, but publically useable, if that was what Mr. Markham was implying could be done and I misunderstood it), or go the iceweasel route, rather than sticking things into non-free, which would just be silly when there are two free alternatives (even if we end up deciding that one of them doesn't meet our needs). Minor nit that may not even be true: if (and only if) we really can't name plugins, etc, "thunderbird-plugins-alienkiller", then it seems like one more reason to go the iceweasel route. Debian has a variety of naming policies among package suites, and almost all
And at night, the flaming foxes come...
On Fri, Dec 31, 2004 at 10:20:26PM -0500, Nathanael Nerode wrote: > [EMAIL PROTECTED] wrote: > >OK, let's say I rename the package to 'somebird' and want to produce a good > >package for debian. Should I use a patched orig.tar.gz or is it ok to > >distribute the source as provided by upstream (of course without the > >trademarked icons) and patch the rest (e.g. thunderbird mozilla) during > >build? > > As long as we're discussing names > > I kind of like "somebird", actually. It's cute and non-confusing. :-) > > For firefox, "iceweasel" has the amusing advantage of being directly in the > Mozilla trademark licencing policy, thanks to my use of that name really > early in the discussion. :-) It might be pretty easy to "standardize" it > among different "option 3" distributors for that reason. > > Of course, it is now in use as the abstract name for a renamed version, so > maybe it wouldn't be so good to use it for a specific version. > > A name for the suite is hard. Along similar veins, but closer, would be "icekitsune". But perhaps it doesn't flow off the tongue very well. ObGeneralTopic: I don't have a deep and abiding interest in using, or not using, the trademarked names, but for reasons I will elucidate in another thread, I suspect that the iceweasel route may be the only *practical* one for Debian to take. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
