On Sun, 2006-01-22 at 11:55 +0100, Francesco Poli wrote:

I hope that's true, but the lack of progress on the GFDL issue is not what I'd call a good precedent... :-(

During the GPLv3 launch a new version of the GFDL has been announced *as ready to ship* by Moglen. It will be released soon. So the GFDL issue can be set aside, for a moment. FSF does listen to all comments and criticisms, but as for all complex matters it takes time to act avoiding mistakes. Changing a license is a very complex task, it takes attention and energy and cannot be done lighthearted. It should also be clear that the reason why GFDL has not been updated yet is because GPLv3 was already in the queue and it had precedence. I am sure that everybody agrees that GPL and LGPL are more important than GFDL :)

So, let's hope I won't throw away mine...

Let us know if that happens, because it shouldn't. The process is open, all comments will be taken into consideration and some of them will become issues that will be analised by Stallman and Moglen. You can track your comments and the issues related to your comment on the gplv3.fsf.org web site.

That is true, and was especially true in the pioneer times, when Free Software was known to very few people only. Now there's a Free Software community, though. I think the concern of the core of this community should be taken into account (especially when a Freeness issue is raised).

I think that the GPLv3 process is a good compromise between openness and control of the results. Apache Foundation recently updated its license and afaik the Apache community had such an open and participated process. Am I wrong? How would you have done the process?

Let's hope for the best...

Let's make it happen! Let's make GPLv3 the best possible license, let's set the standard.

cheers stef

On Sat, 2006-01-28 at 20:40 +0000, MJ Ray wrote:

Debian has put off resolving the FDL bugs in main for so long, but now it is addressing them more, and I doubt vapourware will change that. Please publish the draft, even if its revision is post-GPLv3.

I don't thinking publishing a draft would make any sense, it would only add to the confusion and would raise very harsh critics if it were changed a lot of time after being published.

...

I think that the GPLv3 process is a good compromise between openness and control of the results. Apache Foundation recently updated its license and afaik the Apache community had such an open and participated process. Am I wrong? How would you have done the process?

I agree that it compromises on openness. Who are secret juntas A-E and will their proceedings be public?

IIRC I was told the FSF will publish the members list. The committes will decide themselves if the proceedings will be public or not. I know some of these have already decided for being public, but some of them are still forming so I'd wait some more and see.

I would have used an international, multi-site, multi-speaker tour to introduce the draft and process. The process should be something familiar to hackers, such as a powerful bug tracking system with severities and topic tags to track issues, allowing multiple protocols to be used and not requiring a particular browser featureset, with volunteers acting as helpers, proxies and intermediaries when people won't or can't participate openly.

How the devil could that have got out of control? It uses skills that FSF should already have available, unlike a large political caucus structure, which looks strange for hackers and easy for the uncooperative to subvert.

I do not understand what are you talking about. The web site tool is very powerful and very useful both for putting comments and for searching/browsing or aggregating them into issues, you should try it out. And where's the large political caucus structure ??

The process being used so far is a conference in the homeland of the DMCA, a Big-Business-friendly launch press release, a web site with poor accessibility, and committees to filter comments into group statements for leaders to consider. It all seems rather similar to the Vienna process to me. Sorry, but if it looks like a duck, I ask: will it quack like a duck?

So what's the point in this rant ?

I think you should calm down and look at the outcome, and partecipate by leaving insightful comments on the draft, that would help. It's not at all like the Vienna process, and it does not pretend to be "democratic", but it is open to comments as it should be. The License is that of the FSF and I think the FSF has all the rights to decide which process to use to design a new license. The FSF has demonstrated innumerable times their ideas, and I think you can put at least some trust in their intentions.

Simo.

On Mon, 2006-01-30 at 19:21 +0000, MJ Ray wrote:

Try it out??? That web site tool tells me that my browser is not supported, even though it's a recent Gecko-based one. Not that it's easy to read the badly-CSS'd page anyway. (The message has changed since I last looked to say "Loading comments. If you're still reading this, it's a strong indication that we do not properly support your browser yet. You may need to _email your comments_ instead, or try another recent Gecko-based browser. You can, however, _browse comments_ on any browser.")

I understand your concerns, but I know the people who made the software are working hard to extend the support to other browsers. I have been told so by them in person. There are still some bugs with Firefox too and I see they are addressing them one after one.

But the tool is very powerful and, more important, useful and usable. I think it is a good compromise, Firefox is free software and is also available on multiple platforms, I do not think the requirement is so bad anyway.

The large political caucus structure is described in http://gplv3.fsf.org/process-definition - mere serfs only make comments to the appointed Discussion Committees who then decide what to present to the Foundation in direct hearings (Minor) or International meetings (Major). The Discussion Committees meetings need not be public, so I call it a caucus system after the non-public political party meetings or the WSIS group meetings.

Well, do you understand how much would it cost to make in person meetings and organize them to be open to the public ? This is just a practical decision, most of the discussion between committee members is made electronically or by phone anyway.

...

...

The process being used so far is a conference in the homeland of the DMCA, a Big-Business-friendly launch press release, a web site with poor accessibility, and committees to filter comments into group statements for leaders to consider. It all seems rather similar to the Vienna process to me. Sorry, but if it looks like a duck, I ask: will it quack like a duck?

So what's the point in this rant ?

Try to promote the request to use an open, familiar process with a truly international aspect instead of the cooptable caucuses.

The conference was really open to anyone to come and partecipate, people came from Europe, South America, Asia ... of course being held in Boston there were much more people living in the US than others, but that would have been the same in any place, with locals being more than others. Btw, can you explain what is a "familiar" process ?

Look up "Regulatory Capture" and compare vulnerable models with the GPLv3 process. No licensor nor licensee should be allowed to influence this process in secret.

Anybody is allowed to influence the process through the comments on the GPLv3. Of course committees will be able to summarize the issues they see most important and advice FSF to look at them, but committees have no power decide anything, they are just a way to allow FSF understand the concerns of various parties.

...

I think you should calm down and look at the outcome, and partecipate by leaving insightful comments on the draft, that would help. It's not at all like the Vienna process, and it does not pretend to be "democratic", but it is open to comments as it should be.

These criticisms are made calmly. I'd really prefer to have these bugs fixed long before the outcome maybe goes wrong. The arguments for secrecy are rather limited, aren't they?

What secrecy ? The issues are posted on the gplv3.fsf.org side along with comments and anyone is allowed to see them, which committee made the issue and which explanation is given.

Joke: Do you want me to copy you any mail/phone call I receive during this year to make it an open, non secret, process ? Should I also record all in person talks and forward them too ? :-)

Would leaving comments help? The opaque process does make me doubt it. Each time I ask a question about the process, there's been either "wait" or no clear answer AFAICR.

The process is quite simple. a) people and committee members leave their own comments on the comments page b) committees read the comments of an area they they think is important, try to group comments by argument and discuss the argument. c) committees posts issues on the same page grouping all comments that seems relevant and try to summarize the concerns that were raised on the argument. d) FSF supervises the process, give explanations when needed

At the end, FSF will gather all issues and decide whether they need to be addressed by modifications, clarifications, FAQs, etc..

"Democratic" can just mean governed by the people.

What people ? Do we have a "Free Software Nation" with passports and citizenship ? FSF invited People that actually do use the GPLv2 and are interested in commenting on the GPLv3. I think they tried hard to call persons that represent the majority of people who uses the GPL day by day. It's easy to say this process should be "democratic", but you should perhaps explain who is the "Deimos".

If the FSF did not wish there to be any democracy in GPLv3, then the comments process is insincere.

I think you should really explain what does it mean to have a democratic process in this case. I don't see allowing unknown people to influence what to put in the GPLv3 has any value.

I don't believe that's the case, so I'd like to see at least the minimal democratic transparency.

Can you please explain what this broad requirement should be in practical terms ?

Of course the FSF has the right to use whatever process it wants. I have the right to question the process and it would be wonderful to see some of the FSF board minutes that show the reasoning.

Have you sent them a request about that ?

I think FSF members want the GPLv3 to be useful and have wide public support, but I think it looks like they have picked a lousy tool to try to accomplish that.

I think the tool is a quite good one, and I find really hard to imagine alternative practical methods. Do you have practical advices to make the process better ?

Simo.

On Tue, 2006-01-31 at 12:16 +0000, MJ Ray wrote:

simo simo.sorce@xsec.it [the comments tool]

...

But the tool is very powerful and, more important, useful and usable.

I'll have to take your word for that, seeing as I can't use it!

What browser are you using? Did you inform the webmaster? Did you submit bug report? Your help would be appreciated.

To be clearer: I think FSFE members spoke at about 30 events in 2005. GNU speakers (mostly RMS) seem to do a similar number. Not all of those would be appropriate opportunities, but there would be plenty to introduce GPLv3 to many interested people.

We all in FSFs will definitely do this.

