MapGuide PSC Meeting 02-08-2007

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.