Tags:
create new tag
, view all tags
Now fixed for next beta, see below -- RichardDonkin

[ The CoreTeam has reviewed this topic and provided a resoltion. It was very clear that the intent of TWiki's license.txt is to allow distribution of derivatives :-), but is self conflicting, and indeed absent in the CVS release and was therefore a) extraneous, b) in breach of the GPL (section 1) due to i) the fact the copyright notice cannot be modified. ii) Places extra contraints on derivatives than the CVS version which the official releases are derived from - this isn't allowed since the CVS version contains copyrighted code belonging to people other than the people on the CoreTeam. ]

licence.txt says

TWiki is open source software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Any redistribution of TWiki or it's clones MUST contain this license.txt file UNMODIFIED.

This IMHO is in breach of GPL because it does not allow fork. Clones can be only required to be distributed under GPL and with including Copyright to Peter Thoeny and TWiki's core team, with no other restriction to modify sources, because GPL gives users freedom to ignore any other conditions/restrictions author wishes to place on his software. GPL guarantees users freedom to modify, as long as changes are released under GPL and marked with different name (ot not released at all).

from GPL FAQ:

  • Why does the GPL permit users to publish their modified versions?
  • The GPL requires the maker of a version (clone) to place his or her name on it, to distinguish it from other versions (clones) and to protect the reputations of other maintainers.

CoreTeam wants to have freedom to take parts of code contributed to Twiki under GPL and discard others, exactly the same right has any other user guaranteed by GPL.

So IMHO GPL gives everybody technically right to fork and ignore sentence Any redistribution of TWiki or it's clones MUST contain this license.txt file UNMODIFIED in licence.txt. GPL is to gave users freedonm from "vendor lock".

BTW TWiki.GnuGeneralPublicLicense has correct wording under GPL and does not prevent redistribution of changes, so licence.txt is an omission, IMHO. So let's fix it.

-- PeterMasiar - 13 Aug 2003

It's an interesting, clearly unintentional catch 22 situation, which precludes derivatives being redsitributed in the fashion you would expect. (There is a workaround, but it breaches the spirit of the wording)

Peter's intent is clear : don't remove copyrights please, and you can't change the license.

The catch 22 is this:

  • Peter did used to own all the copyrights in TWiki. Let's work from that point, and assume that the current copyright statement is valid. (It isn't copyrights are owned by more than just Peter & the CoreTeam... Which creates... "interesting" issues.)
  • Section 1 of the GPL provides some grants, "provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice"
  • This means that the copyright notice in a derivative distribution must include the an appropriate copyright notice including those of the people who's work has been included.
    • The UNMODIFIED part of the file precludes compliance from a derivative distribution with this part of section 1.
    • Thus distributing a derivative isn't allowed by the combination of these clauses.

Possible solutions change one piece of wording from this:

TWiki (TM) is copyrighted (C) 1999-2003 by Peter Thoeny,
Peter@Thoeny.com; ALL RIGHTS RESERVED. TWiki's core
team also holds a copyright.

To this:

TWiki (TM) is copyrighted (C) 1999-2003 by Peter Thoeny,
Peter@Thoeny.com; and the TWikiContributors mentioned in the CONTRIBUTORS file.
ALL RIGHTS RESERVED. 

This then allows the file to continue to contain the UNMODIFIED clause.

I'd contend that this is still problematic. Suppose someone decided to redistribute MegaTWiki. They would not be allowed to change the file to say:

Copyright and License of MegaTWiki, 01 Oct 2004
...
Joe Packager, Joe@Packager.com, http://MegaTWiki.org/

This isn't an ideal situation. A better (more traditional) approach is to have a CREDITS file, a COPYRIGHT statement, a COPYING file and a CONTRIBUTORS file. Even large projects like Squid & Linux don't have an unmodified clause. For comparison I copy the header used for the Linux kernel here:

    NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.

    Also note that the only valid version of the GPL as far as the kernel is concerned is this particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.

Linux's CREDITS approach is a particularly interesting approach to the problem of putting in place an appropriate copyright notice.

I understand the sentiment for including the UNMODIFIED clause, but it does (ironically) preclude redistribution of derivatives, which I'm certain isn't intended! There's lots of possible solutions to this and I've only laid out a couple examples above.

-- TWikiGuest - 13 Aug 2003

Doing a bit of digging on this, I've come to the conclusion that whilst it's clearly intended to be GPL compliant and grant everyone a GPL license there's a few things worth noting about this:

  • The license.txt file was added in Sept 2001 release (and in beta before in all likelyhood). At that time TWiki had been in CVS for some time, incorporated work provided under the GPL back to the project, including from those not on the core team at that time (I think, I need to do further digging) and so on.
  • The CVS tree does not include this license.txt file.
    • This means this UNMODIFIED clause is completely bogus - the code is GPL'd and adding the extra clause is in breach of the GPL, no matter how well meaning.