Sticking "International" in a conference title and expecting people to dump exhaust fumes into the upper atmosphere in winter (and it's not fun to do much else from Europe at this time of year) is not very good. This is why a multi-site intro is a very good idea.

Please then help raise funds to support translations. At the moment FSF staff is already working 200% over-time to improve the site and make it useful. Managing translation falls shortly after 'expanding support to other browsers than FF'.

I think most hackers and users are more familiar with bug trackers than with caucuses. We have a large problem with growing cynicism and falling participation in political processes, while "bazaar" software development seems to be growing, yet FSF looks like it modelled GPLv3 discussion on the declining political processes!

GPLv3 is not only for hackers. It is also for lawyers, public administration, civil servants, businesses, engineers. Therefore the tool tries to take into consideration many many factors, needs and requests. If you have suggestions on /how/ to better manage the process then please submit them, trying to avoid the words 'democratic' and 'open', supplying real use case scenarios as I don't seem to understand your point.

Then please point me the literature where 'growing bazaar style development' is growing, because I see pretty vertical organizations dealing with very large free sw contributions (Eclipse, the whole Apache software, OpenSolaris, OpenOffice.org). I would like to know more about this topic.

Are you saying committees will not be deciding which issues are Major, Minor or dismissed?

Committees will help FSF:

4.2 Issue Resolution Each issue identified in the course of public participation can be resolved in one of four ways: by modification of the license draft, by alteration of descriptive material, by advice concerning the use of the license, or an issue may not require any change. Discussion Committees will characterize issues as Major or Minor. Major issues will be placed on the agenda of all other Discussion Committees and, until resolved, may be placed on the agenda for successive International meetings. All issues unresolved at the end of each drafting stage will be carried over for discussion and resolution during the next discussion stage. All issues not resolved before the issuance of the last discussion draft will be finally determined by the Free Software Foundation at the close of the last call period. All Major issues resolved by the Foundation will be described by a written opinion, publicly available, at GPLv3.fsf.org.

If you want to be in a committee you should ask FSF for an invitation.

Discussion Committees A-E can work in secret if they wish and nothing appears to republicise the process later.

Where is step c "posts issues on the same page" documented? That looks like new data to me. There seemed no requirement for steps b-d to be public. Your description contradicts http://gplv3.fsf.org/process-definition#SECTION00610000000000000000

• does it need updating?

Probably it needs better wordings. Simo has put it the way I understood section 4.1 of the process definition and the way I have heard the process described by Moglen in Boston.

FSF has also locked out many free software users by siting the only public event so far in the USA and by requiring a particular browser. Most foreign users of lynx, w3m, links and much other free software need not apply, or can email and pray.

Oh, come on: look at web site statistics and you will realize that the users of text-only browsers are a very little percentage. And in any case, thinking of those like rms that don't use X, FSF provided the email interface.

The first event took place in Boston for practical and symbolic reasons: practical because organizing in any other place would have costed too much for coordination from FSF. Symbolic because GPLv2 was developed in Boston, with rms working at MIT, therefore the choice of the venue.

Yes, rms apologised for choosing to host the conference in USA, because some decided not to travel there to protest against US government. There will be at least a conference in Europe and in Latin America, be assured.

An open and transparent process with well-understood process and audit trails on all public submissions until the final reckoning. A tin-pot town council can manage it: why not FSF?

Because the scope of a town council and that of a corporation like FSF are totally different? FSF has a manifesto and the responsibility of copyright assignments from hundreds of people. FSF cannot give up completely to this kind of democracy.

1. migrate the fancy web comments to an open bug tracker with BTS proxies and helpers on-call for those who need them,

I won't comment on the choice of the tool as they all have drawbacks and advantages. In any case changing the tool now is out of question.

2. replace Discussion Committees A-E with geographic forums (mainly because cultures and time zones make that grouping as practical as anything else),

Geographic or other criteria are all equally opinable.

3. prepare and dispatch GPLv3 briefing packs to all speakers,

This is done already.

4. organise and call GPLv3 meetings at events,

This is being prepared. There is already one date almost fixed and you will see communication in this list within few days.

5. make people and materials available to local user groups, law libraries and whoever else you think is relevant, and

Lawyers are being called to participate to the process. Committees C has many from few countries. I you have names to suggest please do: write to Moglen and Peter Brown.

Local groups should ask what information they need more than those provided on the site, probably also they should help raise funds to organize local GPLv3 conferences and have FSF speakers.

6. issue calls for participation by non-big-business groups such as free software projects, cooperatives, charities, governments and civil society.

That was done already. But, again, if you feel someone important was left out it was only because FSF is not the Almighty and doesn't know everybody on the planet: let FSF know who should participate in the Committees. There is no reason why FSF would not want more members.

I hope I have answered your concerns. /stef

MJ Ray mjr@phonecoop.coop writes:

...

...

To be clearer: I think FSFE members spoke at about 30 events in 2005. GNU speakers (mostly RMS) seem to do a similar number. Not all of those would be appropriate opportunities, but there would be plenty to introduce GPLv3 to many interested people.

We all in FSFs will definitely do this.

This has been news to me. Has anything been announced?

Here are my notes from a GPLv3 talk I gave in Belfast in January: http://ciaran.compsoc.com/2006-01-19-gplv3-belfast.html

I'm currently confirming the details for giving a talk in London on April 7th. The topic is "legal threats to free software", and GPLv3 will mentioned in that.

I'll also be at IFSO's AGM on February 27th in Dublin, there will not be formal talks, but GPLv3 will be discussed as much as the attendees like.

I'm also helping to organise a free software event for March 16th in Belfast, where Stallman will be one of the speakers. GPLv3 discussion will probably be included. I may or may not speak myself at this.

On Sat, 28 Jan 2006 20:40:51 +0000, MJ Ray said:

I think *updating* the FDL is more important than updating the GPLs.

I concur. The GFDL is suffering from a lot of practical problems and even didn't achieved its goal to foster publishing of free documentation as woodware. Even worse, GNU maintainers have been forced to change all documentation to the GFDL and only a few resisted and kept foing with the GPL.

We now have the so-called printer friendly GFDL and not to long ago the FSF gave up on GNU press and laid off the responsible editor. GFDL a success?

As far as we know, we have working GPLs, but we have a FDL which

There are actually a couple of mid-term problems which should be solved by a new GPL but the whole process thing is too much of big business and too less of modern communication. Its like the old FSF closed shop development model.

I agree that it compromises on openness. Who are secret juntas A-E and will their proceedings be public?

I'd like to know this too. The only detail I know is that minutes From the commitee meetings will be published. A bit of glasnost would do good.

Shalom-Salam,

Werner

On Tue, 31 Jan 2006 10:34:27 +0100, Alfred M\ Szmidt said:

Force and force... GNU maintainers agreed to follow the policies of the GNU project, this is no different than say a Debian maintainer

As long as they make sense; the GFDL does not make any sense. Nobody at the FSF addressed the serious concerns many of us have with the GFDL. In fact the GFDL hinders development of free documentation.

I strongly doubt that the two have anything in relation.

The GFDL has been written with publishers in mind; look at the terms: most make sense only for woodware. And later the own publishing branch ceases work? Have you seen any change on ORA's licenses? I consider the GFDL a compelete failure and I would really like to see how the new draft addresses all the problems.

clarifications (and simplifications, I find the license to long and to complex), but none that are so grave that it is more important than

I can't grab a single short text from the very good glibc manual and use it with other projects - unless I add a bunch of useless attachments. It is simply not designed for sharing. The GPL might be inconvenient for a publisher but it works far better for documentation.

I agree that plain texts are very different to software but documentation is clearly part of the code - at least it should be for any well written code.

Shalom-Salam,

Werner

"Alfred M. Szmidt" ams@gnu.org

Putting documentation and software into the same box doesn't make sense, the GFDL makes perfect sense on the other hand in my mind.

Nowadays, lots of software ships with program and docs on the same media and this is not often called a new or nonsensical development.

Werner Koch wk@gnupg.org [...] In fact the GFDL hinders development of free documentation.

Do you have anything to back this up? GFDLed documentation is free to be shared, used, modified, and viewed [...]

Apart from the bit which is slightly off the current topic, but could be relevant for future topics! If I staple a program to a dead squirrel and the copyright licence says every copy must be linked to a dead squirrel, is it free software?

...

The GFDL has been written with publishers in mind; look at the terms: most make sense only for woodware. And later the own publishing branch ceases work?

Do you know why it stopped? I don't. [...]

Has it stopped? Anyone got an announcement? I missed it.

Have you seen any change on ORA's licenses?

I'm not sure what you mean.

It was claimed that there would be a great explosion of manuals for free software under the FDL because of its adware nature.

...

I can't grab a single short text from the very good glibc manual and use it with other projects - unless I add a bunch of useless attachments.

Yes you can, that is protected under fair use.

Only for limited purposes, which vary from country to country. In general, it's not legal to do so.

...

The GPL might be inconvenient for a publisher but it works far better for documentation.

I disagree. There are many problems with applying the GPL to documentation. The GPL was designed for software in mind, other uses tend to cripple the actual goal (the distinction between `binary' and `source' comes to mind).

The binary/source thing seems better than the opaque/transparent problem of the FDL. What problems with GPL for manuals? The only one that sticks for some uses is public performance.

[...] a _reference_ manual should be part of the code, this is something I could agree to. [...]

So GPL for reference manuals would be fine by you? How about tutorials which may have programs derived from it?

Thanks,

On Wed, 01 Feb 2006 13:48:03 +0000, MJ Ray said:

Apart from the bit which is slightly off the current topic, but could be relevant for future topics! If I staple a program to a dead squirrel and the copyright licence says every copy must be linked to a dead squirrel, is it free software?

We have seen similar things in the past. For example the "GPLed" version of PGP 2 which had two additional restrictions, one was that the long text file with the crypto political background must accompany all distributions of PGP. Clearly that was non-free but something which can easily be done with the GFDL.

Has it stopped? Anyone got an announcement? I missed it.

I am not sure whether there has been an announcement but the GNU Press project is at least dormant since Opus had to leave the FSF.

Only for limited purposes, which vary from country to country. In general, it's not legal to do so.

For example a book on networks might want to include the OOB-Data text from glibc. With 48 lines (w/o the example) it is clearly beyond fair use.

So GPL for reference manuals would be fine by you?

According to RMS, reference manuals are useless ;-)

Shalom-Salam,

Werner

On Wed, 01 Feb 2006 16:33:17 +0100, Alfred M\ Szmidt said:

Because PGP was software, not documentation. Such a clause would be prefectly ok for free documentation.

Again: Documentation is part of the software. All my clients rightfully expect documentaion along with the code. Of course it is up to the author to decide how much documentation is required but nevertheless software without documentaion is usually of minor quality.

Think of literate programming; there the code is actually part of the documentation and not vice-versa.

For example a book on networks might want to include the OOB-Data text from glibc. With 48 lines (w/o the example) it is clearly beyond fair use.

You can ask the FSF to make a execption for examples. This makes sense, and I doubt anyone would object.

I tried to tell that there are 48 lines of actual description (a work) plus some more lines with examples.

Shalom-Salam,

Werner

"Alfred M. Szmidt" ams@gnu.org

Werner Koch wk@gnupg.org

...

For example a book on networks might want to include the OOB-Data text from glibc. With 48 lines (w/o the example) it is clearly beyond fair use.

You can ask the FSF to make a execption for examples. This makes sense, and I doubt anyone would object.

and once more the hackers are reduced to serfs, begging the copyright barons for permission to make sensible use of tools they already hold. I wonder if we would have the FDL problem if bright young hacker modifying a printer driver on a PDP-11 had also wanted to reuse a description from its manual for another project? (See http://www.faifzilla.org/ch01.html )

(Actually, www.faifzilla.org is an interesting case, under the FDL but seemingly dead for over a year now, still not meeting WCAG1A and still not applying the FDL as advised.)

Putting documentation and software into the same box doesn't make sense, the GFDL makes perfect sense on the other hand in my mind.

Nowadays, lots of software ships with program and docs on the same media and this is not often called a new or nonsensical development.

You can still apply dual licensing for each part.

[...] In fact the GFDL hinders development of free documentation.

Do you have anything to back this up? GFDLed documentation is free to be shared, used, modified, and viewed [...]

Apart from the bit which is slightly off the current topic, but could be relevant for future topics! If I staple a program to a dead squirrel and the copyright licence says every copy must be linked to a dead squirrel, is it free software?

No, since you cannot modify it to your hearts content because it is a functional work. But I was speaking about documentation, not software, different rights apply. If we do s/software/documentation/ then it would be free documentation.

...

The GFDL has been written with publishers in mind; look at the terms: most make sense only for woodware. And later the own publishing branch ceases work?

Do you know why it stopped? I don't. [...]

Has it stopped? Anyone got an announcement? I missed it.

I was taking Werner's word for it. I haven't heard an announcment either.

It was claimed that there would be a great explosion of manuals for free software under the FDL because of its adware nature.

Making claims about the future is always silly, and should be taken with a grain of salt.

...

I can't grab a single short text from the very good glibc manual and use it with other projects - unless I add a bunch of useless attachments.

Yes you can, that is protected under fair use.

Only for limited purposes, which vary from country to country. In general, it's not legal to do so.

In general it is, see article 10 of the Berne convention. But it does leave qwuite alot up to each indiviual country to state what fair use is in detail. In either case, fair use applies to most/all European countries and the USA.

...

The GPL might be inconvenient for a publisher but it works far better for documentation.

I disagree. There are many problems with applying the GPL to documentation. The GPL was designed for software in mind, other uses tend to cripple the actual goal (the distinction between `binary' and `source' comes to mind).

The binary/source thing seems better than the opaque/transparent problem of the FDL.

I type the manual on a typewriter, what is the source code for that?

What problems with GPL for manuals? The only one that sticks for some uses is public performance.

A manual licensed under the GPL is free to be modified in any way or form, not just technical content, but also non-technical content. You don't need the right to modify my dedication to the fairies and dragons. You do need the right to modify the technical content though.

[...] a _reference_ manual should be part of the code, this is something I could agree to. [...]

So GPL for reference manuals would be fine by you?

I didn't say that, I said that the reference manual and the code should be in the same code base. Nothing about licensing terms. You can mix GFDL and GPL in the same code base (and if you do not collect copyright assignments, then you can only blame yourself). Nothing prohibits this.

Cheers.

Here's the rub: I'm not that bothered about what you call "free documentation" but I'm convinced that free software needs free software manuals, ones that are under the same terms and can be maintained alongside the software. It's awkward enough following the mix of licences already out there without having manual licences that are incompatible with the licences of the programs that they document, making problems for basing one on the other.

I see no problems mixing free documentaion with free software in the same program. I don't understand how you can see such issues.

...

It was claimed that there would be a great explosion of manuals for free software under the FDL because of its adware nature.

Making claims about the future is always silly, and should be taken with a grain of salt.

I agree, but it was done to reduce dissent against the FDL, painting a new future with better manuals for free software. Instead, this advertware licence seemed to irritate some GNU developers who were amongst the best at documenting their software, by sending a message "the terms used for your programs under are too free for your manuals: we want to attach permanent adverts to them."

Many things irritate GNU developers, this is probobly one of the least that annoys anyone. The whole thing resolves around a group of people wanting to claim that `everything is software', and another group that claims `not everything is software'. Different rights apply to different things.

I would apperciate it if all this claims that things where done to reduce some kind of dissent against the GFDL, or the really silly claims Werner did, they don't serve any purpose other than mud tossing, and ignore the important points of the discussion.

If you type a program on a typewriter, what is the source code?

How do you execute the program? That is the fundamental difference between manuals and software, manuals aren't executed (lets ignore Postscript and the like), programs are.

You don't need the right to force everyone to use extra media reprint the ode to your goldfish forever. It's unethical to waste paper, CDs and so on like that. Removable invariants would give a way to create free software from FDL'd works.

I think the GPL not allowing such invariants to start with is a feature, not a bug.

The GPL applies to software, having invariant sections in software would make software non-free. Invariant sections in documentation makes perfect sense.

If you feel that having a small blurb is so wasteful, what will you do with copyright notices? They must be on top of each file, and you must include the license in the distribution. And if you don't collect assignment papers, the list of copyright holders can grow indefintely.

Atleast with a GFDL manual, you can actually remove the invariant sections, if you are the copyright holder. You can't ever remove the copyright notices unless you get agreement from the person(s) who hold the copyright.

I didn't say that, I said that the reference manual and the code should be in the same code base. Nothing about licensing terms. You can mix GFDL and GPL in the same code base (and if you do not collect copyright assignments, then you can only blame yourself). Nothing prohibits this.

It's not prohibited, but while FDL isn't a free software licence, that would mean the code base isn't free software. Another example how FDL harms the ideal of a free software operating system, GNU.

How does it harm anything that is free software? It is a free _documentation_ license, it has no relation to software. And what is it with all these claims that the GFDL hurts the GNU system, and that it was the reason for the supposed demise of GNUpress? Can't we just stick to facts instead? Please?

I agree that there are problems with the GFDL, but they don't come in the form of invariant sections. They come in the form of people having to much room to do things, which will lead to mistakes (some people have put entire documents under a invariant section, even if this isn't allowed by the GFDL). The GFDL is simply to complex, I still don't grok large parts of it, and I have read it, and reread it several times.

For something that is licensed under the GPL it is quite easy to define what the licenses goal is in a sentence, but for the GFDL this is impossible, since it depends on who applied what clause when.

Cheers.

reduce some kind of dissent against the GFDL, or the really silly claims Werner did, they don't serve any purpose other than mud tossing, and ignore the important points of the discussion.

There are a lot of long term hackers and GNU people who disagree with you on this. It is not just me and that are not only my claims.

I'm all for having a level headed discussion about the GFDL, but you did make claims without proof like GNUpress being `shutdown', and the GFDL somehow reducing the set of free manuals. That is what I refered to as mud tossing and silly arguments. The GFDL isn't without problems, it has many of them, far more than the GPL, and those problems should be poitned out and solved.

For example, it might make sense to allow removal of invariant sections after say 5 years after the copyright date or some such. Personally, I don't know if that would be a good thing or not and would have to think about it abit more to be able to decide if I like the idea.

I think the major problem with this whole GFDL thing is that neither party wants to budge. One party considers it essentialy to have invariant sections, and the other one doesn't. So getting to a compromise is simply impossible.

Anyway, I see that further discussion won't change anything so I'll better spend my time to serve the community.

Well, who knows? Maybe you can convince me that the GFDL is indeed as bad as you claim it is. :-)

GFDL somehow reducing the set of free manuals. That is what I

Yes, because in practise it does not allow to share.

How? To be able tos hare manuals is important, and the GFDL does allow for that.

In theory you can share manuals but this is limited by invariant sections and the requirement to put all authors onto the title page.

Including a few lines of the Emacs manual into Jed's manual (assuming that is GFDLed) would require to also include the GNU Manifesto and other stuff. Some people might want to state their opinon on some of Richard's thoughts too and voila another invariant sections needs to be carried on.

Sure, you can do that but the extra texts are irrelevant, dead weight and might not convey the intention of the author.

Werner, I'm really not following you. Either you can share something, or you cannot. Obviously, you can share GFDl:ed manuals, I hope we can agree on that. What you are speaking about is combining different works, this isn't the same thing as sharing. Even the GPL has some dead weight.

A few lines of material cannot be considered a legally significant change. So you are free to include those few lines and ignoring the license (basically). If you wish to incoperate a whole page, or chapter, it would be better to simply refer to it and not include it if you do not wish to have the invariant sections. The same thing applies to GPLed works which you wish to include in non-free programs, where you have to jump around abunch of hoops to be able to do that.

Cheers.

Nonsense. It is the heart of FS software development.

But the GFDL is for documentation, not software.

I am only talking about FS and in particular works with GPL compatible licenses. Refering to otehr parts of the code or manual is not an option.

And I'm speaking about Free Documentation.

Nobody is saying that the GFDL is a free software license.

Since we are speaking about two different things, we obviously cannot agree on anything. :-)

