[bernarde]

Hi

I'm a relatively new OpenFOAM user, but I already feel the potential of a truly open source CFD code is immense. I have read through all the posts in this thread, and I must commend Alberto for the effort he has invested in this.

I would like to answer the questions posed by Alberto (I think all community members should provide their answers so we can get a clear idea of what route to follow):

• How do we want to proceed with the project?
  • Do something as -dev but including the documentation, and maintain the dependency on upstream/official OpenFOAM?
  • Formally fork and proceed independently, under a new name?
• What to do with the documentation project?
  • Do we want a formal documentation project?
  • Will be simply included in the "new version" of the code? If so, how do we plan to organize it?

1. Formal fork and proceed independently under a new name
2. A formal documentation project like the FOAM documentation project

I have seen a similar type of scenario in the Content Management System world with the Joomla fork of Mambo. The central issue was also one of copyright ownership. The Joomla fork has been very successful, in fact more so than the original Mambo system. You can check this article for more info (its a little old though): http://www.thejemreport.com/content/view/212/1/

[olesen]

Posting Removed

[bernarde]

Hi Mark

I wouldn't suggest that the two scenarios are identical. I certainly don't try to suggest anybody is attacking OpenFOAM. The following section of the article just illustrates that there were similar issues:

The misunderstanding over this reassignment of copyrights was twofold: Lamont thought of this demand as the first step in a coup d'etat by rogue Mambo developers who wanted to hoard the software for their own commercial purposes. The developers thought that Miro was trying to retain control over the code so that it could dictate who could and could not offer official Mambo training and certification. Neither party appears to have fully understood that the code copyrights fell under the control and jurisdiction of the GNU General Public License, which prevents anyone from "taking" code away from the copyright holders, and corporations from restricting others from offering services.

According to this, the GNU GPL specifically prevents corporations from restricting others from offering services. Would this not relate also to the OpenFOAM documentation project?

[olesen]

Posting removed

[bernarde]

I agree, you should not be able to use names that are mis-representative or misleading. However, would the same apply if I wanted to present a conference or a workshop on OpenFOAM? Would it mean I cannot mention OpenFOAM in the name of the conference or in any documentation?

[olesen]

Posting Removed

[alberto]

Originally Posted by bernarde

I agree, you should not be able to use names that are mis-representative or misleading. However, would the same apply if I wanted to present a conference or a workshop on OpenFOAM? Would it mean I cannot mention OpenFOAM in the name of the conference or in any documentation?

Yes, it meant that for the OpenFOAM conference, which has been renamed "OpenSource CFD Conference" as reminded in this same discussion by a commenter.

Best,

[alberto]

Originally Posted by olesen