It means therefore that anyone can redistribute TWiki as long as they adhere to the GPL, do so in full (in preferred form), and they actually have to either a) remove the UNMODIFIED clause in order to be GPL compliant OR b) derive from the CVS repository (Since the unmodified clause isn't not allowed by the GPL to be there anyway - it takes away rights specifically granted by the GPL - and the CVS repository being the code base which releases are derived from ensures this state of affairs.)

This means any FriendlyFork can (and probably should) split the license.txt file into it's usual combination of CREDITs, COPYING and LICENSING.

Sorry if bringing this issue up offends anyone...

-- TWikiGuest - 15 Aug 2003

just to add a little more poop, Debian-legal considers invarient sections such as the one discussed here as causing the package to be non-free. they use the copyrights file as the license and copyright holding data file, and require it to be script mine-able (and then reference one gpl-license file in the text of that file rather than havig duplicate copies)

-- SvenDowideit - 16 Aug 2003

I'm sure the CoreTeam will demonstrate their LeadershipSkills by resolving this matter promptly.

-- MartinCleaver - 27 Aug 2003

I'm sure they will too. Promptly would mean simply stripping the unmodified clause - since a) it's not necessary b) it conflicts with the GPL c) doing that isn't exactly a big deal since it just brings TWiki's licensing back to being the same as the original Dec 2000 release (and prior releases). Could be any one of them too given it's a minor, clearly unintentional mistake that causes quite a big problem. (eg TWiki being non-free as far as Debian is concerned, self conflicting license file etc)

-- TWikiGuest - 27 Aug 2003

Debian recently changed licence.txt - the made it GPL. Current twiki.org version was filled as a bug.

-- PeterMasiar - 27 Aug 2003

TWikiGuest, I don't need to tell you that resolution of this is in the best interests of the CodevCommunity. Apparently what the FSF appeals violations to be reported to them - as on http://www.gnu.no/copyleft/gpl-violation.html ; Given the time that has passed and the lack of further comment we should consider this process.

So, perhaps you could build the email on this topic so that we can give you feedback on the wording. Once I am happy with the wording, if the matter is not cleared up in 7 days (by the 4th Sept) I will sign the letter with you. 21 days is more than reasonable for something so easily rectifiable.

-- MartinCleaver - 28 Aug 2003

Actually I tend to take 28 days as sufficient - it's a standard time frame to expect a reasonable response to a simple, easy to fix problem in most other similar scenarios. Given that the CoreTeam are clearly extremely busy it think it's only fair to give them that length of time. I'm almost 100% certain that due to the alpha/beta/production releases clearly deriving from the GPL'd CVS source over which copyrights are held by more than just the CoreTeam that I have every right to ignore/remove the UNMODIFIED clause - however I don't want to do that at present - I would rather see a positive move to working with people who run FriendlyForks rather than set a negative precedent.

After the intent of a FriendlyFork is to enrich TWiki rather than diminish from TWiki. There is a loophole though - distribute the tarfile inside a second tar file unmodified and patch at install, but that sucks in many respects - but the TWikiUnixInstaller functions that way, so it's easy enough to do. It's very wrong to have to use loopholes, remove notices and so on, simply to comply with incompatible licensing terms on a GPL work.

-- TWikiGuest - 28 Aug 2003

Fine. Let's make it 12 Sept then.

-- MartinCleaver - 28 Aug 2003

Based on recent actions by Peter it is very clear he is willfully ignoring this issue - no comment and implementing features simply because they're in what I have always intended to be FriendlyFork (and stating retroactively that these features have already been implemented) -- Peter views as an UnfriendlyFork and wishes to cause problems for anyone who wishes to run a FriendlyFork, and one clear way is to not address this issue. It is very sad he (apparently) has chosen this path.

Maybe Peter would simply like me to walk away, leave all the work behind I have done for his, mine and the community's benefit and cease trying to contribute code & specifications that benefit the CodevCommunity ? I cannot see how ignoring this issue doing this benefits the community. (After all the sum of all TWiki users exceeds dramatically those who inhabit Codev)

-- TWikiGuest - 29 Aug 2003

[I know this will spark a flame, but I cannot stand it more! I must speak in public!]

TWikiGuest, please stop slapping us all in the face as if all the work spent by all of us on TWiki was nothing.

You speak as if your contribution are more important then the rest. The fact is that your contribution is equally important!

We have worked hard on TWiki, and Peter spends thousands of hours for all of us. I even wonder if he has any time left for his wife and kids ... (I'm serious)

You are pushing the limits too hard. Please stop pushing us as if we were your kids.

You are showing little respect for the work of others.

We are addressing the license.txt issue. (I vote for the correction suggested by you)

I personally think that a fork (even a FriendlyFork) is bad because it wasts efforts. (My suggestion in AppealToCodevCommunityByCoreTeam was meant as a "fork within TWiki" ... i.e. it was more on the lines of the "design the new version of TWiki")

Could you, please, respect us? (and Peter, in particular)

-- AndreaSterbini - 29 Aug 2003

This isn't intended as a flame - I'm suprised that you think I am belittling your, Peter's and the CoreTeam's efforts. This is NOT my intent, and if you have been insulted, please accept my sincere apologies. If Peter stopped work on TWiki tomorrow - as is his right - it would be a great loss to the world. The same goes for any CoreTeam member. I am immensely grateful for everyone's efforts. I had hoped that this issue would be dealt with swiftly, prompted with common sense. (ie "Oh bugger, I didn't mean to do that... There. That's fixed it." and we'd carry on)