Hi,

Eneko Lacunza hispalinux.listas@enlar.net wrote:

Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"?

I think this is the crucial point. As long one group think that everything is software and everything should fulfil the free software definition and another group make some distinctions between free software and free documentation, it makes no sense to discuss the GFDL because there is no common base.

So the first step should be to agree that we talk about free documentation and that their could be some differences. Only than it's possible to talk about the GFDL and about possible differences between free software and free documentation.

Personally i understand both sides. On one side manuals are basically as functional as software, so everyone should have the same freedom for manuals as for software. On the other side we have the GFDL which was afaik mainly written with real books in mind. I can understand when the FSF wants to release their books with a special foreword or a special front- and back cover and i agree that it's not fundamentally necessary that people can change the foreword or the cover of a book.

I think it could be really hard to bring both sides together.

Maybe it should be possible to use only the functional information without the invariant sections if someone doesn't use the manual as a whole but only some chapters for his new manual. I think this could be a good compromise. For the functional part people would have the same freedom as for software without carrying all the invariant sections along and for the book as a whole the author would have the possibility of some personal notes or a personal front- back cover. But i don't know if it is possible to define in a license the difference between the work as a whole (which should of course include bug-fixes, updates, extensions etc.) and only parts of a work which are used for a new work.

Cheers, Bjoern

On Wed, 2006-02-08 at 20:20 +0100, Eneko Lacunza wrote:

...

And I'm speaking about Free Documentation. Nobody is saying that the GFDL is a free software license. Since we are speaking about two different things, we obviously cannot agree on anything. :-)

Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"?

I think the GFDL was designed with some pretty narrow use cases in mind - there is definitely a lot of documentation it's not suitable for. But, that's not to say we should treat documentation the same as we treat software all the time (though often we probably could/should).

If you look how documentation is treated as software, it only really makes some sense in the digital world - e.g., GPL'ing docs. I would struggle to define a paperback book as any of source code, object code or executable - and in that sense, printing a GPL'd book is problematic.

It also doesn't address specific non-electronic-format rights you might like - for example, the GFDL makes explicit the ability to lend. The GPL doesn't give you that right. If you can't lend a GPL'd paperback, is it still "free"? If you didn't create it electronically, is it "free"? (probably not; it forces others to re-type the whole thing into electronic format in order to fulfil the source availability clauses).

Also, even in the electronic world, documents and software are treated differently, as a matter of law if nothing else. So, for example, in this country I have in inalienable right to be identified as the author of any given document I may have created - with software, that's not the case. On at least a practical level, we need to take those differences into account.

There is people that thinks software is the conjuction of programs and their documentation (and other thing, like images, etc.). For example, Debian project seems to think this way.

Well, Debian have a specific problem domain: e.g., they're putting stuff onto CD, and want to be able to distribute it. And that's fair enough, and there's a lot of mileage in treating electronic documents the same as software. Having consistent licensing terms across everything they distribute makes pretty obvious sense.

