Dan Bartlett spotted some GLScene source code in FireMonkey, see this thread in the Embarcadero forum for details, parts of the VectorGeometry.pas, Spline.pas and raycasting code have been identified. The code having been incorporated in closed-source code (KSDev’s, Delphi XE2) it hadn’t been spotted or reported so far (at least to my knowledge).
edit: snippet posted in the comments, < & > lost, but you’ll get the idea.
edit 2: I’ve been contacted by Embarcadero, the code is being looked into, rewritten/replaced to get out of MPL where needs be, and everything should come to a happy conclusion.
FWIW, neither Embarcadero nor KSDev have made any closed-source or special non-MPL agreement with the original authors, so technically speaking, they’re in breach of license.
For the parts mentioned above, the original authors would be mostly me, Mike Lischke, and whoever you can see mentioned in the Sourceforge CVS/SVN log at the date the code was copied, so they’re not in the big trouble they would be if they had ended up using Oracle’s code or Apple’s drawings 😉
GLScene being under MPL, it should be reasonably easy for Embarcadero to get into compliance, to quote wikipedia:
all distributed copies must contain the source code, all modifications must be described in accompanying documentation, all necessary patents must be described in accompanying documentation, all copies of the code must have a statement of copyright attached, and all modified code must be distributed under MPL, although new files containing new code need not be distributed under MPL.
And also:
The way in which the Mozilla Public License is drafted basically requires subsequent users to license the original code under MPL and all additional code under any kind of license
Meaning in short that all compiled FireMonkey applications should have a copyright statement about GLScene (in the about box f.i.), and if you modify FireMonkey source files yourself, depending on what you modify, you could fall under MPL and you would have to publish those modifications.
KSDev applications released in the wild should also have that copyright statement added, btw.
Note that you don’t have to physically include the MPL source code with the binaries, as long as you provide a link to a website hosting the code (in this case GLScene.org or the SourceForge page).
I definitely want to see this play out. I think it is behoven upon the accusers to list specific sections of code, not just make reference to topics.
There is going to have to be scrutiny from all sides to make sure that the reverse situtation has not happened instead. (KSDev code working its way into GLScene without the author’s knowledge – it’s not like everyone is always reading open source to look for infringement)
Or worse, that this is not a tempest in a teapot and the sections are not significant enough to warrent infringment or protection – or indeed that they are not generic enough to have been based on the same source material (a book or common algorithm for example).
I’m not coming down on any side or pointing any fingers, but if we are finally getting into this particular pissing match in the Delphi world, I definitely want to see all the facts before I feel inclined to act one way or the other. I doubt I am the only one.
Thankfully, Firemonkey is far too young a platform to trust to any serious work, and it does not take much to find flaws and signs of immaturity in the framework itself.
The 2d parts will get well explored for cross platform, but the 3d stuff will likely languish for a version or 2 before it develops enough (indeed, it may well fail utterly because of its inherent limitations, or loose its platform independence even)
It *IS* mighty fun to play with tho.
@C Johnson
Well, at the moment I have personally seen neither the XE2 nor the KSDev source code, but two of the portions listed by Dan (spline & raycasts) should be quite recognizable, as they were written quite outside of the literature, as are some of the VectorGeometry routines.
I’m also interested to see how they will react on this.
Well that’s interesting. Seems like the second time they’ve shunned the indie developers. They’ll take from indie game developers, but they won’t give much back to them will they?
Oh and hey Eric! Long time. 🙂
@Jason McMillen
Hey WILL! I’m visiting PGD from time, but haven’t gotten the dang time to get any game started again in a long while…
And yeah, I heard that they didn’t even tell any of the FreePascal guys they would use their compiler.
Virtually all the stand-alone functions in FMX.Types3D ( http://docwiki.embarcadero.com/VCL/en/FMX.Types3D#Functions ) are from VectorGeometry.pas, I know they didn’t originally come from KSDev code because most of GLScene’s VectorGeometry code is 10-15 years old, and as for being independently developed from same sources, the code, variable names and comments in some places are too similar for that.
Here’s the SVN log of VectoryGeometry.pas back to 2003 ( http://glscene.svn.sourceforge.net/viewvc/glscene/trunk/Source/Base/VectorGeometry.pas?view=log ), but it was previously name Geometry.pas in the CVS version of GLScene and goes back a few years prior to that.
An example function from GLScene’s VectorGeometry.pas:
function RayCastTriangleIntersect(const rayStart, rayVector : TVector; const p1, p2, p3 : TAffineVector; intersectPoint : PVector = nil; intersectNormal : PVector = nil) : Boolean; var pvec : TAffineVector; v1, v2, qvec, tvec : TVector; t, u, v, det, invDet : Single; begin VectorSubtract(p2, p1, v1); VectorSubtract(p3, p1, v2); VectorCrossProduct(rayVector, v2, pvec); det:=VectorDotProduct(v1, pvec); if ((det-EPSILON2)) then begin // vector is parallel to triangle's plane Result:=False; Exit; end; invDet:=cOne/det; VectorSubtract(rayStart, p1, tvec); u:=VectorDotProduct(tvec, pvec)*invDet; if (u1) then Result:=False else begin qvec:=VectorCrossProduct(tvec, v1); v:=VectorDotProduct(rayVector, qvec)*invDet; Result:=(v>=0) and (u+v0 then begin if intersectPointnil then VectorCombine(rayStart, rayVector, t, intersectPoint^); if intersectNormalnil then VectorCrossProduct(v1, v2, intersectNormal^); end else Result:=False; end; end; end;And from FMX.Types3D.pas (I wouldn’t normally post Delphi source-code, but well, it’s 99% the same as GLScene version):
function RayCastTriangleIntersect(const rayStart, rayVector: TVector3D; const p1, p2, p3: TVector3D; intersecTPoint3D: PVector3D = nil; intersectNormal: PVector3D = nil): Boolean; var pvec: TVector3D; v1, v2, qvec, tvec: TVector3D; t, u, V, det, invDet: Single; begin v1 := Vector3DSubtract(p2, p1); v2 := Vector3DSubtract(p3, p1); pvec := Vector3DCrossProduct(rayVector, v2); det := Vector3DDotProduct(v1, pvec); if ((det -EPSILON2)) then begin Result := False; Exit; end; invDet := cOne / det; tvec := Vector3DSubtract(rayStart, p1); u := Vector3DDotProduct(tvec, pvec) * invDet; if (u 1) then Result := False else begin qvec := Vector3DCrossProduct(tvec, v1); V := Vector3DDotProduct(rayVector, qvec) * invDet; Result := (V >= 0) and (u + V 0 then begin if intersecTPoint3D nil then Vector3DCombine(rayStart, rayVector, t, intersecTPoint3D^); if intersectNormal nil then intersectNormal^ := Vector3DCrossProduct(v1, v2); end else Result := False; end; end; end;@Eric
You know, I’ve been talking with David I. and we’ve had talks about Delphi and the indie perspective. He seems to get it, but I don’t think his company is 100% ‘on board’ with a a lot of the ideas we’ve discussed.
Funny though, Starter Edition did come not too long after a long chat we had on Skype about a lower cost Delphi for indies. *shrug* Not that I’m claiming to have seeded the idea in their heads, but… you have to wonder. 😉
Well be sure to come back to PGD for this Oct/November when the next PGD Annual starts up again. At least come post something sometime when you can, it’ll start a discussion all on it’s own.
@Dan Bartlett
That’s rather quite verbatim.
Besides name and format, the call convention for vector functions also looked exactly like that at some point (func vs proc), and IIRC I went back & forth between the two forms depending on how the compiler handled them.
I’ve tagged your comment with “pre”, it still stretches the blogs stylesheets though, and the </> got lost, but hey, more readable it is!
Lets hope they just quickly openly admit the code is borrowed (which it clearly is) and do what is needed to follow the license.
I can understand this stuff easily happen when a hobby project grows into a large code base and becomes a commercial product that the developer forget about the origins and license requirements of some routines. Perhaps that is what took place here.
This incident aside, I’m very impressed with the XE2 release and look forward to working more with it.
There was already a MPL public directory in VGScene/DXScene.
It’s still available on the original KSDev site.
See http://www.ksdev.com/mplfiles/
I guess they will do the same for all ambiguous code – this will complete the license requirements.
@A. Bouchez
This directory doesn’t seem to have glscene units in it, also it’s only half of the requirement, the other requirement being the copyright mention, which would have to appear not just in the Delphi IDE, but also in all FireMonkey (or ksdev application, along with a link to opensource directory + modified files directory.
@Dan Bartlett
The RayCastTriangle example falls into that catagory I mentioned early: code not likely to be protected. It is just straight up vector MATH – there are not a lot of different ways to do it, both examples could be pascal translations of the same algorythm (or C code).
Sorry, I definitely need to see more than this. Most of the standalone functions I have been reading in FMX.Types3d are exactly the same – generic math in very generic pascal expression, as simple as possible.
Show me code doing something I can’t find in a math text or similar reference and then we’ll do some serious comparisons.
See for yourself..
http://www.simdesign.nl/images/FM_vs_GLScene.png
The two are not perfectly equal but certainly related, ie the chosen names etc and so on. But maybe the sources both come from a common ancestor long ago, maybe even coming from C etc.
I am not a lawyer and I wont say this is a direct copy, but the similarity is certainly striking!
Well, the point here isn’t patent but code copyright, which covers such cases. As for being lifted from previous C code or a book, I encourage you to find it, with the same names, order of operations, and same conventions. Some of the code was made to work around some limitations of the Delphi compiler and aren’t always the first solution one might have come up with. For instance in raycast function here, the intersect normal served a specific purpose (why was it bundled? A simple implementation wouldn’t have bundled it as it’s just a cross product, and not even normalized… Answers to that is in GLScene usages of that function rather than FireMonkey’s).
For most GLScene functions, you can see them “evolve” by replaying the CVS/SVN history, as the sourceforge repository has been in use for a long time. Before it, it should still be possible to grab even more ancient source zips from old Delphi repositories.
Again, we need to see Embarcadero reply – and I would like to see something that is actually copyright worthy as an example. The function so far is pretty much the text book example of a thing that is NOT copyrightable.
Based on pre-established math, follows a fixed routine already well established by vector mathmatics.
I’m not saying the similiarities aren’t striking, I am saying: WELL DUH – this is how you do this stuff. dig up a few mathbooks on the topic, I am betting you see a few similarities there too.
As for variable names… We all think along similar names. It’s not like they arbitrarilly decided to use “cow” and “chicken” and those got copied. No, V1, V2 V3 for vectors. I have 2d Polygon code, and I have P1, P2 and P3 variables in routines – I’ll bet you find other code that uses similar variables names and do EXACTLY the same thing, because for something like the area of a polygon – they method to do it is well established and who needs to waste time being creative?
No, it’s already been well established that basic math is not the sort of thing you can copyright. It’s what you do on the higher levels that is special and covered by protection.
We need to see more examples of that to be compelling and meaningful.
No, you’re confusing patents and copyright. Patents protect high level aspects, copyright protects low-level aspects, such as verbatim code copy.
That’s what is actually well established, and the very foundation for copyright licenses (MPL, GPL, etc.), which do NOT cover patents, f.i. it’s not uncommon to have to honor both patent and code licenses separately, from distinct entities.
@Eric
So if I write the code
c := a + b;
If you copy that line into your own code you are guilty of infringing my copyright?
Seriously?
As C Johnson says, it’s very likely that many programmers will end up using the exact same variable names because they make obvious sense for what is being coded. The operations will be essentially identical because the math demands it.
And that kind of code, in isolation, cannot be considered a copyright infringement else no-one else can legally write a simple addition statement using the variables names a, b, and c!
Even a series of such statements, if they constitute a commonly known math algorithm, cannot be subject of copyright – you cannot copyright mathemetical statements or algorithms any more than you can patent them.
If you contain such methods within a unit that implements a control you designed (for example), now you are talking – the unit as a whole can be protected under copyright. But the isolated examples of mathematical functions in that unit are still fair game precisely because others could reasonably write the vey same code even down to the variable names and formatting without having ever seen yours.
They cannot be subject to patents, but are subject to copyright, yes. At how many statements copyright begins? Depends on the cases. I doubt you or Embarcadero (or me) wants to escalate this to lawyers or free software defense organizations, but if you want a definitive answer, feel free to submit the case. As I said I would be interested in the answers (and Embarcadero’s reaction for that matter)
It is obviously copy/pasted. While I agree that the algorithms involved might be pretty generic this doesn’t warrant someone the right simply copy-paste the code in.
I’ve actually done quite a few google searches using different terms taken from the method in question. I could not find any prior code except GLScene’s implementation.
Event if a book example would have been used, I don’t think it would look the same…
Also, Wayne & Johnson, XE2 Trial doesn’t include source, so I can’t check myself how close the source logic is, but in terms of high level aspects, there are high-level GLScene concepts that are found with similar logic and names, the dummy component, the camera/Target, etc. Those concepts are found in other scene graphs, sure, but often with different names and different approaches. Some of the simpler GLScene demos can be converted straight 1:1 to FireMonkey, just replace the names. That’s not something possible with other scenegraphs and 3D engines, where you would have different setups logic, behaviors, structures, etc.
In many cases I did the maths from scratch, maybe not the most efficient approach, and some of the implementations may not be up to academic canon, but hey, it was more fun that way 😉
This is why I believe that each author of code within a development team should be required to put their name into every block of code which belongs to them… that way, if someone “borrows” sources from elsewhere, you know who to hang from the highest yard-arm in the land!
It’s hard to believe that Embarcadero’s legal department would turn a blind eye to one or more of its developers stealing sources from elsewhere… so if it is true that FireMokney is a copyright-theft-Frankenstein, I have to believe that it’s the fault of one or two “rouge developers”, rather than the collective intent of EMB as a company!
Certainly, Embarcadero haven’t attempted to steal from me in our dealings! When they wanted to make use of a certain project I’ve produced (can’t say which), they licensed it from me! This is despite me making the entire thing open source in the most liberal way possible for everyone!
This matter warrants investigation and comment! The last thing Embarcadero would want to do right now is to alienate the customers (us)… especially as we’re on the verge of realizing a long-time dream of cross-platform Delphi development!
That info is there in headers & CVS/SVN history, but keep in mind GLScene takes its roots way back in the last century, if there are relatively few people that did most of the work, there have been dozens of people involved at various points in time, and GLScene portions have percolated in multiple other open & closed-source source projects. For raycasting alone, besides myself, I can remember at least two main contributers from the top of my head, you can add probably 4-5 once you factor in the “noteworthy” improvements contributions, and maybe a dozen if you list all contributions down to the code line.
At the moment, there is nothing to indicate it was done on purpose from Embarcadero’s part, signs point at KSDev’s libraries (DXScene) being a little more than just inspired from GLScene, and that having been lost/forgotten/overlooked at some point in the process.
Also it seems to hint that the FireMonkey R&D team could be either “new” to Delphi, or new to the (Delphi) 3D world (from some of the FireMonkey design choices, I’d risk a guess that it’s a bit of both).
@Eric
You can’t copyright or license math already in the public domain. You also can’t copyright or license variables names, much as you might want to. If the math was some how unique, it might be protectable, but just translating well established vector math into generic routines…
Something more complicated would have to be done here to warrent copyright or license protection. That’s all I want to see.
@C Johnson
That is not correct. What is copyrighted is not the math, but the code itself. You are confusing patents and copyright. This is a common mistake.
They could code the same thing from scratch, and it would be OK. But
they could not have used it, as they did, without authorization.