Are There Problems with the Perforce Open Source License? 29
"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."
Multiple licensing schemes? (Score:1)
Free hosting on slashdot (Score:4, Informative)
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'
Re:Free hosting on slashdot (Score:1)
Bah. REAL men retype the article character by character.
Re:Free hosting on slashdot (Score:2, Funny)
With error correction.
Re:Free hosting on slashdot (Score:2)
(&#^@%}{:> NO CARRIER
Re:Free hosting on slashdot (Score:2)
Wait... Why do you want me to page down? And you don't need to use ^C before it since it's not a user-space command.
-Bill
I am not a lawyer, so... (Score:2)
You don't want to sign paperwork if you're not sure of the consequences, but you don't want to overreact either. Let a legal expert determine if the risk is real.
Your point being what, exactly? (Score:2)
1) You need to provide the license under which you want to work instead of being given a blank check to work under any FSF-approved Open Source license. (Richard Stallman is going to have a seizure when he reads that, but anyway...)
2) They insist that you always offer public access and you don't always want to do that.
Re #1, who cares? This may be a nuisance and they'd probably make life easier for themselves by offering a preapproved list, but I don't see any major crisi
Re:Your point being what, exactly? (Score:1, Insightful)
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.
Re:Your point being what, exactly? (Score:2)
Like he said...If you were adding a BSD module
FYI, BSD+GPL = GPL is perfectly okay (Score:4, Informative)
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
Re:Do not do it this way (Score:2, Interesting)
You are only going to have problems if you try to claim it as GPL'ed--which Perforce does not allow.
Perforce is not open source (Score:5, Insightful)
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.
Open Source's philosophy is not Free Software's (Score:2)
Actually, the freedoms the Free Software movement talks about [gnu.org] were defined over a decade before the Open Source movement came into being. RMS has been quite careful [gnu.org]
notes. (Score:3, Interesting)
* However, the DFSG [debian.org] sort of are.
* No, this doesn't look like a DFSG-compliant license to me.
* IANAL
There is a fine distinction here... (Score:4, Insightful)
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.)
Re:There is a fine distinction here... (Score:3, Informative)
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
Either you are confused or the CEO is... (Score:4, Insightful)
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
There are other free (libre) alternative to CVS (Score:3, Informative)
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.
Public access = GPL compliance (Score:1)
This seems to obviate your 3rd problem. No matter who releases your code, you'll always be in compliance, because your code is
why not bitkeeper? (Score:2)
In what area is Perforce better than CVS? (Score:2)
I'm using both. I have almost exactly the same kind of problems and benefits with both pieces of software, only the commands differ somewhat.
What is available in perforce that is not in CVS?
Re:In what area is Perforce better than CVS? (Score:1)
Re:In what area is Perforce better than CVS? (Score:2)
My largest perforce project is smaller (200kloc). So far I haven't seen any huge advantage. Most little hassles like conflict are handled better in CVS I find. Maybe the big painful job I haven't experienced yet are indeed better handled in perforce.
I don't like the perfor