Cheers,

Alex.

"Alfred M. Szmidt" ams@gnu.org

[quote unattributed in body]

...

Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"?

It isn't that different, the four freedoms still apply. The difference is that the content isn't a functional work, [...]

Have you read the FDL? The preamble starts: "The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially."

Note that it claims the FDL purpose is for functional work.

Of course, the desire for those freedoms extends beyond whatever the judgement of the day about what is "functional" or what is "effective freedom".

Because such restrictions make sense, you don't need the right to modify my thoughts about why I wrote the book, or to whom I dedicated the book. [...]

Someone modifying your essay should not modify your thoughts! Please consult a mental health expert if you find it does! I think it's as reasonable to base my essay on the work of a more talented author as it is to base my programs on the work of a more talented hacker. Why not?

I'm less sure about dedications, but I can think of times when it would be good to rededicate a book.

Debian consideres _everything_ software, which is simply bogus.

No, many DDs consider that debian only distributes software in the main archive, which is computer storage after all, and debian considers everything there against the DFSG. This is not the same as claiming to consider everything software, which would be bogus (for example, my desk).

Hope that helps,

"Alfred M. Szmidt" ams@gnu.org

Sorry for being unclear, I meant that a manual isn't in its whole a functional work, and can contain non-functional parts, like an dedication.

...

Note that it claims the FDL purpose is for functional work.

... with non-functional parts.

Were that true, then the FDL preamble would be an argument that the FDL is not suitable for applying to invariant sections.

...

Because such restrictions make sense, you don't need the right to modify my thoughts about why I wrote the book, or to whom I dedicated the book. [...]

Someone modifying your essay should not modify your thoughts! Please consult a mental health expert if you find it does!

Please consult a English teacher.

You first. It does make a difference whether we are seeking to modify your essay or your thoughts. (I'm a native English-speaker, with some problems, but illiteracy is not one of them TTBOMK.)

[... more flame bait ...]

Are you really incapable of having a leavel headed discussion without resorting to these kind of silly arguments?

I think a level-headed discussion is impossible if you are going to contradict the licence you claim to support. Please stick to the FDL.

Alfred M. Szmidt wrote:

There is no doubt that free software needs free documentation, even FSF says this. If so, why does FSF allow restrictions to modifications of documentation (using FDL) that does not allow for software?

Because such restrictions make sense, you don't need the right to modify my thoughts about why I wrote the book, or to whom I dedicated the book.

As this seems to be a center of your argument, can you back this up (to use your favourite expression)?

Why should a dedication of a manual deserve different restrictions than one of a computer program?

You might say because a computer program is functional. But so is the main part of a manual (as has been pointed out to you). So the question can be reformulated as: Why must a computer program be 100% functional, and a manual doesn't have to be?

Technical differences don't really apply in most cases. An invariant part could be included in most kinds of programs without hindering their normal performance, such as being shown by a particular option or menu item, or even on a startup screen (that a user who doesn't want to read it can click through, just like a manual reader(*) can skip over the pages with the invariant sections).

(*) To avoid any misunderstanding: By "manual reader" I mean a reader of a manual, rather than someone who reads with his hands. This might be clear from context, but you never know ...

Secondly, the question whether someone should be allowed to modify your expression (or your "thoughts", as you prefer to call it), is beside the point. Even a GPL work can be accompanied by an unmodifiable text (GPL, paragraph 2, last sentence). There are two main differences compared to an FDL work with invariant sections:

1. The former case would be two different licenses (GPL plus something else), the latter case would be "all FDL". But that's really just naming, as the FDL already gives two rather different sets of rights for the main part and secondary sections.

2. In the FDL case, the invariant sections are tied to the main part. You can't reuse parts of the latter without including the former. In the GPL+x case, you can. That's IMHO the main difference, so I'd like to know why you think having to include them is a good thing.

Frank

Alfred M. Szmidt wrote:

Why should a dedication of a manual deserve different restrictions than one of a computer program?

Because a dedication isn't a computer program? A computer program thrives on being modified. A dedication doesn't.

And a dedication is not a manual. A manual thrives on being modified. I don't see anything in your statement to justify why a dedication of a manual should deserve different restrictions than one of a computer program.

Can you explain why you need the right to modify my poem about dragons?

I don't. I said so. The way I suggested (e.g., GPL for the main work, and CC by-nd for the dedication) wouldn't give that right either. Why do you keep arguing uncontroversial points?

And why I shouldn't be allowed to attach it to a manual?

Who said you shouldn't be allowed to? I didn't. But why should someone who reuses parts of the manual not be allowed to detach your poem again?

Technical differences don't really apply in most cases. An invariant part could be included in most kinds of programs without hindering their normal performance, such as being shown by a particular option or menu item, or even on a startup screen (that a user who doesn't want to read it can click through, just like a manual reader(*) can skip over the pages with the invariant sections).

Alas, a menu item or a startup screen changes the _behaviour_ of the program, and you should always be allowed to change the behaviour of the program.

Are you aware that clause 2c) of the GPL also restricts changing the behaviour of the program? Sure, in a very specific way, I'm aware of that, and we don't need to argue about it. But according to your statement that "you should *always* be allowed to change the behaviour of the program" (my emphasis), the GPL doesn't satisfy your requirements either. If you didn't mean your statement in such an absolute way, please state it the way you mean it.

Secondly, the question whether someone should be allowed to modify your expression (or your "thoughts", as you prefer to call it), is beside the point. Even a GPL work can be accompanied by an unmodifiable text (GPL, paragraph 2, last sentence).

I think you are misreading that paragraph. It is about aggregation, and not putting specific bits into a GPLed work. I.e. you can put GPLed software and non-free software on the same CD, but you cannot combine those two into one work.

So it's a different work then, what's the problem? If you have a GPL program with FDL software in one package, these are also two works (in the legal meaning of the term, as described, e.g., in GPL paragraph 0).

2. In the FDL case, the invariant sections are tied to the main part.

They aren't tied to the main part, infact, they cannot be tied to the main part in anyway or form.

Are you arguing about the meaning of the word "tie", or what are you trying to say? Fact is that in many circumstances, you cannot reuse parts of the main part of a FDL work without copying the invariant sections. (You don't deny this fact, do you? It's the heart of the FDL.) I called this "to tie". I could back this up with some dictonary quotes, but I really don't care. If you don't like this word, you can suggest another term. It doesn't change anything about my original argument.

  You can't reuse parts of the latter without including the
  former. In the GPL+x case, you can. That's IMHO the main
  difference, so I'd like to know why you think having to include
  them is a good thing.

