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."
Yes, you are responsible. Yes, bad things can happen. Yes, RMS warned about these kinds of situations, which is why he's a hardliner on the concept that you shouldn't use anything but open source.
If you want freedom, use open source. In this case, you have a choice to trade that freedom for features. The freedom you trade might be some of that freedom you have to work on open source software.
Really, it's not rocket science. You pick.
If tits were wings it'd be flying around.
I think that the concern is not as much about the principle, but the fact that one could theoretically be liable if the server goes down due to say, a blackout.
While it would be against the spirit of the agreement for Perforce to fine this guy if his server went down for reasons beyond his control, that does not change the fact that signing that agreement opens one up to that liability.
This is not some dopey click-through license agreement. This is a real binding legal agreement.
(NOTE: IANAL, so go check with one if this actually matters to you.)
First, Peforce is saying they have the right that if you violate the terms of their OSSD agreement that they have the right to charge for commercial use of their software. How is that wrong in the least?
Secondly, the problem they have isn't people using your software to make money, or even someone taking your GPLed (or otherwise licensed code) and distributing it for money. There are plenty of people making money off of Perl, but Perl is covered under this agreement.
What I believe they are concerned about is someone (one of your named users, and not just some random shmoe using the anonymous account. Note they state Users as defined in attachment B of their agreement in sections 13A and 13B which are where any proscribed remedies are described.) who has a perforce license developing PURELY COMMERCIAL code in your repository and it not being available to the public under an OSI approved license.
In otherwords. Let's say you develop a BSD-licensed app called foobar and you use perforce. You have 10 users. Someone starts developing another app, call it foo bar bletch, which is an add-on to foo bar. But foo bar bletch is commercial software, and the protections on that code tree prevent global access. Then perforce has remedies.
If, however, someone uses the anonymous account and takes a bunch of your OSI licensed code, and then goes and does something commerical with it. Perforce has no remedies. Other than acquiring the source (which is an OSI-approved and non-commercial activity!) this rogue hasn't done anything commerical with perforce. You might have legal remedy against this rogue, but Perforce isn't a party to this litigation, and has no remedy in this instance as there are no damages.
Well, anyhow, that's MY read of the license. Perforce's CEO and lawyers might feel differently, and if you're seriously concerned, I'd go get a lawyer to read it. However, note that there is plenty of prior art of people doing the sorts of things you sound worried about with Perl. And Perforce isn't cracking the whip there.
(side note: I use perforce heavily at work. It's great software, and the people are great too. So I don't think you have too much to worry about if you deal in good faith.)
Blockquote two excerpts from CEOs Email:
We can certainly pre-bless a license before they start developing [...] We do suggest the GPL and FreeBSD licenses are likely to meet quick
approval
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.
I think what the CEO is trying to say is that as long as you keep offering the source as open while developing using Perforce it's OK, but as soon as you take that code, close it up nice and tight and start selling it yourself without offering source to anyone, then you're in violation. If someone else takes your BSD licensed code your team was developing in Perforce and then develops that on something else (CVS say) and sells it commercially then you're not in violation as long as you keep offering the source you're developing yourself in Perforce.
Then again he is making two contradictory remarks, saying he agrees with BSD licenced code being developed with Perforce then making a comment about the restrictive terms of the license being violated. Anyone can take BSD code, modify it and close it up nice and tight, put it in a shrinkwrap box with a pricetag on it and sit it on a rack without giving out source. Hell, MS does it.
This is pretty murky, without reading the license myself, which there doesn't seem to be a link to, I really don't know, and IANAL either.
Regardless, the argument submitted by the CEO of Perforce on point #3 is 100% valid and just. I don't think that should be contested. If you want to make and code a completely in house app then use another revision control system.
-- iCEBaLM