Addressing the license.txt issue is a minor fix, but very important to resolve. It is being wilfully ignored on TWiki.org. It does NOT mean I don't appreciate the efforts of everyone - you say that my contributions are equal - no, they're not - they come nowhere close to being as important as those of the CoreTeam to date. (Not even the several hundred lines in the installer that makes life easy for end users)

However, breaching the GPL in a GPL-intended project is a bad thing. If you feel I am dismissing yours or anyone else's work I am not, the contributions far outweigh anything else.

You state that you feel a fork is wasted effort - it isn't - Peter has been merging efforts from my private fork now for months, and has taken several minor patches over a period of years. My private fork has proven beneficial to the community. It is simply because I am being asked by lots of people to make it public that I am doing so, and doing so has so far benefited at least one person. (Nowhere near the thousands Peter's and your tree has benefited, but 1 is better than none no?) I don't want to fragment the TWiki audience - which is why I have suggested FindTopicOnOtherTWikiServer.

Here is the patch to resolve the license.txt issue. TWiki remains GPL'd and therefore protected as it was prior to and up to the original Dec 2000 release. It's an entirely trivial fix.

--- license.txt 2003-02-02 01:15:24.000000000 +0000
+++ license.txt.new     2003-08-29 11:05:07.000000000 +0100
@@ -9,8 +9,7 @@
 and/or modify it under the terms of the GNU General Public
 License as published by the Free Software Foundation;
 either version 2 of the License, or (at your option) any
-later version. Any redistribution of TWiki or it's clones
-MUST contain this license.txt file UNMODIFIED.
+later version.

 This program is distributed in the hope that it will be
 useful, but WITHOUT ANY WARRANTY; without even the implied

It's the deliberate ignoring, deleting of comments relating to this, and implementation of code to avoid the fix that I object to. I am disappointed and saddened - that this cannot be discussed in public like reasonable grown up adults rather than shunted and ignored, and any disagreement deleted (cf the "CopyrightAndLicensingFAQ") ? Yes.

You state I am asking for too much, but I am simply now asking for 1 thing - application of the patch above - to eliminate the problem with TWiki's license.txt that even Debian views as non-free/bust. You do not have to apply it. I am asking in the interests of the community however.

It would be far easier for me to simply walk away, and cease tracking important bug fixes, providing bug fixes, tracking major problems (such as the TOC handling) but I can't see how ceasing trying to provide help in the form of spec, code, installers and so on - all feeding directly out of a fork helps reduce the CoreTeam burden.

Finally and once again, if you feel upset or insulted, please accept my apologies, it is not my intent to upset or insult you, belittle yours Peters or anyone elses work. And finally on the notes above above wife & kids - this is why I am trying to make it possible to contribute to TWiki. If I take some code lifting work, making twiki easier to install & maintain, offer to write code, provide patches, and so on it hopefully makes life easier for him. (And the downside is that it takes time away from my wife and kids...)

Heck, if people could just loosen there grip for a second and realise I've been running a separate fork (privately) for 3 years now and note that it's beneficial, and code coming out improves TWiki's environment (eg the installer), they might find they have more time in their lives.

-- TWikiGuest - 29 Aug 2003

Andreas, I am glad to hear someone from the core team comment on the issue - what's the point of the CoreTeam just speaking in private to each other about this? To us, the public, that just sounds like silence. From the silence I can only assume you are ignoring the issue or you don't know about it. Why do we get more upset about the issue? Because we think you are ignoring the issue. All that can we do about it? Make a stronger case with the last resort to threaten to go our separate way with a complete ProjectFork. No one wants that to happen.

As you point out, and we are all well aware, this is a waste of everyone's time if the issue is about to be resolved. Yet, we don't know that it is unless someone from the CoreTeam says so. I push for commitments and dates not because I want to push the core team around but if I have those then I know it will be worth working on other things. (e.g. I would rather be working on transforming the BeijingArchitectureDiagram to a CairoArchitectureDiagram or finding common agreement on ConsolidateFunctionalityFromSkins than writing this but that topic is irrelevant to me until the GPL issue is sorted).

Although TWikiGuest may be - naturally - most concerned about his own contributions, this is the nub of an issue that affects everybody in the CoreTeam and CodevCommunity. I know of people who have walked away because of the real GPL anomalies and the perception problems at NoRegisterDownload.