Having an "invariant section" in a program, makes it impossible to modify it so that it does something you want (say that it has a GUI, and you wish to remove this GUI and make it into a library, if the GUI splash screen was an `invariant section', then you would never be allowed to do this). I think we can agree on this.

You mention a case of turning a program into a different form. A valid scenario, indeed.

Having an invariant section in a manual, doesn't cause the same dilema. You can still modify the technical content of the manual so that it is synced with the program. And still be able to make an manual that you can use.

So let's also here consider a case of turning a (FDL) manual into a different form, to have a fair comparison. Examples such as reference cards or posters have been given. If, e.g., the invariant sections are longer than the physical space on a reference part permits, then you would never be allowed to do this according to the FDL. (And while I'm not a lawyer, I'm quite sure that citation or fair use rights don't cover this case, if the copied material makes up the major part of the new work.)

Frank

Alessandro Rubini wrote:

Frank:

...

You mention a case of turning a program into a different form. A valid scenario, indeed.

...

[...]

...

So let's also here consider a case of turning a (FDL) manual into a different form, to have a fair comparison. Examples such as reference cards or posters [...]

Good point. Actually, It seems to me the FDL has been designed for linear evolution of a manual, and not for using the material of the manual in other contexts. While the pool of GPL works allow a "mix and pick" approach, this is actually denied by the FDL. People can see this as a problem or not, I personally do.

Well stated. I thought something like this, but I haven't seen it put so clearly before. Thanks.

FWIW, I generally also see it as a problem. There may be cases where it might not be an actual problem, but since the license decision is final (at least if you can't/don't want to relicense later), I'd have to be sure in advance that the problem could never occur for any given work before putting it under the FDL, and I see few possibilities to be sure of this in advance.

"Mix and pick" is a common approach in many fields (where permitted), including free software (GNU and other), documentation (e.g., new FAQs/HOWTOs including parts of older, perhaps otherwise obsolete, documents), even in arts such as music (sampling) and probably many areas I'm not aware of.

As a personal summary of this discussion (as there seem to be no new relevant points anymore), I must say I haven't actually learned much new about the FDL, partly because I was already familiar with many issues before, and partly because many "arguments" presented were simply unfounded claims or opinions.

Initially, when the FDL appeared, I was kind of sympathetic to it and even used it for awhile. I saw the complexities and had some doubts about possible consequences, but I thought since it was created by the FSF it would be ok somehow. (And BTW, back to the original subject, now that I'm no more so sure of it, I'll also watch the GPLv3 process more critically. For most of my code, I've used GPLv2 only so far, not "any later version", and now I'm not sure if/when I'll switch to v3. If there will be a discussion about the contents of the GPLv3 draft here, I'll probably raise some points, but after the confusing messages I've seen so far, I'm not even sure where/how/if the contents should be discussed to make any impact.)

Later I learned about the problems with the FDL that had been discussed at Debian and elsewhere, and I found no satisfying answers to them -- either explaining why the problematic situations, as described in many places both abstractly and in concrete examples, were not actually problematic, or explaining what greater benefit would be gained in exchange for allowing those problems -- even though I tried to find such answers. At this point I switched back to the GPL myself, and my general impression was, FDL without invariant sections and cover texts is harmless though too complex, with any of them it's quite problematic.

Now you (Alessandro) described how even FDL without invariant sections and cover texts can be harmful (because you can't prevent others from adding some). That was basically the only new argument to me in this whole discussion (thanks again), and it's made me even more skeptical of the FDL.

Of course, your scenario does not only apply to your publishing of a book. It might be interesting to apply it to GNU documentation:

- Someone takes an important FDL manual of the GNU project (Emacs or whatever).

- He adds some substantial and useful content to it (tutorials, detailed usage hints for certain purposes, whatever -- there are probably many relevant topics one could write about).

- He adds invariant sections that strongly disagree with many central items of the GNU philosophy (such as advocating "open source", disparaging copyleft, misrepresenting the history of free software and the important of the GNU project, or to be really evil perhaps advocating software patents and DRM -- you know, all the stuff we don't like to see, yet see all too often).

- And finally distributes the whole thing (for free or for a charge, as he likes).

Now the FSF can, of course, by the FDL, include the new content into their distribution, but not without also adding the new invariant sections. What would they do?

- Actually include the invariant sections? Doubtful, as it might do them some serious PR harm (even more so if they tried to explain they were forced to do so by their own license).

- Politely ask the author for different terms? They can, of course, try that (though I've always thought the point of free licenses was to avoid having to beg the authors for permission for legitimate uses), but the author can just say no, what then?

- Rewrite the new content? This would require a complete clean-room implementation under especially difficult conditions (if the original source is readily available, the danger of accidental copying is bigger, and such accusations will be harder to refute), and waste a lot of duplicated effort. (Which shouldn't be the goal of free development IMHO.)

- Ignore the new content and do without it? (Which also shouldn't be the goal of free development.) This seems to me the most likely outcome. What's the result?

* The new ("evil") author has a superior (by content) manual than the FSF distributes.

* He can include new material added to the FSF distribution whenever he likes, to ensure his version remains superior without much further effort on his part. (Unless/until some FSF contributor adds invariant sections that appall him, which then would have to stay forever in the official FSF manual, though.)

* He can rightfully claim his enhanced manual is released under an FSF-approved free documentation license.

* He can (and indeed must) write "A GNU Manual" on the front of his version, if that was the front-cover text of the original manual.

Note: Obviously, this is only meant as a thought experiment. There's no point in actually doing this to make a point, and the large effort involved can much better be spent on other purposes. But I wonder if it really takes someone to do it (which will then probably be someone with really evil intentions) until the problems are addressed, rather than denied.

Frank

Now you (Alessandro) described how even FDL without invariant sections and cover texts can be harmful (because you can't prevent others from adding some).

None of what Alessandro described is harmful, it is explcitly allowed by the license. You are claiming that there are problems when there are none, it is like having people claiming that the GPL has problems by disallowing a GPLed project being converted into a non-free program.

Now the FSF can, of course, by the FDL, include the new content into their distribution, but not without also adding the new invariant sections. What would they do?

Same thing they would do if they wanted to include GPLed code into Emacs: require a copyright transfer. This is required for GNU projects, and should be required for _any_ and _all_ projects. That people think that there has to be some kind of a `free for all' is absurd.

If you wish to have a way to enforce the copyright, then you will need to have copyright papers. Otherwise, you cannot enforce it at all, it really doesn't matter what license you are using. A judge would love to hear "Sorry your Honour, but I couldn't gather the copyright holders to actually sue the accused'.

This is a misconception you, and others have shown repatedly when it comes to copyleft, that unless you have a single copyright holder (or a very small number), it is impractible to enforce the license. And if you cannot enforce the license, the license looses its charm.

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

That's why it's harmful. If it wasn't allowed by the license, it could simply be prohibited by enforcing the license. If you don't think the outcome (as I described in an extreme form) is harmful, then we just have to disagree. I think it's harmful, so I don't like the FDL.

That you consider it harmful is one thing, it doesn't make the clauses harmful in it self.

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

Back up this claim.

What part of `in theory' didn't you get?

Cheers.

Alfred M. Szmidt wrote:

That's why it's harmful. If it wasn't allowed by the license, it could simply be prohibited by enforcing the license. If you don't think the outcome (as I described in an extreme form) is harmful, then we just have to disagree. I think it's harmful, so I don't like the FDL.

That you consider it harmful is one thing, it doesn't make the clauses harmful in it self.

Alessandro and I described scenarios with outcomes that follow from what the FDL clauses allow (1) and those outcomes we consider harmful (2).

(1) was derived by logical conclusion. Your only refutation to them that I can see, that the FSF could *require* copyright assignments (rather than ask for them), has been disproven.

The FSF _requires_ copyright assignments for works to be incoperated into a GNU project (not all, but most). If it cannot get a copyright assignment for a change, the change isn't incoperated.

[...] So far, you haven't tried to explain your opinion (i.e., why you don't consider these scenarios problematic, or else which benefits the FDL gives that would justify the problems), [...]

Once again you resort to outright lying. I have repeatedly shown why invariant sections make sense: You do not need the right to modify what I think about fluffy puppies. http://www.gnu.org/philosophy/free-doc.html also explain is well.

You have repeatedly shown why _in_your_opinion_ invariant sections make sense, without touching on the problems (fwiw, I think they make sense, but the problems outweight the benetis).

I don't see them as problems, I have repeatedly explained why they are not problems and have repatedly stated that I do not see these issues as problems. It is exactly the same scenario of combining a GPLed work with a work which is licensed under an license which is incompatible with the GPL. Both of which are free software.

As Simo Sorce suggested, let's agree to disagree and stop this useless thread. BTW, you agreed to disagree about semantics quite some time ago[4], so why are we still wasting everyone's time?

Maybe Because Frank is to busy spreading lies.

The fact that _you_ have an opinion does not mean all other are wrong or lying or absurd, etc.

I never claimed that. Frank has repeatedly stated that I have not explained this or that when I cleary have. This is where I'm calling Frank a liar. That he has a different opinion is not even related to this.

By flooding the list of mails [...]

I reply on ocassion to mail in a batch like fashion, that you dislike this practise is really not my problem, sorry.

Summarizing the positions seen so far are these:

Software: A) anything representable on a digital medium B) only programs, data is not software C) some mid position

GNU FDL: 1) it is bad because it is not free software (with meaning A) 2) it is ok because it is a free documentation license (software as B) 3) it has some problems but it is ok 4) problems outweight benefits

Generally the problems are caused by the fact that GFDL include invariant sections or that the text of the license is too difficult to read and/or apply.

That's all I think and I have not seen any opinion changing by an inch in the last days. So please let's all just stop here unless there is something really new to add to the discussion.

Beating ones head against another hard head is quite a fun thing to do though, also a very good expeirence since it will open up differenet doors. For example, my belief that invariant sections are a good thing has been strengthed, and that the GFDL is to complex as a license has also been strengthened.

Cheers.

Alfred M. Szmidt wrote:

Alessandro and I described scenarios with outcomes that follow from what the FDL clauses allow (1) and those outcomes we consider harmful (2).

(1) was derived by logical conclusion. Your only refutation to them that I can see, that the FSF could *require* copyright assignments (rather than ask for them), has been disproven.

The FSF _requires_ copyright assignments for works to be incoperated into a GNU project (not all, but most). If it cannot get a copyright assignment for a change, the change isn't incoperated.

Never mind that Alessandro's and my examples specifically involved the change *not* being incorporated into the original project. Just keep repeating your phrases without looking at the context.

[...]

Let's say I write a shoot-em-up game, where you're shooting aliens (similar to, say, Doom). I release that under GPL.

Now, someone else comes along and changes the game (which they're perfectly entitled to do under GPL, obviously). Instead of shooting at aliens, you're now shooting Shia Muslims, as an example.

They had to add new material to do this, i.e. change the pictures of the monsters into Shia Muslims. So it isn't as simple as `modification'.

OK, so changing is not modification, I see. Please go on ...

Frank

On Sun, 2006-02-12 at 13:47 +0100, Alfred M. Szmidt wrote:

None of what Alessandro described is harmful, it is explcitly allowed by the license. You are claiming that there are problems when there are none, it is like having people claiming that the GPL has problems by disallowing a GPLed project being converted into a non-free program.

I must say the analogy is completely wrong, and, I'm sorry, almost specious here.

If you wish to have a way to enforce the copyright, then you will need to have copyright papers. Otherwise, you cannot enforce it at all, it really doesn't matter what license you are using. A judge would love to hear "Sorry your Honour, but I couldn't gather the copyright holders to actually sue the accused'.

I do not think a judge would love that, probably an evil lawyer from the other side, but not the judge. I think the judge would actually like to judge facts not handle formalities.

This is a misconception you, and others have shown repatedly when it comes to copyleft, that unless you have a single copyright holder (or a very small number), it is impractible to enforce the license. And if you cannot enforce the license, the license looses its charm.

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

In practice I think this shows up to be false, otherwise it would have already happened, don't you think SCO would have already done that otherwise for example ?

Simo.

On Mon, 2006-02-13 at 21:03 +0100, Alfred M. Szmidt wrote:

...

None of what Alessandro described is harmful, it is explcitly allowed by the license. You are claiming that there are problems when there are none, it is like having people claiming that the GPL has problems by disallowing a GPLed project being converted into a non-free program.

I must say the analogy is completely wrong, and, I'm sorry, almost specious here.

Care to explain why?

Because you can't make a GPLed program non free against the authors will. Instead with the GFDL you can add a very nasty invariant section against the original authors will, and against the sprit of the work and he will not be able to remove that section if he wish to reuse the material in a new edition made by himself. I think this is not the sort of "freedom" a copyleft license should allow, even for documentation which I think is different from Software. I rather see using only verbatim copy licenses or GPL licenses for new works until these GFDL bugs get fixed.

...

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

In practice I think this shows up to be false, otherwise it would have already happened, don't you think SCO would have already done that otherwise for example ?

It has happened, and it is continuing to happen. Usually it is easily solved though.

It is easy to solve just because you do not need to gather all the developers of Linux to sue someone on the use of Linux. You just need someone that have enough copyright on Linux in key parts of it, that it makes it impossible to use that kernel without the work of the person who is suing. But others have already explained this point very well, and more than theory real facts shows that.

Simo.

Alfred M. Szmidt wrote:

Because you can't make a GPLed program non free against the authors will.

Neither can you make a GFDLed document non-free against the authors will/wishes...

I think it is better to simply agree to disagree about the GFDL, just like one has to agree to disagree about BSD-like licenses vs. copyleft licenses.

Are we disagreeing about appropriateness of the licenses or the facts of the licenses and their provisions?

Or at least could someone state the resultant area of disagreement for my own edification so I can add it to my mental "watch out for" list.

Sam

Alfred M. Szmidt wrote:

Are we disagreeing about appropriateness of the licenses or the facts of the licenses and their provisions?

Or at least could someone state the resultant area of disagreement for my own edification so I can add it to my mental "watch out for" list.

If the invariant sections are `good' or `bad'.

Thanks.

Is it that you think FDL invariants are "bad" because itS effect stopped you doing something that you might want to do, which was to take back the odd new chapter that someone wrote who had released a "updated" version of your work?

Was there any dispute over whether or not it would have the effect you did not like, or just whether that effect was "good" or "bad"? Or perhaos the way you excercise the freedom is cumbersome?

I don't mean to drag up old arguments I just want to understand how it ended up.

thanks

Sam

On Mon, 2006-02-13 at 23:28 +0100, Alfred M. Szmidt wrote:

Are we disagreeing about appropriateness of the licenses or the facts of the licenses and their provisions?

Or at least could someone state the resultant area of disagreement for my own edification so I can add it to my mental "watch out for" list.

If the invariant sections are `good' or `bad'.

To me it is more that invariant sections cannot be removed is bad, not that invariant are bad per se.

I would prefer my opinion to be removed entirely than see them changed, so I welcome invariant sections to some degree but not the way they are made in the GFDL. I think that removable invariant sections would be a good thing.

Simo.

I agree. But as I've proposed and asked before, do we really need a revised FDL or other new license to achieve that goal? Wouldn't it suffice to put the primary content under the (L)GPL and the "invariant sections" under a simple unlimited-distribution, no-modification license?

The GPL/Lesser GPL are specificially designed for software. And for either of those to be suitable for documentation, they would need extensive changes. For example, large parts section 2 simply cannot apply to documents.

Such a change would also allow for documents which are completly invariant, something the GFDL specifically disallows.

On Mon, Feb 13, 2006 at 11:02:04PM +0100, Alfred M. Szmidt wrote:

Not really. People have quoted specific instances, inparticular Netfilter, where you had one person who wrote the bulk of the work.

Just a quickie - is this actually true, or a guess?

FWIW I've just emailed Harald a few questions, so hopefully we can actually put much of this argument to rest when we get real, actual facts about how copyright infringement cases have gone in practice, rather than going backwards and forwards with different theories.

Gareth

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

I suggest you read http://gpl-violations.org/ in order to see where the GPL has been discussed, and upheld, in court, following companies attempting to make the Linux kernel proprietary. Harald Welte, who started the site and wrote some of the Netfilter code, took (and continues to take) many companies to court over the use of his code, which is included in the kernel. The violations being sued for now are on a wider scale than just Netfilter, as I understand it.

This is different, netfilter had presumable only a single copyright holder (or a few), Harald Welte. This isn't the case with the whole of Linux. For each infginged part, you would have to figure out who the copyright holder is, and ask them to sue. Something that is infact a practical impossibility. Harald Welte can only ask for his copyrighted bits to either be removed, or have the infringing party to comply with the license, he (or the court I think) cannot dictate what should be done with the other parts, since no copyright holder has come up and sued.

None of the cases at http://gpl-violations.org are about companies infringing on the license of Linux, but seperate projects or stand alone bits in Linux, as far as I can see.

I spoke about Linux as a whole, not in small parts.

For example you could do something like: take Linux, someone sues, you remove the infringing bit, continue distributing a non-free version of Linux, and simply wait until someone "sues" again (have any of the cases listed on gpl-violations.org gone go court?), and only do the minimal to comply with the bits you are infringing on.

Anyway, this is all in theory...

Cheers.

Anyway, this is all in theory...

And practically speaking now, if a piece of software has multiple authors, each author can sue. You don't need the agreement of all authors for that. So there are thousands of developers who can actually sue when somebody infringes the copyrights of Linux.

No, they can sue for the _parts_ in Linux that they hold the copyright on. To enforce the copyright of the whole Linux kernel is impossible without an agreement from all parties that have copyrighted material in it.

Removing the bits which are copyrighted by somebody isn't really feasible if they have contributed a lot. You need to find out what a person has committed over the years and which work is based on that, etc. And it's not like you can remove the virtual memory code and run without it or rewrite in a few hours. There are a few developers like Linus who could sue and then you really don't have anything usable left.

You'd have a stronger poitn if say Ingo Molnar sued, Linus' contribution are quite small these days.

And they would also have to prove that they wrote the code, which is a bit easier these days, but in the good old days you didn't even have a detailed ChangeLog.

Cheers.

On Sun, Feb 12, 2006 at 07:29:46PM +0100, Alfred M. Szmidt wrote:

...

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

I suggest you read http://gpl-violations.org/ in order to see where the GPL has been discussed, and upheld, in court, following companies attempting to make the Linux kernel proprietary. Harald Welte, who started the site and wrote some of the Netfilter code, took (and continues to take) many companies to court over the use of his code, which is included in the kernel. The violations being sued for now are on a wider scale than just Netfilter, as I understand it.

This is different, netfilter had presumable only a single copyright holder (or a few), Harald Welte.

It has many contributors. While Harald is only suing for his specific parts of code, on a practical level, there's enough of his code in the core Netfilter to make it practically unusable if it were to be removed.

This isn't the case with the whole of Linux. For each infginged part, you would have to figure out who the copyright holder is, and ask them to sue. Something that is infact a practical impossibility.

If you're talking about getting *every* copyright holder to sue, then I agree. But you don't need everyone, only a few key people who have code dotted all over the place. Let's say, for example, Alan Cox sued. He has code (and by inference, copyright) throughout many parts of the kernel. To remove his code, and his code only, and still have a usable kernel, being realistic, I can't see it happening. It's the same for Harald, or Rusty, or many of the core contributors. All you need is for a small number of key people to sue to make it impractical to continue to infringe.

Also, while I don't remember off-hand which case it was (I believe it was the first one mentioned on gpl-violations.org), I remember Harald got an injunction against a distributor until the case came to trial. This stopped them distributing the *whole* product - it was unrealistic to remove Harald's code and still have a decent product.

My point is that you don't need to have many people suing (or simply threatening to sue) for companies infringing on the GPL to comply. Simply having a few key people is all you need. Harald's proved that one person is plenty.

Harald Welte can only ask for his copyrighted bits to either be removed, or have the infringing party to comply with the license, he (or the court I think) cannot dictate what should be done with the other parts, since no copyright holder has come up and sued.

I don't know the legal status of this, IANAL, but I'd be surprised if I turned up to court and said "this guy's infringing upon my copyright, and here's my proof. By the way, he's also infringing on these other people's copyright too, as it's all licensed to the same way. Please stop him" if a court didn't stipulate that they had to comply with the licence in its entirety. Anyway, as I said, I don't know the legal ins and outs, so unless someone has a genuine legal opinion to express, let's drop this particular part, if that's OK :)

