Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 18 Oct 2011, at 23:21, dave perry wrote: 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. Jus tot keep repeating (forever, until I have time to write the code) - don't confuse development and deployment here. The package system I'm working on includes the notion of aircraft catalogs (each an XML feed), listing aircraft. It's up to the catalog maintainer which aircraft he adds to it (or authors he allows to add to the catalog), and it's up to the end-users which catalog(s) they subscribe too. I'm also trying to force some metadata as part of this, about era / type / usage, so someone could create a '1950s Military' catalog, or alternatively use a 'all-aircraft' catalog, and then do a filter by era / class / license / rating / something else. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData Split Completed - a.k.a. Life after the Split
On 10/19/2011 10:36 AM, James Turner wrote: On 18 Oct 2011, at 23:21, dave perry wrote: 2. Assuming the answers are no, yes, to #1, will all these repositories be centrally located so one can track new or modified ac of interest? 3. Is there any interest in creating repositories by ac class/type? e.g. historical, military-fighter, military-transport, civilian-light-ac, airliners, etc. Jus tot keep repeating (forever, until I have time to write the code) - don't confuse development and deployment here. The package system I'm working on includes the notion of aircraft catalogs (each an XML feed), listing aircraft. It's up to the catalog maintainer which aircraft he adds to it (or authors he allows to add to the catalog), and it's up to the end-users which catalog(s) they subscribe too. I'm also trying to force some metadata as part of this, about era / type / usage, so someone could create a '1950s Military' catalog, or alternatively use a 'all-aircraft' catalog, and then do a filter by era / class / license / rating / something else. Hi, Is there any written spec on this system? I got frustrated when looking for a specific aircraft in fgrun :) and so I suggested something similar several days ago on IRC, but it got confused with a/c rating. If I understand you correctly, submit a/c to a catalogue would mean that the information would not be kept in the a/c data - which has its pros and cons. I rather think that the metadata should be in the a/c itself. Maybe some combination would be the best of all worlds? I think that each a/c should define: - type (SR-71B, MiG-15bis) - manufacturer / constructor (e.g. for Soviet planes) - (Grumman, Mikoyan) - nicknames and codenames (Delfin / Maya, Avenger) - year of first flight or production or some such - country of origin - role (fighter, airliner) - tags (jet, blimp, ..., movable wings, ..., WW2, ) - a bit fuzzy Also the liveries/camouflages themselves could/should define - country - civil or military - force / company - years from-to The advantage of user supplied info is that it's independent of a/c author and can be possibly more up to date, or specify categories not considered by the author - like a List of aircraft flying in the Redflag exercise. Otoh metadata specified directly by author within a/c data will be probably more accurate and authoritative, usable by offline tools like fgrun and less prone to a sudden disappearance. Any thoughts? Edheldil -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
I would need: CLtail = f(alpha_tail, delta_elevator) where alpha_tail = alpha_aircraft + horizontal_stab_angle - Epsilon We should be able to do this. Some time ago I've been told that this can be done using the speedbrake property (indeed this is the way it is done in the 747 example) as if it were the stabilizer (only a matter of names); that's OK, but I only wonder whay there is no stabilizer property, or is it? I hope this time I was more descriptive. Thanks. If you can run JSBSim in standalone mode (compiling and linking with JSBSim.cpp) then you can do this at the command line (I am assuming that the executable is in the src/ directory, as it would be in the JSBSim build tree under Linux or Cygwin): src/jsbsim --aircraft=c172x --catalog The --catalog option will give you a list of all the properties that JSBSim defines and knows about. That is separate from FlightGear-specific properties that are part of the *interface* between FlightGear and JSBSim. JSBSim does have its own elevator deflection property. I don't understand the issue with the 747 model, and (unfortunately) I don't have time to look into it at the moment. Jon - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Epsilon, alpha_tail and independent tail contributions
I would need: CLtail = f(alpha_tail, delta_elevator) where alpha_tail = alpha_aircraft + horizontal_stab_angle - Epsilon src/jsbsim --aircraft=c172x --catalog The --catalog option will give you a list of all the properties that JSBSim defines and knows about. That is separate from FlightGear-specific properties that are part of the *interface* between FlightGear and JSBSim. JSBSim does have its own elevator deflection property. I don't understand the issue with the 747 model, and (unfortunately) I don't have time to look into it at the moment. Jon I am not talking about the elevator property, but about the horizontal stabilizer (HS)property, which seems to be missing in JSBSim. In most airliners and bussiness jets there is an all-moving HS, together with the elevator (and maybe also a trim-tab). Then I would need to refer to the HS current deflection (which the pilot changes in order to trim the aircraft pitching moment) in order to calculate the tail angle of attack : alpha_ac + HS - Epsilon. Here is the relevant part of the 747.xml as defined in the aircraft subdirectory that ships with JSBSim package. 1. Note that: descriptionLift_due_to_stabilizer_deflection/description 2. But: propertyfcs/speedbrake-pos-rad/property 3. My question is: why it uses speedbrake? function name=aero/coefficient/CLs 1. See here --- descriptionLift_due_to_stabilizer_deflection/description product propertyaero/qbar-psf/property propertymetrics/Sw-sqft/property 2. and here --- propertyfcs/speedbrake-pos-rad/property table independentVarvelocities/mach/independentVar tableData 0.0.8190 0.20000.7850 0.65000.7390 0.90000.8590 /tableData /table /product /function Fabian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On 25 Jun 2011, at 22:59, Alex Perry wrote: . Does anybody know offhand how much trouble it would be for our source code to have all loaders of aircraft files go through a library that understands what a relative URL is? If we can cut that over, anybody can develop and host an airplane simply by sticking some static files on the web somewhere. Which can reference components of other airplanes. This is 'doable, but quite a bit of work'. What' I've been idly hacking up is a helper tool/library that would process aircraft catalogs (basically the first part of the -set.xml files, slurped together into one or several files, with the aircraft id, metatadata fields, thumbnail URL, a download URL, and an MD5 sum), and use that info to download aircraft from 'a backend' - the default backend being .zips on a HTTP server, but with the option to support an SVN repo, Git URL or whatever if the backend can be glued in. (So you'd have a stable version of the 744 pointing at an HTTP server, and a separate entry in the catalog, with a 'development' metadata flag set, pointing at the live Git repo, potentially - and could switch between them) (If the catalog entries encode the min- and max- compatible flightgear versions for a particular aircraft variant, this also gives us a way to keep the '2.0.0 compatible' archives available for legacy users, which I am sure they would appreciated) The tool code then does the work of fetching updated catalog XML files (eg, daily), and checking for updated version of aircraft, supporting multiple concurrent variants of aircraft, and crucially, placing the extracted/downloaded zip/Git repo in a place fgfs can find it. The reason I'm building this as a library/command line tool is, obviously the various GUI launchers might want to use it, but as Vivian pointed out, there are good reasons to be able to download/manage from inside FG - as was just proved with terrasync :) It *is* possible to go to the next step, and keep the .zip files as compressed blobs, like Java .jar files - but that means a lot more FG hacking to get the OSG file loaders and other places we load files, using a different stream backend. Entirely possible, but I'd sooner establish the core concept - aircraft are pulled as blobs from HTTP - before worrying about the niceties. Code wise, I have about 30% of this prototyped - but not at a point where it can be tested. Since it appears to be a hot topic, I am thinking i should revisit it for 2.5 :) James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.. http://p.sf.net/sfu/splunk-d2d-c1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nose strut absorber animation, anyone worked on that?
On Sunday 12 November 2006 06:21, Detlef Faber wrote: There is a property /gear/gear[0]/compression-norm (at least in yasim), you can use for that. I seem to recall seeing similar variable in JSBsim as well, but I don't have access to FlightGear right now so I cannot check. Ampere To my surprise, there is not: $ src/jsbsim --aircraft=c172x --catalog | grep gear /fdm/jsbsim/gear/gear-pos-norm /fdm/jsbsim/gear/gear-cmd-norm /fdm/jsbsim/gear/num-units /fdm/jsbsim/gear/unit/slip-angle-deg /fdm/jsbsim/gear/unit[1]/slip-angle-deg /fdm/jsbsim/gear/unit[2]/slip-angle-deg /fdm/jsbsim/gear/unit[3]/slip-angle-deg /fdm/jsbsim/gear/unit[4]/slip-angle-deg /fdm/jsbsim/gear/unit[5]/slip-angle-deg /fdm/jsbsim/forces/fbx-gear-lbs /fdm/jsbsim/forces/fby-gear-lbs /fdm/jsbsim/forces/fbz-gear-lbs /fdm/jsbsim/moments/l-gear-lbsft /fdm/jsbsim/moments/m-gear-lbsft /fdm/jsbsim/moments/n-gear-lbsft But there should be. Another one for the feature request tracker. Jon - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nose strut absorber animation, anyone worked on that?
To my surprise, there is not: $ src/jsbsim --aircraft=c172x --catalog | grep gear /fdm/jsbsim/gear/gear-pos-norm /fdm/jsbsim/gear/gear-cmd-norm /fdm/jsbsim/gear/num-units /fdm/jsbsim/gear/unit/slip-angle-deg /fdm/jsbsim/gear/unit[1]/slip-angle-deg /fdm/jsbsim/gear/unit[2]/slip-angle-deg /fdm/jsbsim/gear/unit[3]/slip-angle-deg /fdm/jsbsim/gear/unit[4]/slip-angle-deg /fdm/jsbsim/gear/unit[5]/slip-angle-deg /fdm/jsbsim/forces/fbx-gear-lbs /fdm/jsbsim/forces/fby-gear-lbs /fdm/jsbsim/forces/fbz-gear-lbs /fdm/jsbsim/moments/l-gear-lbsft /fdm/jsbsim/moments/m-gear-lbsft /fdm/jsbsim/moments/n-gear-lbsft But there should be. Another one for the feature request tracker. Jon I've found (and used) /gear/gear[0]/compression-norm . What should the difference to /fdm/jsbsim/gear/compression-norm be? Roberto - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 12/31/2008 06:23 AM, James Turner wrote: Reckons 5 degrees per-dot for a VOR, 1.25 for a LOC (yay, the 4x factor is sane) and 'about a quarter of a degree per dot' for a GS indicator, so the 0.32 term is plausible. Standard dogma in IFR training is that the VOR CDI indicates two degrees per dot, while the LOC CDI indicates half a degree per dot. These numbers are quite believable. Good practice is to check them as part of the 30-day IFR receiver check. Experience suggests that a better way to think about it is in terms of _full scale_. The pilot sees ±10 degrees full scale on a VOR and ±2.5 degrees full scale on a localizer. That's because talking about degrees per dot doesn't work too well for RNAV units, which display cross-track error with dimensions of distance, not dimensions of angle. Again the sensitivity is greater on approach than enroute. http://www.avweb.com/news/system/183179-1.html But even if we confine attention to VORs, the vast majority of CDIs have ± 5 dots full scale (or a ring and four dots, which comes to the same thing) ... so 10 degrees full scale is equivalent to 2 degrees per dot: www.psavionics.com/images/KI208hi.png www.psavionics.com/images/ki209hi.gif http://www.auf.asn.au/navimages/vor.jpg http://www.knappair.com/N4792CHSI.jpg http://www.aircraftspruce.com/catalog/graphics/11-05106.gif And meanwhile some instruments VERY EXCEPTIONALLY have fewer dots http://www.aircraftmech.com/pics/nd1.gif which would mean MORE degrees per dot. I suspect there may be some CDIs with 6 dots full scale, but I can't cite any examples at the moment. As to the magic 5 fudge factor, I have no idea what purpose that serves. It is *not* meant to create 10 volts full scale or anything like that, because the industry standard is ±150 millivolts full scale. http://www.seaerospace.com/lc/cart.php?target=productDetailsmodel=GNS-530substring=011-00550-10 I'd be happy to consider alternatives to the magic 5 : One could make a case for *) ±1.0 full scale, for obvious reasons, or *) ±0.150 full scale i.e. ±0.150 _volts_ to model the real world *) ±10.0 full scale, just to avoid changing things that don't absolutely need to be changed. == Before diving into navradio.cxx, I suggest you take a look at http://www.av8n.com/fly/fgfs/servol.diff which fixes the worst of the service volume silliness. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Hi, ..my apologies to [EMAIL PROTECTED] for the FlightGear top-mix posts fw'd and cc'd to you, FlightGear strives to be multi-platform. ;o) On Fri, 21 Nov 2008 06:02:06 +0100, Arnt wrote in message [EMAIL PROTECTED]: On Thu, 20 Nov 2008 22:37:18 -0500, Matthew wrote in message [EMAIL PROTECTED]: Unfortunately, the GPL doesn't account for emotion. For those who have met RMS, interpersonal relationships don't really fit... Certain rights are gained, others are given up. The best we can hope for is that they are interested in being a part of a community, the worst we should expect is that they add no value and sell it as a package. ..in this case I think we have an excellent opportunity to stand up for the GPL by enforcing it, copyright law and criminal law. ;o) ..FG is still GPLv2? That means these people will need _explicit_ permission from _each_ copyright owner, _if_ there has been _any_ violation of the license. ..absent such explicit permission from _any_ copyright owner, his or her no longer permitted code must be removed, and the vendor's binaries must be recompiled to exclude that forbidden code. ..the GPLv3 is a bit more lenient right there, ;o) the bad guys are forgiven under the GPLv3 once they become _good_ guys by _complying_. ;o) ..fwiw, I ran wget -m -l0 http://idbproductions.com/catalog/ too: ;o) FINISHED --2008-11-21 07:09:33-- Downloaded: 4624 files, 169M in 52m 37s (54.7 KB/s) I don't believe that FG I structured in a way to be able to receive funds as an organization, and consequently we can only hope that they will be a good community member and sponsor and assist where they can. If people want me to slueth around and find some more info and ..by all means go ahead. ;o) possibly reach out, please advise. ..me, I find this rather instructive: ;o) http://gpl-violations.org/faq/legal-faq.html ..here I'd like the copyright owners to weigh in, me, I recommend hiring a lawyer for this job, to make sure we get it _right_. ;o) ..given http://www.idbproductions.com/Products/ and http://idbproductions.com/catalog/ this is _not_ just us, so I'd have Harald Welte and the guys at http://gpl-violations.org/ weigh in with advice on how to proceed. I cc this there. ..playing with dig, jwhois and a web browser and the names I find, it's _amazing_ how I get thrown back to: http://idbproductions.com/catalog/ ;o) Regards... Matthew On 11/20/08, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Hi, For clarifying my position, I don't care if they sell flightfear. But I do care if that affects our project in either technically or emotionally. According to some threads or posts in the list and the forum, it seems that many developers and users do not like the current situation. I guess the problem is they don't make any communication with us including contribution. I do welcome some third parties sell flightgear if they are friendly and hopefully make a contribution. Needless to say they need to observe the GPL thingies. You can pack everything into either DVD or thumb drive and sell it as long as it doesn't brake any legal issue. But... For me it's more on human relation issue. As long as they are friendly and actively open to us, then we can collaborate and make flightfear better from both open source and bussiness aspects. I think there is still much room in improving the usability, functionality, and quality of flightgear. If marchants can collect such needs and give some offers and feedback (preferably in implementation, but just an idea is OK) to flightgear community, that'll be super good. Look forward to seeing reply from them, Tat p.s. Sorry for full quote. I'm writing on iPhone. this fun tool is missing copy-past and cut-paste things. On Nov 21, 2008, at 10:16 AM, Matthew Tippett [EMAIL PROTECTED] wrote: One thing to be *very* careful of is assuming that flightgear has some absolute right to control what happens downstream. If this company is honoring it's responsibilities under the GPL, there is nothing that the FG community can do to prevent it happening. The GPL enshrines those rights to the recipient, and by extension you give up the right of control as an author when you allow code to be distributed under the GPL. The main thing that the GPL prevents is 'flightsimpro' creating a flightsim that has unique features and linking it into the the main binary and preventing the release of that. But if the developer is keeping their stuff separate (say an advanced-clean room implementation of terrasync using different scenery, or a bridge to a different flight sim network), again they have done nothing wrong by the GPL (distribution of aggregations is a confusing area). Contact with this company would clarify most of this quickly
Re: [Flightgear-devel] Dots, degrees and magic '5's
On 01/03/2009 06:58 AM, James Turner wrote: - everyone seems agreed that the GS is a 1.4 degree volume, so 0.7 degrees above and below the GS line. I concur. And the '0.35' degrees per dot comes up, which basically implies 2 dots from the center line to the 0.7 degree limit. Sorry, no. Here's a counterexample: http://www.aircraftspruce.com/catalog/graphics/11-05106.gif Referring back to the ICAO docs that John Denker posted, and the Mk-VIII manual, which says 0.0875 DDM per dot on the GS, and the ICAO docs say the GS 'sector' is 0.175, and the half- sector is 0.0875. Please let's not confuse ICAO (which is quite general) with Mk-VIII (which is just one instrument). I.e two 'dots' would be the very edge of the sector (0.175 DDM). This is important because the 'soft' alert limit is defined as 1.3 dots, and the hard limit is 2 dots. Which again makes sense, and brings us back to the fact that most high-end GS indicators (Primus, Honeywell/ Boeing) use two dots either side for the indicator. Please let's write code that works for all instruments, not most instruments or most high-end instruments. So my inclination is to add the degrees deviation properties as discussed, and to avoid 'dots' in the navradio code, Yes, dots are to be avoided. Anything involving dots is just begging to be misunderstood. While we're on the subject: It is good practice to spell out what is meant by full scale. It could be either center-to-side or side-to-side. (I've made this mistake myself :-) Talking about 1.4 degrees full sector (peg to peg) seems reasonably convenient and unambiguous. Also talking about an interval in the form [0 ± 0.7] is unambiguous. but to add - ddm properties. DDM? I can't imagine why anyone would want to mess with that level of detail. Deflection as a fraction of full sector is all any Sim World instrument designer needs. Maybe once in ten years somebody should check that the full-sector width is what we think it is, but that's been done now. Obviously I won't touch the existing 'deflection' properties, but I hope over time they'll rot. I think they're just fine. I don't see any need for additional complexity. If it ain't broke, don't fix it. For the Mk-VIII, I'll convert to 'dots' using the terms defined in the INSTALL manual, which of course match the ICAO 'half-sector' values exactly. Since the deflection values are exact, why not use them? I'm not sure where all of this leaves Syd, or other panel designers. Working in DDM seems a little awkward, Agreed, awkward and unnecessary. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
On Thu, 20 Nov 2008 22:37:18 -0500, Matthew wrote in message [EMAIL PROTECTED]: Unfortunately, the GPL doesn't account for emotion. For those who have met RMS, interpersonal relationships don't really fit... Certain rights are gained, others are given up. The best we can hope for is that they are interested in being a part of a community, the worst we should expect is that they add no value and sell it as a package. ..in this case I think we have an excellent opportunity to stand up for the GPL by enforcing it, copyright law and criminal law. ;o) I don't believe that FG I structured in a way to be able to receive funds as an organization, and consequently we can only hope that they will be a good community member and sponsor and assist where they can. If people want me to slueth around and find some more info and ..by all means go ahead. ;o) possibly reach out, please advise. ..here I'd like the copyright owners to weigh in, me, I recommend hiring a lawyer for this job, to make sure we get it _right_. ;o) ..given http://www.idbproductions.com/Products/ and http://idbproductions.com/catalog/ this is _not_ just us, so I'd have Harald Welte and the guys at http://gpl-violations.org/ weigh in with advice on how to proceed. I cc this there. ..playing with dig, jwhois and a web browser and the names I find, it's _amazing_ how I get thrown back to: http://idbproductions.com/catalog/ ;o) Regards... Matthew On 11/20/08, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Hi, For clarifying my position, I don't care if they sell flightfear. But I do care if that affects our project in either technically or emotionally. According to some threads or posts in the list and the forum, it seems that many developers and users do not like the current situation. I guess the problem is they don't make any communication with us including contribution. I do welcome some third parties sell flightgear if they are friendly and hopefully make a contribution. Needless to say they need to observe the GPL thingies. You can pack everything into either DVD or thumb drive and sell it as long as it doesn't brake any legal issue. But... For me it's more on human relation issue. As long as they are friendly and actively open to us, then we can collaborate and make flightfear better from both open source and bussiness aspects. I think there is still much room in improving the usability, functionality, and quality of flightgear. If marchants can collect such needs and give some offers and feedback (preferably in implementation, but just an idea is OK) to flightgear community, that'll be super good. Look forward to seeing reply from them, Tat p.s. Sorry for full quote. I'm writing on iPhone. this fun tool is missing copy-past and cut-paste things. On Nov 21, 2008, at 10:16 AM, Matthew Tippett [EMAIL PROTECTED] wrote: One thing to be *very* careful of is assuming that flightgear has some absolute right to control what happens downstream. If this company is honoring it's responsibilities under the GPL, there is nothing that the FG community can do to prevent it happening. The GPL enshrines those rights to the recipient, and by extension you give up the right of control as an author when you allow code to be distributed under the GPL. The main thing that the GPL prevents is 'flightsimpro' creating a flightsim that has unique features and linking it into the the main binary and preventing the release of that. But if the developer is keeping their stuff separate (say an advanced-clean room implementation of terrasync using different scenery, or a bridge to a different flight sim network), again they have done nothing wrong by the GPL (distribution of aggregations is a confusing area). Contact with this company would clarify most of this quickly. (A parasite isn't always violating the GPL - a lot of X and kernel developers call Ubuntu a parasite since they don't contribute a proportional amount upstream.) Regards... Matthew On 11/20/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- On Thu, 20/11/08, Curtis Olson wrote: Someone pointed out this site to me. It probably falls into the category of just barely ok, but I thought I'd post the link here to get some more eyes on it. http://flight-aviator.com/ One way to discourage this sort of thing would be to include www.flightgear.org prominently in the startup screens, in the same way that we include initializing sub-systems, initializing scenery. Possibly with an added message along the lines of Welcome to FlightGear, the free open source flight simulator. That would force the rip-off merchants to at least compile the code, rather than simply replacing some .pngs! -Stuart --- --- --- This SF.Net email is sponsored
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Still, the question is if this company is violating the GPL. We have no proof of that. (The gpl-violations.org guys go after people who are not honoring the release of source for both distributed and derived works - typically in embedded systems. Usually they settle when the company honors the GPL and provides source or stops distributing the offending product.) At this stage it appears that they are simply selling a binary distribution of a set of OSS applications. As mentioned before, ethics or questionable business practices aside, we need to focus on what they are actually violating. Even the wikipedia screen shots are licensed under the GPL can be re-used freely. Regards... Matthew On 11/21/08, Arnt Karlsen [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2008 22:37:18 -0500, Matthew wrote in message [EMAIL PROTECTED]: Unfortunately, the GPL doesn't account for emotion. For those who have met RMS, interpersonal relationships don't really fit... Certain rights are gained, others are given up. The best we can hope for is that they are interested in being a part of a community, the worst we should expect is that they add no value and sell it as a package. ..in this case I think we have an excellent opportunity to stand up for the GPL by enforcing it, copyright law and criminal law. ;o) I don't believe that FG I structured in a way to be able to receive funds as an organization, and consequently we can only hope that they will be a good community member and sponsor and assist where they can. If people want me to slueth around and find some more info and ..by all means go ahead. ;o) possibly reach out, please advise. ..here I'd like the copyright owners to weigh in, me, I recommend hiring a lawyer for this job, to make sure we get it _right_. ;o) ..given http://www.idbproductions.com/Products/ and http://idbproductions.com/catalog/ this is _not_ just us, so I'd have Harald Welte and the guys at http://gpl-violations.org/ weigh in with advice on how to proceed. I cc this there. ..playing with dig, jwhois and a web browser and the names I find, it's _amazing_ how I get thrown back to: http://idbproductions.com/catalog/ ;o) Regards... Matthew On 11/20/08, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Hi, For clarifying my position, I don't care if they sell flightfear. But I do care if that affects our project in either technically or emotionally. According to some threads or posts in the list and the forum, it seems that many developers and users do not like the current situation. I guess the problem is they don't make any communication with us including contribution. I do welcome some third parties sell flightgear if they are friendly and hopefully make a contribution. Needless to say they need to observe the GPL thingies. You can pack everything into either DVD or thumb drive and sell it as long as it doesn't brake any legal issue. But... For me it's more on human relation issue. As long as they are friendly and actively open to us, then we can collaborate and make flightfear better from both open source and bussiness aspects. I think there is still much room in improving the usability, functionality, and quality of flightgear. If marchants can collect such needs and give some offers and feedback (preferably in implementation, but just an idea is OK) to flightgear community, that'll be super good. Look forward to seeing reply from them, Tat p.s. Sorry for full quote. I'm writing on iPhone. this fun tool is missing copy-past and cut-paste things. On Nov 21, 2008, at 10:16 AM, Matthew Tippett [EMAIL PROTECTED] wrote: One thing to be *very* careful of is assuming that flightgear has some absolute right to control what happens downstream. If this company is honoring it's responsibilities under the GPL, there is nothing that the FG community can do to prevent it happening. The GPL enshrines those rights to the recipient, and by extension you give up the right of control as an author when you allow code to be distributed under the GPL. The main thing that the GPL prevents is 'flightsimpro' creating a flightsim that has unique features and linking it into the the main binary and preventing the release of that. But if the developer is keeping their stuff separate (say an advanced-clean room implementation of terrasync using different scenery, or a bridge to a different flight sim network), again they have done nothing wrong by the GPL (distribution of aggregations is a confusing area). Contact with this company would clarify most of this quickly. (A parasite isn't always violating the GPL - a lot of X and kernel developers call Ubuntu a parasite since they don't contribute a proportional amount upstream.) Regards... Matthew On 11/20/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- On Thu, 20/11/08, Curtis Olson wrote: Someone pointed
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
On Thu, 20 Nov 2008 20:11:27 -0700, Ron wrote in message [EMAIL PROTECTED]: On Thu, 2008-11-20 at 15:43 -0600, Curtis Olson wrote: Someone pointed out this site to me. It probably falls into the category of just barely ok, but I thought I'd post the link here to get some more eyes on it. http://flight-aviator.com/ Best regards, Curt. -- http://www.idbproductions.com/Products/FlightProSim/original/FlightGear% 20Flight%20Simulator.htm They're mirroring the home page for us... ..how nice. ;o) And it's not only us: http://idbproductions.com/catalog/ and http://www.idbproductions.com/Products/ ... I shall be _really_ intrigued to hear _this_ story. ;o) ..and I think this story belongs here http://groklaw.net/ and here: http://gpl-violations.org/mailinglists.html . ..same people: [EMAIL PROTECTED]:~/0a16 $ jwhois idbproductions.com [Querying whois.verisign-grs.com] [Redirected to whois.godaddy.com] [Querying whois.godaddy.com] [whois.godaddy.com] The data contained in GoDaddy.com, Inc.'s WhoIs database, while believed by the company to be reliable, is provided as is with no guarantee or warranties regarding its accuracy. This information is provided for the sole purpose of assisting you in obtaining information about domain name registration records. Any use of this data for any other purpose is expressly forbidden without the prior written permission of GoDaddy.com, Inc. By submitting an inquiry, you agree to these terms of usage and limitations of warranty. In particular, you agree not to use this data to allow, enable, or otherwise make possible, dissemination or collection of this data, in part or in its entirety, for any purpose, such as the transmission of unsolicited advertising and and solicitations of any kind, including spam. You further agree not to use this data to enable high volume, automated or robotic electronic processes designed to collect or compile this data for any purpose, including mining this data for your own personal or commercial purposes. Please note: the registrant of the domain name is specified in the registrant field. In most cases, GoDaddy.com, Inc. is not the registrant of domain names listed in this database. Registrant: KcKpers Ltd 5a Jasmine place Wigram Christchurch, Canterbury 8004 New Zealand Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) Domain Name: IDBPRODUCTIONS.COM Created on: 27-Aug-07 Expires on: 28-Aug-10 Last Updated on: 27-Aug-07 Administrative Contact: Casey, Andrew [EMAIL PROTECTED] KcKpers Ltd 5a Jasmine place Wigram Christchurch, Canterbury 8004 New Zealand 0211863057 Fax -- Technical Contact: Casey, Andrew [EMAIL PROTECTED] KcKpers Ltd 5a Jasmine place Wigram Christchurch, Canterbury 8004 New Zealand 0211863057 Fax -- Domain servers in listed order: NS1.SWIFTCO.NET NS2.SWIFTCO.NET [EMAIL PROTECTED]:~/0a16 $ [EMAIL PROTECTED]:~/0a16 $ jwhois flight-aviator.com [Cached] [whois.godaddy.com] The data contained in GoDaddy.com, Inc.'s WhoIs database, while believed by the company to be reliable, is provided as is with no guarantee or warranties regarding its accuracy. This information is provided for the sole purpose of assisting you in obtaining information about domain name registration records. Any use of this data for any other purpose is expressly forbidden without the prior written permission of GoDaddy.com, Inc. By submitting an inquiry, you agree to these terms of usage and limitations of warranty. In particular, you agree not to use this data to allow, enable, or otherwise make possible, dissemination or collection of this data, in part or in its entirety, for any purpose, such as the transmission of unsolicited advertising and and solicitations of any kind, including spam. You further agree not to use this data to enable high volume, automated or robotic electronic processes designed to collect or compile this data for any purpose, including mining this data for your own personal or commercial purposes. Please note: the registrant of the domain name is specified in the registrant field. In most cases, GoDaddy.com, Inc. is not the registrant of domain names listed in this database. Registrant: KcKpers Ltd 5a Jasmine place Wigram Christchurch, Canterbury 8004 New Zealand Registered through: GoDaddy.com, Inc. (http://www.godaddy.com) Domain Name: FLIGHT-AVIATOR.COM Created on: 25-Aug-08 Expires on: 26-Aug-10 Last Updated on: 25-Aug-08 Administrative Contact: Casey, Andrew [EMAIL PROTECTED] KcKpers Ltd 5a Jasmine place Wigram Christchurch, Canterbury 8004 New Zealand (021) 186-3057 Fax -- Technical Contact: Casey, Andrew [EMAIL PROTECTED] KcKpers Ltd 5a Jasmine place Wigram Christchurch
