Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: I don't think it's as simple as that. After all, Debian has a trademark policy, and restricts use of its trademarks, as does the Apache Group. Is Debian's trademark policy freedom-restricting? [...] Yes. Why do you think it's under review? It's causing some minor silly situations when it interacts with copyrights of free software. I wasn't aware it was under review. The Apache foundation have also rumbled about naming here, IIRC. I think you're nicer, so far. Thank you :-) I try. Because part of the Mozilla Foundation's strategy to raise enough money to employ people to work on the code involves leveraging the name. I think this is great - because it's not a model which restricts the freedom of the code. [...] You wrote this, but you claimed that it stops the default search engine being changed away from my favourite invite spammers g**gl* - is this a contradiction? No, at least not by my understanding of what makes code free (i.e. that it's under a Free licence). Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Firefox/Thunderbird trademarks: a proposal
Here's my attempt at something which hopefully everyone can accept. I've tried to take into account all the excellent feedback over the past few weeks, for which I thank all involved. Comments are in square brackets. This assumes that DFSG #8 means that Debian can be given rights over and above the rights necessary to make a program free, as long as all the rights necessary to make it free are transferable. 1) The Foundation grants Debian, and all redistributors of the official Debian packages of the Foundation's products, the right to label those packages with a name containing the trademark. [This document would apply to Firefox, Thunderbird, and any other trademarks on software names we may hold in future. The name would be Firefox, Community Edition or whatever is agreed between the Foundation and the maintainer. It's not important to this document.] 2) The Foundation agrees to document the procedure for changing the name to its satisfaction, for the benefit of Debian and anyone else, and to work to make that procedure as simple as possible. [This means that if you or a Debian redistributor ever has to change the name, it hopefully won't be too onerous. And it means we can't blindside anyone with 'but you forgot to change *this* instance.] 3) The Foundation will review the current Debian package at freeze time, and at other times at their discretion, and bring any issues they have to the attention of the maintainer. The maintainer is not responsible for notifying the Foundation of any changes he may make to the package, or obligated to make any change that the Foundation may suggest. However, in the unlikely event of irreconcilable differences occurring between the maintainer and the Foundation, the name of the package will have to be changed in all as-yet-unreleased versions of Debian. [This gives you a free hand over the development process, and us the oversight that we need by law to be seen to be having.] 4) The Foundation agrees not to withdraw the permission more than three months into a freeze. [This is intended to mean that we can't require an inconvenient change just when you are about to release; if we don't notice until it's too late, it's our problem. My understanding of the Debian process is not complete; 'freeze' may not be the correct term here.] 5) The Foundation agrees not to withdraw the permission for versions of the product shipping in stable releases of Debian, provided all updates to the package are within Debian's guidelines for package updates in stable releases. [You have carte blanche to make security fixes. We are happy because your own procedures say you can't gut the package and replace it with something different. And you are happy because you have to follow your own procedures anyway, so it's not a burden.] 6) The Foundation agrees that it's not Debian's responsibility to make sure the distributors of any derivative works of Debian packages have an implicit or explicit trademark license from the Foundation. [No hassle for you.] 7) The Foundation requests that Debian document, in a place where it might be seen by package modifiers, the potential need to acquire such a trademark licence. [I hope you would view such a notice as a service to your users - but distributors of modified versions may need a license whether you add the notice or not. This is hopefully in line with DFSG #4, which says that packages are free even if derived works are required to carry a different name. It is also in line with free software licenses where changes require other changes, e.g. the GPL 2a) where code changes must be documented.] Is this a runner? Gerv One final note: I can't completely exclude the possibility that someone higher up at the Foundation (e.g. Mitchell Baker) will say that I've overreached myself. But I don't know of any reason why that would be the case, and I'm negotiating in good faith. I would, of course, get a final version approved by all necessary parties :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
Walter Landry wrote: There is a difference between simple as possible and undue burden. It may turn out that as simple as possible is still hard. If it were phrased something like To change the name, the Mozilla foundation will find it sufficient to change only the single instance of the name in branding.txt. then I would be happy. It's not far off that. You should only have to change it in fingers-of-two-hands places at most; anything else is a bug. And we've committed to documenting the exact procedure. Remember, Netscape did this regularly to make Netscape releases, so we are set up for this. I talked to the other licensing guy at the Foundation tonight; we are going to look at getting someone to confirm and document the process. Given a source tarball, I would estimate 10 minutes work - perhaps a bit more if there's a graphic or two with the word Firefox in it to replace, and you count the time making new graphics. Hopefully, that's easy enough. :-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
Michael K. Edwards wrote lots of convincing arguments and then said: In this factual setting, I think it's wisest for everyone to fall back to trademark statute if the agreement falls apart. Fair enough. I'm convinced :-) Replace the name of the package will have to be changed in all as-yet-unreleased versions of Debian with permission to use the trademarks will be withdrawn for all as-yet-unreleased versions of Debian. That should deal with the issue were MJ felt it was more like a contract than a permissions grant. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
MJ Ray wrote: Should I set this in browserconfig.properties or what? about:config in your built and running copy, or one of the default preferences files (not sure which) in the source. This probably isn't the correct fix, but it's one that'll work. I mentioned it merely for information; I'm not planning to develop the instructions document by interactive trial-and-error with you on debian-legal ;-) I think you're asserting 10 minutes, but that might only be the case with intimate knowledge of the source tree. Or, perhaps, a document describing how the process is done? :-) I'm certainly not asserting that someone can download a Mozilla source tarball and, without reading any docs, figure out in 10 minutes how to rebrand it entirely. Is this enough to continue the discussion without getting stuck on this point? Of course. I'm just pointing out that this process is nowhere near done and you should not lead people to believe otherwise. I don't think I did. I said that we'd write the document, and work to fix any issues which made it harder than it needs to be. But I don't think completing this process needs to be a requirement for working out the remaining issues. I'm sceptical that it will be done quickly, because one still has to hack to get firefox builds running on multi-user systems and that's been a critical known bug for some time. So, by simple extrapolation, all important Mozilla bugs take six months to fix? ;-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
Eric Dorland wrote: Now then, I personally will not accept any deal that is Debian specific. Absolutely reasonable - it would be entirely against DFSG #8. Umm, I don't understand. You'd like to make a deal but you recognize that we can't under DFSG #8? That seems very paradoxical to me. What I meant was that your stance is absolutely reasonable. I quite understand that you don't want any deal that is Debian-specific. In any case, such a deal wouldn't be acceptable under DFSG #8. I hope that clarifies things :-) Whether or not this is actually against DFSG #8 or not is beside the point, I don't want to play if it's only because we're the popular kid. This problem goes beyond Debian. Other distributions are not going to be able to use the trademark license as written. Are you going to cut deals with Fedora, Slackware and Gentoo as well? Absolutely. Ubuntu have already been in touch, and are watching the discussion closely. And I worked out a deal with Gentoo several months ago. And what were the specifics of the deal you reached with Gentoo? It seems Gentoo would be a big problem for your QA issues since Gentoo is designed to allow you to compile it with crazy optimizations. The default Gentoo build is extremely like ours - much more so than Debian's - and uses sane compiler settings. Like the proposed agreement here, Gentoo are not responsible for people who redistribute their stuff with crazy options (although, of course, that's much rarer with Gentoo than with Debian - distributing binaries isn't their thing ;-). Such people would have to get a trademark licence from us, too, just like Debian distributors. (I believe Gentoo actually distribute with the official logos, too, but they are tied to a particular configuration in the ebuild system, and automatically get unbuilt if the build configuration changes. Very nifty.) I'm open to talking to anyone. I'm hoping that what comes out of this discussion is a fairly general trademark permission that we can execute with anyone who convinces us that they aren't going to ship rubbish with our name on. Right, but the fact is they need to seek you out to get that permission, rather than it being in the Trademark License itself. Define exactly what constitutes rubbish in the trademark license, and allow anyone who is !rubbish to use your trademark. That's what the current Community Edition requirements try to do. But, as I understand it, restrictions of that form are incompatible with the DFSG, as well as practically very difficult. The two possible approaches to this both have practical problems. If you try to enumerate all the things a person _cannot_ do if they want to use the trademark, you leave yourself open to not thinking of something they could do to screw things up. If you try and enumerate all the things a person can do and still keep using the trademark, you run into the problem that people always want to do different things. We've taken the second approach with the Community Edition stuff and, sure enough, Debian wants to do different things. So the only sensible way to manage this is to have a general policy which hopefully covers most people (the Community Edition stuff) but to negotiate on a per-instance basis with people who want to do something different (Debian, Gentoo, etc.). Perhaps you can see where I'm coming from if you think of the most complex piece of software you've written, pretend that when it starts up, it puts up a big written by Eric Dorland message, and try and write down all the things you would like people not to do to it and still have your name on the front. Would you prefer a set of technical requirements? I haven't gone down that path precisely because of the large number of DFSG issues it would immediately raise. I'm not sure why that would cause DFSG difficulties, it would still only apply to trademark. It would be wonderful if you could define in technical terms what it means to be Firefox and allow anyone who meets those requirements to use the name. (I've outlined the problems with this sort of approach above.) In contrast, my proposal contains provisions for all of the things in your bulleted list. It's really very hands-off. Right, but your proposal is Debian specific. It needs to be a more general proposal that can be included in the Trademark License so that anyone can abide by them. It's Debian-specific only in that Debian is the first group we've tried to come to this sort of arrangement with. As I said, an agreement of that form would be available to others. If you like, I could parameterise the agreement even before Debian agrees to it. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox/Thunderbird trademarks: a proposal
I must admit I'm finding this a bit frustrating. I came to debian-legal, listened to what people (including, I believe, the Thunderbird package maintainer) were saying, and drew up a document[0] which I hoped would meet Debian's requirements, further modifying it based on feedback[1]. This modified version has been approved of by at least one list member[2]. However, I am now hearing a completely different viewpoint from Eric about what sort of things are acceptable and considered DFSG-free. This is not a criticism of Eric - as Firefox package maintainer, his opinion is clearly important. But is this sort of thing merely something one has to accept when dealing with Debian, or is there anyone in authority who can actually give me a consistent story here? Who eventually decides what sort of licence is acceptable? What if the Firefox and Thunderbird maintainers have totally opposing viewpoints? What if we come up with something, and later project-wide discussion on the general issue of trademarks decides that it's in fact non-free? [0] http://lists.debian.org/debian-legal/2005/01/msg00503.html [1] http://lists.debian.org/debian-legal/2005/01/msg00780.html [2] http://lists.debian.org/debian-legal/2005/01/msg00795.html Eric Dorland wrote: Interesting. What about the case of Fedora? They've applied even more patches than Debian has to their package (at least it looked that way from what I saw). They certainly don't fall under the current trademark license. Have you approached them with an agreement? There's only one of me, and this isn't my full-time job. Debian approached us to make sure that they are doing the right thing, and this is what we are working out here. Or would you rather I did everyone else first, and left the Debian package in legal limbo? They are certainly practically very difficult, but they need not be that exhaustively precise. I certainly believe the Mozilla Foundation is acting in good faith. If the Mozilla Foundation puts the general things down it wants in the Trademark License and they apply equally to everyone, I don't see any reason we need to get too bogged down in details and semantics. Let's take just one example. The Mozilla Foundation is very keen that nothing ships as Firefox which contains spyware. How would you define spyware in a watertight way for the trademark license document? Remember, you have to get it perfectly right first time, otherwise the person exploiting the loophole you left would just say well, I'm taking my permissions under version 1.0 of the agreement, not 1.1. Well with due respect the Community Edition clause is going to be completely useless to any distro. I mean you can't even backport a security fix under it. Indeed. The Community Edition stuff is not designed for Linux distributions. Perhaps you can see where I'm coming from if you think of the most complex piece of software you've written, pretend that when it starts up, it puts up a big written by Eric Dorland message, and try and write down all the things you would like people not to do to it and still have your name on the front. I understand what you're saying, and that's why you've sought protection for your mark. In general we don't concern ourselves with trademarks since they're generally easy to circumvent (ie, rename things) if the mark holder objects to our using the name. And we will do our best to make it as easy to circumvent as possible, should anyone wish to. However, you've formalized things with your Trademark Policy. And we will do our best to abide by your wishes in that document. As the document stands we can't use your marks. If you'd like us to, (and I would like that very much), then you need to put the provisions in the trademark license, where anyone can use them. But the trademark should only be used on quality products. And defining quality for something as complex as software is an extremely difficult task. Say we wrote a test suite. What happens if Debian's change to fix multi-user stuff broke the suite? Such a thing would easily become a restriction on how you could change the code. The currently suggested mechanism imposes no such restrictions - you can make whatever changes you like. If I did have a trademark on Eric Dorland, and I didn't like what someone was doing with it, I could ask them (legally) to stop. I don't need a Trademark License to enforce that. You would rather Debian was in the situation where the Mozilla Foundation could ask them to stop using the Firefox trademark immediately and totally at any time? One of the things I thought we'd established earlier in this discussion (which you may not have seen) is that such uncertainty is not acceptable to Debian. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Legal] Firefox not truly Free?
William Ballard wrote: I don't know what to make of this statement: http://news.zdnet.co.uk/0,39020330,39189475,00.htm [quote] The main disadvantage of the deal with Google is that native language versions of Firefox are not permitted to change the default search engine to one that is more useful for searching Web pages in a particular language.[/quote] You need to not believe everything you read :-) The Mozilla Foundation has agreed with Google that official builds of Mozilla Firefox will have Google as the default search engine. We have similar deals with other search providers to be in the list. This deal is not binding on people who, for example, release a modified Firefox under the Community Edition rules (section 2 of the Trademark Policy): http://www.mozilla.org/foundation/trademarks/policy.html And, were Debian to ship a Firefox, it would not be binding on Debian. Contrary to what the article implies, native language official builds of Firefox do change the search engine to their local version of Google. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
Martin Schulze wrote: I've sent this letter to the PHP group: Dear authors, we are a group of developers that build up an entire GNU/Linux system based on the Linux kernel, GNU utilities and a lot of other software. It is named Debian GNU/Linux http://www.debian.org/, you may already have heard about it. Martin, I may not be the most tactful person in the world, not a debian-legal regular or Debian developer, but I feel I should say that if I received an email like the one you sent the PHP developers, my first reaction would be rather negative towards the author and his organisation. The attitude which came across in your email seemed to be We're the big and important Debian project, and we've been violating your licence, which is a bit of a shame, but please tell us we can keep doing so, otherwise we'll yank your software from our distribution, and you wouldn't want that, would you? As the recipient of it, I certainly wouldn't be inspired to work out a constructive solution. Perhaps it would be advisable for letters which go out carrying the authority of Debian (We are a group of developers...) to be reviewed by the list before being sent? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PHP non-free or wrongly named?
David Moreno Garza wrote: I think Joey's mail is quite good since it is just stating facts. Truth cannot be made up, specially on free software (and non-free also) legal issues. It took me a long time to learn this one, but it's true - it's not just what you say, it's the way that you say it. I have no quibble with the factual content of his mail. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL for documentation ?
Daniel Carrera wrote: I was hoping you could help me understand the implications of using the GPL for documentation: 1) The GPL language talks about software. How does that apply to something that is not software? With difficulty, IMO. Although, as someone points out, the GPL only uses the word software a few times, it is assumed throughout. For example, what do you do with a dictionary under the GPL and a word processor? Is it just data used by the program, or is it a part of it? It's really hard to figure it out, and creates uncertainty. (Mozilla/Open Office have this problem at the moment with GPLed dictionaries.) Please don't use the GPL for documentation; it wasn't designed for it. Ideally, you'd use a DFSG-free documentation-specific licence, but I seem to remember there isn't one of those. ICBW, of course. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL for documentation ?
Don Armstrong wrote: What about it? If the combination in question of the GPLed work and your work is a derived work, then the GPL covers the work as a whole. So is a WP a derived work of a dictionary? IMO, it's much harder to make this sort of judgement when you're mixing code and non-code. How does the distinction between the GPL and the LGPL apply to a dictionary? Or are the two licences the same when you are talking about something that can't in any meaningful sense be linked? If you're talking about source code, the prefered form for modification applies equally well to documentation as it does to programmatic works. Sure. I didn't say the entire thing was inapplicable. If there really is a source for confusion, then make an addendum to the license file explaining how the author views the GPL applying to the work. I seem to remember a very recent thread on d-l saying that this sort of thing was a pain because it meant everyone's licence was different. Also, if you must discourage people from using a license, please point out specific problems with the license that preclude its application to a specific class of work. Well, exhibit A in the GPL's not good for documentation discussion is the very existence of the GFDL, its freeness or otherwise notwithstanding. This means that at least one and possibly more smart free software legal minds took a long hard look at the GPL/documentation issue and decided to put a bunch of work into a more appropriate licence. I'm not convinced that was solely so they could force copies of the GNU Manifesto to be prepended to everything. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux and GPLv2
Kuno Woudt wrote: * d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. Incidentally, this is pretty badly drafted, IMO. For example: - The requirement to not remove certain particular code is probably non-free; - The general requirement to make code available for download could be asserted without the don't remove code X clause; - Specifying HTTP is not future-proof, and may not be appropriate for some programs or environments; - What happens if the program interacts with other programs over a network? How do you define interacting with a user? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL for documentation ?
Henning Makholm wrote: The word linking (or any of its forms) appears exactly once in the GPL, and that is in a non-legal, non-technical aside comment: | If your program is a subroutine library, you may consider it more | useful to permit linking proprietary applications | with the library. If this is what you want to do, use the GNU | Library General Public License instead of this License. Fair enough. Having read more widely on the subject, the problems of using the GPL specifically aren't nearly as great as I first thought. Thanks for taking the time to apply the cluestick :-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bittorrent licensing, take 2 [MPL and Jabber inside]
MJ Ray wrote: I had hoped that a Moz Found rep would tell us we've missed some obvious reason this doesn't hurt debian, but not yet. With regard to the six months requirement, does it help to point out that CVS and other source control systems are Electronic Distribution Mechanisms? Therefore, as long as whatever system Debian keeps its Mozilla modifications in is versioned and publically available, you aren't failing to meet the requirement. It might be overload, It is overload. as basic questions from 11 Feb are unanswered yet: can Gerv (or someone else, hey ho) tell us the opinions of the wider Mozilla team about debian's package names, please? I think I've already given them - we'd prefer that they be firefox and thunderbird rather than mozilla-firefox and mozilla-thunderbird. Opinions differ on whether this is something we can legally require :-). When can we expect iceweasel/FireWeb (or whatever white label browser) will be buildable from upstream sources? We are working on it, but I can't give an ETA. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: openssl vs. GPL question
Michael K. Edwards wrote: Do you know whether the NSS implementation is being certified at source code level (a very unusual arrangement) using the sort of maneuvers mentioned in the Linux Journal article on DMLSS? I'm not able to say - it's not my area. If you are interested, news://news.mozilla.org/netscape.public.mozilla.crypto is the place to ask. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mozilla relicensing progress
Branden, As I hope you've been made aware (a kind friend having texted me about the situation), I've spent the last week doing a Christian camp in France (http://www.interaction-france.org) with no net access of any kind. So I've been unable to deal with the unfortunate situation regarding your attempt to mail me about the Mozilla codebase relicensing. I can only apologise for the behaviour of the mozilla.org mail servers; their configuration is something over which I have no control. I believe that at least one other mozilla.org developer (Ben Bucksch) has objected to the denial of mail from dynamic IPs; I suspect there is a bug about the issue in http://bugzilla.mozilla.org, but I haven't been able to find it. As I understand it, the mail servers handling [EMAIL PROTECTED] have no such policy; you should be able to reach me there. Anyway... no need to apologise for sending me mail about the relicensing; that's what I'm here for :-) The current status (which I happen to have summarised recently on my blog[0]) is that we have about 2% of the code in the main Mozilla program's tree left to relicense, plus some more which is specific to Firefox, Thunderbird or Camino. This consists of files where our automated script was, for some reason, unable to correctly parse the license block. The process has been, inevitably, rather stop-start; Mozilla is not my day job, licensing work and enquiries already occupy more of my spare time (that I'd rather spend hacking) than I'd like, and the relicensing script (written in Python for historical reasons, a language with which I am not yet familiar) is maintained by someone else. Still, I've had several volunteers helping me with the remaining files, and the current bottleneck is me looking at all the patches they've sent me while I've been away. In the mean time, the mozilla.org licensing story for our products is MPL or looser; i.e. all the code in the Mozilla suite is available under at least the MPL/NPL (the differences are irrelevant these days) or a looser license such as a BSD-like one (e.g. libjpeg, libpng.) Some code may also be available under other licenses; check the file headers for details and contact us if there is any uncertainty. This situation is obviously not ideal; however, I'm sure you can see we are working to simplify things. If I can be of more help, don't hesitate to drop me a line. Gerv [0] http://weblogs.mozillazine.org/gerv/archives/005992.html
Mozilla and Trademarks
The recent thread about Mozilla and trademarks on debian-legal has been drawn to my attention. For those who don't know me, I'm Gerv, and I'm currently the first point of contact for trademark and copyright licensing issues at Mozilla. I have to say that Alex's original summary of our position actually misrepresented our position in a number of ways. He actually posted the full mail I sent him[0] after the discussion finished; I would ask people to please read that to see what I actually said, and whether we can come to an arrangement which allows Debian to use the name Thunderbird for their version of our software. Specifically: They basically want us to comply to the community editions terms as described in [1]. That's not strictly true - the Community Edition method was one suggestion of a way Debian could distribute our stuff, and still label it Thunderbird. It's not the only way. I have a lot of time for Debian, and I'm happy to spend time negotiating something that works for both sides, if such a thing exists, rather than just pointing you at our standard policy. So, please don't just read the standard policy, as Nathaniel did[2] and assume it would all apply to Debian. My original mail already included some suggested departures from it. This implies that we do not use any term that reads: Mozilla Thunderbird. While true, this is misleading. We want to use the two words together Mozilla Thunderbird to label our own releases, but we'd very much like the Debian version to be of high quality, and to have a name including the word Thunderbird. (This is why we asked for the package to be renamed from mozilla-thunderbird, but suggested thunderbird as an alternative.) I suggested Thunderbird for Debian as an alternative UI name which Alex seemed to like. Andrew Suffield made a good point[1] about the substituting one trademark for another; maybe this isn't the best alternative name. Let's think of another. Another IMHO more important point is, that we need (they want us) to add a statement to the thunderbird copyright file like: This is just not true. I said that Debian _may_ wish to make their users aware of the need to remove our trademarks if they modified the package, and suggested some wording. I am well aware of the pitfalls of mandating text to be placed here, there or everywhere. I think they want us to negotiate all package names individually. In addition, they will be god for us (e.g. we add a patch, they have to agree). [ Quoted from [3] ] We would need to come to an arrangement about each package name (which may revolve around a naming scheme). But there's only three or four of them. And the statement about us being a god for you isn't true. We'd need to find some way to come to an accommodation - we don't want software hacked around to an arbitrary degree being labelled Thunderbird, but obviously you need to make changes and security updates without delay or hassle. So the question is: is the Mozilla Foundation's wish to have a level of quality control over things labelled with its trademark fundamentally incompatible with the Debian project's goals? If so, I'm afraid we're in Iceweasel land. But I hope that's not the case. Gerv P.S. If you do end up deciding to rename the packages, you don't want to use the -zilla postfix. The reason for this is explained under Related Software in [4]. [0] http://lists.debian.org/debian-legal/2004/12/msg00342.html [1] http://lists.debian.org/debian-legal/2004/12/msg00345.html [2] http://lists.debian.org/debian-legal/2004/12/msg00389.html [3] http://lists.debian.org/debian-legal/2004/12/msg00343.html [4] http://www.mozilla.org/foundation/trademarks/policy.html
Re: Mozilla and Trademarks
Alexander Sack wrote: I suggest that we make a standard policy that works for all and not for debian only. Otherwise, I feel that there are problems with dfsg, since we cannot grant the same rights to our users, that you granted us. But, here I might be wrong and maybe others want to elaborate on this. We have to maintain the right of everyone to make arbitrary changes, otherwise the software's not free. So we have to therefore say beyond a certain level of change, please remove our trademarks. The general policy on this is the Community Edition policy. However, I am suggesting that for Debian, we can go a bit further and perhaps allow official Debian releases more flexibility in what they change, because we have a level of confidence in the Debian process for producing quality software which we don't have in Joe Q. Public's process. Therefore, if the Community Edition changes aren't enough for Debian (and I can see that they might not be) then I can't see how we can avoid some sort of special arrangements. But I don't think this is a problem. Another IMHO more important point is, that we need (they want us) to add a statement to the thunderbird copyright file like: This is just not true. I said that Debian _may_ wish to make their users aware of the need to remove our trademarks if they modified the package, and suggested some wording. I am well aware of the pitfalls of mandating text to be placed here, there or everywhere. No, you said we _may_, but in parenthesis you stated (and we would request that they). Indeed. _Request_. Not _require_. We would need to come to an arrangement about each package name (which may revolve around a naming scheme). But there's only three or four of them. And the statement about us being a god for you isn't true. We'd need to find some way to come to an accommodation - we don't want software hacked around to an arbitrary degree being labelled Thunderbird, but obviously you need to make changes and security updates without delay or hassle. It's not only about security updates or minor integration changes. Thunderbird and Firefox distributed in debian are actually of higher quality than what you provide ;). For example the extension manager is completely broken for global install and a patch for this (the patch the debian fox and bird use) is just hanging around in bugzilla waiting for a comment from ben for ages. Without this patch a distribution would be nearly impossible for us. OK... so perhaps what we agree would include me giving some people a kick in order to get them to review and check in the major patches Debian adds. This would reduce the size of the difference, at least. But there's not necessarily a conflict here - in that if the patched version has gone through the official Debian procedure and is therefore of a certain level of quality, then that would probably be OK. The larger issue arises when Joe Q. Public wants to take the Debian tarball, recompile with super-duper gcc-pre-release -O6 optimisations (Hey! it doesn't crash for over five minutes at a time now!) or with his new UI improvement patch which adds sixteen menu items and three toolbars, and redistribute the result, trademarks and all. What can be done about that sort of scenario? My suggestion here would be to give your projects something like a codename (e.g. thunderbird codename freehawk) and explicitly grant the right to use those codenames for derived works of thunderbird in your trademark policy. The same would be true for mozilla, firefox and sunbird. I don't think we want to do that, because we want to come to an agreement with as many distributors as possible to use the names Firefox and Thunderbird :-) Gerv
Re: Mozilla and Trademarks
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. 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.) 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 :-) 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. 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. True again - there are certainly practical difficulties here with Debian-based distributions, all of which would probably need their own trademark licence if they wanted to modify before redistribution. 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). Agreed - non-free is not the right way to go here. Gerv
Re: Strange restrictions
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? Indeed - I proposed no requirement of that form. There's no good way of predicting whether someone will ship good or bad software except track record. Gerv
Re: Trademarks: what is the line?
Francesco Poli wrote:
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).
I should point out that changing the name of Firefox and Thunderbird is
designed to be easy. Netscape does it with the suite to make Netscape,
after all. There's a central branding file or two where you change the
name once and it's picked up almost everywhere.
I'm not saying it's trivial, but it is true that things that make it
difficult are treated as bugs, not features, and fixed.
Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli wrote: tbird - Mail client derived from Mozilla Thunderbird ffox - Web browser derived from Mozilla Firefox sbird - ... derived from Mozilla Sunbird moz - Web browser and mail suite derived from Mozilla For what it's worth (and without making any judgement on the legal weight such a view would have, or how far we'd go in trying to enforce such a view) we'd be very unhappy with Moz (a very common abbreviation for Mozilla, and used already by the project in various ways) and TBird (being a very common abbreviation for Thunderbird), and not particularly keen on ffox either. However, I don't want to get too far into this conversation until we've established whether you will need new names. Ideally, I want to get a good understanding of the Debian position on trademarks in general, and then go to Chris Beard and Mitchell Baker (with whom the trademark buck stops) and see what they say. After they've agreed that nothing can be done, if that's their view, then let's talk about alternative names. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Josh Triplett wrote: Henning Makholm wrote: But isn't the full suite going to be discontinued once the thermodynamically challenged predator and its stormy avian cousin reach maturity anyway? As I understand it, not anymore: there are enough third parties building upon Seamonkey (the suite) that it will continue to be maintained for the forseeable future. That's the current position. Whether we just keep it working or whether it moves along more innovatively depends on whether anyone ports it to the new UI toolkit that Firefox and Thunderbird use. There is an effort under way to do that, but I don't know if it'll succeed. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli wrote: If these names are unacceptable, I begin to be concerned that users won't be able to find the right packages or type the right shell commands, without having to remember weird mutant names from outer space... :-( Don't you feel that many users will use that really cool StormyFlyingAnimal MUA without even knowing it actually is Mozilla Thunderbird with some distro-specific adaptations? Mozilla Thunderbird could be a brand of quality, but who will acknowledge this, when nobody knows he/she is actually using that program? This is the entire point, isn't it? :-) We want people to use Thunderbird in Debian, and to know they are using Thunderbird, and to get the high quality experience people get from using our Thunderbird. And we want to come to some arrangement with Debian to make that possible. However, you guys want the freedom to ship software that sucks - or, more to the point and more likely, want to be able to easily give your software to other people and allow them to make it suck and then ship it. If that software ships using our trademarks, then that is incompatible with our trademark goals. So if we can't come to some arrangement that lets Debian use them but asks redistributors to contact us or remove them, then it's increasingly looking like we can't square this circle :-( 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. :-) Gerv
Re: Trademarks: what is the line?
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 Not so strict, really. Certainly not to the level of preventing security patches. Exactly how it would work would be something we'd negotiate. * or to replace every and each trademarked reference to the work with something else Which isn't too hard, given that we have centralised branding files. The Mozilla trademark license seems to be rather harmless at that because they give permission to retain the command names. Judging from the followups to your message, it seems that this is not the case... :-( Indeed. If you renamed the product, you'd need to change the command and package names also. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli wrote: Exactly. DFSG #8 seems quite clear to me: we do *not* consider Free something that gives all the other important freedoms to Debian only, and not to downstream recipients as well. So the question is: is the right to call a bit of software by a certain name an important freedom? That's definitely debatable. The name you use to refer to a bit of software doesn't affect its function. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Michael K. Edwards wrote: So the question is: is the right to call a bit of software by a certain name an important freedom? That's definitely debatable. The name you use to refer to a bit of software doesn't affect its function. It can, especially in the case of a web browser; consider web servers that verify that the client claims to be a sufficiently new Mozilla or IE before sending DHTML. That's a bit different - no one's arguing that the MoFo should have any control over the UserAgent string of any browser, even one Debian ships, just because it contains the word Mozilla. Such an effort would be both counter-productive and laughable. Exactly what the app is called is a more difficult question. There's a long tradition of ln -s /usr/bin/exim sendmail, but you could also argue that if someone downloads and installs Debian or a derivative and types firefox, the trademark holder should be making sure they get a Firefox they have checked for quality in a trademark sense. It looks to me like there's a real storm brewing over trademark enforcement in open source space. At least in most US jurisdictions, trademark law applies an enforce it or lose it standard, and one of the key criteria in judging whether a company takes its trademark seriously is whether it exercises quality assurance over third parties to which it has (explicitly or implicitly) licensed the right to distribute goods or services marked with its trademark. I think it's absolutely right to raise the wider issue. In a hypothetical situation where Debian is the dominant distribution channel for Software X, performs QA functions, and handles the bulk of bug reports, the upstream for Software X could actually lose ownership of the trademark to Debian. Even when the distributor relationship is non-exclusive, a failure to exercise QA authority over the Debian channel could weaken Mozilla's ability to enforce the trademark on other channels. (Imagine Mozilla Firefox, MS Authorized Edition with the crippling limitations of your choice.) Or even just Mozilla Firefox distributed in an official-looking manner rom www.firefoxbrowser.info with added spyware or bank login capture. So the Mozilla folks are being responsible in setting out the limits of the license to use their trademarks as part of the MPL, rather than leaving the issue unaddressed and then springing it on people in court. We're not actually doing it as part of the MPL - we want to keep trademark licensing separate from code licensing. The MPL doesn't speak about trademarks except to say that it itself doesn't give you any rights to them. I think it would be a good idea to work out a modus vivendi with them, such that the names of Debian-packaged Mozilla products are unchanged, and designated persons from Mozilla have the right to file RC bugs that the maintainer isn't allowed to downgrade. That at least preserves the forms of trademark defense, at a rather minimal cost in freedom. One principle that we were originally working with in our trademark policy is QA in retrospect - i.e. we let you do roughly what you want, but if the packages are of a consistent low standard, we get to pull the trademark and you have to change the name. Now at the beginning of the thread, there were some objections raised to this idea - but is it better than more intrusive forms of trademark control? GErv
Re: mozilla thunderbird trademark restrictions / still dfsg free ?
Brian Masinick wrote: mozilla _wants_ us to make some changes to the thunderbird package in order to not infringe their trademarks. I think plenty of dialog with Mozilla is a good idea. If they don't like the way we package Thunderbird or any of the other packages, I should point out again that (given the discussions I've had with the Thunderbird maintainer) we are almost certainly going to be happy with what Debian itself does. Debian Web browser based on Mozilla Firefox Debian Email client based on Mozilla Thunderbird Debian browser suite based on Mozilla As someone raised earlier, isn't this just replacing one trademark problem with another (Debian)? Those also aren't particularly wieldy names for a title bar or package ;-) I have a hard time believing that after all this time they want people to get away from their names, but if that's really what they want, let's do it. No, we don't want people to get away from the names. But we do want a way of ensuring that they are a mark of quality in trademark terms. Gerv
Re: Hypothetical situation to chew on
Nathanael Nerode wrote: If not, what procedure would be needed to make the software DFSG-free? I'm going to guess clean-room rewrite of all of the documentation, and of any code that could be affected? Not *quite*. But close. (1) Every piece of code must be audited to determine the copyright holders. While I'm here, I should point out that we are in the process of doing this for Mozilla to relicense under MPL/GPL/LGPL. It's taken 3 1/2 years so far. I'm happy to give advice to anyone who wants to do it for their own package. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: MJ Ray [EMAIL PROTECTED] wrote: By the way, the trademark FAQ doesn't tell me how to build without including the proprietary logos. Can anyone tell me how? Spotted another thread (mail is slow here this week) and replaced the branding dir. Rebuild underway. Still need to replace titlebar? I apologise that we don't have a better document detailing this process. - The default build for Firefox and Thunderbird uses non-trademarked logos - The names can be found in files called brand.dtd and brand.properties http://lxr.mozilla.org/mozilla/find?string=browser.*brand (for Firefox) This should change the vast majority of instances. There are a few it doesn't; these are either bugs or unavoidable due to the words being in other pieces of code, like the installer. But try that and see how far you get. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: - The default build for Firefox and Thunderbird uses non-trademarked logos Are you sure? The graphics seem to have the words Firefox in them, which doesn't seem a permitted use of the trademark to me. The default build removes the trademarked logos (the fox-on-globe or the bird-on-envelope) but not the trademarked words. This is because our current trademark policies are more strict about the use of the logo compared to the word, so more people (e.g. all our localisers) use the word. Of course, there's a big under construction sign on all this, so I wouldn't be surprised if reality differs a little from the ideal. - The names can be found in files called brand.dtd and brand.properties http://lxr.mozilla.org/mozilla/find?string=browser.*brand (for Firefox) Ah, I found another directory mozilla/dist/branding as well as the mozilla/other-licenses/branding one that I knew about. Which of these are actually used? mozilla/dist is the built version of Mozilla. mozilla/other-licenses/branding shouldn't be pulled or built unless you've set MOZ_USE_OFFICIAL_BRANDING: http://lxr.mozilla.org/aviarybranch/source/Makefile.in#208 This is done using the --enable-official-branding switch to configure. If a clean CVS pull without that switch is pulling and building in that directory, that's definitely a bug. :-) Is MF implicitly licensing the trademarks by making it so hard to remove them when performing acts permitted by the copyright licence? No. :-) Amusingly, the About FireWWW box says it is copyright contributors, but pressing the credits button displays a box empty apart from FireWWW \n The browser, reloaded. How do Mozilla contributors feel about not being credited on the About box at all? If you wait, it scrolls - or it should do. There are also more contributors at about:credits. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Don Armstrong wrote: I know if I were maintaining it, I would be very worried that the trademark license would be pulled or similar, and I would be in the very wierd position of trying to pull the packages from a stable release and dealing with all of the problems that that would cause for the users of the packages. I don't think we'd have a problem with a system whereby once a stable release was done, we couldn't withdraw permission for that release (given Debian's existing policy of just doing security updates to stable releases). Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Alexander Sack wrote: In contrast, the package you want us to distribute is not distributed by upstream. You distribute something that is restricted by active trademark enforcement, which IMHO is non-free, because a trademark policy is just another way to restrict freedom. I don't think it's as simple as that. After all, Debian has a trademark policy, and restricts use of its trademarks, as does the Apache Group. Is Debian's trademark policy freedom-restricting? I don't think so - it just makes sure consumers know what they are getting. You referred often to 'we'd have to negotiate'. OK, fine. Let's start with it. Maybe you give up on some off your procedures. e.g. you could give up restrictions you try to enforce on us. I mean, debian (as well as other free software distributors) is (are) should not need to care if there is a trademark for some package or something. There is no problem for thousands of packages we include, so why mozilla? Because part of the Mozilla Foundation's strategy to raise enough money to employ people to work on the code involves leveraging the name. I think this is great - because it's not a model which restricts the freedom of the code. It also gives us an incentive to make high-quality releases, because if we don't, the goodwill associated with the name goes down the pan. AFAIK, enforcement of trademarks can be of preventive or responsive nature. I think if you treat your trademarks like others do (in a responsive manner), there would be no problem either. (This might be wrong, though, because me != lawyer) As I may have mentioned before, some sort of responsive scheme may well be OK - but that doesn't get to the heart of what I understand the problem to be, which is the onward transmission of rights. I bet they would go after commercials or other organizations that actually want to harm the brand significantly. ...and their ability to do so may well have been harmed by a lack of trademark enforcement in the past. What I am trying to say is that mozilla is far too eager in enforcing their trademarks. I hope this is because you just think this is needed by law. I hope this is not because you really believe it helps the overall purpose or will maximize the value of your brand. We believe it helps the overall purpose in that it helps fund people to work on the code. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
Francesco Poli wrote: I'm no expert in fund-raising strategies: could you please explain what you mean? How can MoFo raise funds by preventing other people from calling Mozilla Firefox a distributed modified version of its XUL-based web browser? One example is that we have a deal with Google such that they are the default search and on the default home page in Mozilla Firefox. I suspect (and I wasn't involved in negotiating it, so can freely speculate) that we would probably not have got that deal if we couldn't guarantee that all the builds we distribute and publicise would have Google as the default search. Google are happy to pay to ride the wave of publicity we've managed to generate for Firefox. But they'd be less happy to pay if we couldn't guarantee product quality, or we couldn't guarantee their placement. We do both using the trademarks. (Note: I'm not certain of the exact terms, so I don't know whether the deal is linked to all Mozilla Firefox builds or all Firefox builds. I know the Community Edition terms for using Firefox don't let you change the default search engine.) Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: Nick Phillips [EMAIL PROTECTED] wrote: It would seem to me that if you want to distribute a version of mozilla with a different default search, then it is reasonable to require that you do not call it mozilla or use any of their trademarks. I can understand why I can't call it mozilla, because that's their name. They are not called firefox though. They make a thing called Mozilla Firefox and are claiming Firefox as an extra name. Er, that's what a trademark is :-) Nabisco isn't called Oreo, but Oreo is still their trademark. On a purely pragmatic note, if it's fine to require the name is changed for modified versions (like Debian's can be), it's not clear how to do that at present - do we know if it is even possible? Read back in the various threads on this topic - I've been explaining how it's done. It feels like Mozilla may be free but vexatious. Unsurprisingly, I'm a little grumpy at them claiming they are behaving well while making more work for us. I apologise that our trademark policy makes more work for you, but I do think we are behaving well in that all of our software is still Free. Then there are the claims that X or Y from MF will discuss it, even though past attempts failed and it seems nothing has changed on MF's side. I'm here and I'm not going away. Gerv
Re: mozilla thunderbird trademark restrictions / still dfsg free?
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: I don't think it's as simple as that. After all, Debian has a trademark policy, and restricts use of its trademarks, as does the Apache Group. Is Debian's trademark policy freedom-restricting? [...] Yes. Why do you think it's under review? It's causing some minor silly situations when it interacts with copyrights of free software. I wasn't aware it was under review. The Apache foundation have also rumbled about naming here, IIRC. I think you're nicer, so far. Thank you :-) I try. Because part of the Mozilla Foundation's strategy to raise enough money to employ people to work on the code involves leveraging the name. I think this is great - because it's not a model which restricts the freedom of the code. [...] You wrote this, but you claimed that it stops the default search engine being changed away from my favourite invite spammers g**gl* - is this a contradiction? No, at least not by my understanding of what makes code free (i.e. that it's under a Free licence). Gerv
Firefox/Thunderbird trademarks: a proposal
Here's my attempt at something which hopefully everyone can accept. I've tried to take into account all the excellent feedback over the past few weeks, for which I thank all involved. Comments are in square brackets. This assumes that DFSG #8 means that Debian can be given rights over and above the rights necessary to make a program free, as long as all the rights necessary to make it free are transferable. 1) The Foundation grants Debian, and all redistributors of the official Debian packages of the Foundation's products, the right to label those packages with a name containing the trademark. [This document would apply to Firefox, Thunderbird, and any other trademarks on software names we may hold in future. The name would be Firefox, Community Edition or whatever is agreed between the Foundation and the maintainer. It's not important to this document.] 2) The Foundation agrees to document the procedure for changing the name to its satisfaction, for the benefit of Debian and anyone else, and to work to make that procedure as simple as possible. [This means that if you or a Debian redistributor ever has to change the name, it hopefully won't be too onerous. And it means we can't blindside anyone with 'but you forgot to change *this* instance.] 3) The Foundation will review the current Debian package at freeze time, and at other times at their discretion, and bring any issues they have to the attention of the maintainer. The maintainer is not responsible for notifying the Foundation of any changes he may make to the package, or obligated to make any change that the Foundation may suggest. However, in the unlikely event of irreconcilable differences occurring between the maintainer and the Foundation, the name of the package will have to be changed in all as-yet-unreleased versions of Debian. [This gives you a free hand over the development process, and us the oversight that we need by law to be seen to be having.] 4) The Foundation agrees not to withdraw the permission more than three months into a freeze. [This is intended to mean that we can't require an inconvenient change just when you are about to release; if we don't notice until it's too late, it's our problem. My understanding of the Debian process is not complete; 'freeze' may not be the correct term here.] 5) The Foundation agrees not to withdraw the permission for versions of the product shipping in stable releases of Debian, provided all updates to the package are within Debian's guidelines for package updates in stable releases. [You have carte blanche to make security fixes. We are happy because your own procedures say you can't gut the package and replace it with something different. And you are happy because you have to follow your own procedures anyway, so it's not a burden.] 6) The Foundation agrees that it's not Debian's responsibility to make sure the distributors of any derivative works of Debian packages have an implicit or explicit trademark license from the Foundation. [No hassle for you.] 7) The Foundation requests that Debian document, in a place where it might be seen by package modifiers, the potential need to acquire such a trademark licence. [I hope you would view such a notice as a service to your users - but distributors of modified versions may need a license whether you add the notice or not. This is hopefully in line with DFSG #4, which says that packages are free even if derived works are required to carry a different name. It is also in line with free software licenses where changes require other changes, e.g. the GPL 2a) where code changes must be documented.] Is this a runner? Gerv One final note: I can't completely exclude the possibility that someone higher up at the Foundation (e.g. Mitchell Baker) will say that I've overreached myself. But I don't know of any reason why that would be the case, and I'm negotiating in good faith. I would, of course, get a final version approved by all necessary parties :-)
Re: Firefox/Thunderbird trademarks: a proposal
Michael K. Edwards wrote: Change the name of the package will have to be changed to the Mozilla Foundation reserves the right to withdraw license to its trademarks and I think it's completely unobjectionable. Without commenting on whether this change would be OK or not, can you see any circumstances where the two may not be the same thing? Part of the goodwill surrounding this, it seems to me, is that if the Foundation were ever to withdraw the trademark license, Debian would respect both the letter and the spirit of that, rather than turn around and say well actually, legally we can keep using them because of law X. (This passes no judgement on the existence or validity of law X, whatever it might be.) Or was that a point specifically about the name of the Debian package (.deb file)? Gerv
Re: fresh review of: CDDL
Steve Langasek wrote: I have verbal assurance from the Mozilla folks that it is, actually, regardless of what the various copyright statements in the tree currently claim. I don't know who assured you of that, but it's not true. In my copious spare time, I'm attempting to complete the Mozilla relicensing effort. It's about 99% done, but not 100%, and the remaining 1% includes code that ships in the default build of all our products. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: fresh review of: CDDL
Michael K. Edwards wrote: Would it be out of place to ask what code, exactly, is involved? Not at all, no. As the licensing state of the tree is determined by a script, and because I haven't run it in the past few weeks, I can't tell you exactly offhand. I will attempt to take up the well-worn cudgel again in the coming week, and produce such information. Perhaps this list or some of its participants might then be able to help me determine which remaining contributions consist of works of authorship? :-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla can't be GPL? (was: pkcs#11 license)
Lewis Jardine wrote: Ludovic Rousseau wrote: It seams the only human possible solution is to ask RSA to change their licence. I guess the Mozilla foundation could help if they care about licencing issues. Any idea of how we should contact Mozilla and RSA? I am really _not_ a diplomatic guy :-) I'd expect Mozilla are interested in getting this file BSDed as part of their tri-licensing project, so it might make sense to simply draw Mozilla's attention to this problem and leave approaching RSA to them. There seems to be some confusion about Mozilla's current and future licensing status in this thread. The topic implies Mozilla is under the GPL; this isn't true until the relicensing project is finished. We hope to have that done soon, but it's not done yet. The above comment suggests that we are relicensing to a BSD-like licence; that also isn't true, the target relicensing scheme is an MPL/LGPL/GPL tri-licence. Ludo has drawn my attention to the problem; as I originally read the licence, this document referred to the header file, which no-one ever talks about, and so the restriction was in practice meaningless. If that turns out not to be true, we may have more of a problem. The file was originally contributed, with an NPL/GPL dual licence, by Netscape Communications Corp. I would like to think that they would have got clearance to issue the file under that licence before contributing it... Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question on GPL compliance
Michael Poole wrote: The GPL only explicitly permits this for the three-year written offer case. Perhaps suggest that GPLv3 allow it? I agree with Daniel that it would be sensible to permit this, and I've actually made this suggestion already on their rather cool commenting webtool. Here's the thread if anyone wants to chip in: http://gplv3.fsf.org/comments/rt/readsay.html?id=201 Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Clause 7d (was Re: Ironies abound (was Re: GPL v3 draft)
Nathanael Nerode wrote: So here it is: 7d. They may require that propagation of a covered work which causes it to have users other than You, must enable all users of the work to make and receive copies of the work. I like this, together with Arnoud's suggestions. But Walter is right; the devil is in the detail of defining user. In order for the clause to maintain the market in addon clauses which the FSF has talked about, you have to leave it up to the specific clause to define where the line is. And then debian-legal will have the lovely job of judging 27 different variants and deciding which ones are free. There's also a comment discussing potential revisions of this clause on their wiki-like thing. It has my suggestion in, which is along the same lines, but I like yours better. http://gplv3.fsf.org/comments/rt/readsay.html?id=204 I think it's inevitable that, whatever this clause ends up like, it'll be possible to write a non-free additional term with it. But we can at least get it phrased in a way which makes it possible to, and encourages people to write free terms. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please review: The OFL (Open Font License)
Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Won't this forbid anyone (but the original copyright holder) to fix bugs or misfeatures in the font? Not if they choose a different name. For a font bug-for-bug compatibility may be very important to preserve correct rendering of docuements. You do, of course, mean preserve _incorrect_ rendering of documents ;-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Affero General Public License
Glenn Maynard wrote: But that's a special case; more generally, I don't see any way at all of satisfying this for the voicemail, toll booth, etc. cases. (Though the thought of someone corking up a toll booth lane on a busy interstate to plug in a USB pen drive and download its source is somewhat amusing ...) The difficulty here is that in the arcade machine/toll booth case, the person who (IMO) requires source access to exercise his freedoms is the machine _owner_ or toll booth operating company, not the player or tollee. An arcade owner isn't going to allow me to upload hacked firmware to his machines (sadly :-). How do you distinguish between an arcade user and someone using a web application? Is it the presence of a network connecting the two? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla relicensing complete
Francesco Poli wrote: I think that this is good news anyway. Thanks to Gervase Markham for dealing with this (big) issue! You are welcome :-) Perhaps now I can get back to hacking :-) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GNU GPL future
MJ Ray wrote: It's the comment system which is incapable, not the people. IMO there was no good reason to design some people out of it. If it's possible to provide the same level of function with an interface that works in more browsers, great - and I believe they did do that as time went on, as it now works in Konqueror and IE. But the GPL v3 commenting interface is, in my view, an exceptional piece of UI design and the best way I have ever seen of managing that number of comments on a document in a single interface. Given that free software browsers which work with it are available for almost every current OS under the sun, to reduce the function to further widen the browser choice would have been a bad tradeoff. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OSSAL/CC license of xMule parts
Daniel Leidert wrote: I'm not sure of any of these licenses is DFSG-free. AFAIK the CC licenses are considered non-free and I'm concerned about the OSSAL too (that forbids linking against GPLed libraries). And the exceptions don't seem to allow Debian to link against GPLed libraries. Can you clarify the situation? The OSSAL, at least as defined here: http://people.freebsd.org/~seanc/ossal/ also has a BSD advertising clause: 3. All advertising materials mentioning features or use of this software should, in good faith, display the following acknowledgment: This product includes software developed by the AUTHOR and its contributors. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-free IETF RFC/I-Ds in source packages
Simon Josefsson wrote: http://wiki.debian.org/NonFreeIETFDocuments A useful thing to add to that page would be simple instructions on how those authoring IETF documents could make them available under a DFSG-free licence (presumably in parallel to the IETF one) - perhaps some sample boilerplate text to include. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Francesco Poli wrote: Hence, even if it's not a DFSG-freeness issue, I would suggest the license drafter(s) to drop such a useless restriction. It's been tried several times, and it's not happening. See the OFL list for a recent explanation of the rationale. If it's not a freeness issue, let's focus on more important stuff (if there is any). Actually, DFSG#4 states, in part: | The license may require derived works to carry a different name or | version number from the original software. This means that forbidding derived works to carry the same name as the original software is acceptable. I believe that forbidding an unlimited and arbitrary list of Reserved Font Names goes beyond and is *not* DFSG-free. I think that's splitting hairs a bit. Because all of the Reserved Font Names will have been used for the font in the ancestor version tree of the software somewhere, they are all the name of the original software - at different points in its development. I agree that trademark law is a better venue for this sort of restriction, and I have argued as much on the OFL list. But I don't think this quirk makes the license non-free. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. [...] As already pointed out by Andrew Donnellan, this is vague, as the word document is never defined and has no unambiguous meaning. Do you have a proposed definition? What sort of things do you suggest some people might consider documents and others not? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python Software Foundation trademark policy
The Python Software Foundation trademark policy[0] says the following: # Use of the word Python when redistributing the Python programming language as part of a freely distributed application -- Allowed. If the standard version of the Python programming language is modified, this should be clearly indicated. For commercial distributions, contact the PSF for permission. As I understand it, Debian uses the name Python to refer to its Python implementation and the name python for the executable. Does this mean that all commercial distributors of Debian need to get permission from the PSF, or alter their copy of the python package? Gerv [0] http://www.python.org/psf/trademarks/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Francesco Poli wrote: I probably missed where the license makes sure that Reserved Font Names can only become such by being names used in some ancestor version of the Font Software. Could you please elaborate and show the relevant clauses, so that my concerns go away? There is no such clause. What sort of abuse do you think this loophole enables? After all, even if there was such a clause, I could make 200 trivially different versions of the font, each one from the next and each with a name I wished to reserve. But what would be the point? As already pointed out by Andrew Donnellan, this is vague, as the word document is never defined and has no unambiguous meaning. Do you have a proposed definition? What sort of things do you suggest some people might consider documents and others not? I don't have one, since I think that clearly drawing lines to tell various software categories apart is really hard. This discussion has showed up many times on debian-legal, at least since the GFDL times (I think it was 2002 or 2003): I believe there are no clearcut boundaries between documents, programs, images, audio/video works, and so forth. They can be classified in most cases, but the boundaries are always blurred. Hence defining what a document is, turns out to be hard. Given that we clearly need an exception for documents to avoid the problem which led to the GPL font exception, if you can't suggest alternative wording, I'm not really sure how to proceed. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Open Font License 1.1review2 - comments?
Francesco Poli wrote: The clarification from MJ Ray regarding DFSG#4 made me think that each distinct copyright holder had a veto power on _one_ Font Name. At least I hoped it was so, since if each copyright holder can reserve an arbitrary list of Font Names, the restriction can easily grow up to the level it makes finding a non-reserved name nearly impossible. To make finding a non-reserved name nearly impossible, then the list of Reserved Font Names would need to include nearly all words or pronounceable phrases in the English and every other language - whereupon the font file would be too large to distribute with Debian anyway. It seems to me that the chances of an abuse of this mechanism on a scale which can actually cause problems are about at the level of the chances of someone abusing the language in the BSD licence about change and distribute - or whatever it was UWash did. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Software Foundation trademark policy
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: As I understand it, Debian uses the name Python to refer to its Python implementation and the name `python' for the executable. Does this mean that all commercial distributors of Debian need to get permission from the PSF, or alter their copy of the python package? As I understand it, distributors who label their debian packaging and advertising materials with the Python trademark need to make it clear that it is a debianised version of Python. That is indeed one requirement - the bit which says If the standard version of the Python programming language is modified, this should be clearly indicated.. But as I read it, there is also a blanket requirement to get permission for commercial distribution. The policy states: For commercial distributions, contact the PSF for permission., (with permission being permission to [use] the word 'Python' when redistributing the Python programming language). This is a complete, standalone, unqualified sentence, and therefore applies to all commercial distribution, including people selling Debian CDs. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Software Foundation trademark policy
MJ Ray wrote: Gervase Markham [EMAIL PROTECTED] wrote: [...] This is a complete, standalone, unqualified sentence, and therefore applies to all commercial distribution, including people selling Debian CDs. Well, it applies to all commercial distribution which uses the Python trademark. Right. And doesn't calling some software Python count as using the Python trademark? (The word, not any logos there might happen to be.) If I purchase Debian CDs and type python, or I do man python and read all about the interpreter which I can invoke by typing python which interprets the Python programming language, or I install python-doc and read some more, isn't that use of the trademark? Remember, I think the Mozilla problem is their bizarre trademark+non-free-copyright dual defence attempt. This is not about Mozilla. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Software Foundation trademark policy
MJ Ray wrote: If I purchase Debian CDs and type python, or I do man python and read all about the interpreter which I can invoke by typing python which interprets the Python programming language, or I install python-doc and read some more, isn't that use of the trademark? What trade is happening when one types python, or does man python and reads, or installs python-doc and reads? If someone is paying you to do those acts, I expect it may be necessary to beware the trademarks more. sigh Could you really not work out what I meant? The CD I have been sold by the Debian distributor uses the Python trademarks to label their shipped version of the Python code. I notice this when I interact with what I have purchased in any of the ways listed above. The fact that the name Python is not printed on the outside of the CD is surely not relevant to whether the distributor is passing off their version of Python under the trademark. - The policy says: Use of the word Python when redistributing the Python programming language as part of a freely distributed application -- Allowed. If the standard version of the Python programming language is modified, this should be clearly indicated. For commercial distributions, contact the PSF for permission. As I understand it, you are asserting that someone selling Debian CDs does not need to request permission from the PSF under this clause. But I don't understand why. In the case of a Debian redistributor selling me a set of Debian CDs, is your position that: a) The distribution is not commercial distribution of Python; or b) The distributor is not redistributing the Python programming language; or c) The distribution does not use the word Python; or d) The distribution does not meet the test of being a freely distributed application; or y) The PSF does not have the right, under trademark law, to make the restriction quoted above for the uses to which Debian puts the word; or z) something else? (For the sake of argument, I concur that Debian is complying with the middle sentence of the paragraph about labelling modified versions.) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Software Foundation trademark policy
MJ Ray wrote: Passing off is a little different, so I don't want to confuse that with trademarks. That's not something I know much about; a reference on the difference would be appreciated if you have one. How is Python being used by the distributor to label the shipped version of CPython in any way that you can determine *during* purchase? Let's modify the scenario, then. Let's say I am particularly keen to get a Linux distribution which contains this Python language I've heard so much about. I ask the commercial distributor at the stand: Does this copy of Debian contain Python? Does he say: a) Yes b) No c) It includes a bit of software we call python which is based on the official one from the PSF, and we hope it's fully compatible with it, but we have no connection with them, etc. etc. d) Hang on, I have to call the PSF to get their approval before I can tell you. a) is, I assert, trademark infringement. b) is misleading and unhelpful at best. d) is clearly ridiculous. I suppose c) would be OK, but I doubt that's the answer you would get in practice. If it's the only legal answer, does Debian need to warn its distributors? A bit of y, a bit of something like c and a bit of z. My position is that I do not understand why the distributor would *need* to infringe the Python word trademark. I see no need to use the Python mark in the course of trade to distribute debian. So, as I understand it, the use of the word Python in the Debian docs on the CD is using the mark, but it's not in the course of trade? Does that mean if I give away my can's of Gerv's Cola labelled as Coca Cola, instead of selling them, then it's not in the course of trade so it's OK? Or if I sell boxes labelled Famous Name-Brand Cola inside, and people open them after purchase and see cans of what looks very like Coke, that's OK too? I admit this is a bit stretched, but I find it hard to understand how we come to a position where Debian can label anything it likes with any trademarks it likes in its distribution, as long as it doesn't write the trademarks on the outside of the CD. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
Francesco Poli wrote: Clause 5d in GPLv3draft3 is basically unchanged with respect to previous drafts. It's worse than the corresponding clause 2c in GPLv2... :-( It's an inconvenience and border-line with respect to freeness. Actually this clause restricts how I can modify what an interactive program does when run. It mandates a feature that I *must* implement in *any* interactive interface of my modified work. It's very close to place an unacceptable restriction on modification. What is more awkward is that it seems that when a non-interactive work is modified so that it becomes an interactive work, the modifier is *compelled* to implement these features in *any* newly created interactive interface... I would like to see clause 5d dropped entirely. I agree that it's not very good. Given that persuading the FSF to drop the clause entirely at this late stage is unlikely, can we come up with a form of wording to suggest which at least makes it no worse than GPLv2? I would be happy to see all these permissions to add restrictions entirely dropped from Section 7. === not a Freeness issue, but a great loss, since, if this mechanism is kept in the final GPLv3 text, GPL-compatibility will no longer be a DFSG-compliance guarantee... :-( Can you give an example of a DFSG-non-compliant term that could be introduced under section 7? b. requiring preservation of specified reasonable legal notices or author attributions in source or object code forms of material added by you to a covered work; or Kills copyleft: are these the cousins of GFDL's Invariant Sections? What exactly is a reasonable legal notice? What exactly is an author attribution? It seems that these terms are not defined anywhere in the license. I'm concerned that they could be interpreted in a broad sense and allow people to take a GPLv3'd work and add some sort of invariant long text that nobody will ever be able to remove or modify... I can't see any judge with a decent grasp of English or the notion of a legal notice or author attribution permitting the attachment of the GNU Manifesto to a work under this clause. Can you give a concrete example of a problematic situation you see? BTW, does this section make GPLv3 compatible with the license of OpenSSL? 13. Use with the Affero General Public License. Kills copyleft: compatibility with a yet unknown license This section introduces a form of compatibility with a license that is yet unreleased and thus possibly non-free: the Affero General Public License, version 2. The AfferoGPL v1 is, in my opinion, a non-free license, due to its clause 2(d). I won't restate all the reasons for my conclusions (more details in http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-3id=1663). As a consequence, I have few hopes that the forthcoming version 2 of the AfferoGPL will be a free license. Being compatible with an unknown (and thus possibly non-free) license destroys the copyleft mechanism of the GPLv3. Destroys is a bit strong. This clause is a permission to link; therefore, as I read it, the GPLv3 copyleft weakens to an LGPL-style copyleft in the case of linking with the Affero GPL. Each bit of code remains under its own license. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
Francesco Poli wrote: On Mon, 02 Apr 2007 12:26:42 +0100 Gervase Markham wrote: I can't see any judge with a decent grasp of English or the notion of a legal notice or author attribution permitting the attachment of the GNU Manifesto to a work under this clause. Can you give a concrete example of a problematic situation you see? I cannot depict a specific scenario off the top of my head, but my alarm bell rang as soon as I saw the word preservation coupled with undefined (and hence vague) terms as reasonable legal notice and author attribution. Undefined in the license != vague. There are lots of English words the license uses which it does not explicitly define, and yet we seem to manage to understand it pretty well. An author attribution is text which tells you the name of an author. A reasonable legal notice is any notice of relevance to and on the topic of the legal situation surrounding the product. I really can't see any GFDL-like insert GNU Manifesto here problems with this. Since the clause does not seem to be designed as sufficiently narrow to avoid posing nasty problems in the future, I assumed the worst case scenario and concluded that the clause will bite. That was my line of reasoning. How would you rephrase it? BTW, does this section make GPLv3 compatible with the license of OpenSSL? I don't know: I didn't check, as it was not my primary concern. It was a question for the group :-) This clause is a permission to link; therefore, as I read it, the GPLv3 copyleft weakens to an LGPL-style copyleft in the case of linking with the Affero GPL. Each bit of code remains under its own license. Yes, and I dislike it: it sounds as (and probably actually is...) an endorsement of the AfferoGPL v2 by the FSF. Yes, it is. If you never use the Affero GPL, is it really a big deal? They made a promise ages ago, and now are looking for the least painful way to keep it. Having a special exception everyone else can ignore is a far better solution than the previous section-7-based attempt. P.S.: Please do not reply to me, Cc:ing the list, as I didn't asked you to do so. Sorry. It wasn't intentional. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Copyleft variation of MIT license
Suraj N. Kurapati wrote: I had been using the GPL for some years without fully understanding its implications. Recently, I spent some time thinking about my ethical beliefs regarding free software and discovered that I prefer something like Creative Commons' by-sa (attribution + share-alike) license. That is, I want the source code of my software to remain free, like a free bird that cannot be caged. What important difference do you see between the GPL and BY-SA? They were designed to work in similar ways. I looked at other by-sa licenses (particularly MPL, CDDL, CPL, EPL) but found them to be lengthy. Instead, I admire the MIT license for its short length and comprehensibility, and wish to make a copyleft variation of the MIT license[2]. This is a really bad idea, for reasons already explained by people more coherent than me. Please don't do it. This might also be of interest: http://www.dwheeler.com/essays/gpl-compatible.html Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
Francesco Poli wrote: Well, *when* I want a copyleft, I want one that *actually works*... Exemptions for specific incompatible licenses should be left out of the license text (so that who wants them can add them as additional permissions). *When* I choose the GNU GPL, I want to prevent my code from being linked with proprietary code (including AfferoGPL'd code). I'm simplifying things to a great extent here, but I think what I mean is clear enough... Not-quite-DFSG-free != proprietary. Calling Affero code proprietary is a pretty big stretch. Yes, there's a clause in there which is a restriction on modification - so it's not entirely free. But you still have to release the source to modifications, source follows the binary - all that GPL goodness, because the Affero license is based on the GPL. And, from a practical point of view, there's hardly any code under the Affero. Proprietary software companies are not going to relicense under the Affero in order to link with GPLed code - because the Affero doesn't let them keep their code secret. Some of your other points were good, but this one is really not going to be a problem in practice. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL v3 Draft 3- text and comments
Francesco Poli wrote: Not-quite-DFSG-free == non-free, even though close to the freeness boundary == proprietary, even though close to the freeness boundary By definition, whatever is not free, is proprietary. I was using proprietary in what I thought was its fairly common meaning, i.e. closed source, controlled by only one company. I have no intention of getting into a fight about whether the Affero additional restriction is acceptable or free or whatever. The FSF thinks it's free; other people disagree. Their reasons are credible. I don't like it. But my point is that you are acting as if this exception turns all GPLed code into LGPLed code - i.e. Microsoft can come along and link it into Windows, or whatever. But that's obviously not true. The only non-GPLed code your GPLed code can be linked with is code that also follows the GPL exactly _except_ that it has a single additional restriction on modification to a small part of it. This may not be a good thing, but it's not even on the same planet as some of the scenarios the phrase being able to link with proprietary code could cover. And considering the small amount of code actually covered by the Affero GPL (and that there's very little evidence that version 2 of the Affero GPL will cause it to suddenly surge in popularity) then it's also very unlikely that code you write will end up in this situation. Lastly, the FSF is keeping their promises. If you can think of a better way for them to do so (and this way is already a whole load better than their last attempt), then suggest it. So I'd suggest you concentrate your efforts on the other points you made in your analysis, which were good and reasonable. In order to facilitate this, I'm not going to contribute further to this discussion, because its very continuance is counter-productive to its point. The problem is that (if this clause is not dropped) GPLv3'd code will be linkable to non-free-restriction-encumbered code. That's not in the spirit of the GNU GPL v2. True. And Debian can easily refuse to distribute applications so linked. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EPSG data reviewing in progress
I don't know if this conversation is supposed to happen elsewhere, or perhaps with a smaller CC list, but: Francesco Poli wrote: EPSG dataset Terms of use, revised 22/03/2007 (proposed - not adopted!) The EPSG geodetic parameter dataset is owned jointly and severally by the members of the Surveying and Positioning Committee of the International Association of Oil and Gas Producers (OGP), formerly the European Petroleum Survey Group (EPSG). It is compiled by the Geodetic Subcommittee of the OGP from publicly available and member-supplied information and distributed at no charge through the internet. The user assumes the entire risk as to the accuracy and the use of this data. The data may be used, copied and distributed subject to the following conditions: 1. INFORMATION PROVIDED IN THIS DOCUMENT IS PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. 2. The data may be included in any commercial package provided that any commerciality is based on value added by the provider and not on a value ascribed to the EPSG dataset which is made available at no charge. The ownership of the EPSG dataset [OGP] must be acknowledged. This is non-free :-( But they shouldn't be concerned about people selling it standalone; the customers will soon realise they've been duped, and bang goes that business relationship. 3. Subsets of information may be extracted from the dataset. Users are advised that coordinate reference system and coordinate transformation descriptions are incomplete unless all elements detailed as essential in OGP Surveying and Positioning Guidance Note 7-1 annex F are included. This second sentence, while not non-free, should not be part of the license terms, as it is not related to the license. 4. Essental elements should preferably be reproduced as described in the dataset. Modification of parameter values is permitted as described in OGP Surveying and Positioning Guidance Note 7-1 annex G to allow change to the content of the information provided that numeric equivalence is achieved. Numeric equivalence refers to the results of geodetic calculations in which the parameters are used, for example (i) conversion of ellipsoid defining parameters, or (ii) conversion of parameters between one and two standard parallel projection methods, or (iii) conversion of parameters between 7-parameter geocentric transformation methods 5. No data that has been modified other than as permitted in these terms and conditions shall be attributed to the EPSG dataset. This leaves open the question If I don't attribute the data to EPSG, can I modify it in ways other than stated in this licence?. This is ambiguous. What does preferably mean, legally? Do I have to or don't I? I suggest reframing 4 and 5 something like this: 4. You may copy, modify and/or distribute this data for any purpose. Modified data sets may not be attributed to EPSG unless parameter values are only modified as described in OGP Surveying and Positioning Guidance Note 7-1 annex G, and numeric equivalence is achieved. Numeric equivalence refers to the results of geodetic calculations in which the parameters are used, for example (i) conversion of ellipsoid defining parameters, or (ii) conversion of parameters between one and two standard parallel projection methods, or (iii) conversion of parameters between 7-parameter geocentric transformation methods. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of AGPL v3
Francesco Poli wrote: Bad: no clear definition of remote users The term user is not clearly defined. Is your point that it is impossible to clearly define, or do you have alternative language? Do you know how the corresponding clause in the current Affero license has historically been interpreted? This ambiguity is really problematic, as it implies that there's no clear way to tell whether a modified version supports remote interaction, and hence there's no clear way to tell whether it is subject to the restriction specified by this section. It's not that bad. If I turn some AGPLed code into a local graphics-editing application which has no network capabilities, it's fairly clear that it doesn't apply. But then, what happens if I access that desktop using remote X? Hmm... Let's say the clause instead said that anyone who interacts with the work had to get access to the corresponding source, full stop (no network need be involved). Would that be less ambiguous, I wonder? (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to copy the Corresponding Source from a network server at no charge. Bad: use restriction, with a cost associated to it This restriction compels whoever runs the modified version of the Program to accommodate the source code on the server or, alternatively, to set up and maintain a separate network server to provide source code: this may be a significant cost in some cases. I don't understand this argument. Having to provide CDs of source or fulfil the terms of a written offer is also a significant cost, but no-one thinks that makes the GPL non-free. This is ultimately a use restriction (from the point of view of whoever runs the modified version of the Program) What does it prevent you using the Program for? and effectively forbids private use of the modified version on a publicly accessible server. Well, it forbids public use of the modified version on a publicly accessible server. :-) But of course it does - that's the point. But then the GPL forbids giving someone the use of the modified version via giving them a copy without handing them the source code at the same time. That's not a use restriction. The AGPL clearly passes the Desert Island test (and the Tentacles of Evil test). I'm not sure the current wording of the Dissident test had this situation in mind, but I think a good argument could be made that it passes. (Incidentally, what part of the DFSG is the Dissident test supposed to help test against?) Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First draft of AGPL v3
Francesco Poli wrote: The restriction in the GPL is about the act of conveying copies of the work. The restriction in the AGPL is about *using* the modified work: there's a cost associated with *use*... But surely the entire point in question is whether presenting the UI to someone across the network is conveying or not? GPLv3 says it isn't, AGPL says it is. Perhaps it would be better (in respect of this particular question) if the AGPL extra clause said simply: Notwithstanding any other provision of this License, if a user interacts with the program remotely through a computer network, then that is considered an act of conveying. (i.e. change the definition of conveying in section 0.) This is ultimately a use restriction (from the point of view of whoever runs the modified version of the Program) What does it prevent you using the Program for? If the source doesn't fit in the server the modified version runs on (think of small embedded systems, for instance), I have to set up a separate server to provide source to remote users. But that doesn't prevent you *using* the modified version in your small embedded system. It might perhaps be inconvenient, but as Anthony Towns (I believe) said recently, not every obligation a license puts upon you is a cost. In order to *run* the modified version of the Program! Or to convey it, depending on your point of view :-) As I said above, the GPL restricts the act of conveying, the AGPL also restricts the use of modified versions of the Program. Well, those who would use the Affero GPL would see the use you are referring to as a form of conveying. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Sean Kellogg wrote: Francesco... as I've said on this list before, IANAL is not a sufficient disclaimer. Nor is saying this is not legal advice. There are laws, criminal laws, against the providing of legal advice by those who not certified by the Bar Association within the jurisdiction the advice is given in. Are you familiar enough with the laws of Italy (where Francesco appears to reside) to state that there are such laws which apply to him? There is no exception provided by adding disclaimers, there is only the question of whether or not legal advice was given. How are you defining legal advice? If it is advice on matters which may relate to the law, then that could be taken to be anything. It's a definition so broad as to be useless. This, of course, is patently false. Anyone can provide legal advice... people do it all the time (gee Bob, you should claim X on your taxes, or the judge will reduce your ticket if you show up in court, etc). You don't have to be a lawyer to provide it, you just need to be a lawyer to do so legally in those jursidictions that require certification. So if the speaker in your Bob example is in one of these jurisdictions, saying what he said is technically illegal? Do you not think that this makes the law an ass? Of course, the law is an awfully grey space, so there's lots of flexibility, and for the most part lay-persons can get away with providing legal advice to their friends because the relationship is clear. Here, on an email list entitled debian-legal I think one might have a reasonable expectation that actual lawyers were providing advice. Why? I've never seen that happen (although I've only been on the list for a year or two). It's certainly not a regular occurrence. Does this line of argument mean that when I watch Boston Legal, and decide to follow the advice some of those (fictional) lawyers gave their clients, I can sue the program when it all goes wrong, because the word Legal in the name gave me a reasonable expectation that they were providing legal advice? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Steve Langasek wrote: WTF, seriously? Reading this makes me want to go write some new code, license it under the GPLv3 with some random and arbitrary prohibition, and watch someone at the FSF try to argue that the additional restriction has no legal force. Not non-free, just incredibly goofy; I understand the motivation, I just don't see how anyone would actually think this would address the problem. It certainly addresses the problem. Let's look at the two possibilities: Before: GPL (either explicitly or implicitly): you can do X Restriction: you can't do X Result - conflict and confusion; non-redistributable code After: GPL (either explicitly or implicitly): you can do X GPL: If I say you can't do X, you can ignore me Restriction: you can't do X Result - the license is consistent, although it has one part which nullifies another part. This is similar to clauses of the form The previous part of this clause does not apply if you are wearing blue underwear. If you (in your example) license under GPLv3 + restriction, then by picking GPLv3 you are giving me, the recipient of the code, permission to remove the restriction. If you didn't want to give me that permission, you shouldn't have used GPLv3 - just as if you didn't want to give me permission to link my code with the Affero GPL (to take one example of many), you shouldn't have used GPLv3. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Steve Langasek wrote: If I go to the effort of writing This program is Free Software: you can redistribute it and/or modify it under the terms of the GNU General Public License version 3 as published by the Free Software Foundation, with the exception that the prohibition in section 7 of the license on additional restrictions does not apply and the permission in section 13 is not granted. then I have *explicitly addressed* the clause in GPLv3 which purports to prohibit additional restrictions. Yes, you have. Note that this is not the situation we have been considering up to now in this thread; the situation we have been considering is one where there is just a simple additional restriction (e.g. if you redistribute you must send me a postcard). Your above restriction also results in a consistent license. However, it's not GPLv3-compatible. Which statement is going to take precedence? Clearly, your explicit statement that section 7 does not apply. How could one argue otherwise? At best I've created a lawyer bomb because my intentions are not clear; at worst I've succeeded in licensing my code in a manner that's incompatible with the GPLv3. But that's exactly the same problem that we had with GPLv2, so what was the point of adding this clause? Because most of the time, people just add additional restrictions without also adding your language about section 7 - often because they don't realise they can't do that. This feature of the license combats cluelessness, not explicit intent. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Iain Nicol wrote: If this interpretation were true, then the only burden of this section would be to keep the legal notices in the user interfaces that you keep, but you would *not* be required to add any notices to any user interface, regardless of whether you wrote the interface or not. My interactions with the FSF regarding the GPLv3 process, and this clause, have led me to believe that this is not their intent. Their intent is that any new interfaces (added by people who are not the copyright holder on the entire work) must have ALNs. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Steve Langasek wrote: Francesco isn't giving advice to people in Italy, he's giving advice to people on debian-legal as a whole. Given that unlicensed legal advice is a criminal matter as Sean mentions, there is more to be concerned about than his local laws. If this were true, the logical consequences are absurd. If I send an email to my friend Bob in the USA, suggesting that he should go to the judge and ask for leniency on his drink driving charge, I can now be arrested for committing a criminal offence next time I travel to the USA? Whatever happened to the First Amendment? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Adam Borowski wrote: Can we dub GPLv3 GPL with the advertising clause then? I don't think so. The advertising clause was highly impractical. I don't see informing users of their legal rights as being impractical. And the advertising clause is a lot, lot worse than for 4-clause BSD one -- instead of just advertising materials which in free software there usually none, GPLv3 forces us to vomit legal crap right in the face of every single user, even at a cost to functionality. I don't see that at all. Where does it say that the ALNs have to be compulsorily presented to the user at each run, or even once? The ability to display them merely has to be convenient and prominently visible. How can having the equivalent of a Help | About menu item ever be a cost to functionality? One of the good things about the GPLv3 version of this requirement is that you do not have to preserve the _mechanism_ for displaying ALNs. If you acquire some software with a GUI interface where the ALNs are presented as the background image to the main GUI window, then you can switch them to Help | About without any problems. The text focuses on policy, not mechanism. While for GUI apps having an About menu item is usually not an issue, legal notices are a significant burden for console stuff, both full-screen and line-based. How so? And just think about software which communicates using voice (hands-free things, for example). Why does voice-communicating software have any further problems? The ALNs can be read out at the user's request. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Adam Borowski wrote: The only difference is that it's not the author of the software who is being advertised, but GPL and FSF position. This seems an unfairly perjorative way of saying the list of rights the user acquires with the software. This clause is not about making the GNU Manifesto (or even a copy of the GPL) pop up every time you start an application. No text is mandated. And while informing users is not bad when done once, it's an abomination if every single piece of software does that on its own. If I use Debian, I already do know that I'm allowed to do X, Y, Z thanks to the DFSG, and there is no need to repeat that on every step. Except that the GPL also allows you to do Q, but requires you to do R if you do so, both of which are not mentioned in the DFSG. Not to mention the fact that many Debian or Debian-derived distribution users (e.g. Ubuntu) may never have heard of the DFSG but use the software. I think it's reasonable for the software they use to tell them what rights they have to it. Especially when I didn't ask to be spammed with that notice. Repeatedly receiving some text has a price paid in my attention span, making me lose time which could be used for just anything else. It's a cost which in some corner cases can be significantly detrimental to usability. I'm not blind, but I can imagine the time wasted to go through the legal notice with a Braille reader or such. Again, the clause does not say that the user must be forced to be presented with the information. While for GUI apps having an About menu item is usually not an issue, legal notices are a significant burden for console stuff, both full-screen and line-based. How so? For line-based stuff, yeah, you're right. Having bc and colordiff in mind, I forgot about having --spam-me-with-legal-notices as an option merely mentioned in the manpage -- even though this contradicts the requirement about the notice being prominently visible. I don't think so. For someone who uses command-line software, a command-line switch like --version or --help is the equivalent of Help | About. In a non-menu/non-command based full-screen program having a key combination bring up the legal notices could also be a solution, albeit often an annoying one. Let's imagine the following list of keys: * arrows -- move * q -- quit * ^L -- show legal notices Ugh, 33% of explanation being wasted on legal things. Extremely ugly, especially if you consider that for many of us most of the point of Free Software is not having the legal system stand in our way. Except that copyleft is entirely built on the legal system. With Free Software, we (ideally) don't have to care about Intellectual Property, license fees, patents, trade secrets, etc -- just use/modify/copy the software whenever it is for our benefit. GPL gives an extra guarantee that my work won't be used in a way inaccessible to me -- while forbidding me to become a bad guy in this regard. And that's an important extra guarantee and obligation that the user needs to know about. Free Software, when it's really free and not merely a ruse to sneak some proprietary crap through, makes us free from legal concerns -- both am I allowed to use X? and I wouldn't want people to have a right to use Y without paying me are legal concerns here. Having legal notices everywhere destroys this freedom. So the notice You may play ball games in this park destroys the freedom to play ball games in the park? Well, let's take a system with two user interfaces: 1) a GUI where you set up rules like if someone approaches the computer, do X. If someone leaves the room and there's no one else in, do Y.. 2) hands-free interface where user interacts by moving around, waving hands, etc, and gets feedback using voice. Interface 1 can have Help | About just fine. The problem is, you need to make it possible to get legal notices using _every single interface_. For interface 2, this could be something like to unblank screen, approach the computer. To blank it, move away. To get told legal notices, jump. Yep. Why is this worse than the GUI or command-line versions? You could argue that the command could be accidentally invoked, but that's true of buttons in GUIs or mistakenly typing -V instead of -v on a command-line app. Just pick a sequence of movements that it's very difficult to do without meaning it. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Adam Borowski wrote: Ok, let's scrap the high-tech detector with enough resolution to tell you're moving your hand and take a more realistic one which can just tell that you're sitting at the computer -vs- being somewhere else in the room -vs- the room being empty. The voice can tell me a lot while my feedback is very limited. Or, take your common dumb temperature control: you have a box with two buttons and a simple LCD display which can show only two digits. Yet, nowadays everything tends to have a chip inside -- and if anything inside has anything to do with GPLv3, you suddenly need to convey the legal notices... My point is that the requirement of every interactive interface having a feature to display the legal notices can be a severe use constraint. And this is different from GPLv2, or not? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Steve Langasek wrote: Whatever happened to the First Amendment? Do you also count on First Amendment protection against charges of libel, slander, and false advertising? That's a false analogy. All of the things in your list are done with intent to mislead. In the examples we are considering, giving someone advice about a situation related to the law is not. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Anthony W. Youngman wrote: And as I see it, if I say My program is licenced under GPLv3 with the following exceptions ..., if the user ignores the exception, they have broken the terms I set for them to use the program, and the GPL doesn't apply, so they can't take advantage of the clause allowing them to remove the exception ... This seems to suggest that the terms that you wrote explicitly have some special trumping value over the terms in the text of the GPL itself. I don't think that's true. Here's a thought experiment: Suppose I wrote some software, and wrote it to a CD, erasing all other copies. I then wrote out, in longhand, the text of the GPLv3 on paper, and attached it to the CD, and gave it to you. This software would clearly be under the GPLv3, and you could redistribute it under those terms. Now suppose the same situation, except that I also wrote an extra restriction at the bottom: Also, if you copy and distribute this code, you must send me a postcard. Now, a bit of the text I wrote out in my own handwriting earlier says that if I put any extra restrictions on, you can ignore them. I quite clearly wrote that you can - it's there, in my own handwriting. So you can surely choose to do exactly that. Why does the same logic not apply when the text of the GPLv3 was not typed out or written by you, but just added to your software distribution? Now, if I specifically disclaim section 7 in my additional text, then that's perhaps different. But that would just demonstrate that my intent was to confuse :-) At the end of the day, the intentions of the licensor are important, and if those intentions are made explicitly clear, it's a bit difficult for the GPL to contradict them. But the GPL _is_ the intent of the licensor. You know this, because they start with I license this code under the terms of the GPL(v3)... Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of GPL v3
Ben Finney wrote: No. This is no more true than to say that, because the GPL, BSD, and Artistic licenses accompany software in Debian, that those licenses apply to all of that software. The only thing you've clearly done is distribute a license text and a CD. The license text doesn't apply as the terms for the software on the CD unless and until the copyright holder explicitly declares so in a grant of license unabiguously on that particular software. Yes, OK. Extend the thought experiment with a verbal statement from me Here is some software, and the licensing terms which apply. at the time of handover. If you think that's repudiatable, we can posit a video of the handover, or a digitally signed WAV recording of me saying it. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald wrote: 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. I don't believe that Debian provides legal views... My personal view is that GPLv3 is not compatible with the OpenSSL license. The problematic part of the OpenSSL license is the BSD advertising clause: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) (From http://www.openssl.org/source/license.html) The only way this might be compatible with GPLv3 is if this clause was permitted by one of the clauses in GPLv3 section 7, Additional Terms. The only one under which it might fit is clause b): Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: ... * b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; (From http://www.gnu.org/licenses/gpl.html) However, this only permits requiring preservation of notices in the material. An advertisement mentioning OpenSSL is not part of OpenSSL, and so this clause does not make point 3. of the OpenSSL license GPLv3-compatible. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. This seems the correct way forward in the long term. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
Francesco Poli wrote: In the case of the AfferoGPLv3, I am *not* already distributing software. But you are distributing some sort of data - otherwise the person using the software would not be interacting with it. Interaction requires exchange of data. I modified the application and simply want to run it on my server. If it were just running on your server, there would be no distribution requirement. But it is running on your server and sending and receiving data from the user, which is different. In order to do so, I am compelled to offer to distribute source code to users. Let's see what I can do: * if the application runs on a resource-limited server (think about a small embedded system...), I cannot use the same host If it's a small embedded system, the source code is likely also to be small. Or is this a combination of the small embedded system objection and the gigabytes of modified source objection? * if I don't want to publish the application (but only distribute it to my users), I cannot use a public hosting service I refuse to believe that finding somewhere to host a password-protected 10MB tarball is so difficult that it falls into the category of unreasonable requirement. * if I cannot afford the costs of ensuring it is available as long as the application runs, I cannot use another host owned or hired by me And if you can't afford the costs of the bandwidth for the small embedded system, you can't run the service at all! Free as in freedom does not necessarily mean free as in cost to you. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
Christofer C. Bell wrote: As the AGPLv3 will force you, from the United States, to offer cryptographic software for export in the event that you modify server software using it and (make that software available for interaction over a network), it is forcing you to violate US law. Making cryptographic software available for export from the US is not, in an of itself, a violation of the law. Look at all the open source projects which do it (e.g. the Mozilla project). Open source products can be exported from the US under license exception TSU (Technology and Software - Unrestricted) according to Section 740.13(e) of the Export Administration Regulations. http://edocket.access.gpo.gov/cfr_2006/janqtr/pdf/15cfr740.13.pdf (page 2). There may be a one-off notification requirement, I don't recall. But if there were, that would not fall into the unreasonable burden category, which is the point in question. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
Bernhard R. Link wrote: It's not the users of the software, it's the users of services run by the software. But in today's world, that's no longer a meaningful distinction. It used to be that software ran on a computer on my desk, and I interacted with the services provided by that software using the attached monitor and keyboard. Now, I interact with the services provided by software that runs on a computer somewhere else, using the same monitor and keyboard. Why do I require less freedom in this case? In fact, there's not even a bright line between here and somewhere else. If I'm interacting with a web application, a significant proportion of that code _is_ running on my local machine, inside my JavaScript VM or browser. This argument even applies to non-networked applications. If I'm running OpenOffice.org on my machine, I should have software freedom with respect to that software. Why does that change if I'm instead accessing it via a remote X session? You may argue that there's a legal difference between the two in terms of copyright law, performance etc. That may or may not be so. But I assert that there's no difference in the amount of freedom that a user of free software should require. So where to draw the line for use restrictions? If you really want the same abilities and rights, why don't you demand that users can change the software running? Things like Firefox extensions and Greasemonkey actually make this fairly trivial for web apps. And other tools could be developed for other apps. If the licensing of software banned e.g. the use of Greasemonkey scripts on it, then it would definitely be non-free. If it's a small embedded system, the source code is likely also to be small. But usually the memory on embedded systems is even smaller, so this is a very noticeable restriction. There are lots of restrictions imposed upon you when you create an embedded product. If you license proprietary software, you may have to pay money to its owners. If you use free software, you may have to put an extra $1 or $.50c flash chip in to hold a copy of the source. Free software doesn't mean zero cost in meeting the licensing obligations. The question is, is the burden unreasonable? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
MJ Ray wrote: 1. Along similar lines, one question I keep returning to is Would a licence that required me to give a copy of the source at my expense if I let someone use the application on my laptop meet the DFSG? It doesn't require you to give them a copy. It requires you to offer it. In other words, the app you let them use might have a Save Source link, but they are responsible for bringing the USB stick. And I think the answer is No, it breaks DFSG 1 but people are defending the AGPLv3 by saying that the cost is negligible, which I'm unsure about. I'm also not sure whether the scale of the cost matters much - one person's negligible is another's cost of living. Basically, AGPLv3 seems to reduce the user's freedom to use, but not distribute That's a good way of putting it IMO. which isn't explicitly forbidden by the DFSG, but surely outside the normal Free Software Definition. Why surely? Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is AGPLv3 DFSG-free?
Miriam Ruiz wrote: Would you consider that anonymous enough to pass the dissident test? The dissident test does not require that every possible method of source distribution passes the test, but only that it's possible to pass the test. The life of a dissident is a complicated and difficult one. The fact that they cannot avail themselves of the most convenient and lowest cost methods of distributing the source code to their free software is, I suggest, but a minor consideration in their thinking. They probably can't avail themselves of the lowest cost and most convenient forms of transport either (e.g. Oyster cards in London). Consider a dissident in a totalitarian state who wishes to share a modified bit of software with fellow dissidents, but does not wish to reveal the identity of the modifier, or directly reveal the modifications themselves, or even possession of the program, to the government. So he can have a Download source link on his web interface. This does not require revealing anything to anyone who is not one of his fellow dissidents who is using the web interface. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Updating the MPL
On 13/03/10 08:18, Paul Wise wrote: Is there the perception that the MPL is still nessecary? I'm wondering what features of the current/future MPL are desired and are not satisfied by the LGPL / GPL dual licensing combination or could be The scope of the copyleft in the MPL (file-level) is different to that in the LGPL (library-level). Historically, the MPL has proved to be a middle-ground where BSDish people and GPLish people have been able to cooperate. So we have no plans to significantly change the copyleft scope, and that means that something like the LGPL would not be a suitable replacement for the MPL. Since that requires Javascript, you'll find some people will prefer to comment here or on the below lists. co-ment looks to be a very nice piece of software though. While we will attempt to read and consider all feedback we come across, we would prefer discussion to happen on the dedicated list. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnl2n2$a9...@dough.gmane.org
Re: Updating the MPL
On 13/03/10 21:52, Francesco Poli wrote: However, the license text to be commented is *not* identical to the official text of the MPL version 1.1 [2]. [1] http://mpl.mozilla.org/participate/comment/ [2] http://www.mozilla.org/MPL/MPL-1.1.txt (as far as I know) The differences (as shown by wdiff) are not purely cosmetic. For instance, Section 8.2(b) in the official version [2] states [...] | any rights granted to You by such Participant under Sections 2.1(b) | and 2.2(b) are revoked [...] while the same Section in the to-be-commented text [1] states [...] | any rights granted to You by such Participant under Sections 2.1(a) | and 2.2(b) are revoked [...] which is *not* the same: please note 2.1(a) instead of 2.1(b)! Goodness me. Well spotted :-) As far as I can see, all other witnesses I can find have the former text, and only the to-be-commented text has the latter. Reading the licence, the former text looks correct (2.1(b) is about patents, but 2.1(a) is not). I will enquire as to what happened, and hopefully get the draft-for-comment corrected. I used wdiff myself (great tool!) and it seems to me that the only potentially significant changes between the two files you name are this one, and the replacement of an NPL by MPL in section 13, which looks to be like a belated correction when the NPL was turned into the MPL during the drafting process. Are there any other differences you see as significant? Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b9e115b.4030...@gerv.net
Re: Updating the MPL
On 15/03/10 10:52, Gervase Markham wrote: I will enquire as to what happened, and hopefully get the draft-for-comment corrected. https://mpl.co-ment.com/text/NMccndsidpP/view/?comment_id_key=JeG3XyUGGI7 Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnllio$ki...@dough.gmane.org
MPL 2 RC1 released
Hi, all- I'm happy to announce the release of MPL 2 Release Candidate 1 - the text that we hope will become MPL 2.0 and serve the open source community well for the next decade (or three). The plain text of the license is here: http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-RC1.txt (other formats available through http://mpl.mozilla.org/participate/rc ) Changes === We received excellent and useful feedback on Beta 2, which led us to make a lot of smaller changes (definition cleanups, readability changes, etc.) and one larger change - a reorganization of the language on compatibility, merging the bulk of it with the Larger Works language. This should not change the meaning from Beta 2, but the language is very different, and hopefully more clear and understandable. You can see the changes in this pdf: http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-B2-to-RC1.pdf FAQs Along with the RC, we have also posted two draft FAQs that we would also love feedback on. The first FAQ is the license FAQ: http://mpl.mozilla.org/wp-content/uploads/2011/08/FAQ-RC.html The second FAQ is about the process that created MPL 2, and the changes that occurred between 1.1 and 2.0: http://mpl.mozilla.org/wp-content/uploads/2011/08/Revision-FAQ-RC.html We welcome comments on those as well - either comments on the answers, or suggestions for further questions. Feedback As is usual with release candidates, we would like to use this text as the final release with no changes, but we need this group (and anyone else you know who may be interested) to review the license and make sure it is up to snuff. To comment, the same channels used in previous releases are available: commenting tool (linked to from the primary participation page, below); this mailing list, or direct contact with me, Gerv, or Harvey. A link suitable for tweeting, emailing, etc., that has all the links above (and more!) is here: http://mpl.mozilla.org/participate/rc Scheduling == We have not set a firm deadline for feedback and the final release, but we hope it will be in the next few weeks. Please keep that in mind while reviewing. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j2bdau$ovd$1...@dough.gmane.org
Re: Educational Community License 1.0
On 26/08/11 23:09, Ben Finney wrote: Bear in mind that the Debian Free Software Guidelines don't allow a work into Debian if the license is special to Debian. See DFSG §8: 8. License Must Not Be Specific to Debian 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. This effectively means that the trademark license must be universal and open to all recipients, regardless of Debian, otherwise it's not a free work under the Debian guidelines. If you interpret the DFSG that way, then effectively Debian policy is that no trademarks may appear anywhere in Debian. The purpose of trademarks in law is as a determinant of origin. If putting a trademark into Debian requires the trademark holder to allow software from any origin and with arbitrary changes to bear the trademark, then the trademark is no longer valid or defendable. And such a 'trademark' is no longer a trademark (literally: a mark used in trade). I do not think that breaking the trademark system with respect to free software is a necessary or desirable goal for the Debian project. Allowing software makers to build reputations and mark software as being of a certain origin (and therefore having a certain reputation attached) is a user-friendly thing, not a user-hostile thing. It empowers people to make better and more informed software choices. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5b6be4.8040...@gerv.net
Re: Educational Community License 1.0
On 29/08/11 15:18, Ben Finney wrote: then effectively Debian policy is that no trademarks may appear anywhere in Debian. The purpose of trademarks in law is as a determinant of origin. What in DFSG §8 (or in my explanation of it) makes this infeasible, in your view? If you understand DFSG §8 to apply to trademarks, then the right to use a trademark to identify the software must be offered to those outside Debian. Debian also requires that software not be subject to restrictions on its modification (DFSG §3). These two principles combine to say that the the software, arbitrarily modified, must still be permitted to bear the trademark. As any software can be incrementally transformed into any other software, this effectively means the mark can be used on any software at all. I suspect you don't agree with that, so where is my logic wrong? You could argue that trademark holders can grant the right to use the trademark to Debian for the exact Debian version, and to everyone else for the exact Debian version, and so everyone actually has equal rights. But in practice, either this means that the trademark holder needs to approve all changes Debian makes (which is generally unacceptable to Debian, I understand) or the trademark holder says OK, Debian, I trust you, make modifications - at which point, the licence becomes specific to Debian again and you are back behind §8. And such a 'trademark' is no longer a trademark (literally: a mark used in trade). This is a non sequitur AFAICT (nothing in what you're describing stops the mark from being used in trade), but it also doesn't seem to be crucial to your point. To expand my brackets further: (literally: a mark used in trade to identify the origin of goods). A mark anyone can use cannot be such a mark, by definition, because it could be applied to goods of any origin, and therefore does not identify origin. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j3ns9m$rt5$1...@dough.gmane.org
Re: Mozilla Public License 2.0 released
On 05/01/12 23:16, Francesco Poli wrote: Clause 1.5(b) fails to solve existing compatibility headaches. It disables the default (L)GPL compatibility (caused by clause 3.3) for those works that were previously incompatible because they were only licensed under the MPL v1.1 (or earlier). This means that any existing compatibility headache stays unfixed, unfortunately. As you can imagine; this was an intentional choice. Some people chose the MPL because it was GPL-incompatible; pulling the rug from under them would have been an unreasonable move. I think that it would have been far better if the license authors had enabled (L)GPL compatibility for previously incompatible MPL-licensed works. Doing so would have instantly solved many compatibility issues that currently affect MPL-licensed works. But possibly ridden roughshod over the intentions of the author of the works. Clause 2.3 limits the patent license grant when Covered Software is modified. This may create troubles (legal uncertainty) for people willing to modify the work (see DFSG#3). No-one is going to offer to license any and every applicable patent they own relating to a work which can be arbitrarily modified. Otherwise, it's effectively giving a licence to everyone for every patent you own, because any software can be incrementally transformed into any other software. If I understand correctly, accompanying the Executable with the Source Code is considered an acceptable way to satisfy clause 3.2(a). Also, if someone offers access to the Executable Form from a place, then offering equivalent access to Source Code from the same place (at a further charge no more than the cost of distribution) is considered another acceptable way to satisfy this clause. Both of those are corect, although in the second case, it would be wise to include a notice in the executable form about where the download location is. Clause 3.2(b) allows to sublicense the Executable Form under different terms, while the corresponding Source Code must remain available under the terms of the MPL. This is very confusing, IMHO: having Source Code and Executable forms under different licenses makes things unclear for the recipients. This is inherent in the idea of a copyleft licence which does not necessarily cover all the code in an Executable Form. LGPLv3 section 4 does the same for the LGPL (You may convey a Combined Work under terms of your choice...). This clause states that any law or regulation doing something shall not apply to this License: how can this be enforceable? can I write a license that disables laws, by simply stating that they do not apply?!? You can do that for laws which allow it to be done. The method of resolving license ambiguities is a default rule, but can be changed by the contract itself. Random Googled reference: http://contractman.blogspot.com/2010/04/ambiguity.html It is effectively a protection for the Contributor, who might otherwise be stuck with a problem caused by Mozilla's inability to write clear English. Warning for people thinking to license their own works under the terms of the MPL: you have to really trust the Mozilla Foundation to always get things right, if you decide to license anything under the MPL! As with the FSF and the GPL (if you use or later). I hope that the relationship of the spirit of MPL 2.0 to MPL 1.1 should be good evidence of our benificence in this area. It's good that this is permitted, but it should have been strongly discouraged! It has been: http://www-stage.mozilla.org/MPL/2.0/FAQ.html#making-my-own-license Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f0eebd4.4080...@gerv.net
Re: Mozilla Public License 2.0 released
On 13/01/12 21:31, Francesco Poli wrote: Nonetheless, all the existing GPL-incompatibilities due to the MPL v1.1, including the *unintentional* ones, won't be solved, except for the cases where the copyright holders may be tracked down, and convinced to explicitly enable the compatibility: How would you suggest distinguishing between intentional and unintentional, without tracking all the copyright holders down and asking their intentions? And, once you've tracked them down, you might as well ask permission for relicensing under plain MPL 2. That's a reasonable and convincing explanation. Unfortunately, the clause does not include some additional words to clarify this rationale. As a consequence, some people willing to modify an MPL-licensed work could feel legal uncertainty and be scared away... That's basically what I meant, when talking about legal uncertainty. This particular provision of MPL 2 is very similar to that of MPL 1.1. Therefore, I am not too worried that it will create significant legal uncertainty. This is inherent in the idea of a copyleft licence which does not necessarily cover all the code in an Executable Form. LGPLv3 section 4 does the same for the LGPL (You may convey a Combined Work under terms of your choice...). I am not sure that this is exactly the same as in the GNU LGPL. The LGPL seems to only give this permission for Combined Works, while the MPL seems to allow sublicensing even for the Executable Form of an unmodified MPL-licensed Source Code... That is true; but in practice, the difference is tiny. If we required that people modify the MPL-licensed source code before being allowed to licence it under a new licence, there are any number of trivial modifications they could make. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f15796e.6080...@gerv.net
Re: Ethics/morals issue
On 25/11/12 22:08, Gary Wilson wrote: Thank you very much. Your assistance is greatly appreciated If your son is interested in how it can be that there exists a complete operating system and thousands of pieces of software which are freely available for him to use without restriction and without need for legal agreement, he might like to start reading here: http://www.gnu.org/philosophy/free-sw.html If he is a Christian and interested in the moral issues surrounding free software, he may also be interested in this: http://www.gerv.net/writings/christianity-and-fsm/ Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50b4bfc4.2060...@gerv.net
Re: Are all files produced by GPL Ghostscript copyrighted by 'Artifex Software, Inc.'?
On 22/12/12 12:33, Vaibhav Niku wrote: One solution to the problem is to get the source code, delete the lines which insert the copyright notice (“modify the code”), compile the code, and use this. This is legal as the code is released under GPL and GPL allows modifications. (You could release your modifications too. This is how Debian makes ‘Iceweasel’ out of ‘Firefox’ -- just so that Debian users don't have to sign a EULA with Mozilla.) Can I just correct a misunderstanding here: Firefox does not have a EULA, and there is no need to sign anything to use it. The builds you can download from www.mozilla.org are fully free software under the MPL 2. [It is true that we retain trademark control over use of the Firefox logo, which is probably why Iceweasel still exists - although, not being involved in that project, I couldn't say for definite.] Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50df2d29.7060...@gerv.net
Re: AGPLv3 and BSD-4-clause compatibility in the same source
On 27/10/13 17:19, Ondřej Surý wrote: Since BSD-4-clause is not compatible with GPL do I understand it correctly that they basically made Berkeley DB 6.0.20 indistributable by us? Or am I missing something about mixing BSD-4-clause and AGPLv3? It depends on who the acknowledged party is. If it's the University of California, Berkeley, then see: ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change In other words, such UCB files are now effectively 3-clause BSD and so GPL-compatible. Gerv -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l4ohj5$nt8$1...@ger.gmane.org