None of the cases at http://gpl-violations.org are about companies infringing on the license of Linux, but seperate projects or stand alone bits in Linux, as far as I can see.

It's not quite that black and white. They *are* infringing upon the licence of Linux, but the cases in point are about specific parts of Linux to which Harald (and/or others) are copyright holders.

I spoke about Linux as a whole, not in small parts.

From a hypothetical point of view, you're absolutely correct. To sue someone for infringing upon the rights of Linux as a whole would be impossible. I simply don't believe it's necessary to consider Linux as a single whole. While Harald has been vocal with his site, I know that others in the Linux kernel community have also has similar discussions with distributors of their code.

For example you could do something like: take Linux, someone sues, you remove the infringing bit, continue distributing a non-free version of Linux, and simply wait until someone "sues" again (have any of the cases listed on gpl-violations.org gone go court?), and only do the minimal to comply with the bits you are infringing on.

From memory, at least one has gone to court, at least to a preliminary injunctive stage. I don't know the specifics of how things ended, except that the company in question relented, released the modifications under the GPL and made some payments to someone somewhere as redress. the details are, I'm sure, available on gpl-violations.org if you're interested.

Cheers,

Gareth

Alfred M. Szmidt wrote:

This is different, netfilter had presumable only a single copyright holder (or a few), Harald Welte. This isn't the case with the whole of Linux. For each infginged part, you would have to figure out who the copyright holder is, and ask them to sue.

Why each, and not any? Suing for any infringment should suffice, AFAICS. (Though, as I said, perhaps for lesser damages etc., so it's probably good to get as many and substantial contributors as possible, but I can't see why all would be required.)

If your position is true, then how about the following scenario (yes, I like to construct scenarios ;-):

- I take some important GPL GNU software project.

- I make some modifications to it (they don't even have to be substiantial or very useful).

- I release this modified work on my own (under the GPL which, of course, allows me to do that).

- If FSF asks me for a copyright assignment for my modifications, I politely refuse, as I don't care whether my modifications get included into the main project.

- E. Vil gets my distribution.

- E. Vil violates the GPL severly (making a propietary version, or whatever).

- FSF complains to E. Vil, who is unrelenting, so FSF wants to sue him.

- I don't want to sue, as I don't care much about the modifications I made anymore.

- E. Vil claims that as not all of the copyright holders of the work he obtained are suing, they cannot sue at all.

That's obviously an absurd defense. I suppose you agree.

I spoke about Linux as a whole, not in small parts.

Yes, you talked about "mak[ing] Linux [as a whole] a non-free program". But since this would violate the license of the whole, it would also violate the license of each of its parts (some double-licensed parts perhaps excluded).

For example you could do something like: take Linux, someone sues, you remove the infringing bit, continue distributing a non-free version of Linux, and simply wait until someone "sues" again (have any of the cases listed on gpl-violations.org gone go court?),

Yes, it's written there on the site (and was discussed here when it happened AFAIR).

and only do the minimal to comply with the bits you are infringing on.

So, if the one who sues is Linus Torvalds? You'd have to spend quite some effort to identify and remove hit "bits", and even more replacing them so you get something working again. And all that only in order to wait for Alan Cox to sue you next (in which will probably a rather simple court decision, given that it will be the same situation applied to the next "few" source lines), etc. And even in the meantime you probably can't do much with your non-free version if you don't want to become liable for damages (probably for intentional violation, at least from the second time). Seems like an even sillier tactic than SCO's, IMHO. IANAL.

Frank

On Mon, Feb 13, 2006 at 03:17:15AM +0100, Frank Heckenbach wrote:

• E. Vil claims that as not all of the copyright holders of the work he obtained are suing, they cannot sue at all.

This is a myth, and probably stems from US copyright.

At least .de copyright distinguishes between 'joint authorship' (Miturheberschaft) and 'modifiying authorship' (Bearbeiterurheberrecht).

Only in the case of joint authorship all copyright holders need to take action.

So if I write a piece of code, put it on the web, and somebody else picks it up, modifies it, again releases it, and that cycle continues, you always have 'modifying authorship'. The original copyright holder has the original copyright, and each and everybody who did moidfications and released modified versions has that 'Bearbeiterurheberrecht'.

Even one of the 'modifiers' alone could enforce his copyright.

On Sun, Feb 12, 2006 at 07:29:46PM +0100, Alfred M. Szmidt wrote:

...

In theory, anyone can go and make Linux a non-free program, since it is simply impossible to enforce the license there.

I suggest you read http://gpl-violations.org/ in order to see where the GPL has been discussed, and upheld, in court, following companies attempting to make the Linux kernel proprietary. Harald Welte, who started the site and wrote some of the Netfilter code, took (and continues to take) many companies to court over the use of his code, which is included in the kernel. The violations being sued for now are on a wider scale than just Netfilter, as I understand it.

This is different, netfilter had presumable only a single copyright holder (or a few), Harald Welte.

Oh no, they are certainly in the order of 50+ people who really hold copyrightable contributions. All the rest is probably too simple bugfixes to be copyrightabel works.

It doesn't really matter how many there are. The only important fact is that you can identify a given piece of code as copyrightable work by the person who wants to enforce.

This isn't the case with the whole of Linux. For each infginged part, you would have to figure out who the copyright holder is, and ask them to sue.

Yes, this is true if you think you need to enforce each and every piece separately. But in all practical cases, doing ot for one part is enough to make them learn.

Something that is infact a practical impossibility. Harald Welte can only ask for his copyrighted bits to either be removed, or have the infringing party to comply with the license, he (or the court I think) cannot dictate what should be done with the other parts, since no copyright holder has come up and sued.

That is true. But you are missing some points, see below.

None of the cases at http://gpl-violations.org are about companies infringing on the license of Linux, but seperate projects or stand alone bits in Linux, as far as I can see.

there are no 'stand alone bits' in Linux. Every software of reasonable complexity has sections. And as long as one copyright holder wants to enforce his copyright on his section, he's perfectly free to do so.

For example you could do something like: take Linux, someone sues, you remove the infringing bit, continue distributing a non-free version of Linux, and simply wait until someone "sues" again

EvilCorpTM could certainly do so, but:

1) there's still the question of 'past infringement'. Just changing the software by removing that 'section' and complying from now on is not sufficient to redeem the past infringements.

