+972 52-548-6969
Open Source & Forking
Joe raises an interesting question as a result of my post about Dunn & Churchill forking a commercial version of Active Record. I mentioned that I am alright, personally, with this behavior, and he asks:
Why would you be alright with that? Hammett, yourself and others have put countless hours in to the project and then these two dopes repackage and sell your work. I understand that legally it may be OK, but it doesn't pass muster in any way at all ethically.
We have two different things going on here at once.
I certainly don't like it, I would much rather that instead of selling "DunnChurchill.Data.DiamondBinding.ActiveRecord", which is a copy of Castle ActiveRecord, they would package their product with Castle ActiveRecord. Just in terms of allowing their users to know that they can go to the Castle Forums and ask a question, or google for a question regarding that, it would be a significant difference. Quite a side from the matter of giving credit where it is due.
But, and this is important, when I worked on Castle, I explicitly decided that my contributions should go under an open source license. Let us look at the definition of that, shall we? Here are the two relevant clauses for this discussion:
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
Most often, the discussion of open source revolves around the free redistribution (well, just the free part of it :-) ), but derived work is just as relevant.
If we go to the Apache license, which is what Castle is released under, we will find:
2. Grant of Copyright License.
Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
So, this it where I (Contributor) grants you the rights to do a whole lots of things on Castle and any derived work from it, in both source and object form. Section 4 of the same license deals with the steps you must take to ensure that you have the right to redistribute, and from a cursory glance, it looks like Dunn & Churchill has done what they are required to do.
Let us go over it again:
- The OSS definition allows it, in fact, it sees it as a core part of what OSS is about.
- The specific license allows it.
- I have agreed to both of those when I contributed.
I don't think that after saying:
- You can redistribute this software and/or your modifications.
- You can use this software in commercial products.
We can also add, but if you do all both we will be angry. There is no stealing involved, because it is allowed.
Now, all of that said, I mentioned already that I don't like it. I don't like it because while it is permitted, is it usually not... done. Perhaps I should say that it is not polite to do so? I think that this is a good distinction, it is legal, but not polite. It is certainly not the Right Thing To Do as far as I am concerned.
There are reasons for forking a code base, which move from politics and personal vendettas to disagreeing about code styles to stagnated project or actual wishing to take a code base in a different direction. Without commenting on the validity of these, and keeping in mind that I don't personally like forking in general, all of the above are considered "normal" reasons for forking.
Usually a fork die off, or the parent project die off, but those are what considered to be the acceptable reasons for forking. Forking in order to change the name and sell the product is not, in my opinion, an acceptable reason. Mainly because as far as I can see, the only reason to do that was to be able to package the whole thing under their name.
The value added in this product is the VS integration, I would imagine, and I doubt that any would have a problem with them selling such a product if they kept using Castle ActiveRecord. As it is, it looks like they are trying to offer in their product more than they actually have built, probably because there isn't that much of a need for VS integration alone.
In short, legal, but not polite, and it goes quite outside the usual accepted practices of what you can usually do. I am fine with it because when I contributed, I agreed what can be done legally to my contributions, not just what is considered accepted. Nevertheless, I still don't like it, and I have no problem holding both opinions at the same time.
Comments
Legal, of course. Ethical, nope.
But then that's what you have to put up with to get the benefits of open source. And those who contribute to open source accept that the benefits outweigh the negatives.
However, if I was a commercial organisation asked to pay for the work, and then later found out it was a copy of an open source project with a small addition, I would probably be more than a little annoyed, and would probably look to recover my money from the vendor for trading under a false premise.
I have an incredible sense of déjà vu... this conversation has been repeated and repeated...
Rik,
Naturally, this is not the first time such a thing happened, and likely the same response have been written.
This will probably not be the last time.
Did they really "fork" it? Are they accepting contributions? Or are they packaging it and continuing to pull updates from the Castle project? There's an important distinction here. The latter case is done all the time. Look at Red Hat.
The most important parts of the Apache license in terms of DiamondBinding are not #1, #2, or #3, it is #4 "Redistribution". There are conditions to redistribution of OSS products and Derivative Works, and from what I can tell, they are not meeting these conditions.
If I understand it correctly, they are fine if they retain all existing license notices, clearly note what they have changed, and continue to make the product available under the same license. Has anyone downloaded their product and checked it out? Are they releasing under the Apache 2.0 license? If not, it is not legal.
I could be wrong - not a lawyer.
Haacked,
I call it forking because they abandon the original code base.
RedHat has its own branch, if you will, of the kernel code, but it is clear what the original was, and what the future holds.
Here, nothing is very clear at all.
Yeah, I won't be buying the Dunn & Churchill product. In fact, when given the choice, how many people would pay for the same thing they can get for free? Go ahead and sell it. You might get a few buyers, but not enough to remain viable. Castle AR is free, and people are going to choose free in most cases. Additionally, those of us who know its a rip-off will most likely harbor negative feelings for Dunn & Churchill.
From APL section 4. Redistribution, they aren't distributing source, so (b) & (c) are not applicable, we don't have a NOTICE file, so they aren't violating (d).
They do distribute the castle license, so that takes care of (a).
About the extra conditions:
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions
I noticed you can by-pass having to register on their site, and get a direct download here;
http://dunnchurchill.com/support/downloads/diamondbinding/Dunn%20&%20Churchill%20Diamond%20Binding.msi
"You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions"
I'm fairly certain this is interpreted as, they can re-license any modifications they make, but they can't re-license the original Castle portions. Which is a fairly standard clause, read about the current GPL/BSD wireless driver mess for some debate on similar issues on re-licensing.
A brief read of the APL says to me that as long as they are distributing it with the APL license text, then they're in the clear.
That get to lawyersomeness that I would rather avoid getting into.
But they do distribute it with the castle license.
@Orin, @Kevin, @Tanner
The Apache license is not a reciprocal license, so there is no requirement that a derivative work be distributed under the same license. However, there is no way to appropriate copyright on the part of the original work retained in the derivative (that's standard copyright law). And Apache does have some special rules if you do make a derivative under the Apache license.
The attribution requirement is important. The benchmark for this is probably Sun Microsystem when it distributes LGPL (i.e., OpenOffice.org) code and GLP code (other stuff, Java?). There is always a text file with the binaries that provies attribution to the different but GPL-compatible bits that have been incorporated and/or derived in their work. Lots of BSD and MIT and Apache license code shows up that way (although not so sure about Apache because of the discomfort Stallman has had with that and GPL2).
I think attribution is very important. It helps establish the provenance of the code and it might help someone understand whether they should inquire if the original work ends up with a bug or security vulnerability that may have been inherited into the derivative product. For that and other reasons, it is probably best to incorporate the original work and not modify it directly, so that an upgraded or path is easier to introduce. It is even more helpful if somewhere there is identification of the specific version of the original work that has been packaged in the larger work.
But now I am talking about seriously polite behavior. By obfuscating the derivative, I'd say they have cut themselves off from some invaluable assistance if they have problems in their code.
I agree that this conduct is a serious warning sign about the likely difficulty that might arise in dealings with such a supplier.
"so that an upgraded or path is easier to introduce" should be read as "so that an upgrade or patch is easier to introduce" since, clearly, that is what I meant to say.
Comment preview