From the CoreTeam no-comment on this topic, general CoreTeam silence on others and your sentiment indicator in [I must speak in public!] I infer that there seems to be a CoreTeam policy of not talking about certain issues. As the LeadershipSkills page on ManagersSelfAssessment (on http://www.sonic.net/~mfreeman/manage.htm) asks about any management team:

  • Do you communicate with your people openly, honestly, frequently?
  • Do you return phone calls and respond to messages promptly?
    • (Not only am I refering to responses to topics here, but also my several repeated requests to Peter to talk through things with him on the phone, Peter has not replied to these emails.)
  • Do you follow up on problems and or commitments?
  • Do you have a process to escalate work flow problems and suggestions?
  • Do you listen?

These all form part of a relationship that feeds back to the CoreTeam in the form of:

  • Do you treat those with whom you work with respect and dignity?

IMHO, the only way we can resolve issues is by talking about them. We "noisemakers" don't make noise for the fun of it. It is not fun. We make noise because we want the CoreTeam to both listen and implement the changes (to TWikiDotOrg and to the code base) that we are powerless to make for ourselves.

In short, we feel that the CoreTeam is treating us like kids and you feel we are treating us like kids.

As the for CodeFork within TWiki, issues such as PleaseCreateNewWeb or PleaseCreateNewCategories are still not resolved, despite - I hope - powers to do so having been bestowed to Colas, Walter and Arthur. If the CoreTeam are having private conversations about these issues, why are they so private? This affects us, your CodevCommunity, too. Or is it that you are not talking about them at all? Without you telling us, we cannot tell the difference between silence and not addressing an issue

Simply put, we need more open dialogue.

-- MartinCleaver - 29 Aug 2003

Martin, you are right .... it would be better if the discussion was public.

In fact there is no discussion going on on the private side smile ... (we are NOT treating you as our kids) and we are patiently waiting for Peter's answer.

I am used to long waits ... we all have a lot to do ... I imagine that somebody could have been disgusted for my "absence" in this last long year, but there is a Real Life outside TWiki that drives (forces) our priorities and that one must learn to cope with. (this means also that I definitely lack LeadershipSkills smile ).

I am ready to wait for Peter's answer for as long it takes ... I know he will answer openly and that he is always available for our comments.

I have been too harsh (I am sure) on Michael because I feel the pressure rather high respect to the usual slow speed of Codev discussions. Sorry.

-- AndreaSterbini - 29 Aug 2003

No apology needed. We all disappear off from time to time. I for one am pleased to see you "back" from your "absence" - I hope it's "back to have fun", rather than "back because I should". I'm 100% certain it's the former of those two.

In case you're wondering why the pressure to get this resolved, I'm trying to get a release of the friendly fork out in the next week or two because I will have alot on my plate for a little while after that. (So best to get a release out first, let people play and patch, and hopefully at the "end" of that busy period that I know is coming up do a second release and merge back)

-- TWikiGuest - 29 Aug 2003

Peter Masiar asked a very reasonable question and he can expect a reasonable response from the core team. He will.

The reason for the delay in response? It is not Peter's question, but the attitute of others. As I stated previously, PEOPLE WHO SCREAM AND SHOUT LOUDEST get the least amount of attention from myself. I am just not playing that game, sorry. (So I also qualify for lack of LeadershipSkills smile ). We used to have a very friendly dev environment and I would like to see that restored. I am juggling my priorities on TWiki, spending many hours advancing the project and trying to bring the community together. The CoreTeam sincerely hopes to get the support from the CodevCommunity.

Now, I will be offline for the next 2-3 days. I go with my family to a volcanic park, should be fun for the kids to see bubbling mud holes and steaming lakes. smile

-- PeterThoeny - 30 Aug 2003

Re the LeadershipSkills point made so bluntly by Martin - is it really reasonable to expect rapid responses, escalating to phone calls, for an OpenSource project that remains a part-time activity undertaken by busy people, particularly when many of the CoreTeam are on holiday? Obviously it has taken too long to respond to this issue, and rapid responses would be good. One reason there has been no response here is most likely because the last license discussion ended up in bad feeling and mass deletions.

Clearly the CoreTeam is lacking in LeadershipSkills by your estimation, but that's a bit like criticising the people cooking in the kitchen at home - should they really have a management structure, escalation workflow, etc, when this is a part time activity? Do we really want to re-invent the tedious structure of corporate management in this project when the majority of OpenSource projects get by fine without it? By all means volunteer to help in the kitchen, but telling them they lack leadership skills is unlikely to motivate them to improve things.

The CoreTeam do want to resolve the license.txt issue and have discussed it by email, and I'm sure this will be resolved reasonably soon. Peter is putting a huge amount of effort into improving the way the CodevCommunity works, expanding the CoreTeam, etc - please be patient about this issue and refrain from telling very overworked people they don't have the right skills, unless you are willing for this to descend into another flame war that we really don't need right now. I'm sure you mean well but the way you are going about this is not really helping.

Having new CoreTeam members is great but it doesn't mean that all issues can be resolved quickly - there is a need for agreement within the CoreTeam and CodevCommunity about significant changes such as PleaseCreateNewWeb. We are delegating tasks within the CoreTeam, which will help matters, but agreement is still needed.

-- RichardDonkin - 30 Aug 2003

> Peter Masiar asked a very reasonable question and he can
> expect a reasonable response from the core team. He will.

Peter Masiar was (in part) raising it here because I spoke to him on IRC whilst I was locked out of TWiki.org (for disagreeing with you about contributor's rights) about me having raise the issue in email with you that day.

He was raising it as I understand it because I could not.

Given your response - which is essentially if anyone cares about an issue with TWiki enough to raise it for 16 straight days, and for the best part of a month they must be ignored quite frankly I think that sucks.

If you cannot bring yourself to even acknowledge that there is an issue with your license.txt file that prevents derivatives from complying with section 1 of the GPL - as indeed TWiki's core distribution does not (TWiki contains code copyright by others than yourselves and the CoreTeam and hence the copyright statement is incomplete - which makes it not an appropriate notice and is therefore in breach, preventing modifying it is a secondary violation - the GPL requires it to be updated) then although I'm just one person I have to re-evaluate my position - do I continue trying to work with a project I love working on despite the fact that only lipservice to the GPL is made, or do I go another way.

I choose to go another way. I had always wanted to go down the FriendlyFork line, and I am only being left with the UnfriendlyFork line. I have always said I will not go down that second route, so I am not - I choose to walk away instead. I shall be removing my name from TWiki.org (except where it is necessary for copyright reasons) in the coming days, but I will not be removing contributions.

-- TWikiGuest - 30 Aug 2003

I sent Peter the first request on 19th July. The second on the 27th. I don't call my expectations rapid or unreasonable. Indeed, we had a very civil and progressive conversation when I called him.

Needing LeadershipSkills is not unique to corporate environments; it is common also to school fetes, to church outings and to open source software. The starting point in leadership is listening and acknowledgement of problems, not ignoring an important topic like this for weeks on end and then stating that you intend to continue to ignore people who make a point.

What does this tell me about future issues that I - and others - might have with TWiki? Only that they will be ignored. Do I have to get a petition - witness PleaseEmpowerYourContributors - for every issue? Sorry, I don't have time, not now that there is so much competition from other implementations.

And for the licence file, what was there to discuss?! Two lines of text. But for me the licence is not the problem - it is a symptom of indecision and lack of autonomy in the core team. Any one of you - the empowered - could have changed it. Why didn't you? Its not my place to guess, that's your problem.

We had a friendly dev environment because it worked for everyone. It doesn't work any more.

I fully appreciate that we each need to cherish our lives - I am completely behind this (indeed, this is why I dropped writing CvsWebClient when the developers of SandWeb came along). Like TWikiGuest, wasting my time having to write on topic like this costs me more time than I am prepared to give.

-- MartinCleaver - 30 Aug 2003

I've implemented the suggested change on twiki.sf.net (the TWiki SourceForge shell server) at /home/groups/t/tw/twiki/b/license.txt, i.e. for the next beta the license.txt will be fixed as per the patch above, as agreed with the CoreTeam. Unfortunately non core team people can't see that file, since it is not in CVS, but rest assured it is fixed! Sorry for the delays in getting this done, your patience is appreciated.

Other license issues re bundled webs and contributed code are under discussion - one thing to ponder is that the GNU FDL is not DFSG (Google:Debian+free+software+guidelines) compatible, as this extract from Debian Weekly News shows:

Survey about the Freeness of the FDL. Branden Robinson posted the
[23]results of a [24]survey to measure the level of consensus on
whether the [25]GNU Free Documentation License (FDL) is considered a
free license according to the [26]Debian Free Software Guidelines
(DFSG) or not. The majority of Debian developers and also the majority
of non-developers don't regard the GNU FDL as a license that can
easily satisfy the DFSG.

23. http://lists.debian.org/debian-devel-announce-0308/msg00017.html
24. http://lists.debian.org/debian-legal-0308/msg01031.html
25. http://www.gnu.org/copyleft/fdl.html
26. http://www.debian.org/social_contract#guidelines

Summary: there's a definite majority among Debian developers and users who responded to the survey, agreeing that the FDL is not DFSG compatible.

-- RichardDonkin - 04 Sep 2003

My comments remain FDL'd to the TWiki.org - and as clarification - no invariant sections, no cover texts. The debian lists have mentioned that if there are neither of these that the FDL is a free license, but in it's default state it isn't. At some point I expect the FSF to address Debian's concerns - at which point the content being FDL'd won't be an issue.

I was aware of this before FDL'ing my comments to the core team. Given the FDL is being used as the default license for many things - from books through to the majority of new howto's then whether this is acceptable to the CoreTeam is up to them. Various people on IRC have heard my opinion on how to resolve the license issues for the topic content on TWiki.org, and should realise that I'd go along with whatever is decided by the community. (ie stay silent) The reason for choosing the FDL is unlike the GPL it directly addresses issues that affect written documents as opposed to code - such as translations. (Translations are independent copyrighted works which in published situations are often handled very carefully. If the document was GPL'd then the translation would not have to be since it would contain no common words. The FDL is the only license I know of that addresses translations hence the choice.)

On a second note, whether a license is changed on a private server is almost (but not!) irrelevant... It's good to see movement, but it falls short of totally rectifying the problem. As of this instant, AFAICT the license file is not changed for the version twiki.org is distributing. I suspect a build is a painful process based on other topics so I'm not surpised this route has been taken, but the fact of the matter is betas have been few and far between for a very long time.

I would suggest that the following one off quick approach be taken:

  • Take an existing most recent beta tar ball (and the production one perhaps?)
  • Change it's license file
  • Re-upload
... unless a beta is planned and scheduled/whatever in the next few days. (That said the statement above supercedes the license file, so I suppose it's not as urgent)

Not a demand, just a suggestion... I assume from the above statement that it'd be fine to change local versions in the same way.

I am pleased the CoreTeam has taken the time to resolve this issue.

On a sadder note... (this will come over angry I suspect - it's actually sad... frown )

However nothing can change the fact that the leader of the project went out of his way to a) implement a feature clearly (essentially) marked "the patch implementing this will be uploaded ONLY if the small easy to resolve licensing issue is dealt with" b) turned round and said that by caring about an issue lots and talking about it that they were marked a shouter, and therefore not worth listening to (despite the fact it was a legal issue - now essentially resolved, not a wishy-washy process, feature, architecture or whatever issue) c) after being told that they had merged code against the authors wishes in a highly broken fashion that broke the author's content (bigtime) didn't bother to apologise, just essentially turned round and said "tough, put up with it", and only removed the code after removing a lock on that author out (for trying the single sanction any contributor has who disagrees - pulling their contributions), d) To date has not apologised for his actions.