In gpl-violations.org out-of-court settlements, the settlement usually includes wording to state that the complete corresponding source code of all (L)GPL licensed parts of the product(s) has to be handed over to me.

Also, with real-world products, it's unlikely that you will be able to prevent any sale of even a single device that still contains the old software (including the enforced 'section') after the enforcement is 'active'.

This means that the copyright holder could go after each and every distirbutor, importer, wholesale, even retail store who still has the old software version and distributes it gpl-incompliant. This will create enormous economic pressure onto the vendor, since they can all regress onto him, and will probably refrain from selling any of his products in the future.

2) if other parts outside that 'section' are derivative works, then the GPL has to apply to them, too

3) from the first enforcement on the first section on, it is definitely known infringement on the rest of the program. This changes the liability and damages claims situation drastically for any following-up enforcements on other sections.

(have any of the cases listed on gpl-violations.org gone go court?),

three preliminary injunctions (maybe four? I don't even remember off my head), of which one had an appeal filed which was later turned down.

On 11-Feb-2006, Alfred M. Szmidt wrote:

[...] the English language allows for writting non-functional pieces. Can you explain why you need the right to modify my poem about dragons?

Because I find it useful as the basis of my own work. As with works licensed under the GPL, I would find it a reasonable requirement that I note the copyright holder of the existing work, and note that I made modifications.

And why I shouldn't be allowed to attach it to a manual?

I have been arguing that one *should* be allowed to combine such works together and redistribute, just as with programs.

On 11-Feb-2006, Alfred M. Szmidt wrote:

...

[...] the English language allows for writting non-functional pieces. Can you explain why you need the right to modify my poem about dragons?

Because I find it useful as the basis of my own work.

But you can base it on your own work. It is called a reference.

That's not using it as a *basis for* my work. If I like that poem, I may want to base my own poem on it, taking parts of it and combining it seamlessly with my own work.

You seem to be arguing that a license denying me that freedom (placing the poem in a part of the existing work that I can't modify and redistribute) is still nevertheless a free license. That's a disconnect I don't understand.

On 12-Feb-2006, Alfred M. Szmidt wrote:

If I like that poem [that is in part of your work under FDL do-not-modify-or-remove restriction], I may want to base my own poem on it, taking parts of it and combining it seamlessly with my own work.

Maybe we are from two different worlds, this is what is usually a basis for scientific articles. Where you never copy the actual material at hand unless you quote it properly, and only reference it.

Now that we know what's I'm asking, can you answer the question: why do you believe that a license restricting me from taking part of your work that I find useful, and exercising the freedom to modify, combine with my own work, and redistribute, is somehow a free license?

Hi Alfred,

El vie, 10-02-2006 a las 12:23 +0100, Alfred M. Szmidt escribió:

Este mensaje ha sido analizado y protegido contra virus y spam Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"? It isn't that different, the four freedoms still apply. The difference is that the content isn't a functional work, and one may wish to attach a dedication to the text, or maybe something else that isn't related at all to the actual text.

But there are problems with this. If every contributer/derivator adds a dedication, then we can end with lots of dedications for a relatively small piece of work.

And besides that, FDL doesn't limit the purpose of an invariant section, so in fact is allowing to restrict the freedom to modify the work.

Why does FSF have two distinct opinions about the adequate level of freedom for manuals and for software? Because they are different. It is that simple. http://www.gnu.org/philosophy/free-doc.html

But the 4 freedoms do not change, it does not matter wheter it is software or not.

There is no doubt that free software needs free documentation, even FSF says this. If so, why does FSF allow restrictions to modifications of documentation (using FDL) that does not allow for software? Because such restrictions make sense, you don't need the right to modify my thoughts about why I wrote the book, or to whom I dedicated the book.

That's right. But then, your thought are not free, and if you insist to attach those thoughts to your work, then your work neither is free.

You cannot pretend to do a free document, and then pretend that it has a part that can't be striped and modified. Because then it is not free.

There is people that thinks software is the conjuction of programs and their documentation (and other thing, like images, etc.). For example, Debian project seems to think this way. Debian consideres _everything_ software, which is simply bogus. Some images might make sense to have as verbatim only, same applies for many texts about philosophy, or even music recordings. This does not apply to functional works, like software, where modification is an essential right. You don't need the right to modify my poem about dragons, or infact, this text.

I agree that Debian's position is quite arguable, but they're doing it.

I also agree that it makes sense that some philosophy text, music recordings or images can't be changed. But IF they can't be changed, they are NOT free. Let's not pretend that everything must be free and next change the meaning of freedom.

I can agree that a program is free, if it uses/contains a non-modifiable (thus, non-free) image, as long as it can be striped out of that (free!) program.

Why limit modification of documentation of a free program, if we do not want that limit for the program itself and if the documentation is necessary? You aren't limited anywhere when you modify free documentation of a free program. This is like saying that you are limited by the GPL to create non-free works, which is simply nonsense.

Sorry, but if the documentation of a free program has FDL, then it can contain invariant sections, so that I am limited :)

Kind regards, Eneko

Hi Rui Miguel,

First of all, my apologies for having replyied this message before reading (almost) al the thread about this issue the past days.

El mié, 22-02-2006 a las 20:55 +0000, Rui Miguel Silva Seabra escribió:

Este mensaje ha sido analizado y protegido contra virus y spam On Wed, 2006-02-22 at 21:11 +0100, Eneko Lacunza wrote:

...

And besides that, FDL doesn't limit the purpose of an invariant section, so in fact is allowing to restrict the freedom to modify the work.

I guess you didn't bother to check yourself and chose to believe some.

[...]

It's much easier to dispel specific doubts and misbeliefs like the one you stated instead of Debian's bogus "GFDL is not Free".

You're right, and I apologise for my fault. But I don't think Debian's "GFDL is not Free" is bogus, as do many more.

You also don't comment my first paragraph about the problems with invariant/dedications.

...

...

Why does FSF have two distinct opinions about the adequate level of freedom for manuals and for software? Because they are different. It is that simple. http://www.gnu.org/philosophy/free-doc.html

But the 4 freedoms do not change, it does not matter wheter it is software or not.

Oh really? Let's see...

Theory: 4 software freedoms are the same for books

If Theory is true then you can "run" a book for "an purpose" (software freedom 0) since it is a software freedom.

But since you can't "run" books, then you can't exercise one of the four freedoms.

Hence, the 4 software freedoms are not the same for books. Q.E.D.

I do not understand "Q.E.D.". For the other part, if you understand "run" as "read", which I think is quite appropiate, it works.

...

...

Because such restrictions make sense, you don't need the right to modify my thoughts about why I wrote the book, or to whom I dedicated the book.

That's right. But then, your thought are not free, and if you insist to attach those thoughts to your work, then your work neither is free.

But my thoughts and opinions are mine, and not yours. I made them and those specific words where what I wrote and shared with you. If you alter that you are effectively rewriting what _I_ said. That's close to 1984's new speak.

Your thoughts and opinions and yours, and if I change the document that has them writen down, the text contained in the document no longer are your thoughts and opinions. So what?

I can equally create a document from scratch that contains texts with thoughts and opinions that are not yours :)

I respect you to not want the text you've written be modified, no matter the contents, but then it is NOT FREE.

...

I also agree that it makes sense that some philosophy text, music recordings or images can't be changed. But IF they can't be changed, they are NOT free. Let's not pretend that everything must be free and next change the meaning of freedom.

Let's not confuse the purpose of freedom. You don't have freedom without limits, or you'll be able to exert power over your "inferiors" (think proprietary versions of Free Software that doesn't use a user protecting license like the GNU GPL).

I agree that freedom has limits, but any limit is not posible for freedom. An invariant section does nothing to protect the freeness of a document.

The moment you want to make it so that what _I_ wrote is something else, you're placing words in my mouth, so you're not exercising freedom.

But I can do it anyway without modifying a document written by you :)

...

Sorry, but if the documentation of a free program has FDL, then it can contain invariant sections, so that I am limited :)

Wrong. Only if it _has_ invariants.

No. I'm limited because someone can insert invariant sections later, a newly modified derivation. I can't reuse that derived version without taking the invariant section with it. :-)

I must say that I was quite convinced that GFDL was a free documentation license some time ago. But after Debian's GR I researched a bit so that I understood why the resolution was approved. After reading all this read and some suplementary links provided by Alessandro Rubini, I'm more convinced that ever that GFDL is not free.

Regards Eneko.

Alfred M. Szmidt wrote:

I do not understand "Q.E.D.". For the other part, if you understand "run" as "read", which I think is quite appropiate, it works.

QED means `quod erat demonstrandum', which is Latin for `which was demonstrated'.

Actually "which was to be demonstrated", BTW.

...

...

Sorry, but if the documentation of a free program has FDL, then it can contain invariant sections, so that I am limited :)

Wrong. Only if it _has_ invariants.

No. I'm limited because someone can insert invariant sections later, a newly modified derivation. I can't reuse that derived version without taking the invariant section with it. :-)

