MapGuide PSC Meeting 02-08-2007
Revision as of 15:01, 8 February 2007 by Wiki-Robertbray (talk | contribs)
MapGuide PSC - Home
Meeting Info
The sixth meeting of the MapGuide PSC will take place Thursday February 8th at 18:00 UTC (1:00 PM EST / 11:00 AM MST / 10:00 AM PST).
Meeting Chair: Bob Bray Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=02&day=08&year=2007&hour=18&min=0&sec=0&p1=0 Location: The meeting will be held on IRC at #mapguide
Agenda
- More CLA Topics
- Incubation Status
- Process to put a minor modification into an already approved RFC. (Tom)
Actions
- (Bob) Update CLA to clarify that it refers only to the project
- (Bob) Post Corporate CLA for Review / Motion
- (Bob) Look into DWF Toolkit License
- (Tom) Update PSC Guidelines with RFC modification process
Transcript
<rbray> First topic is CLAs. <bdechant> Hello everyone <rbray> Daniel raised a good point about it not mentioning whether it pertains to the project or the foundation. <rbray> I think that needs to be clarified in the CLA itself. Which means we will probably need to revote and recollect them. <jasonbirch> Works for me. <rbray> I don't like it because we have already collected a bunch, but I don't see any other choice. <rbray> I am also pondering the Corporate CLA. I am reviewing that with legal as well. <jasonbirch> Hmm. The new one is more specific. If the original submitters are happy with the wording, I don't really see the need to re-submit. <rbray> The foundation may have an issue with it. <rbray> Because there is nothing in it that ties the agreement to the project. It reads as though it applies to eveything in the foundation. <danmo> Did anyone from the board of the foundation comment on this CLA issue? <jasonbirch> Oh. I'd prefer to avoid that then. Have to deal with some startup pain I guess. <rbray> No but I have not raised it to the board. Maybe I should before I get carried away. <danmo> FrankW is on the mapguide-internals list so he must have seen the email pass. I wonder if he read it <rbray> Dunno. I'll ping him seperately by e-mail and cc you. <rbray> I know the board has discussed CLAs at one or more board meetings. <danmo> ok. or maybe this email can be sent to IncCom since CLA is kind of IncCom business? <rbray> Yea, I know the attitude of some projects is not to use a CLA. So I am inclined to just say our CLA needs to be project specific. <FrankW> My opinion is the same as Jason's that as long as the contributor doesn't mind the original CLA wording it is harmless. <rbray> FrankW: Should we fix it going forward, or leave it as is? <FrankW> So just fix it, and if anyone wants, let them submit a new CLA in place of the old. <rbray> Great. <FrankW> I do think you should fix it. I won't sign the old one for FDO for instance. <FrankW> (too broad) <rbray> Yes I agree. I'll have our IP lawyer fix it for me. Should have a new one for approval by weeks end. <rbray> I am reviewing the old Corporate CLA with her now and will also be posting that for review. ADSK would prefer to use one of those. <rbray> DM Solutions might as well. <rbray> Because of all this though, I was thinking of extending the deadline another week. Any objections? <jasonbirch> No, +1 <bdechant> No objection here <rbray> OK <rbray> danmo: Any new incubation issues to discuss? The incom meeting on Monday seems like the next step. <jasonbirch> Bob, what's the license on the DWF toolkit? <danmo> nothing other than the email that I sent earlier this week. All the rest seems good to go. Monday's meeting seems to be the next step, right. <FrankW> danmo / rbray: will you both be able to make the incubation meeting on monday? <rbray> jasonbirch: I am digging that up. Will post it today. <rbray> I'll be there as well. <rbray> I think it is a free use license, kind of like LGPL but not. <jasonbirch> lol <rbray> I know there are a lot of third parties using it, so it can't be something terrible. <FrankW> Is it OSI? And is the DWF toolkit distributed from OSGeo? <rbray> And our legal team cleared it when we open sourced MG. <FrankW> we have a fairly strict rule that OSGeo distributed software should be under an OSI approved open source license. <FrankW> Of course Autodesk can distribute it no problem. <rbray> I don't know if it is OSI yet, because I have not looked at it in over a year. <rbray> It's in the MG source tree, so we are distributing it in that way. <TomFukushima> License is here: http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=5522878 <sigq> Title: Autodesk - Developer Center - License and Download for DWF Toolkit 7 (at usa.autodesk.com) <FrankW> ok, if it's in the source tree then I do think the issue should be resolved (with regard to being actually OSI legit). <rbray> It is an ADSK license. Not OSI. <FrankW> I mean OSI approved. <rbray> I highly doubt it. How does a license become OSI approved? <FrankW> It is submitted to OSI and run by their lawyers with regard to the essential freedoms of the open source definition. <FrankW> Well, lets flag this for further review. I don't think it needs to hold up graduating or anything like that. <rbray> OK. Tom is this flagged in the Provinence Review? I mean the license and is the license itself in the tree? <danmo> ... or even better you pick an already approved license... but there may be good reasons why ADSK lawyers chose to build their own license instead of reusing an existing one? <TomFukushima> It's flagged: the license needs to be added to the source repository <jasonbirch> I'm a bit worried about 1.1.3: <jasonbirch> (b)The terms of sublicenses granted by Licensee must (i) contain all applicable terms of this Agreement <jasonbirch> Does that mean that the LGPL license of MapGuide is not good enough, or does including the DWF license text in the distribution cover this? <rbray> I don't know the history behind it all. <rbray> When Rich reviewed this he thought having the license text in the distro covered it. <jasonbirch> I wouldn't mind seeing DWF under a true OSI license :) <rbray> Maybe to be safe I will check with legal again, since I am having daily discussions with them anyway :) <jasonbirch> Anything else for incubation, now that I've fuinished stirring the pot? <rbray> I think that is it until Mondays incom meeting. <danmo> agreed <rbray> I'll follow up on the DWF issue on the internals list, once I learn more. <rbray> Ok, last topic on the formal agenda is RFC modifications. <rbray> Did everyone read Tom's proposal on the mail list? <jasonbirch> Oh, sure... :) <rbray> Ok before we go there (giving Jason time to read). <rbray> danmo: How does MapServer deal with changes to an RFC that arrise after it was accepted? <danmo> I don't think we have a clear policy. My opinion is that it would be fine to update the RFC with approval of the PSC until the implementation is complete and released. <FrankW> The only policy that was stated in this regard is that a complete rework of an RFC should be issued under a new #. <danmo> After the features in a RFC have been released then I don't think we should be allowed to edit a RFC, the old RFC shoudl be deprecated and a new RFC created to supercede it <jasonbirch> That kind of change should not require a new RFC. I like Tom's outline, as long as the RFC has not been flagged as completed. If it has, then a new bug task or enhancement task should be used depending on the scale of the changes. <rbray> Yea that makes a lot of sense. That is more or less what Tom is proposing. <rbray> Yea, what Tom is refering to are changes that arrise during implementation. <TomFukushima> right <jasonbirch> Sounds like we have concensus :) <rbray> That was too easy. Nice that we have a well established model to follow. :) <TomFukushima> Great! Should I put this in one of the the PSC process doc <jasonbirch> Do we vote now, or wait for modifications to the doc? <danmo> If you put that in writing in your RFC process docs then you'll be ahead of MapServer :) <jasonbirch> Process is everything, unless it gets in the way of reality... <TomFukushima> Ok, I'll put it in the process doc and then we can vote on it next week <rbray> Ok, so the question is should we modify the doc for this or just post it as a seperate RFC doc? <jasonbirch> lol. <rbray> We do have a page on RFCs somewhere... <rbray> Nevermind, lets update the doc. <jasonbirch> That was a recursive topic... <rbray> :) <bdechant> :) <jasonbirch> Wow, do we get to adjourn early? <rbray> Unless someone has additional topics? <rbray> Going once... <rbray> twice... <FrankW> wants to submit the "make mapguide work on 64bit linux rfc".... <jasonbirch> That would be awesome. <rbray> Awesome. Are you going to do the work? <FrankW> just kidding ... adjourn. <FrankW> lol <jasonbirch> No teasing :) <FrankW> Well, lets say I'm going to do a little experimenting with FDO on 64bit linux, but I'm not taking on MapGuide. <jasonbirch> How about getting sorting working in SDF ;) <rbray> Ok, lets adjourn. I'll go call my favorite folks in legal, sigh... <jasonbirch> +1. At least they aren't coming to YOU with application development questions... <rbray> FrankW: I think Traian got 32 bit MG running on 64 bit linux. <rbray> So you could check in with him. <FrankW> rbray: My aim is to be able to work natively on my desktop 64bit system, but I'll settle for being able to run fdo+gdal provider for now. <rbray> FrankW: Cool, could be the start of 64 bit MG. Let us know how it goes. <FrankW> will do - I'll comment on fdo-internals on what I find. <pagameba> FrankW ... Shawn is working on an fgs build of mapguide stuff now ... <rbray> Meeting Adjourned: Thanks everyone. <danmo> bye <FrankW> pagameba: yes, I heard that last week. It is fantastic news.