If I try to follow your comparison correctly (http://www.thejemreport.com/content/view/212/1/), who do you see is playing the role of Brian Connolly in attacking OpenFOAM? From what I read, this seems to have been the central thing sparking everything off.

Dear Mark,

nobody is attacking OpenFOAM(r) and OpenCFD(r). If you carefully read this discussion from the beginning, many opportunities to talk (talk, not agree) were offered, and various alternatives were considered. This thread simply reports what happened, and discusses about it, openly.

The whole point of the discussion is to find a solution that allows a formal documentation project to be created and effectively maintained by the community, without worrying about potential legal litigations.
The fact this solution might be identified in a formal fork from the upstream release is due to external factors not under the control of the community and of its contributors. As a consequence this can be hardly interpreted as an attack, but should be seen, if it will happen, as a painful consequence of the failure of other attempts.

Best,

[olesen]

Posting Removed

[alberto]

Originally Posted by olesen

Sorry Alberto but I find your chiding is completely out of place and I must unfortunately ask that you carefully reread the context of my posting. I would have thought it rather unambiguous that I questioned the comparison between the cited Mambo/Joomla case and that of OpenFOAM.
Since according to the cited reference (again: http://www.thejemreport.com/content/view/212/1/ in case you wish to read it) the fork was precipitated by "the Brian Connolly attack on Mambo, its corporate sponsor Miro International, and individual developers and participants therein ... [and] many of the people involved with Mambo felt that the project needed more protection against similar attacks in the future. Miro had been providing that protection up until then, using its own resources.", I was certainly interested in how deep the comparison went in Bernhard's opinion. Who he saw in which role. The unasked follow up question would, of course, have been if he felt that OpenFOAM need better protection against attacks than it currently has (cf. Miro protecting Mambo).

If I gauge Bernhard's subsequent post correctly, he understood the gist of my question and noted the limits of his comparison. I don't know why you took sufficient exception to it that you not only felt the need to admonish me to improve my reading skills, but also indeed misconstrued it to imply that my question was raised in different context than the immediate one (ie, the comparison of the Mambo/Joomla case and that of OpenFOAM). Please reread Berhnard's post (#141) and my response (#142) if you are unsure.

Hi Mark,

in my previous message I simply stated that nobody attacks OpenFOAM(r) and OpenCFD(r), as it should be clear from this thread. I'm sorry if it could be interpreted otherwise, but my intent was simply to state that once more.
I find that making this point very clear is extremely important for different reasons:

• All these problems were faced by contributors that were working for free, using their time, for the development of the community, the documentation, and, as a consequence, the code itself.
• It is very easy to interpret the suggestion of a fork as a simplest hostile alternative, which is not the case. It is never simple given the amount of work it involves, and in this case, if it happens, it could not be interpreted as hostile, since we have been discussing it openly and looked for an alternative for a long time.
• The discussion is becoming long (150 messages with this one), and new readers might not follow it from the beginning. It is absolutely understandable.

Now, hopefully without any other misunderstanding, let's go back to the central topic of the discussion.

Best,

[olesen]

Posting removed

[bernarde]

Hi Alberto

I have three questions regarding a possible fork (as mentioned earlier):

1. You mention that there will be a lot of work involved. What do you see as the areas where the most work will be required?
2. If OpenCFD regards a fork as a hostile move, what do you think will be their reaction to it?
3. What do you think will be the community's reaction to a fork - will it be regarded as positive, or will it create confusion?

Regards

Bernard

[alberto]

Originally Posted by olesen

Yes, I see that you still haven't bother to read or understand the context of my post.

This is your opinion. I read all the posts of this discussion, and the context of your point was quite clear. At this point, again, let's move on and go back to the topic.

Thanks,
Alberto

[alberto]

Originally Posted by bernarde

Hi Alberto

I have three questions regarding a possible fork (as mentioned earlier):

1. You mention that there will be a lot of work involved. What do you see as the areas where the most work will be required?

At this point I have no real idea of who would participate in a fork, as a consequence all what I write assumes the most complicated scenario, where a completely new project has to be launched. So I see the following steps as necessary:

1. Find a new name and logo, to avoid further troubles with the trademark policy. And of course spread them and make it clear what happened.
2. Create a repository with the initial branch of OpenFOAM 1.6.x, and of OpenFOAM-dev, which, in my opinion should be merged (and that's probably the longest part), since there are contributions in -dev I would like to lose.
3. Announce the fork formally, and start to spread the new name/logo, clarifying the goal of the new project.
4. Contact Holger and help him in re-branding/re-launching the documentation project. I think his original proposal was the right way(tm) to do it.

2. If OpenCFD regards a fork as a hostile move, what do you think will be their reaction to it?

If we look at the legal aspects, since the code is under a license that admit forks legally, the fork, if formally done, cannot be blocked.
About their specific reaction, I frankly cannot know what it will be.

3. What do you think will be the community's reaction to a fork - will it be regarded as positive, or will it create confusion?

It is quite clear that it will be confusing at the beginning. Someone is using the upstream release of OF, someone is using the -dev distribution. A fork, even if based on both, at a point will have to take decisions, define a line to follow, and will necessarily become an independent project from the upstream release.

It is our task to clarify the doubts and remove the confusion, and this can be achieved in my view with a clear message when the fork is announced, and providing transparent information to the community. In particular, a clear plan should be prepared to inform them about

• Status of the fork
• Migration to the new project from a user point of view
• Development plan at least for the short period

In the end, it will be our (community) choice if the fork will become a successful project or will fail, since it will depend more on external contributions for both code and documentation. I am quite optimistic since I know this kind of projects can work, even for complex projects like CFD codes. Of course it requires quite some work, time, and people. At this point the question is who will take part to it?

Best,

[pauls]

1. You mention that there will be a lot of work involved. What do you see as the areas
where the most work will be required?

Most of the involved work has already been done by discussing 153 times, why it is so much work to rename OpenFOAM.

If it is too much work to find a new name, I can offer to start my random string generator.

There is already enough confusion with OpenFOAM, OpenFOAM-dev and OpenFOAM-extend. Adding another name won't hurt.

If there was real need for Alberto's documentation project, somebody would have taken the necessary steps. So let us thank him for his initiative, and let the project rest until somebody takes the responsibility instead of discussing that it is too much work.

[alberto]

Originally Posted by pauls

Most of the involved work has already been done by discussing 153 times, why it is so much work to rename OpenFOAM.

If it is too much work to find a new name, I can offer to start my random string generator.

There is already enough confusion with OpenFOAM, OpenFOAM-dev and OpenFOAM-extend. Adding another name won't hurt.

If there was real need for Alberto's documentation project, somebody would have taken the necessary steps. So let us thank him for his initiative, and let the project rest until somebody takes the responsibility instead of discussing that it is too much work.

The "work" is not simply to find a name, which is simple operation. It is to ensure the project can be maintained on the long run, which is harder, and takes more time to find the resources.

I think it would be less responsible to fork in a hurry just to do that, create further confusion in the community, and then let the project die because of lack of resources to keep it in good shape.

This said, I agree with you. The discussion is stuck since I did not see crowds of volunteers offering their help, supporting a fork or an alternative initiative. Without volunteers it is not possible to proceed, at least if you want to create a sustainable project.

Best,

[Horus]

Most people who can support the new project with contributions are probably already active with the -dev/-extend/freefoam projects. I think it is most important to convice them to put their effort in a new single project and merge the extensions.
As a user I will be very happy to support a fork just by using it and maybe becoming a contributer at a later time.
Another important point, the documentation project has already been started but paused and could be reactivated. IMHO the doc project should be affiliated closely with a fork (developers are the people who know the code good enough to write documentation though they don't like it usually)
I wouldn't infer from a lack of discussion here that there won't be any contributers. They are there are already, it will be the challenge to unite them.
From my point of view the next steps would be:
- Convince the (three AFAIK) extension projects from the general idea of a fork
- Find a new name
- Set up a common repository at sourceforge or something like that
- Merge the code

Though at this point there hasn't been created any new code it gives a user a single checkout which also includes the dev and extend and hopefully also uses the freefoam build system.
Now see how the project evolves. If it keeps a close track with the openFoam distribution there is no problem in porting features (in both directions).

[alberto]

Originally Posted by Horus

Most people who can support the new project with contributions are probably already active with the -dev/-extend/freefoam projects. I think it is most important to convice them to put their effort in a new single project and merge the extensions.

Yes. I know they are following the discussion, and that would be the best way to proceed in my view too. The only thing we can do is asking them if they want to.

As a user I will be very happy to support a fork just by using it and maybe becoming a contributer at a later time.

Well using it is important too. It would not make any sense to create a fork without users taking advantage of it.

Another important point, the documentation project has already been started but paused and could be reactivated. IMHO the doc project should be affiliated closely with a fork (developers are the people who know the code good enough to write documentation though they don't like it usually)
I wouldn't infer from a lack of discussion here that there won't be any contributers. They are there are already, it will be the challenge to unite them.

I agree. The problem is that not taking part to the discussion (why?) is not going to make things easier. In the end it has been one of the problems OpenFOAM(r) users had to face since the beginning: it is hard to communicate and share. It does not seem to me a good thing to carry the same approach in the new project.

From my point of view the next steps would be:
- Convince the (three AFAIK) extension projects from the general idea of a fork
- Find a new name
- Set up a common repository at sourceforge or something like that
- Merge the code

I agree

Though at this point there hasn't been created any new code it gives a user a single checkout which also includes the dev and extend and hopefully also uses the freefoam build system.

That's surely a great "initial condition" for the new project.

Best,
Alberto

[wyldckat]

Hello to all,

I'm sorry to intrude, but I've tried to read the most of this thread, and also used the forum's search engine and I couldn't find a single reference to the GNU Free Documentation License (GFDL) on it. Right on the GFDL preamble states:

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. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. (...)
It complements the GNU General Public License, which is a copyleft license designed for free software.

Both the user and programmers guides that OpenCFD has made for OpenFOAM are under the GFDL. This (I think) implies that any documentation done without the permission from OpenCFD, and in reference to OpenFOAM, should be done with the same license. Especially because OpenFOAM's code is under GPL.

So, my questions are:

• was the (now closed) ******** Documentation Project made under the GFDL, like openfoamwiki.net is?
• Did it state that it was unofficial?
• Did it include the same Trademark section as do the OpenCFD's documents?
• Did it state:

  This offering is not approved or endorsed by OpenCFD Limited, the producer of the OpenFOAM software and owner of the OPENFOAM® and OpenCFD® trade marks.

• Did it state "documentation done by developers/users using OpenFOAM technology"?

I believe these questions are valid for the previous project, as well as a future fork project, because I believe that in it's (future) heart, it will still use OpenFOAM technology, whether it has a new name or not!

(edit: post clutter moved to here)

I just hope for the best and am willing to help as I can.

Best regards,
Bruno Santos

-----
Disclaimer: This post does is in no way reflect the position of the company I work for, on this matter; nor am I related to OpenCFD(R) nor to the developers of OpenFOAM(R). I have no legal/copy rights over OpenFOAM(R)... and probably should've kept my mouth shut, since I'm just a newbie in this community....

[pauls]

>Both the user and programmers guides that OpenCFD has made for OpenFOAM are
>under the GFDL. This (I think) implies that any documentation done without the
>permission from OpenCFD, and in reference to OpenFOAM, should be done with the
>same license.

What you think is wrong. Only because some documentation on OpenFOAM is published under GFDL does by no means imply that every new documentation must be GFDL.

>Especially because OpenFOAM's code is under GPL.

The code license has nothing whatsoever to do with the documentation license.

>I believe these questions are valid for the previous project, as well as a future fork
>project, because I believe that in it's (future) heart, it will still use OpenFOAM
>technology, whether it has a new name or not!

To use or not to use, this is the question. http://www.opencfd.co.uk/openfoam/ distributes the software under the GPL. This gives every user all rights from the GPL, and not all rights from the GPL minus the restrictions from some trademark policies.
I can call a multiplication function "Paul technology" and publish it under GPL. But I cannot force everybody who uses multiplications to acknowledge the use of Paul technology.

>I just hope for the best and am willing to help as I can.

One thing that will certainly help is not to add more confusion to this discussion.