You can't take a GPLed licensed work without licensing the derived work under the same terms as the GPL. So you cannot reuse the resulting work under a GPL-incompatible license.

But you can reuse parts of the work under a GPL-compatible license. And it's up to you which parts you take.

Nothing different for the GFDL.

Quite different for the GFDL. You can reuse parts of the work under a GFDL-compatible license, and you can choose which parts of the non-invariant sections you take, but you always have to take all of the invariant sections.

Frank

On Thu, 2006-02-23 at 00:01 +0100, Eneko Lacunza wrote:

You also don't comment my first paragraph about the problems with invariant/dedications.

Dedications can't be Invariants.

...

...

...

Why does FSF have two distinct opinions about the adequate level of freedom for manuals and for software? Because they are different. It is that simple. http://www.gnu.org/philosophy/free-doc.html

But the 4 freedoms do not change, it does not matter wheter it is software or not.

Oh really? Let's see...

Theory: 4 software freedoms are the same for books

If Theory is true then you can "run" a book for "an purpose" (software freedom 0) since it is a software freedom.

But since you can't "run" books, then you can't exercise one of the four freedoms.

Hence, the 4 software freedoms are not the same for books. Q.E.D.

I do not understand "Q.E.D.". For the other part, if you understand "run" as "read", which I think is quite appropiate, it works.

But "read" is not "run" (freedom 0) but "study" (freedom 1).

I respect you to not want the text you've written be modified, no matter the contents, but then it is NOT FREE.

Passing yourself for me is not allowed by law. So I think your confusing a math text book I write with an invariant section where I say how I can have X or Y levels of orgasm with the theories of a certain researcher.

Rui

On Thu, 2006-02-23 at 11:40 +0000, Sam Liddicott wrote:

Rui Miguel Silva Seabra wrote:

...

But "read" is not "run" (freedom 0) but "study" (freedom 1).

perhaps "perform" or "teach from" or "read aloud" is "run".

I can't imagine how you can think that.

First remember that run is a form of ./program (be it interpreter program or an executable by itself).

"perform" you don't perform a book, you read it or segments of it. read is study, hence perform is a form of reading aimed mainly at others. You can also perform in that exact same form the source code and it still is not running, and most people would be totally pissed off for hearing such gibberish as s//%"$/$/dsfsur&sdruywi5/ or whatever mind-numbing language you wrote the code (just think brain-fuck).

"teach from" duplicate example. "teach" is a form of "perfomance"

"read aloud" duplicate example, see above.

Rui

On Thu, 2006-02-23 at 13:46 +0000, Sam Liddicott wrote:

I argue that "perform" "teach from" and "read" are equivalences of "run" for literary works, and I will now explain to you how I think that.

You can't argue that unless you mean to argue that software freedom 0 is the same as software freedom 1.

I don't intend to force you into making such a statement.

I don't see any shotguns aimed at anyone, so I can't see how anyone can force anyone to anything.

...

First remember that run is a form of ./program (be it interpreter program or an executable by itself).

"perform" you don't perform a book, you read it or segments of it.

That is one use of a book, I have also performed books. The books were bound scripts.

However, freedom 0 is not about "use" but about "running".

"Use" is too generic. For an user, "use" means running. For a programmer, "use" may mean incorporating code (library or copy & paste).

That may be the basis for so much ado about nothing. Not understanding what the terms mean.

Rui

Rui Miguel Silva Seabra wrote:

On Thu, 2006-02-23 at 00:01 +0100, Eneko Lacunza wrote:

...

You also don't comment my first paragraph about the problems with invariant/dedications.

Dedications can't be Invariants.

Because you say so? According to the FDL, dedications can certainly be secondary sections and thus invariant sections.

In case you mean FDL 4.K and the last paragraphs of 5. and 9., these clauses refer only to sections entitled ["Acknowledgments" or] "Dedications", not to any section containing dedications, but entitled differently. (BTW, the conditions for those are not that much different from invariant sections, but that's irrelevant to the point here.)

...

I respect you to not want the text you've written be modified, no matter the contents, but then it is NOT FREE.

Passing yourself for me is not allowed by law.

Which is exactly why you don't need the license to try to enforce this (in a cumbersome way). It is already forbidden by law! Diffamation laws don't depend on copyright licenses.

IANAL. Frank

Rui Miguel Silva Seabra rms@1407.org

On Thu, 2006-02-23 at 22:04 +0100, Frank Heckenbach wrote:

...

According to the FDL, dedications can certainly be secondary sections and thus invariant sections.

Oh really? Let's quote (again):

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the=09 relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

So... no. No dedications.

A dedication could be to a person who has started your involvement with the subject, so would be a matter of historical connection, which is explicitly permitted above. I think that much is obvious.

"Ode to my goldfish" was a frequently-used example and I don't remember anyone claiming it couldn't be an invariant section before this year. Was it so claimed before then?

[...]

The rest is irrelevant, since it is clear you haven't read the GFDL.

Can you prove he hasn't read it? Then don't claim it so quickly.

Thanks,

Rui Miguel Silva Seabra rms@1407.org

On Thu, 2006-02-23 at 22:12 +0000, MJ Ray wrote:

...

Can you prove he hasn't read it? Then don't claim it so quickly.

Let's see... he makes direct claims over content of the GFDL of things that not only are _not_ there, but also explicitly can't be according to the text.

In the part of the message you removed, I explained why I think certain common dedications (such as to people involved in your historical connection with the subject) are explicitly allowed in invariant sections. Therefore, it's not proven any more than a claim that *you* haven't read the FDL. If one cares about formal proof enough to use QED, please explain the steps.

Also, I feel accusing someone of reading while on crack cocaine is a personal attack, even if it was (lame IMO) humour. Would you enjoy that accusation being made of you? Please consider apologising.

In hope,

On Fri, 2006-02-24 at 00:49 +0100, Frank Heckenbach wrote:

Rui Miguel Silva Seabra wrote:

...

What GFDL are you reading? The Crack-Cocaine one? :)

[...]

The rest is irrelevant, since it is clear you haven't read the GFDL.

I was going to answer to your arguments, but if you resort to personal insults like Alfred does, there's no basis for a reasonable discussion with you either. (I had written the reply to your previous mail already, so I'm still sending it. Perhaps I shouldn't. But now you have one last chance to show that you're able to reply to arguments without personal attacks.)

It's not a personal attack, don't be so sensitive.

Rui

Rui Miguel Silva Seabra wrote:

The moment you want to make it so that what _I_ wrote is something else,

That's not only legally not allowed, that's a plain impossibility. Nobody can "make it so that what [you] wrote is something else", unless they have a past-manipulating science-fiction device. They can perhaps make it *appear* that what [you] wrote is something else, or something else, but what you write is just silly.

If you really believe (and not just claim this to continue a lost argument) that defamation was allowed if the license doesn't explicitly prevent it, do you therefore believe everyone is allowed to add diffamation in GFDL non-invariant sections, or GPL/LGPL works, BSD-licensed works, CC-licensed works, public domain works, etc.? (Whether these works are documentation, other forms of writing, computer programs, art or whatever is irrelevant, as defamation can be done in any of them, see e.g. the shooter program example.)

...

Sorry, but if the documentation of a free program has FDL, then it can contain invariant sections, so that I am limited :)

Wrong. Only if it _has_ invariants.

Or if those can be added. This is, always under the FDL, as the FDL doesn't permit me to forbid future contirbutors from adding invariant sections.

Frank

Rui Miguel Silva Seabra summed it up very well.

Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"?

It isn't that different, the four freedoms still apply. The difference is that the content isn't a functional work, and one may wish to attach a dedication to the text, or maybe something else that isn't related at all to the actual text.

But there are problems with this. If every contributer/derivator adds a dedication, then we can end with lots of dedications for a relatively small piece of work.

And if you lots of people modify a small program, and do not collect copyright assignments, then you will have a long list of copyright holders. Nothing different from dedications.

You can pretend to like fluffy puppies, but don't pretend that you like them more than more. Because then it is simply not true.

You are arguing that I can rewrite whatever I write, to whatever I wish to. Since otherwise, it is simply not `free'. Well, here I did exactly that. Here are the exact modifications I made:

You [-can-] {+cannot+} pretend to [-like fluffy puppies, but don't-] {+do a free document, and then+} pretend that [-you like them more than more.-] {+it has a part that can't be striped and modified.+} Because then it is [-simply-] not [-true.-] {+free.+}

If we allow for the modification of what is written, at all costs, then we cannot have a serious discussion, ever. We cannot express what we think without the fear that someone will claim that one claims something else, etc. I took the liberty to modify what you wrote, to explain to you how utterly silly, and devastating it is to allow such things. Nobody should ever have this right.

I also agree that it makes sense that some philosophy text, music recordings or images can't be changed. But IF they can't be changed, they are NOT free. Let's not pretend that everything must be free and next change the meaning of freedom.

They aren't free _software_, but they are free texts/recordings/images. Nobody is redefining the meaning of freedom here. You are on the other hand trying to redefine freedom to mean `free software'.

You aren't limited anywhere when you modify free documentation of a free program. This is like saying that you are limited by the GPL to create non-free works, which is simply nonsense.

Sorry, but if the documentation of a free program has FDL, then it can contain invariant sections, so that I am limited :)

You aren't limited, you are free to change the main work of the document; nobody stops you from doing this.

Cheers.

And if you lots of people modify a small program, and do not collect copyright assignments, then you will have a long list of copyright holders. Nothing different from dedications.

Says you who permanently keeps pointing out subtle differences in others' comparisons. Do you really need to be explained the difference between dedications and a list of copyright holders?

Again, I suggest you read what was written. I did not claim that they are exactly the same, just that they are not different enough to warrant differentiation.

...

difference between dedications and a list of copyright holders?

Again, I suggest you read what was written. I did not claim that they are exactly the same, just that they are not different enough to warrant differentiation.

Did you disagree with the FSF campaign against the BSD dedications? http://www.gnu.org/philosophy/bsd.html FDL seems far more extreme.

The BSD license is for software, the FDL is for documentation. Using the BSD license with dedications for manuals would be OK. Using the same license for software would not.

On Mon, 2006-01-30 at 00:52 +0100, Francesco Poli wrote:

Of course changing a license is not at all an easy task. But so far there was little indication that FSF was actually recognizing the existence of the issues raised about the GFDL...

FSF recognizes that thare are 'issues' with the current version of GFDL and it has assigned a value to such 'issues'. FSF have set their priorities according to its goals, technical and political. There is very little to argue about the priority assigned to GPLv3, rather than GFDL.

Thanks to all that are submitting comments on http://gplv3.fsf.org/

bye stef