ie from my perspective the events of the past month have been:

  • Ignores patch after patch after patch from contributor after contributor after contributor
    • This is fair enough - no patch must be accepted - for an author to think their patch MUST be accepted is the height of arrogance. If things aren't looked at people go away.
  • Then when a contributor starts pulling their patches, applies one which they'd been asked not to.
    • Patches were being removed because if they weren't being looked at (which is fair enough) I didn't feel I wanted to support them. Having seen many things dropped and ignored when they're in active use and known useful though I thought that these things would go the same way. (installers, major improvements in maintainability, and so on) This wasn't borne of a few months experience, but of 2-3 years experience. (After all I implemented a fully working distributed TWiki using data and code separation 2 1/2 years ago, and saw the work I'd done not just ignored, but actively "replaced" with other features that have never seen the light of day and are still left as incomplete according to the only page that talks about them to this day. )
      • I suppose for "shouting" about a method that works and caused lots of people to flock to TWiki was the reason I was ignored based on the above comment. frown
    • This is now acknowledged to be a cockup - however the next step went massively wrong...
  • When challenged about this turns round and says essentially "tough, document the feature"
  • The author then looks at how his code (this feature and others) is being distributed, and comes to the conclusion there's a problem - which simply needs resolving.
  • Raises it
  • Gets flamed by people misunderstanding the tone
    • Decides that if that's the attitude he's better off not sharing his work
  • Gets locked out for this attitude
    • Lots of people (both on and off the CoreTeam agree the lock out goes on for far too long)
  • Apologises profusely for getting angry at the above events.
  • Notes that the license.txt file is bust on IRC
  • Notes to the CoreTeam that the license.txt file is bust
  • Wait for a resolution
  • Don't hear anything from anyone
    • Try prompting for an answer (minor change to the header at top of this page)
    • Try prompting for an answer again (minor change to the top of this page)
    • Start updating this page with number of days waiting.
    • Start adding new pages with functionality from my code tree, but noting the patches are witheld until the issue is resolved
  • Hear from Andrea that he finds the approach insulting - I actively apologise for coming across that way since that wasn't my intent - the fact that it looked like it was being ignored due to discussions in private made it impossible to tell that this issue was being considered. (both in email and on this page)
    • Also in response I cease updating the number on this page, since it's clear the issue was being looked at
  • Peter then implements one of the features (and has the arrogance to state after implementing the feature after the feature "request" was added that the feature already existed)
  • This is followed by an angry message from Peter stating essentially that if an issue is worth shouting about he's not going to listen, and combined with the attitude of the previous action ("I've got this, but you can only have it if you fix your license and listen to people", gets implemented independently (was trivial after all - mine accepts TWiki variables however...), then stated "this is implemented already", followed by "shut up, and put up" (essentially)), along with all the prior lack of regret for breaching the GPL, for merging code against wishes (even inadvertantly - personally I'd apologise and remove it instantly)...

All leaves me with an intensely sour taste in my mouth.

I'd much rather ascribe cockup rather than malice were it not for the latter few points confirming behaviour I've observed as a non-core team member over the past few years. I truly believe that Peter does mean well - which is why I ascribe cockup here, but whilst changing a few words IS important (very important in fact), it can't erase the past month.

I can now release my code base to people - and people are welcome to take anything from it they wish... They're nothing special IMO - most of these things can be re-implemented easily, but some people have asked for it which is why I wanted the license fixed.

Once again, thankyou to the core team & Peter for resolving this self-inconsistency which I always stated I thought was accidental.

-- TWikiGuest - 04 Sep 2003

I am back from the trip to bubbling mud holes and steaming lakes; very interesting to see nature so close by!

My previous comment about not giving attention to screaming folks was too harsh. I did not intend to offend anyone, my apologies if I did.

I am not going to address TWikiGuest's latest claims because I think that yet another flame war does not help in bringing the community back together. Those who are interested to know my reasons can send me a private e-mail.

The WebHome home states that the "web is the main collaboration area for TWiki development, open to end users with comments and suggestions, ..., and to software developers interested in discussing and contributing to the code keeping in mind the TWikiMission." Furthermore, ReadmeFirst gives some more details on how we should work together.

Over the last two month there have been many posts that are off-topic based on those guidelines. For example, I do not think that advertising an external fork in 30 Codev topics is within those guidelines, nor within the interests of the community. Over the next few weeks I will clean up the Codev web and I intend to remove or summarize comments that are damaging to the TWiki project (they will be still available in the history). I know that one or two persons will not like that, and some people will consider this censorship. The criteria is this: (1) Are the comments inviting or off-putting to a new developer browsing the Codev web for the first time? (2) Are the comments totally off-topic or in line with the introduction outlined in the Codev home?

The CoreTeam is listening to constructive feedback and is taking actions. As announced by RichardDonkin, the core team discussed the UNMODIFIED clause and we decided unanimously that it is in the best interest of the TWiki project and the CodevCommunity to remove it. Furthermore, we are slowly but surely progressing on the changes laid out in AppealToCodevCommunityByCoreTeam. The Core Team is also looking for additional help.

-- PeterThoeny - 05 Sep 2003

I agree with Peter, re-hashing the issues of the last few months doesn't really get us anywhere - various initiatives are underway to avoid problems, which is already underway (see AppealToCodevCommunityByCoreTeam), and better communication will help avoid the impression that issues are being ignored.

Re license.txt - I'd like to see this in CVS as well, so that it's clear that the TWikiAlphaRelease is under the same license as the beta and production releases.

Re the FDL'ing issue - I'm aware that TWikiGuest has added some conditions to his FDL that make it DFSG compatible, but this seems like a kludge. Surely it's better to use a license that is clearly DFSG compatible from the start? My main interest here is to avoid future licensing hassles, whether with Debian or the CodevCommunity - of course, a TWikiContributor is free to choose the licence that best meets his needs for his code.

-- RichardDonkin - 05 Sep 2003

Why is WillNoris editing the text of other peoples' entries, without even noting the reason for this. I think it is questionable that the change is being done at all. To do it silently is even more questionable. Yes, I could tell via the history, but this mechanism becomes unobvious after a short time. There appear to be a lot of recent changes where the name on the changes page doesn't reflect an obvious contribution to a topic.

Note the change was to bring in the text TWikiContributor, rather than a specific person's name. I leave it to Richard to change back if he wants to. I imagine this is likely to have been seen as a fix, given the recent edits to signatures by TWikiGuest; this again shows why changes to historic text is dangerous - the context changes and topics change the meaning, often meaning a contributors text does not say what was intended.

-- JohnTalintyre - 07 Sep 2003

If you don't like people removing their names, maybe people should apologise when they PISS PEOPLE OFF.

After all I said in email to you and Peter at the end of the lockout that Peter imposed because I wanted to leave TWiki.org and take my contributions with me because he and others had IMO crapped on me.

> As you can expect I have been angry, with what you would expect I would
> feel is justifiable reasons. I have felt hurt and betrayed at times.

To this I recieved ZERO response - not a shred of remorse or regret.

So yes, I'm removing my name - as and when I have a spare 1/2 hour. Tough luck, and if others support me in it, consider that Peter is not always right, and his persona that he portrays TWiki.org is that of ignoring contributors who disagree with him, of attacking CoreTeam members privately when they publicly disagree with him, of someone who craps on contributors who have no desire to be on the CoreTeam, someone who feels they are above the law, and so. (That's the persona I see coming across, you may see it differently)

