Hi Francesco,
let me give you my personal view on the issue:
On Sat, Dec 10, 2005 at 06:19:48PM +0100, Francesco Poli wrote:
I share many of MJ Ray's concerns about the design of the GPLv3 development process.
I fear the process will not take into account all the issues that will be brought to the FSF's attention. The process leaders could neglect (even in good faith) the issues that they feel as unimportant or minor, while concentrating on some others only.
yes, it is true , the last call will be made by Richard. However I do not consider this a disadvantage as Richard is known to accept any substantial argument based on the argument alone. He is a lot better in this than any scientist I know. So if somebody wants an issue in - give Richard a good argument.
How can you assure every group's voice will be heard? How can you assure the Discussion Committees will represent the various categories of interested parties adequately? IIUC, Committees will be formed by invitation in top-down fashion: how can a group of interested people become one such committee?
The process document at http://gplv3.fsf.org/process-definition describes two possibilities to become part of a committee: You get an invitation from the FSF or you get invited later by one of the committees.
Given that the committees are there to channel the comments so that the FSF and Richards are able to work, the design is reasonable. Basically I imagine those committees to be the ears and eyes of Richard. This means they better should fit him and his working style. With such wide open ears, documenting everything reasonable they hear, it will be hard for a group to not be heard. They would need to throw away their ticket number.
IMHO, the FSF should make this process more democratic and open.
P.S.: please Cc: me on replies, as I am not subscribed to the list; thanks.
I think this process is a huge improvement over how it was done in the past any by other groups that draft licenses. Note that the GPL writing was never a democratic process. If we were to follow the majority it is likely that we would not have Free Software, GNU/Linux nor the GNU GPL.
Having the main part of the process written down in a rather short document, the ability to give trackable comments, and the time frame of a year make this process quite open.
Nevertheless, there is always room for improvement and I expect the FSF to be open for your comments!
What we can do in Europe is to convince our governments and companies to donate more money and time into thinking about Free Software and enabling the European Free Software people to carry the discussion to as many places in Europe we can.
Best Regards, Bernhard
On Tue, 17 Jan 2006 22:50:40 +0100 Bernhard Reiter wrote:
Hi Francesco,
let me give you my personal view on the issue:
Thanks for your time!
On Sat, Dec 10, 2005 at 06:19:48PM +0100, Francesco Poli wrote:
I share many of MJ Ray's concerns about the design of the GPLv3 development process.
I fear the process will not take into account all the issues that will be brought to the FSF's attention. The process leaders could neglect (even in good faith) the issues that they feel as unimportant or minor, while concentrating on some others only.
yes, it is true , the last call will be made by Richard. However I do not consider this a disadvantage as Richard is known to accept any substantial argument based on the argument alone. He is a lot better in this than any scientist I know. So if somebody wants an issue in - give Richard a good argument.
I hope that's true, but the lack of progress on the GFDL issue is not what I'd call a good precedent... :-(
How can you assure every group's voice will be heard? How can you assure the Discussion Committees will represent the various categories of interested parties adequately? IIUC, Committees will be formed by invitation in top-down fashion: how can a group of interested people become one such committee?
The process document at http://gplv3.fsf.org/process-definition describes two possibilities to become part of a committee: You get an invitation from the FSF or you get invited later by one of the committees.
Given that the committees are there to channel the comments so that the FSF and Richards are able to work, the design is reasonable. Basically I imagine those committees to be the ears and eyes of Richard. This means they better should fit him and his working style. With such wide open ears, documenting everything reasonable they hear, it will be hard for a group to not be heard. They would need to throw away their ticket number.
So, let's hope I won't throw away mine...
IMHO, the FSF should make this process more democratic and open.
P.S.: please Cc: me on replies, as I am not subscribed to the list; thanks.
I think this process is a huge improvement over how it was done in the past any by other groups that draft licenses. Note that the GPL writing was never a democratic process. If we were to follow the majority it is likely that we would not have Free Software, GNU/Linux nor the GNU GPL.
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).
Having the main part of the process written down in a rather short document, the ability to give trackable comments, and the time frame of a year make this process quite open.
Nevertheless, there is always room for improvement and I expect the FSF to be open for your comments!
Let's hope for the best...
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
Stefano Maffulli stef@zoomata.com
[...] I am sure that everybody agrees that GPL and LGPL are more important than GFDL :)
I think *updating* the FDL is more important than updating the GPLs. As far as we know, we have working GPLs, but we have a FDL which can't be used for free software and is causing divisions. There are tutorials appearing under FDL, but you can't derive free software from the example code presented! This is important to fix and the FSF could help free software by fixing all of them at once.
[next comment appears out of order]
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. [...]
Like Deming said, "In god we trust, all others bring data"
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 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?
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.
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?
I'm not sure how Apache updated their licence. I didn't see much of the process, I didn't find it on www.apache.org and I vaguely remember someone from ASF throwing trademark allegations into debian-legal which may or may not have been related.
Best wishes,
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.
simo simo.sorce@xsec.it
On Sat, 2006-01-28 at 20:40 +0000, MJ Ray wrote:
[bug tracking GPLv3]
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 ??
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.")
Compare: "We support the Best Viewed with Any Browser campaign" http://www.gnu.org/server/fsf-html-style-sheet.html#HTMLGuidelines
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.
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. 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.
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?
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.
"Democratic" can just mean governed by the people. If the FSF did not wish there to be any democracy in GPLv3, then the comments process is insincere. I don't believe that's the case, so I'd like to see at least the minimal democratic transparency.
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.
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.
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 have more trust in FSF over the GPL than when they go outside free software, but I admit that my trust was shaken by treating valid FDL concerns with contempt.
Regards,
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.
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!
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.
It's a long way from "We support the Any Browser Campaign". Do you think Any Browser support is pointless, then?
(Firefox is free software? Don't look in the other-licences folder at the unmodifiable parts then... Most firefox-based browsers are free software, even so.)
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.
Did you read my suggestions for a good comment process? Where did I call for open public in-person committee meetings?
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.
[the point]
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.
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.
Btw, can you explain what is a "familiar" process ?
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!
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.
Are you saying committees will not be deciding which issues are Major, Minor or dismissed?
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.
Discussion Committees A-E can work in secret if they wish and nothing appears to republicise the process later.
I'll take your word about "which committee made the issue and which explanation is given" because I think it's too early to tell and my browser is unsupported by gplv3.fsf.org
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 ? :-)
If something is introduced for consideration, you should make it public at some point and it should remain public from that point on.
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
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?
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 ?
Licensors and licensees, I would expect. Most of these are software developers or software users, who I suspect are more likely to be familiar with bug tracking systems, rather than political caucuses.
Do we have a "Free Software Nation" with passports and citizenship ?
Are you enjoying whistling past the graveyard?
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.
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.
[...]
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 ?
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?
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 ?
Years ago, I asked for the FSF annual meeting minutes. I was told there was no need for them to be published. Do you think this request would get a better reply? (So no, I've not asked, but I'm not eager to waste my time calling into a void. Why aren't FSF board proceedings published anyway?)
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 ?
There's a touch of "if I was going to get there, I wouldn't start from here" to this and I've hinted at most of it, but I would:
1. migrate the fancy web comments to an open bug tracker with BTS proxies and helpers on-call for those who need them, 2. replace Discussion Committees A-E with geographic forums (mainly because cultures and time zones make that grouping as practical as anything else), 3. prepare and dispatch GPLv3 briefing packs to all speakers, 4. organise and call GPLv3 meetings at events, 5. make people and materials available to local user groups, law libraries and whoever else you think is relevant, and 6. issue calls for participation by non-big-business groups such as free software projects, cooperatives, charities, governments and civil society.
Hope that you will support those,
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.
- 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.
- 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.
- prepare and dispatch GPLv3 briefing packs to all speakers,
This is done already.
- 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.
- 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.
- 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
Stefano Maffulli stef@zoomata.com [the comments tool]
What browser are you using? Did you inform the webmaster? Did you submit bug report? Your help would be appreciated.
A local compilation from Firefox 1.0.x sources that doesn't use the non-free-software parts. There is no webmaster or bug contact listed on the broken comments system that I can see, but I'm discussing it with a GNU webmaster at the moment.
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?
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'.
As you should remember, there are two problems with this: 1. I won't fund-raise for FSF when it could use that money to promote non-free-software licences like FDL. Last time I discussed it with FSFE, we couldn't earmark donations. 2. I can translate into one non-native language, but most of the FSF sites are not free software either. Is the GPLv3 draft under a liberal/permissive licence?
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.
Are you suggesting that users, including lawyers, public administration, civil servants, businesses and engineers, are not more familiar with ticket systems than caucuses or the legendary comments system?
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.
Already done. What were the use cases which led to selection of the current tool? Then I can offer comparative ones.
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.
The Apache Software Foundation is actually a lot of projects with some shared features, not just the httpd, and is a sort of structured bazaar. You can find more literature either from ASF or the ApacheCon presenters. OpenOffice.org does seem like a fairly single-software effort and I know the other two even less. Beyond that, there are far more "forge" efforts than before, bringing together collaborators.
[...]
If you want to be in a committee you should ask FSF for an invitation.
I am sceptical of the process, but I would. Sadly, it says to feed such requests through either the inaccessible comment system or in person at the Boston conference! The email interface to the comment system doesn't seem to offer a way to do anything other than comment on text. Can you see why this seems ridiculous? If there is another channel for such requests, please announce it.
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.
I also realise that web site statistics are generated from headers that are often forged and few webmasters bother to look whether a graphical browser is running text-only or not because that's more involved. Don't you think it's sort of a shame if FSF doesn't support some free software when following the specs isn't hard and it claims "Any Browser" on the site?
And in any case, thinking of those like rms that don't use X, FSF provided the email interface.
The email interface appears not to serve some tasks.
[...]
There will be at least a conference in Europe and in Latin America, be assured.
This is news to me. Thank you.
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.
A town council has a manifesto and the responsibility of all sorts of property assignments from thousands of people, yet it is given up to a type of democracy. I don't see why FSF shouldn't at least be accountable and verifiable even if not democratic.
- 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.
That comment is so outrageous I can barely answer it. The current tool is broken, but migration is out of the question?
- 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.
Yes, but do you agree that they should be open forums rather than private committees?
- prepare and dispatch GPLv3 briefing packs to all speakers,
This is done already.
Great! Is there a pack for non-FSF presenters too?
- 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.
OK.
- 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.
I will do so, although I may well be suggesting people who are already part of the membership because it's not public info.
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.
I'll encourage other local groups to do so, but funds should be kept within the group and not paid to FSF beyond expenses because of the FDL problem.
- 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.
Please stop suggesting that I do things which FSF says to do with the comments system! It is broken! I cannot use it! If you meant to let them know some other way, please be clearer.
Hope that explains the extent of the access problems better,
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.
I think *updating* the FDL is more important than updating the GPLs. As far as we know, we have working GPLs, but we have a FDL which can't be used for free software and is causing divisions.
The GFDL isn't meant for free software, it is for licensing free documentation. A task which it achives quite well.
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
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.
From what I know, and have read, the GFDL did achive the goal it tried
to achive. http://www.gnu.org/philosophy/free-doc.html has the short story, there might be more tidbits somewhere else.
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.
Force and force... GNU maintainers agreed to follow the policies of the GNU project, this is no different than say a Debian maintainer being asked to follow Debian policies. Say, excluding free documentation even if they disagree with the policy to do so.
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?
I strongly doubt that the two have anything in relation.
Note that I'm a supporter of the current GFDL, it does need some clarifications (and simplifications, I find the license to long and to complex), but none that are so grave that it is more important than updating the GPL.
Cheers.
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
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.
Putting documentation and software into the same box doesn't make sense, the GFDL makes perfect sense on the other hand in my mind.
Nobody at the FSF addressed the serious concerns many of us have with the GFDL. 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, I fail to see how any of that could hinder development of free documentation, on the contrary, it would foster 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?
Do you know why it stopped? I don't. You are making claims without evidence as far as I can see, i.e. it stopped, so lets blame the GFDL. Maybe Lisa Goldstein (the person who started GNUpress) reordered priorities and started doing other work. I don't know, and as far as I can tell, neither do you. Making such baseless claims won't bring anything to the discussion. If you have anything to back this up, please share.
Have you seen any change on ORA's licenses?
I'm not sure what you mean.
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.
Yes you can, that is protected under fair use.
It is simply not designed for sharing.
A GFDL document can be shared just as GPLed software. The GFDL does not put any chains on you as how you can share. I think you are making a similar (no offence meant) to what companies/people who support non-free software make, `I cannot use a GPLed program in my non-free program'. I.e., you disagree how to actually share the documentation.
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).
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.
I disagree strongly, a _reference_ manual should be part of the code, this is something I could agree to. But a documentation that describes the software, say the Emacs manual, should not be part of the source code since they are two very different works.
Cheers, and happy hacking!
"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,
So GPL for reference manuals would be fine by you? How about tutorials which may have programs derived from it?
I had this very question with the documentation on http://linux-net.osd.org/
They changed the license from CC sharealike to CC Attribution-sharealike so that the knowledge can be more freely used to derive programs.
Sam
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
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.
Because PGP was software, not documentation. Such a clause would be prefectly ok for free documentation.
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.
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
Because PGP was software, not documentation. Such a clause would be prefectly ok for free documentation.
Again: Documentation is part of the software.
It _can_ be part of the program, but for Emacs and the GNU C library and other works, this isn't the case. They are two seperatly licensed entities. PGP as a whole was licensed under a non-free software license.
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.
What was the result?
Cheers.
"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.)
and once more the hackers are reduced to serfs, begging the copyright barons for permission to make sensible use of tools they already hold.
Sorry, but that is how it has always worked, for free software too. If you want to use a non-GPL compatible licensed program with a GPLed licensed program, then you have to ask for permission. If you wish to include free documentation in a free software program, same thing. There is no `begging', and never was.
The facts are that you can use, modify, distribute and look at documentation licensed under the GFDL. You don't need to ask for permission to do such things, if you do have to ask for permission to do those things, then it simply isn't free documentation.
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.
"Alfred M. Szmidt" ams@gnu.org
[...] 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.
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.
[...]
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."
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.
Have you read how limited they are? 10(1) only allows you to quote (not include a short text as the basis of your work), 10(2) lets you use works for teaching. And for 10(1), national legislation need not permit much. Look at the English law: http://www.jenkins-ip.com/patlaw/cdpa1.htm#s28
In general, you cannot grab a single short text unless you comply with its copyright licence. Fair use is a pretty foreign ideal not useful for much here.
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?
If you type a program on a typewriter, what is the source code? If you correct it by scribbling on printed pages and retyping, maybe the printed pages are the source code at that point. I don't think many FDL'd manuals are made entirely on typewriters.
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.
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.
[...] 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.
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.
Hope that helps,
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.
On Fri, 03 Feb 2006 20:03:23 +0100, Alfred M Szmidt said:
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.
Anyway, I see that further discussion won't change anything so I'll better spend my time to serve the community.
Salam-Shalom,
Werner
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. :-)
On Tue, 07 Feb 2006 18:14:23 +0100, Alfred M\ Szmidt said:
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
Go and ask the FSF about this.
GFDL somehow reducing the set of free manuals. That is what I
Yes, because in practise it does not allow to share.
Shalom-Salam,
Werner
On Tue, 07 Feb 2006 20:07:01 +0100, Alfred M\ Szmidt said:
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.
Salam-Shalom,
Werner
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.
On Wed, 08 Feb 2006 14:46:48 +0100, Alfred M\ Szmidt said:
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
Nonsense. It is the heart of FS software development.
A few lines of material cannot be considered a legally significant change. So you are free to include those few lines and ignoring the
Wrong. I am not talking about quoting - and even that is limited.
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.
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.
Salam-Shalom,
Werner
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,
Just trying to clarify the concerns about FDL :)
El mié, 08-02-2006 a las 15:23 +0100, Alfred M. Szmidt escribió:
Este mensaje ha sido analizado y protegido contra virus y spam 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. :-)
Why is different the "free" as in freedom concept for documentation from the concept of "free" as in freedom for "software"?
Why does FSF have two distinct opinions about the adequate level of freedom for manuals and for software?
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?
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.
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?
Saludos
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
Bjoern Schiessle wrote:
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.
But GFDL is much stricter (and of course, more complicated) than that. AFAICS, this scenario (which I think can be quite reasonable) can be achieved by "mere aggregation" of free (say, GPL) content plus less-free (say, CC by-nd) foreword, cover texts, etc.
Frank
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.
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.
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
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.
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.
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.
Cheers!
"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,
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:
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.
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.
[... more flame bait ...]
Are you really incapable of having a leavel headed discussion without resorting to these kind of silly arguments?
"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.
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.
Huh?
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.
I haven't contradicted anything. You are inventing things, and putting words into my mouth.
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
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)?
Do you really need the right to modify my essay about how I simply love chocholate cookies, thoughts which I want to share with the world?
I'd think that the right _not_ to modify such a piece is self evident
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.
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).
And as I have also pointed out. This is exactly why only secondary sections can be invariants.
So the question can be reformulated as: Why must a computer program be 100% functional, and a manual doesn't have to be?
Becasue the English language allows for writting non-functional pieces. Can you explain why you need the right to modify my poem about dragons? And why I shouldn't be allowed to attach it to a manual?
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. A manual doesn't have a `behaviour'.
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.
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.
They aren't tied to the main part, infact, they cannot be tied to the main part in anyway or form.
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.
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.
Cheers.
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).
- 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
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.
All the material I find on gnu.org, in fact, talks about direct evolution of a manual or FDL work in general. I was sure I had seen reference to building a pool of free documents whence to build from, but I can't find it today.
/alessandro
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
On Sun, 2006-02-12 at 04:44 +0100, Frank Heckenbach wrote:
- 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).
Here it comes the very good provision many European Copyright laws have, and that US does not have unfortunately, which are the "rights of the author" (droit d'autor, diritti d'autore). In most Europe (I think at least Italy, Germany and France), the author can't in any way dispossess himself of these rights and they permit the author to stop a distribution of his work (or a derived one) if that work damages his image or twist so much it's production to go against the principles that inspired it.
Anyway, I must thank you because this proof of concept finally convinced me that the GFDL has really serious problems, and that persistent invariant sections can indeed be more harmful than helpful.
The FSF will have to undergo a careful evaluation of these problems, I hope they will do so soon after the GPLv3 process will be completed.
Simo.
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.
Alfred M. Szmidt wrote:
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.
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.
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.
They cannot require it. They can only ask for it, and the "evil" author can just decline the request.
This is required for GNU projects, and should be required for _any_ and _all_ projects.
This is a requirement the FSF puts on itself before accepting contributions. It's not a requirement they can put on the contributors, because the FSF does not have special powers by the license (unlike NPL and such), which is a good thing. (I know you didn't say otherwise, but if you think so, this is probably a misconception on your part.)
So in my scenario, as they couldn't fulfill their requirement, they'd have to reject the contributions in their distribution, but they couldn't stop someone else from distributing them (according to the freedoms given by the licsense). That's what I called the "most likely outcome" and described with its possible worst consequences. Again, if you don't see a problem with those consequences, then the FDL might be ok for you.
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.
Back up this claim.
I cannot see why a copyright holder of only part of the code cannot enforce this copyright on his part. E.g., Linus Torvalds alone could certainly sue someone would did what you said and terminate that person's GPL rights (according to paragraph 4). Then that person would have no rights anymore to use a Linux version that contains any code from Linus, and might also be liable for copyright infringement or damages, even if only partly for Linus' part of the code. Unless they'd replace all of Linus' code, they couldn't use Linux at all then. (And if they do, the next major contributor might jump in and sue for his part of the code, etc.) If only a small contributor is ready to sue, someone might be able to step around it (practically, not legally), but as soon as a major contributor is ready to sue, I don't see how they could. So FSF's collecting of copyright assignments is not a necessity for enforcing the license, but an additional safety to them (for the very unlikely case that all the major contributors disappear or, perhaps more likely, are unwilling to or do not have the resources to take action themselves). IANAL.
Frank
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. So unless other flaws in the way of conclusions are pointed out, it follows that the clauses are as harmful as the outcomes we described, or even more harmful (if there are even worse outcomes that have not been found yet).
(2) is, of course, a matter of opinion. But according to (1) it follows that if you don't consider the clauses harmful, you also cannot consider these outcome (as we described) harmful, if your opinions are logically consistent. You can have this opinion, sure, and we can have different opinions. 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), so it's no wonder you don't convince anyone. Just repeating "different works need different freedoms" (even if assumed to be true) does not imply that exactly the FDL provisions are best, even less so in the presence of concrete examples that seem to indicate otherwise.
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?
I got every part of it, really. Do you mean to imply that claims in theory need no backing up? (If so, you might mean by "theory" what others call "fiction".)
Frank
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.
Frank:
[...] 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), [...]
Alfred:
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.
Frank is not lying. You did _not_ address the problems.
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).
Passing your opinion as truth and banning other opinions as "absurd", up to stating that the Debian position is "absurd by all logical means"[1], and addressing your party with "you simply invent absurd lies"[2] makes no good to anyone. There are different opinions out there, but they are _all_ opinions. Nobody is lying when expressing an opinion, so please stop replying yo each and every mail just to have your points and attacks[3] repeated over and over.
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?
[1] 1140867570.959705.30943.nullmailer@Update.UU.SE
[2] 1140867570.959705.30943.nullmailer@Update.UU.SE again
[3] "cluttering the list with abusrd lies" in 1140866700.724403.30924.nullmailer@Update.UU.SE "Once again you resort to outright lying" quoted above, from 1140868181.724421.30958.nullmailer@Update.UU.SE "The only person who has resprted to personal insults is you." in 1140864755.563387.30114.nullmailer@Update.UU.SE "You have repeatedly shown a clear lack of comprehension skills" in 1140867570.959705.30943.nullmailer@Update.UU.SE and so on.
[4] On Feb 11, in 1139659629.747381.6554.nullmailer@Update.UU.SE
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.
On Sat, 2006-02-25 at 13:59 +0100, Alfred M. Szmidt wrote:
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.
The fact that _you_ don't see them as a problem, is very well understood at this point. The fact that _you_ have an opinion does not mean all other are wrong or lying or absurd, etc. By flooding the list of mails at this point I must say your are just pissing people off, and you may even obtain exactly the opposite effects you want to reach.
I recognize you had some points, but you are not going to convince anyone on this list by just repeating over and over and over again the same thing. We are not puppets and can read our archives, mere repetition is just a waste of bandwidth, it's useless.
In 2 hours my mailbox have seen 13 mails from you, and I've read 0, I'm full off, and I am sure many others are.
Maybe Because Frank is to busy spreading lies.
This kind of disrespect from you is what is pissing me and many others off. Can you stop marking opinions or beliefs you don't agree on as lies ?
Let's return to civil discussion where people think of others in positive terms and try to do their best to not attack each other.
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.
Simo.
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:
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.
I can't see where you addressed the specific concerns that were raised in the scenario of Alessandro and Frank: someone takes my FDL-licensed document and adds some useful chapters to it, together with an invariant section saying something that I find disrespectful or wrong, or that makes the document illegal in some parts of the world (as pointed out by MJR). What freedom do I have at this point? I see two basic options: either (i) ignore the contributions or (ii) include them, but only together with the new, unwanted invariant. Since (ii) is not an option, I have to choose (i). I have to accept then that someone might profit from my work but I cannot profit from his/her modifications and additions to this work (which doesn't seem to be in the spirit of Copyleft to me). Where did you address this specific problem that someone deliberately adds an invariant section with some obviously offensive remarks about his/her relation to the document in order to keep anyone else from reusing added or modified parts of the document?
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.
Huh? I don't see what's in common between these scenarios. In the scenario described by Alessandro and Frank, both the original and the derived work were licensed under FDL (since a modified version of the original FDL'ed document must be released "under precisely this License"). I cannot see how someone else but the author could turn GPL'ed code into GPL-incompatible code without breaching the license. So why is it exactly the same scenario? Or what else do you refer to?
Peter.
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
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.
Nothing stops anyone from incoperating the changes into a project which isn't the original one.
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 ...
You know perfectly well what I was refering to, and simply resort to stupid comments like these, again and again.
If you remove a file, and replace it with a new file you have a change, if you take the original file, and change the colours in it, you have a modified version of the same file.
It is clear that you are only interested in causing a flame war.
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.
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?
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.
The judge would infact throw the case out. Only the copyright holder can sue for infrigment.
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.
Cheers.
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.
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.
But others have already explained this point very well, and more than theory real facts shows that.
Not really. People have quoted specific instances, inparticular Netfilter, where you had one person who wrote the bulk of the work. I don't know who has written the bulk, or even who the copyright holder is of the guts of Linux. Maybe you do, but I don't...
Cheers
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
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'.
Cheers.
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
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?
I think that the sections are infact a good thing. So I don't know how to actually answer your questions, maybe you directed them to someone else?
(And you write like the Emacs doctor! :-)
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.
simo wrote:
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.
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?
BTW, the author then has even the options of licensing the "invariant sections" as a whole or each on its own, so that some of sections may or may not be removed on their own, as he chooses.
One advantage would obviously be that the licenses used are well understood, so there'd be little potential for unexpected surprises (such as the "evil person adding invariant sections to FDL work" scenario Alessandro and I described -- I supposed it wasn't the intention of the FDL creators, but an unexpected consequence arising from its complexities, or just from its being new and less well understood).
Frank
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, 2006-02-13 at 23:02 +0100, 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...
Never claimed that, I explained that what I see problematic is that you can insert invariant sections that speak against the original author, or his believes, and they will be not only invariant but not removable!
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.
It's not quite the same thing, but anyway it seem you have strong unchangeable feelings about the FDL so I won't argue further.
But others have already explained this point very well, and more than theory real facts shows that.
Not really. People have quoted specific instances, inparticular Netfilter, where you had one person who wrote the bulk of the work. I don't know who has written the bulk, or even who the copyright holder is of the guts of Linux. Maybe you do, but I don't...
I simply don't mind, I see facts as they are, actually I know of no major violation that is both public and not addressed, that means the GPL is strong and that Linux _is_ defensible. The day that will change I'll say you were right. But actually facts speak in the opposite direction.
Simo.
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
On Sun, Feb 12, 2006 at 01:47:44PM +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.
Therefore I suggest that it is not impossible to enforce the GPL with regard to the Linux kernel. It's already been done, many times.
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.
At Sun, 12 Feb 2006 19:29:46 +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. 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...
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.
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.
And yes, two cases of gpl-violations.org have gone to court and have resulted in an injuction.
Jeroen Dekkers
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.
At Mon, 13 Feb 2006 13:40:19 +0100, Alfred M. Szmidt wrote:
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.
And in practice that's the same.
Jeroen Dekkers
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
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.
Well, it is a bit different in the case of Netfilter, Haral probobly wrote most of the bits, it is kinda hard to claim that FOO wrote most of the bits for Linux.
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.
Maybe, maybe not. One would also have to prove that Alan Cox wrote the changes he claims to have written, since older Linux versions do not have a detailed ChangeLog this is hard (and I strongly doubt Alan can remeber each line he wrote, I can't even vouch that I wrote some files on my computer, which have my named attached!). Should be easier nowadays with a VCS and those write-of's.
=46rom 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.
I couldn't find them, the web page seems a bit adhoc. :-( Does anyone have a direct link?
Cheers.
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
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.)
You can only sue for the bits you hold the copyright on.
If your position is true, then how about the following scenario (yes, I like to construct scenarios ;-):
Me too. :-)
- E. Vil claims that as not all of the copyright holders of the work he obtained are suing, they cannot sue at all.
Since E. Vil is still violating the copyright of the FSF copyrighted works, they will need to comply, "or else". They can then keep _your_ changes non-free, since you didn't sue.
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).
And each party would have to come to the table to protect the `whole' work. They can ofcourse come to the table and protect parts of the work.
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.
Linus' bits are really small in Linux.
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.
Sure, I didn't say it was practical. :-)
Cheers.
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.
Harald Welte wrote:
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.
(A myth I was trying to disprove with my absurd scenario, BTW.)
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.
Thanks for this info. I wasn't aware of this difference, and it's always good to learn new things (a welcome change in a thread like this ;-).
So IIUIC, copyright assignments would make the difference between one "joint authorship" (with assignments) and (single or joint) authorship for the original author(s) plus "modifying authorship" for the new contributor(s) (without assignments), but it wouldn't change the fact that each of the authors can take action on his own, right?
Frank
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 Sat, 11 Feb 2006 19:30:13 +0100, Alessandro Rubini said:
evolution of a manual or FDL work in general. I was sure I had seen reference to building a pool of free documents whence to build from, but I can't find it today.
RMS mentioned this several times in his talks back around 2000.
Salam-Shalom,
Werner
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.
[...] 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.
But you can base it on your own work. It is called a reference.
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.
Noted.
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.
[...] 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.
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.
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.
But that freedom isn't being denied...
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?
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?
Depends on the license, take for example a GPL incompatible license, which is a free software license. You cannot combine this with your own work if your work is licensed under the GPL.
(Note that the GFDL doesn't prohibit any of the above, I know that you didn't imply it, this is just a reassertion)
Cheers.
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
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.
The "Invariant Sections" are certain *Secondary* Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. *If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant.* The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
So Invariants are Secondaries that can't be modified. If it isn't Secondary, it can't be an Invariant. So. What is a Secondary?
A "Secondary Section" is a *named*appendix* or a *front-matter section* of the Document *that deals exclusively* with the *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.
It's much easier to dispel specific doubts and misbeliefs like the one you stated instead of Debian's bogus "GFDL is not Free".
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.
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.
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).
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.
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.
Rui
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.
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'.
Exchanging `run' for `read' will not make any difference, specially since if you do that change, you still have those freedoms with documents licensed under the GFDL, you can modify, use, study and distribute GFDLed documents.
But obviously, such these freedoms to not extend to _all_ written works. See below...
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?
The resulting document claims that Rui Miguel claims something that he simply doesn't claim. And people will think that this is what Rui Miguel thinks.
I can equally create a document from scratch that contains texts with thoughts and opinions that are not yours :)
Sure, but Rui would be able to sue you if you claimed that he thought those things if you did write it from scratch, not so if you modifed the actual text from Rui.
I respect you to not want the text you've written be modified, no matter the contents, but then it is NOT FREE.
No, it isn't `non-free'. First you need to define what `free' means. You have not done this, clearly, the freedom to modify a work in anyway or form for an text that states ones personal opinion is not a right anyone other than the author should have.
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 :)
Unless you wish to get sued for libel, defamnation, slander, etc, no, you cannot. You could do it if Rui or anyone else licensed a work under a license which explicitly allows for such modifications though.
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. Nothing different for the GFDL.
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.
The GFDL is clearly a free documentation license, it allows for all the freedoms: "studying", modification, distribution, copying. It is clearly not a free _software_ license, nobody disputes this, Debian requires all the things it includes to be under a free software license, even for non-software, this is simply illogical for many reasons which have been stated and restated several times now.
Cheers.
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
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.
You can't reuse a non-GPL compatible work with a GPL licensed work, I fail to see the point. If they are incompatible, well, then they are incompatible. This doesn't change the freeness of the license.
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.
Not different at all. With GPLed compatible works you need to take the copyright list, if the extra inclusion of some text is so annoying to you, don't use the work. It still doesn't change the fact that the GFDL is a free documentation license.
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
Rui Miguel Silva Seabra wrote:
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.
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. I don't intend to force you into making such a statement.
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.
Perform is an equivalence of run for scripts because it the ultimate purpose for which the script was intended.
You may find a meaning of "ultimate purpose" where this is not true, perhaps I should use "ultimate use" or "natural area of utility" but I am sure you are able to work out the meaning behind my use of "ultimate purpose"
Same for poetry. For novels, "read" is AN equivalence for run when it is the ultimate purpose for which the book was intended. Not all readings are study.
I think you are drawing equivalence by means of word roots, I am drawing equivalence by looking at common actions on each type of work in the context of the nature of the work.
A program is instructions for a computer to obey (run); a script is instructions for performing artists, a poem contains literary and cultural directions to be interpreted and expressed by the reader with an implicit cultural invitation "to read", as do novels.
Thus we see the similarity of the performance of each type of work, although for one it is commonly called "run" and another it is called "read" or "perform" or "teach from".
read is study, hence perform is a form of reading aimed mainly at others.
read is not always study, a view that many teachers will support. I am certain that many artists will argue that perform is not neccessarily aimed at others, though many will argue it is.
You can also perform in that exact same form the source code and it still is not running,
certainly not running in the computer sense, but certainly what I suggested running is in the literary sense, which as you point out few will want to do, and was not the ulimate purpose for the program.
When I used run in the literary sense I enclosed it in quotes "" to attach a different connotation and to emphasise an equivalence. Here you are using running, a word with the same root but with different meaning and applied to something different. It is as if you used a different word because you intend a different meaning. The visual similarity between "run" as used by me and running used by you is misleading.
Because are argue that they have an equivalence in terms of licensing does not mean I argue that humans act the same way to carry out each operation.
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"
it a similar example, one tailored to a different type of book. Some books are written to be taught from.
"read aloud" duplicate example, see above.
Some books are written to be read aloud.
You pointed out that no-one would want to perform a program vocally, neither might one want to perform a teaching book on stage.
I argue that "perform" "teach from" and "read" are equivalences of "run" for literary works, and I have now explained to you how I think that. I don't intend to convince you.
Sam
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 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 admit that for literary works the distinction is blurred because it is a human that carries out both activities; with software the distinction is clear because one of the activities cannot be accomplished without the use of a computer.
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.
Quite so, but I was anxious to avoid the appearance of doing so. I meant that once I felt I had explained myself, it would be sufficient, even if you think my view is not supportable. I clarify myself slightly in this post, but I think thats enough!
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".
indeed; I was just selecting the form of use most equivalent to running for a literary work.
"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.
It was merely an attempt to arrive at an equivalent freedom for literary works that don't require a piece of hardware to "run" on, and to consider what "run" might mean. I felt that abstracting run (for software) might also describe some use for literary works, and give insight.
Anyway....
Sam
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
On Thu, 2006-02-23 at 22:04 +0100, Frank Heckenbach wrote:
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?
No. Because the FDL says what can be considered Secondary sections, and an Invariant is merely a fixed Secondary section.
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 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. What GFDL are you reading? The Crack-Cocaine one? :)
In case you mean FDL 4.K
But that section can't be a Secondary, thus can't be an Invariant, thus is an inappropriate example.
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.)
Again, not in the context of Secondary sections, hence not Invariants.
The rest is irrelevant, since it is clear you haven't read the GFDL.
Rui
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,
On Thu, 2006-02-23 at 22:12 +0000, MJ Ray wrote:
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.
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.
Either he's trusting what _others_ said or he doesn't understand it at all or worse...
Rui
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,
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.)
Frank
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
I was going to answer to your arguments, but if you resort to personal insults like Alfred does, [...]
The only person who has resprted to personal insults is you.
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
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.
It is perfectly legal to modify what one has written, this is what the GPL does, it grants such a right.
Nobody can "make it so that what [you] wrote is something else", [...]
Sure they can. I write a program looks like this:
(if (give 'ams 'cookies) (setq ams-happy t) (setq ams-happy nil))
Lets translate it into English: If ams gets a cookie then ams will be happy, otherwise he won't.
So now you modify this with s/cookies/death/, and viola. What I wrote was modified into something that is simply not true, yet still allowed if such permission was given.
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.
Alfred M. Szmidt wrote:
Rui Miguel Silva Seabra summed it up very well.
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.
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?
Frank
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.
"Alfred M. Szmidt" ams@gnu.org
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.
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 Sat, 28 Jan 2006 17:56:40 +0100 Stefano Maffulli wrote:
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 :)
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...
Anyway, we will see once a new GFDL version is out... Or even better, once a new GFDL public draft is out and asking for comments.
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.
I am currently submitting comments, I hope that this process will actually be useful...
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