Difference between revisions of "MapGuide PSC Meeting 02-08-2007"

From OSGeo
Jump to navigation Jump to search
Line 18: Line 18:
  
 
== Transcript ==
 
== 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.

Revision as of 14:57, 8 February 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

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.
Retrieved from "http://wiki.osgeo.org/w/index.php?title=MapGuide_PSC_Meeting_02-08-2007&oldid=11491"