Hence why I do not wish to be associated with him despite the fact that the rest of TWiki.org is populated by dozens of great people I respect (including yourself John).

-- TWikiGuest - 08 Sep 2003

Dear Michael, (aka TWikiGuest)

I think you have given a very good push to the core team both for the licence issue and to start a collaboration among friendly forks. Thanks!

But I see that you are still angry with us and you are removing your name from all the pages of twiki.org. This is a distructive behaviour and I deeply dislike the way you are doing it.

Ehy, man, give us a break! smile Peter and the core team are adapting Twiki to tackle all the issues raised by you and PeterMasiar and others! We are responding positively to your requests! What more one could ask?

When I see you deleting your name I fear that this would makes more difficult to work constructively and friendly together. This is a pity. frown

I hope you will change your mind and return to constructive contributions.

Friendly.

-- AndreaSterbini - 08 Sep 2003

Well said Andrea. Michael - haven't you got much of what you wanted? Okay, so it took longer than you wanted, but isn't time to get a positve response from you smile Many people felt hurt by this, in and out of the CoreTeam - can't we please move forward now.

-- JohnTalintyre - 08 Sep 2003

Michael, I am still unclear on your opinion of the state of TWiki's GPL status. Would you please clarify on here? Thanks.

-- MartinCleaver - 15 Dec 2003

