Slashdot Mirror
Are There Problems with the Perforce Open Source License?
"I've recently put some work into an Open Source project, and since a lot of other people displayed interest in participating I volunteered to set up a source control system. Having worked with Perforce at a previous employer I knew that there are systems a lot better than CVS out there, and since I had also heard about Perforce being free for Open Source development I decided to give it a shot.
Installation went almost without a hitch, you do notice it's a very professional package. I had the evaluation version up and running in no time on my Red Hat 9 server, and I happily checked in the code and the revisions I had already made as well as opening up the second evaluation account for a friend. All was well.
Next day at work I printed out their Open Source License (.pdf) and started filling it in. However, I do read what I sign, and after a while I became quite worried. What I read suggests that, if this license was sent in, I would suddenly become personally responsible (with hefty economic penalties) for what other developers or even other read-only users (which I am forced to give access to according to the license) would do with the source. I decided to write a mail to opensource@perforce.com voicing my concerns. I was quite sure that this Open Source thing was new to them and that we would have no problems reaching a revised license agreement.
Not! Their reaction to my questions was not what I had expected. The CEO answered, and basically said that yes - if I want to use their server, I have to accept the responsibility. That's ok with me - when it's about stuff I can control. In this case however, that's what I feel is missing. While developing Open Source it's not that uncommon to be non-compliant towards the chosen license (GPL, as an example) for brief times during the development. This is not something Perforce allows. According to them the software has to be 'released' at all times, and it has to be compliant to the chosen license at all times. If a rogue developer, or someone at Perforce, releases a non-compliant build the person responsible for running the Perforce server is in breach of the contract with Perforce.
The paragraphs in the license that I base my arguments on are:
- 6B - distributing the software in a non-OS way is a breach of the agreement.,
6C - I must give read-only rights to anyone who uses a Perforce connection.
13A - Here's where the figure $750 times number of users comes from.
My main objection is being economically responsible for the actions of others, and I also think that by requiring the application to be 'distributed' as soon as it enters Perforce a lot of valid Open Source projects cannot abide by this license since they at some point, even if just for a short while, might not qualify for the Open Source license the agreement with Perforce states (like, including BSD code temporarily in a GPL project with the intent of doing a rewrite before release).
Am I paranoid, or is this something Perforce need to go through in detail with the Open Source community, if they want us to use their software? They are of course doing this as a form of advertisment, and I applaud that. I do want to use Perforce for this project - but I don't want to create a license agreement between myself and each and everyone I can control using the server (do remember that I have no control over what people using Perforce computers might do) regulating what they can do and that they would be liable towards me, in the same way Perforce forces me to be liable to them. I do not want Perforce to feel that their gift to the Open Source community isn't appreciated, but I'm not at ease signing their license agreement - and if other Open Source projects have done it, I want to know if I'm the only one.
The mail from me to Perforce, and the answer from their CEO, can be viewed here until my ADSL-connected server melts down."
Why melt your modem. Ctrl-C...Ctrl-V:
From: Troed
To: Perforce
I've now printed out the license and filled it in - but I feel that I need
to make you aware of wordings that make it a bit troublesome for private
persons like myself developing Open Source software to use it.
1) You do not recognize FSF/GNU as an authority on what is and what is not
an Open Source license. While the initial product we are developing indeed
is licensed under GPL, additional planned products might use other OS
licenses. You do state that the licenses listed on opensource.org are good
candidates, but it would simplify OS-development a lot if it was possible
to just comply to those in your license instead of having to send you new
contracts for each new OS license we might use.
2) Being the maintainer of an OS project and responsible for running the
revision control server (Perforce in this case) is not usually a role that
comes with economic responsibility. If someone ("rogue developer") use the
software we develop in a way that wouldn't comply with OS-licenses I would
not be responsible in any way - that developer would. However, signing
your license agreement makes me responsible for $750*noUsers economically
towards you if someone _else_ does something! Is this really your
intention? This is not how Open Source development is run.
3) "Loophole". The GPL (et al) are licenses that "force" the person who
releases software outside of the organisation to also deliver the source.
Any project is "GPL compliant" as long as it never releases any software
publically. Are you aware of this? It would be possible for me to develop
whatever software I like as long as I don't make public releases. Since
you force me to have read-only accounts set up someone _else_ can release
the software though - and thus I would again be in breach of contract with
you - even though I never intended to release the software in the state it
was in at that time. (It's quite common in the OS-world to be
non-compliant with the license for development purpose, but with the
intention of becoming compliant before the release. If you don't believe
me, look up OpenOffice.org. It's actually not GPL-compliant in it's
current state!)
***
From: Perforce CEO
To: Troed
1. You want a pre-blessing on some set of licenses.
We can certainly pre-bless a license before they start developing under
it, but there are too many potential candidates for us to enumerate,
and some of them change over time. We do not, in fact, recognize FSF/GNU
as the authority on what constitutes "open source" for our purposes.
We do suggest the GPL and FreeBSD licenses are likely to meet quick
approval, but we need to see each and every license for source code
being managed by Perforce with one of our EULA for OSSD.
2. You want us to give up the provision that if someone uses your free
Perforce licenses for commercial purposes, we can go after you for the
value of commercial Perforce licenses. It appears that you want to
be completely free and clear if these free licenses happen to end up
getting used for commercial purposes; the comment about "running Perforce
is not a role that comes with financial responsibility" suggests that
you're not willing to be on the hook for anything whatsoever in case
the restricted terms of the open source license are violated.
The software you develop can be used commercially under our EULA for OSSD.
Perl certainly is. Our basic requirement is that the software is not
proprietary, i.e. it is distributed as open source.
The provision here is to keep people from signing up for a EULA for OSSD,
and then selling it to someone for commercial (proprietary) software
development.
3. You don't like letting us access your Perforce depot to keep an eye on
what you're doing, based on the idea that software that's never released
outside the developer'
Jesus was all right but his disciples were thick and ordinary. -John Lennon
a lot of valid Open Source projects cannot abide by this license since they at some point, even if just for a short while, might not qualify for the Open Source license the agreement with Perforce states (like, including BSD code temporarily in a GPL project with the intent of doing a rewrite before release).
Including BSD licensed code with a GPL project is not in any way violating either license. The BSD code remains under the BSD license and the project as a whole under the GPL. There is plenty of BSD-licensed code in the Linux kernel for example.
The GPL says that any license may be used as long as there are no ADDITIONAL restrictions (such as the BSD+advertising clause).
This is tangential from your cause for concern, but I thought this should be clarified.
-molo
Using your sig line to advertise for friends is lame.
darcs, monotone, cvscc, mcvs, subversion, GNU arch.
Use them, and help the free software community improve the tool. Yes, at the moment Perforce is (probably) better. But Subversion with RapidSVN and (if using windows) TortoiseSVN are more than adequate. And with time (and _users_), the free solution may be much better than the commercial alternatives.
I read the license and the letter of the CEO exactly as you say. I wonder how one can understand that wrong.
I mean, the perforce agreement pretty well states what YOU are expected to do if you want to use perforce in OSS development. There is nothing in the license agreemtn where YOU are expected to take over rsponsibility for what your codevelopers do.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.