Chris Cason  wrote in message <48809f34@news.povray.org>:
> I am seriously considering opening our revision control system for public
> read access. The main issue stopping me is that I don't want to revisit the
> same sort of issues that people flame us for already: they don't like our
> type of 'free'. We use Perforce for revision control, which has free (as in
> no cost to use) client software*, but is not Free Software such as SVN is.
> I don't expect a requirement to have to install non "Free Software" to
> access the repo would be very popular, and frankly I don't want to have to
> deal with the inevitable complaints (as Linus's experience with a
> proprietary SCCS showed).
> 
> While I could migrate to SVN (there is a p42svn tool), I'd prefer to wait
> until 3.7 is finished if this is to be done (note I use SVN daily at work
> and am in a good position to compare the two - I find I prefer Perforce).

I am very glad to read that, thanks a lot.

I think you could quell most of the complaints by saying everything out
loud: on the page with the instructions to get the source code, just write
something like:

"You can access the current source code using Perforce. Please note that
Perforce is free/gratis but not free/libre; a probable change for Subversion
is scheduled for after the release of the final 3.7 version."

I know I would be perfectly satisfied with such a message (although I would
grumble that I can not install a perforce client with apt-get), and I think
anyone sympathetic to free software would feel the same.

For just the same reason, I think that the intended licence change and the
reason for the delay should be written on the download page:

"Distribution and Modification of POV-Ray is governed by our distribution
license and source license. Please refer to those documents before
re-distributing or modifying any POV-Ray files. {+A change for a more common
open source license is scheduled for the 4.0 release.+}"

(with "scheduled" being a link to a FAQ entry explaining the impossibility
to change the licence when authors are missing)

This is not much, but just writing it on the visible pages would show even
FSF fanatics that you are aware of their concerns.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> "You can access the current source code using Perforce. Please note that
> Perforce is free/gratis but not free/libre; a probable change for Subversion
> is scheduled for after the release of the final 3.7 version."

  I'm not convinced it's the pov-teams duty to start nitpicking on
terminology and specifying whether some software conforms to whatever
the FSF wants it to mean.

  I think "perforce is cost-free" is more than enough, without the need to
go into terminology nor politics.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 18 Jul 2008 10:59:24 -0400, Warp wrote:

> Nicolas George <nicolas$george@salle-s.org> wrote:
>> "You can access the current source code using Perforce. Please note
>> that Perforce is free/gratis but not free/libre; a probable change for
>> Subversion is scheduled for after the release of the final 3.7
>> version."
> 
>   I'm not convinced it's the pov-teams duty to start nitpicking on
> terminology and specifying whether some software conforms to whatever
> the FSF wants it to mean.
> 
>   I think "perforce is cost-free" is more than enough, without the need
>   to
> go into terminology nor politics.

I would actually agree with this.  Just say the client is available at no 
cost and that's the solution that the team has decided to use.  I don't 
see a need to justify the choice of toolset.

Jim

Post a reply to this message

Warp  wrote in message <4880afcc@news.povray.org>:
>   I'm not convinced it's the pov-teams duty to start nitpicking on
> terminology and specifying whether some software conforms to whatever
> the FSF wants it to mean.
> 
>   I think "perforce is cost-free" is more than enough, without the need to
> go into terminology nor politics.

This is not cost and/or licence, this is also a question of convenience:

she-seel ~ $ sudo apt-get install perforce  
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Couldn't find package perforce

While every single computer I have access to already has a subversion
client. This is strictly a practical concern. The more obstacles you put to
the access to the source code (and having to install yet another * revision
control client is an obstacle), the less contributors you will have.

Which brings us back to the question:

Do you actually want contributors?

Post a reply to this message

Nicolas George wrote:
> she-seel ~ $ sudo apt-get install perforce  
> Reading package lists... Done
> Building dependency tree       
> Reading state information... Done
> E: Couldn't find package perforce

Yes, this is slightly annoying, though it could be resolved - perhaps by
perforce co-ordinating with the folks who manage the repos (though I
imagine that if it's not there yet it's not going to be). It's not that it
can't be available but that at least in your case (I presume you did a
apt-cache search?) the repository maintainers chose not to have it.

I use freebsd for povray.org and the official perforce clients (command-
line and GUI), plus the perforce C API (their protocol is fully documented)
are available via pkg_add (similar concept to apt-get), in addition to a
number of useful (sometimes third-party) tools; e.g.:

  c4             A CVS-like Frontend to Perforce
  cvs2p4         CVS to Perforce Converter
  p4.el          Perforce-Emacs Integration|
  p4api          Perforce API (static libraries and header files)
  p4db           Perforce Browser
  p4delta        Summarizes and manages diffs between local files and p4
  p4genpatch     Helper scripts for generating RCS patches from Perforce
  p4v            Visual client for Perforce SCM
  p4-P4::Client  Perl extension for the Perforce API|
  p5-VCP         A tool for copying files between various SCM repositories
  py24-px        Perforce p4 wrapper and Python Perforce interface|
  ruby18-p4      Ruby interface to the Perforce API
  tkp4           Tcl/Tk frontends to Perforce's p4

See http://www.perforce.com/perforce/loadsupp.html for more info about the
tools offered by perforce. There's also a p4ftp server which I could
install; this allows access to the repo from standard FTP clients.

> The more obstacles you put to the access to the source code (and having
> to install yet another revision control client is an obstacle)

Perhaps, but not much of one: installing the p4 client is as simple as:

  wget http://www.perforce.com/downloads/perforce/r07.3/bin.linux26x86/p4

which is the linux 2.6 x86 client, ready to run.

If installing p4 is enough of an obstacle to discourage someone from
developing then they might not get far with the POV source: it's not easy
to make effective non-trivial changes to the raytracer.

That said, I understand that it would be better if we had a svn interface.
As mentioned, it's under consideration.

-- Chris

Post a reply to this message

Thorsten Froehlich wrote:

> Yes, I agree that every team member needs to greet all contributors with
> flowers personally.
> Thorsten

What if given developer has an allergy to particular flower?

Post a reply to this message

Jim Henderson wrote:
> Unless the publisher explicitly grants permission for that type of
> distribution as a one-off. 

That can't be easily done with software with lots of authors. If I
contribute code to the Linux kernel under the GPL, can Linus Torvalds give
an exception to a specific person to redistribute the kernel under
different terms, including that tiny bit of code I contributed?

Post a reply to this message

Nicolas George wrote:
> - a public developers mailing-list; that list must be where the actual
>   development takes place, or at least a significant part of it;

There is povray.programming. I agree in that there's probably a lot of
communication the current POV-Ray developers have privately, and it should
go on that newsgroup.

> - access to the current state of the source code; the best way to achieve
>   that is to offer read-only anonymous access to a version control system.

Agreed completely.

Post a reply to this message

Chris Cason wrote:
> Yes, this is slightly annoying, though it could be resolved - perhaps by
> perforce co-ordinating with the folks who manage the repos (though I
> imagine that if it's not there yet it's not going to be). It's not that it
> can't be available but that at least in your case (I presume you did a
> apt-cache search?) the repository maintainers chose not to have it.

There are license reasons why Linux distros don't put some programs in their
repositories.

For example, Ubuntu puts povray package in the multiverse category, which
is "Unsupported non-free software". ("universe" is "unsupported free
software", and "main" is "supported free software". This means "supported
by Ubuntu"; software in universe or multiverse is probably still supported
by the developers of that software, of course)

Post a reply to this message

Tom York wrote:
> Additionally, some of the known issues require executive decisions - for
> example, the preferred behaviour for media and transparency.

That's what the newsgroups are for :)

Post a reply to this message