This specific request on the license file vs GPL you'll find came from PeterMasiar. I am ONLY responding due to this specific request. I doubt people agree with my opinions, and I have the feeling that by even replying in what I hope are couched terms below that it is unwelcome. I hope I'm wrong about that - it why the comment below is so long, I'm really trying to get the point if people disagree with me, that's their perogative, and they should delete my words. Also if anyone finds a difference of opinion offensive, please delete my opinons below. (or anywhere else)

That said, in specific answer to your question above, the way I would answer it is with 2 questions:

  • Has a release happened with this changed wording in - last time I looked it hadn't? (I haven't noticed if it has - I've been busy with family stuff last few days - apologies if I've missed it)
  • Hoping yes to the prior question, does the distribution of TWiki contain a list of all people with copyrights in TWiki - or some other method of complying with the highlighted part below:
        1. You may copy and distribute verbatim copies of the Program's
      source code as you receive it, in any medium, provided that you
      conspicuously and appropriately publish on each copy an appropriate
      copyright notice and disclaimer of warranty; keep intact all the
      notices that refer to this License and to the absence of any warranty;
      and give any other recipients of the Program a copy of this License
      along with the Program.
      

A copyright notice has to include the names of all (or as close to all as practicable) people (or entities) that own the copyrights on those parts. (If it's a partial copyright notice ala TWiki's readme, such a notice claims all copyrights for that partial group). I know that's not what's intended/yada yada yada... But it is the effect .

