Re: MySQL licensing and OpenSSL linking issues
On Sat, Jun 07, 2003 at 01:08:21PM -0500, Branden Robinson wrote: On Fri, Jun 06, 2003 at 02:25:45PM -0500, Steve Langasek wrote: Other than that issue, I think this would nicely address Debian's needs. I'm pleased to see MySQL AB taking this step to clarify the license of the client libraries. It seems at that point that it would be easier to just put it under the LGPL. Except that the LGPL permits use of the code in ways that MySQL does not want to allow. Well, what do they want to allow, and what don't they want to allow? Perhaps we can help them formalize the wording, if we understand their desires. As I understand it, they're looking for the copyleft protection of the GPL to avoid exploitation of the library in proprietary applications, but at the same time want to permit linkage from GPL-incompatible Free Software (I'll bet PHP is a big factor here). Beyond that, I imagine their desire is fairly vague, and passing the buck to the OSI would relieve them of the burden of formal wording. :) -- Steve Langasek postmodern programmer pgpl8xlDV3QWj.pgp Description: PGP signature
Re: A single unified license
The idea of writing a single license for both software and documentation (i.e., for content) is a good one. Perhaps this could be done in GPL version 4. I would hope that in extending it, the beauty of the current GPL is preserved. What is beautiful about the GPL is that it grants the licensee total freedom to do what s/he likes with the work, with a single well understood limitation: s/he cannot distribute an improved version of the work under more restrictive terms or conditions than those of the GPL. This restriction is not a burdensome restriction on anyone who wants to contribute to the commons: it simply rules out a certain dangerous sort of exploitative behavior: the Embrace and Extend(tm) strategy. The GPL places minimal restrictions on the use of the content itself. That is more than can be said for the GFDL. The GFDL places several different kinds of restrictions on the content itself, none of which appears to be either necessary or sufficient for the effective protection of software freedom. We are supposed to accept these restrictions on the grounds that RMS doesn't find them too onerous. That just isn't good enough, at least for Debian's purposes. So I hope that a future unified content license is modelled on the current GPL, not on the GFDL. -- Thomas Hood Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
Re: A single unified license
GPL 3 is not at the stage to ask for public comments.
Re: A single unified license
Can someone remind me how exactly the license above is incompatible with the GNU GPL? Each one is a copyleft. The GPL says the combined work must be under the GPL. The simple license says the combined work must be under that license. Both cannot be true at once.
Re: Proposed: Debian's Five Freedoms for Free Works
4) The freedom to change the Work for any purpose[1], to distribute one's changes, and to distribute the Work in modified form. Access to the form of the work which is preferred for making modifications, if applicable, is a precondition for this. OK, so there's lots of argument about preferred form. How about a more negative definition: Deliberately obfusticated or encrypted forms and program-generated forms are *not* preferred forms for making modifications.
Re: A single unified license
On Saturday, Jun 14, 2003, at 07:03 US/Eastern, Richard Braakman That's a lot easier than Here's a Debian CD. And here's my solemn promise to provide source CDs for this Debian version to anyone who asks for the next three years. Please wait while I go buy a CD burner. (Note that 2(c) is not an option here because Debian doesn't use 2(b).) Well, the CD burner thing doesn't really apply; either I got that Debian CD by burning it, from a friend, or buying it. In the first case, I already have the CD burner. In the second case and third case, I should have source disks or a 2(b) offer. In the third case (and maybe the second case), the first sale doctrine applies as well, so I don't have to worry about the GPL. However, I see your point here. For me giving a Debian CD to my friend, I shouldn't have to either worry about doubling the number of CDs (and download time) or 2(b). I agree that 2(c) needs to be improved in light of the seldom use of 2(b). May I suggest: d) Accompany it with information you reasonably expect to remain accurate for at least one year as to how to obtain, for a charge no more than the cost of physically performing source distribution, corresponding source. (This alternative is allowed only for noncommercial distribution in quantities of under 120 per year) The wording needs some help, of course. But the major changes: 1) You must reasonably expect the information to remain accurate for one (or should this be 3?) years. In the case of Debian, you'd use ftp.d.o or archive.d.o. 2) You may only do it 120 times or less per year. This number seems high to me... Maybe it should be less. I sure don't give out 10 Debian CDs a month. One problem I still see with the wording is that the information I could give could be: Visit http://www.google.com/, search for foomajig 0.13.2. I think 2(d) reflects what people already do in practice. It may even dispel some of the misinformation and misunderstanding surrounding the GPL, by making it clear that this alternative is NOT allowed for commercial distribution. Hopefully, at least one of the works distributed by someone doing commercial distribution without even reading the license will be registered with the Copyright Office. That way, they can learn about statutory damages under Title 17. I'd hope people doing commercial distribution would be a little more cautious; and, of course, if they're not reading the license, then adding in this clause isn't going to help.
Re: A single unified license
RMS said: GPL 3 is not at the stage to ask for public comments. Rumor has it that it will contain loads of stuff which Debian considers non-free. This is a *problem*. The FDL public comment period resulted in *no* significant changes due to the public comments. RMS has declared that he has the final word on anything the FSF does, and refuses to give out the names of anyone else involved [1]. Getting information about his reasons for decisions about the controversial parts of the FDL has been like squeezing blood from a stone [2]. (It took about a year to get the information that he considered invariant sections acceptable because he classed them as 'packaging restrictions'.) The FSF is set up as a charitable corporation, which means its board is self-perpetuating. It is currently run as RMS's personal autocratic fiefdom [3], and there's really no chance of that changing without RMS's assent given a self-perpetuating board. (Unless he dies, of course.) Previously, developers were willing to assign their copyrights to the FSF because they trusted RMS/the FSF to preserve the freedom of their code. After the FDL fiasco, I no longer trust him to do that. I am waiting for a definitive legal opinion from the FSF on whether I can relicence my *own* contributions under a more permissive license (such as the GPL v.2). (I do not appear to get that right from my copyright assignment papers.) If that right is absent, I will have to cancel my current copyright assignment to the FSF, in favor of a disclaimer (since putting my work in the public domain is far better than allowing it to be made proprietary by the FSF). -- If we can anticipate consistent behavior from the FSF, we will see the following: 1. The GPL v.3 will be presented for public comment. It will contain unacceptable non-free provisions with no good explanation. 2. The comment period will contain lots of complaints about this. 3. The final version of the GPL v.3 will be released, with no change in the non-free provisions, and no explanation as to why. At this point, it will be necessary for free software developers to do the following: a) Discourage version 2 or later licensing in favor of version 2 licensing b) Encourage the forking of all FSF-copyrighted projects I would personally start a fork of GCC. Forking and relicensing is a slow, tedious process. Accordingly, if the FSF is planning to release a non-free GPL v.3, we want to start the process as soon as possible; waiting simply gives them a head start at subverting free software. On the other hand, if the GPL v.3 will be just *fine*, we don't *want* to cause the trouble caused by forking and relicensing. What free software developers want are reassurances that the FSF is *not* planning to cause this nightmare scenario by making a GPL v.3 which is unacceptable to Debian. We have *no* such reassurances. The recent past leads us to be very suspicious. The no information coming out attitude from the FSF means, sadly, that we must believe the worst: that the FSF is planning to subvert free software with the GPL v.3, and that RMS is trying to hold off on supplying information as long as possible so as to leave the opposition scrambling to catch up, as it is with the FDL. I will be starting the following projects: 1. Informational website with reasons to avoid the GNU FDL, and how to do so. 2. List of free software developers who oppose the GNU FDL. 3. Project to create free (GPL) manuals for GCC, and eventually other projects with FDL'ed manuals. (This is partly awaiting the FSF's legal opinion on relicensing of one's own contributions, since if we definitely can, I just need to collect the contributions of willing developers and then fill the gaps.) I'll need help with all of these. :-( [1] Personal communication. [2] Archives of debian-legal. [3] In addition to the evidence above, all requests for licensing changes on FSF projects must go through RMS personally, which can be testified to by many GCC developers.
Re: Proposed: Debian's Five Freedoms for Free Works
On Sunday, Jun 15, 2003, at 12:45 US/Eastern, Nathanael Nerode wrote: Deliberately obfusticated or encrypted forms and program-generated forms are *not* preferred forms for making modifications. Program-generated forms can become the preferred form. Its certainly possible to use something like glade, for example, to generate skeleton code then fill it in. Or, more weirdly, people do hack up configure, flex/bison output, etc.
Re: Proposed: Debian's Five Freedoms for Free Works
On Fri, Jun 13, 2003 at 12:57:13AM -0400, Greg Pomerantz wrote: Branden Robinson [EMAIL PROTECTED] wrote: I would say that the controlling preference is that of the person who last modified the Work and distributed it in that modified form. Anyone downstream from that person would have to keep the source in that form and the binary together. I think one formulation that makes this a bit more explicit is this: 4) The freedom to change the Work for any purpose, to distribute one's changes, and to distribute the Work in modified form. Unrestricted access to the form of the work which is preferred by its author for making modifications, if applicable, is a precondition for this. (with the possible addition of the words or translator after author). This makes explicit the fact that there is no single preferred form. If you allow individual authors to define their own preferred version, you solve problems like this -- In trying to specify, this phrasing overlooks other important preferred forms. Someone may make changes to an existing piece of software which involve rearranging the APIs. Is this a translation? I'm not sure it is; but it may change the source sufficiently that the original author would prefer not to use that form as a basis for further modifications. The important nuance here is that the preferred form is the form that the last person to modify the code worked in when making those changes. This is unfortunately hard to specify precisely in a definition. Andrea writes a program in C. Marty rewrites Andrea's program in Fortran. Ulysses gets Marty's binary and asks for source -- Marty can send his Fortran source because it is the form Marty prefers for making modifications. Alternately, assume Marty lives on a proprietary island and only has access to proprietary programming languages. Marty should not be barred from translating Andrea's program into a proprietary language and distributing his modifications in that language (which is preferred because its the only thing he's got). I think any definition of preferred form needs to pass this test. In other words, I think that any definition of preferred form that requires an open or transparent format will be non-free. The same holds true for document formats of course. The person who aims to prepare a derivative work should have the option of using whatever form she prefers, and should have no obligation beyond the distribution of modifications in her preferred form. I am not sure at this point the extent to which certain exceptions need to be in place in the case where the author has some vested interest in selling you a proprietary interpreter (in the extreme case, pay me $100 for the AES key you need to decrypt my preferred form). Any thoughts? I think there are two distinct issues here that need to be considered: whether a piece of software can be considered free if the only source available for it requires proprietary software to be useful, and whether a license can be considered free if it enforces redistribution of source in a form that is useful without proprietary tools. The first question seems to be the more important one to this discussion, since being able to use/compile/edit the software is more fundamental than being able to redistribute it in modified form. And I think the intuitive answer here is the correct one: for purposes of identifying whether a piece of software comes with enough source code to be considered free, we already have a separation in Debian between the main archive and the contrib archive. Software in contrib is *effectively* non-free, even though it's not *intrinsically* non-free; it's non-free by circumstance. Free Software is well out of its bootstrapping infancy, and being self-hosting is an important characteristic of Debian. I think this formulation of freedom in response to the first question leads naturally to an answer to the second question: yes, we recognize certain copyleft compromises as being free, and one of these is that a license can require the redistribution of source code under free terms. If source code written to a non-free interpreter is effectively non-free, then I think a license which doesn't recognize distribution of this sort of source code as fulfilling the source distribution requirements *is* free. I'm not sure such a license requirement is necessarily a good idea, and I'm not sure whether the GPL contains this requirement, but I do think such a requirement would not render a license non-free. -- Steve Langasek postmodern programmer pgpncN7roXdyY.pgp Description: PGP signature
Re: Defining 'preferred form for making modifications'
J == J D Hood [EMAIL PROTECTED] writes: J I suggest that the definition of 'preferred form for making J modifications' be information-theoretical. Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was?
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 05:15:14PM -0400, Sam Hartman wrote: Why? What real-world problem does this solve? Have we actually run into situations where it was not obvious in a particular instance what the preferred form for modifications was? I know of one thorny problem in this area: many graphics are distributed as .png or .jpg files, even though their creator probably used a richer format like .xcf. IIRC, there was also a case of a ROM image that was released into the public domain, but the source for it no longer existed. I don't remember enough details to search for it, though. Richard Braakman
Re: Defining 'preferred form for making modifications'
On Sun, Jun 15, 2003 at 07:47:32PM +0100, J.D. Hood wrote: I suggest that the definition of 'preferred form for making modifications' be information-theoretical. When source code is compiled into binary code there is a loss of information, as indicated by the fact that you cannot get the original source back, given only the binary code. On the other hand, if there is a set of different forms each of which is convertible into the others by means of freely available tools then any member of the set is as good as any other. What if the program is written using proprietary tools and formats, and translated into commented, maintainable C/java for release? (Not a straw man; the technologies are being developed and we're going to start seeing them over the next few years. One-dimensional text is not the most effective representation of a program, it's just the easiest to implement) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpuQrasSc4pO.pgp Description: PGP signature
Re: A single unified license
RMS said: Reiser's statement was inaccurate. For GPL version 3 we are considering requirements for preserving certain limited author information in the source code, and making explicit that other GPL-compatible licenses that are present on parts of the code cannot be removed from the source, but nothing beyond that. *Heaves big sigh of relief* OK, I'm happy. :-) Thanks for the reassurances. -- Nathanael Nerode neroden at gcc.gnu.org Don't use the GNU FDL for free documentation. See http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Proposed: Debian's Five Freedoms for Free Works
On Sun, Jun 15, 2003 at 01:28:18PM -0500, Steve Langasek wrote: The first question seems to be the more important one to this discussion, since being able to use/compile/edit the software is more fundamental than being able to redistribute it in modified form. FWIW, I disagree with this prioritization. While some of the definitional freedoms may be dependent on others, none is less important than another. We do not have sufficient freedom if we are allowed to modify our freely-licensed software DVD players to ignore region coding, not pass the Macrovision signal, and skip FBI warnings commercials for other products manufactured or sold by the same company that produced a DVD in our posession, but forbidden from redistributing a free software DVD player that has these features available. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgp44sh7EFzMI.pgp Description: PGP signature
Re: A single unified license
On Sun, Jun 15, 2003 at 08:10:12PM -0400, Richard Stallman wrote: I look forward to read a draft of the GPL v3, since Hans Reiser did mention that the equivalent of 'Invariant Sections' would be added in the forthcoming GPL v3. Reiser's statement was inaccurate. For GPL version 3 we are considering requirements for preserving certain limited author information in the source code, and making explicit that other GPL-compatible licenses that are present on parts of the code cannot be removed from the source, but nothing beyond that. So you are not considering adding Invariant Sections, Acknowlegdements, or Endorsements to GPLv3? That is encouraging, if true. -- G. Branden Robinson| There's no trick to being a Debian GNU/Linux | humorist when you have the whole [EMAIL PROTECTED] | government working for you. http://people.debian.org/~branden/ | -- Will Rogers pgph09l7OmfWg.pgp Description: PGP signature