Personally I've not seen any movement to getting that fixed - but I might not have seen this movement - not all TWiki release work happens on TWiki.org as has been indicated elsewhere. (Specifically the comment about PeterMasiar's request being fixed in readiness for the next release, but not visible outside the core team) That said, it might simply be a difference of interpretation more than anything else, and the ONLY reason I am responding here is the direct request for my opinion. If it's not welcome, please, please, please delete it, and the solicitation for opinion. As with anything I write on TWiki.org, like everyone else it's just an opinion. (An opinon I now think it's a mistake to even think about speaking let alone actually answer the question here).

If the core team think (and I think they do, but I'm not psychic - this isn't meant as a slight) they're complying with the part I highlight above, just mark it up as differences of interpretation. If people aren't listed in the way I personally think things should be to be compliant, I personally won't be presenting code to twiki.org for inclusion - people are more than welcome to view that as my loss. (But then the chances of that have diminished substantially anyway) However if other people take it (since they can) that's more than acceptable - after all the GPL guarantees their right to free speech as much as anyone elses.

Once again, these are just my opinions not necessarily those of anyone else, and as a result not any more right or wrong than other interpretations (and the same goes for anyone else who has said anything). I'm no more, and no less qualified than anyone else to interpret the GPL. (I've looked into it and it's friends quite a lot for various reasons, at the end of the day I'm not a lawyer) As discussed many times the interpretation of the part I've highlighted above can be taken in many ways. If the core team views things differently, they view things differently - this is their project, and it's their perogative to run things their way rather than get moaned at all the time.

I'll shut up now, since whenever I type something here it often offends due to a difference of opinion and that's not my intent, delete any part you find offensive. (I've tried not to be, but differences of opinion are sometimes taken the wrong way...) Or better yet, write some code, write a plugin, refactor documentation - write better docs as has been asked for by one core team member (can't remember the topic - one of Arthur's frown ), or do something more constructive than GPL discussions - like watching paint dry. I personally only raised them in the first place due to it being IMO breached, and quite frankly in retrospect/hindsight the best way of dealing with a percieved GPL breach is probably to simply release code back to the community in a different way. You completely avoid the problem then. It doesn't solve the original problem, but it's a lot simpler/easier.

Once again, in case anyone missed it, if anyone finds this offensive, please, please, please delete this answer & the question.

-- MS - 15 Dec 2003

Thanks for your reply Michael, I am sure we all appreciate it.

By the terms of the GPL as you see it, will the matter be closed once the version in CVS is issued as part of a release?

-- MartinCleaver - 16 Dec 2003

I believe the recent text from MS can be summarised as:

  • Need to include the names of all copyright holders with the license, with the distribution.
At present TWiki deals with this by reference to the Codev site, where contributions are first placed.

A list of copyright holders is likely to be included in the next TWiki release so that this matter can be laid to rest. More of an issue is finding enough time to get the release out. I for one, unfortunately, don't have much time to help.

-- JohnTalintyre - 16 Dec 2003

I have nothing new to add, just reiterating:

  • The main purpose of TWiki.org is to advance TWiki in a friendly, courteous and fun way (and we are working to bring it back like it was in the beginning). Disagreements brought forward in a friendly manner will be addressed. Folks who don't play by these rules will be ignored
  • A license.txt file with changed wording will be made available in the upcoming Beta (within a few days, depending on resolving a security issue and solidifying the password code changes)
    • This is to raise the comfort level (people may misunderstand and misinterpret the GPL)
  • We always acknowledged and appreciated contributions (accusations that we don't are addressed in my open letter in OWikiFork)

-- PeterThoeny - 17 Dec 2003

The only thing I have to add is that this is now resolved.

  • APPLAUSE

-- MichaelSparks - 19 Dec 2003

Edit | Attach | Watch | Print version | History: r45 < r44 < r43 < r42 < r41 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r45 - 2004-11-11 - SamHasler
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.