From: Earnie <ea...@us...> - 2010-06-30 13:12:50
|
Conan Kudo (ニール・ゴンパ) wrote: > > Git also has the capability of acting like a CVS or SVN server. > Additionally, has anyone actually asked about them moving to Git or > something? > IDK, but sourceware.org itself hosts git repositories http://sourceware.org/git/ but Cygwin isn't one of them. I don't know what the stance is for Cygwin and git. -- Earnie -- http://www.for-my-kids.com |
From: Erwin W. <wat...@xs...> - 2010-06-30 14:33:24
|
Op 30-06-10 14:11, Earnie schreef: > >> I don't know what "git conversion scripts" you mean, but if it's just >> about using git with additional CVS-like and SVN-like interfaces, it >> sounds like a great plan to me. >> >> > > Git provides scripts to checkout repositories from CVS or SVN and create > a local git repository for your work. Then when you're ready to create > a patch git will diff against the official repository so that the > maintainers can apply the patch to the official VCS of choice or if > you're a maintainer preferring git you can push the changes to the > official VCS of choice. I have yet to try this method. > > So if the repository is SVN, you can choose between clients SVN or GIT. This is a non-issue. The question is what VCS format should be used for the repository when Mingw and Mingw64 merge. Erwin |
From: Earnie <ea...@us...> - 2010-06-30 18:48:27
|
Erwin Waterlander wrote: > > The question is what VCS format should be used for the repository when > Mingw and Mingw64 merge. > That depends primarily on Cygwin but those maintainers have agreed in the past to break out the MinGW runtime and W32API into a separate project on sourceware.org. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2010-07-02 04:37:36
|
On 6/30/2010 10:33 AM, Erwin Waterlander wrote: > The question is what VCS format should be used for the repository when > Mingw and Mingw64 merge. Honestly, guys, I don't see any official merge between mingw.org and mingw64. And, I don't think either team, or their users, really want that -- the two projects are *different*. For one thing, the contents of mingw.org's (but actually hosted by sourceware/cygwin) src/winsup/mingw/ are VERY different than the contents of mingw64's crt/. The contents of mingw.org's (but actually hosted by sourceware/cygwin) src/winsup/w32api are organized quite differently than mingw64's include/. Even if mingw.org was able to import a lot of the advancements achieved by mingw64, we'd have to modify them to fit *our* codes' structure and arrangement; it wouldn't ever be a copy-n-paste. (And surely vice versa, as well). Also, mingw.org has pretty much settled on using dw2 exception handling, NOT sjlj. This is ok for 32bit (but means we *can't* support 64bit that way). Also, another drawback of our choice is the inability to throw exceptions in functions passed as callbacks to "foreign" frames -- like Win32 functions. OTOH, dw2 is MUCH faster -- if you don't need the capabilities above. For one example, I've heard that gcc java is *painfully* slow using sjlj, but at least tolerable using dw2. These differences probably won't be going away. But... That's. Okay. I think the best thing would be a greater sense of cooperation between two projects that serve different user communities and fill different niches. But...don't hold your breath waiting for mingw.org's VCS and mingw64's to "merge". And certainly don't predicate any decision on what VCS mingw.org "ought to" switch to, based on some hypothetical future condition that is 99.40% certain to never occur. -- Chuck |
From: Stefano S. <ste...@po...> - 2010-06-30 16:26:47
|
On date Tuesday 2010-06-29 12:09:55 -0400, Earnie wrote: > Jasper Horn wrote: > > > > - mingw.org uses cvs while mingw64 uses svn (complicated by the fact > > that mingw.org has the requirement of self-containment, so the used > > version control client should be available as an msys package) > > > > There is no complication presented by self-containment. You can use a > windows native application with MSYS as long as you that client allows > you to save the files with \n rather than \r\n line endings and you > cannot use RXVT with MSYS because of pty emulation issues. > > The issue of which VCS to use is one of "why create work when what we > have now works" scenario. We can could have easily changed to SVN and > then to GIT and then to Mercurial and then to the zumpdilitious flavor > of the month VCS but we chose not to. My main problem with cvs is that I don't know how to properly use it (as most "young" programmers) neither I am motivated into using/learning it, and indeed I find it painful to deal with it, especially now that I'm accustomed to the facilities provided by git. That means that potential new contributors may be discouraged to contribute to the project, as that would imply the use/knowledge of a tool which is awkward to them. I know that is possible to use git even with the current repo scenario (as someone published a git clone of the current cvs repo IIRC), but that's another hoop you have to go through which is increasing (although slightly) the entrance cost. My 2€cents. |
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-30 16:43:12
|
On Wed, Jun 30, 2010 at 11:25 AM, Stefano Sabatini < ste...@po...> wrote: > On date Tuesday 2010-06-29 12:09:55 -0400, Earnie wrote: > > Jasper Horn wrote: > > > > > > - mingw.org uses cvs while mingw64 uses svn (complicated by the fact > > > that mingw.org has the requirement of self-containment, so the used > > > version control client should be available as an msys package) > > > > > > > There is no complication presented by self-containment. You can use a > > windows native application with MSYS as long as you that client allows > > you to save the files with \n rather than \r\n line endings and you > > cannot use RXVT with MSYS because of pty emulation issues. > > > > The issue of which VCS to use is one of "why create work when what we > > have now works" scenario. We can could have easily changed to SVN and > > then to GIT and then to Mercurial and then to the zumpdilitious flavor > > of the month VCS but we chose not to. > > My main problem with cvs is that I don't know how to properly use it > (as most "young" programmers) neither I am motivated into > using/learning it, and indeed I find it painful to deal with it, > especially now that I'm accustomed to the facilities provided by git. > > That means that potential new contributors may be discouraged to > contribute to the project, as that would imply the use/knowledge of a > tool which is awkward to them. > > I know that is possible to use git even with the current repo scenario > (as someone published a git clone of the current cvs repo IIRC), but > that's another hoop you have to go through which is increasing > (although slightly) the entrance cost. > > My 2€cents. > > Additionally, self-containment with git should not be a big problem. Git for Windows is already in an msys package, perhaps talking to the msysgit developers and getting them to merge in their work into mainline msys would be a good idea? And for those that want to use CVS or SVN, git provides support for the protocols so CVS and SVN clients can connect to git servers. Quite frankly, I'm not willing to deal with CVS, at all. I can deal with git or even SVN, but I will not deal with CVS. I went through that before with a few other projects and I'm not doing it again, now that better stuff is out there. I'd support a move to git since that probably would be the easiest path to maintain MinGW's need for "self-containment". And if sourceware.org has a git system, perhaps you should just ask for the CVS repo to be migrated to git. Since cygwin is a Unix environment, I have no doubt they've already got git available for cygwin. After all, it seems git has become ridiculously popular nowadays. |
From: Earnie <ea...@us...> - 2010-06-30 18:45:27
|
Stefano Sabatini wrote: > > My main problem with cvs is that I don't know how to properly use it > (as most "young" programmers) neither I am motivated into > using/learning it, and indeed I find it painful to deal with it, > especially now that I'm accustomed to the facilities provided by git. > Oh, hell, who hasn't had to learn something new once in a while. This industry changes every time the wind blows and if you can learn new things you'll be stuck using the same old thing and even old things can be new to those who haven't used them. Legacy systems and code will live on forever. There will always be CVS, you don't believe me, then take a look back to the Y2K work that corporations and open source communities spent many man hours to give a warm fuzzy for. Yes, the newer systems are good to use but so are the older ones. > That means that potential new contributors may be discouraged to > contribute to the project, as that would imply the use/knowledge of a > tool which is awkward to them. > I'm tired of this attitude. Those discouraged from learning something different will never get far in this industry. Not every project will use the same systems or coding. Not every project will use C or C++, some may be just UNIX scripting or maybe it is Windows scripting or maybe both. You may use Java or Ada or Fortran or COBOL or RPG or D or whatever flavor of "high level" programming language fits the project specs or maybe even assembler. If you as a programmer are not flexible enough to learn on the fly the needs for the project then you will not be able to contribute to the project, regardless of what the project is. > I know that is possible to use git even with the current repo scenario > (as someone published a git clone of the current cvs repo IIRC), but > that's another hoop you have to go through which is increasing > (although slightly) the entrance cost. And the problem of these forked source repositories is one of synchronization. For one reason or another it will become out-of-sync and cause issues with patches that should be created from the master repository. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2010-06-26 01:49:13
|
[speaking for myself, and not the mingw team; this is a highly personalized and probably biased summary from my own perspective; etc etc etc] On 6/25/2010 2:45 PM, Conan Kudo (ニール・ゴンパ) wrote: > Perhaps the problem isn't them, but the MinGW project instead. Perhaps > the MinGW project should offer 64-bit support in addition to 32-bit > support. There's no use getting angry about project choosing to use a > different MinGW distribution because of a deficiency in the MinGW project. There could be something to what you say. We took a huge hit when Danny left. Eventually, that hole was temporarily filled by Aaron, and now by Cesar. But it took a while to get there. Further, there were some choices made back in the 3.4.x days, which turned out in retrospect to be poor ones. Specifically the major hack to support "C++ exceptions across dlls" -- and the decision to NOT port that hack forward to gcc-4.x. This decision was one of the things that delayed work on mingw-gcc-4.x for so long -- to the point that TDM's releases DO include a version of that old hack. (The "Right Thing To Do" is to use shared libgcc -- which wasn't possible until relatively recently. However, many people don't like that, so the hack is still necessary for C++,exceptions,DLLs,static-libgcc. And since "official" mingw-gcc-4.x doesn't include that hack, this can't be done with "official" mingw-gcc-4.x. But the REAL problem -- 64 bit support -- is somewhat religious in nature. The mingw team feels strongly that the runtime library and SDK (headers and such) MUST be completely public domain, developed entirely from publicly available documentation and NEVER, EVER, contain anything copied from the Windows SDK. This is because those Windows SDK files are copyrighted by MS, and are released under a restrictive license (take a look at license\license.html in your SDK installation sometime). Therefore, we can't copy their copyrighted stuff, stick it in our w32api headers, and pretend the result is "public domain". The mingw64 team is, IMO, somewhat less...doctrinaire in their compliance with those restrictions. Hence, their version of the w32api headers, and link libraries, are more complete than ours especially with regards to items necessary for 64bit support. Note that I am NOT accusing the mingw64 guys of anything untoward; merely that they don't appear to insist on a pointer to public documentation when accepting new contributions to their version of w32api. With a lower barrier for contributions...and a greater need for lots of new (64bit) stuff...their version has progressed faster. Now, there is an argument to be made -- especially under the 2001 Consent Decree http://en.wikipedia.org/wiki/United_States_v._Microsoft#Settlement that if MS publishes certain APIs only in header form, and does not provide explicit documentation, then MS is obligated to allow a technical violation of their copyright on those headers (e.g. by "somebody" copying those APIs into "other" headers) in order to abide by the Consent Decree governing interoperability. But. I am not a lawyer. You are not a lawyer. And nobody around here is paying any lawyers on behalf of mingw.org. So...we choose to play it safe. mingw64 chooses a somewhat looser path. But, because of these differences -- religious, or legal, or whatever -- there is a split between mingw.org and mingw64. Until (a) mingw.org agrees with mingw64 about the propriety of accepting API information with provenance OTHER than msdn documentation, or (b) somebody does the legwork of locating publicly available documentation describing all of the mingw64 w32api and runtime changes, so that we can merge it into mingw.org's code...nothing will change, and mingw.org and mingw64 will differ, and mingw.org won't have 64bit support. Side note, sure to cause heartburn, angst, wailing, and miscellaneous swearing: it is possible that mingw64 is better positioned on this issue than we are. It appears that fedora-cross is using the mingw64 releases -- and the fedora project is more zealous about license compliance than anybody but debian, AND they have the $$$ to pay for lawyers to make sure every thing is kosher. If mingw64's approach is good enough for fedora... So...that's the nature of the mingw/mingw64 divergence. The TDM fork was started in frustration during the long hiatus between Danny's departure and Aaron/Cesar's "arrival". However, TDM's ports differ in the following ways: 1) They include the old 3.4-era hack for C++ exceptions across DLLs when linking with static libgcc. It is doubtful that mingw.org will ever do so. 2) TDM provides both "dw2" and "sjlj" exception handling for 32bits -- and actually recommends the slower, sjlj version. mingw.org's releases use dw2 because it is (much) faster, but there are drawbacks even for 32bit code. mingw64 uses sjlj because dw2 doesn't work in 64bit mode; TDM's 64bit compiler is similarly sjlj-only. So, you've basically got three different primary sources of gcc-for-windows compilers. Then, there are all the (slightly different) cross compiler toolkits out there, including Fedora's version and OpenSuse's version. Mandriva has one, too, I think. Each of them are likely derived from one (or some combination) of the three "primary" sources. Kinda. 'Cause when you get right down to it, most of mingw.org's "version", AND the mingw64 version, are straight from gcc.org's svn repo. There's only a little external patching done by either project; we both try to get our 'stuff' upstream. It's just that "theirs" in compiled with --build=mingw64, and "ours" with --build=mingw32 (or something to that effect). Actually, I believe TDM's releases are more heavily patched than either of the other two. It's a mess, but I really don't see how to reconcile the issues. -- Chuck |
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-26 05:06:47
|
I see, I do have a problem with one thing, though. On Fri, Jun 25, 2010 at 8:40 PM, Charles Wilson < cwi...@us...> wrote: > The mingw team feels strongly that the runtime library and SDK (headers > and such) MUST be completely public domain, developed entirely from > publicly available documentation and NEVER, EVER, contain anything > copied from the Windows SDK. This is because those Windows SDK files > are copyrighted by MS, and are released under a restrictive license > (take a look at license\license.html in your SDK installation sometime). > Therefore, we can't copy their copyrighted stuff, stick it in our > w32api headers, and pretend the result is "public domain". > > > The mingw64 team is, IMO, somewhat less...doctrinaire in their > compliance with those restrictions. Hence, their version of the w32api > headers, and link libraries, are more complete than ours especially with > regards to items necessary for 64bit support. Note that I am NOT > accusing the mingw64 guys of anything untoward; merely that they don't > appear to insist on a pointer to public documentation when accepting new > contributions to their version of w32api. With a lower barrier for > contributions...and a greater need for lots of new (64bit) stuff...their > version has progressed faster. > > Many countries in Europe have made it illegal to make anything "Public Domain" and use anything under "Public Domain" because "Public Domain" disclaims ALL rights, including moral ones. Two big examples I know of are France and Germany. Public Domain code makes lawyers nervous because Public Domain is handled differently in each country that even allows it in the first place. The MinGW64 team actually probably made the smart decision not to stick with public domain, because that allowed them to be legally usable in countries that prohibit Public Domain. This is probably also why MinGW64 is advancing further than regular MinGW, and this is almost certainly why distros choose MinGW64 for their Windows cross compilers over MinGW. |
From: NightStrike <nig...@gm...> - 2010-06-26 05:38:54
|
2010/6/26 Conan Kudo (ニール・ゴンパ) <ngo...@gm...>: > This is probably also why MinGW64 is advancing further than regular MinGW, > and this is almost certainly why distros choose MinGW64 for their Windows > cross compilers over MinGW. The biggest reason is not that. Licensing plays a role, but above all, it's how we support our users. We are cordial, polite, and respectful, even in the face of the opposite. Everyone across the board says some derivation of the same thing -- We like you better because you work with us. People in general rarely remember things you say to them (engineering types will of course remember more than average). But people always remember how you made them feel. |
From: Charles W. <cwi...@us...> - 2010-06-26 15:43:37
|
On 6/26/2010 1:38 AM, NightStrike wrote: > 2010/6/26 Conan Kudo (ニール・ゴンパ) >> This is probably also why MinGW64 is advancing further than regular MinGW, >> and this is almost certainly why distros choose MinGW64 for their Windows >> cross compilers over MinGW. > > The biggest reason is not that. Licensing plays a role, but above > all, it's how we support our users. We are cordial, polite, and > respectful, even in the face of the opposite. Nightstrike, I know you believe this. You never miss an opportunity to state it; I was researching my post last night and found at least four separate conversations where the main point of any of your contributions to that conversation was the opinion above. I would ask you to consider something: by saying people "like" the mingw64 project (implied: better than mingw.org) because "we are cordial, polite, and respectful, even in the face of the opposite" is implicitly stating "those mingw guys are uncordial, impolite, and disrespectful". Maybe it's true. Maybe it's false. And you are certainly welcome to hold whatever opinion you like, and share it with whomever you like. But is it "cordial, respectful, and polite" to constantly berate me, here, on this list? To incessantly call me names? Or the other contributors? Six(?) months ago, Kai and Earnie TRIED to bury the hatchet. And then, a guy named NightStrike came along and, in that very thread, dug it up again and used that hatchet to express...the opinion you just stated. Again. (Granted, another member of this team also poured some fuel on the fire that Earnie and Kai were trying to put out. But that's another issue). NS, please stop doing that. You have a personal problem with me or some other member(s) of this list; please try to -- preferably -- resolve it with those individuals offline, or -- at the very least -- keep it from infecting every single attempt at positive interaction between the two projects? PLEASE? And as far as the primary reason for the original fork goes...it really does boil down to the licensing issue. According to Kai's summary of the incident (and my admittedly possibly frail memory of that summary), Kai and his company worked valiantly and hard -- but behind closed doors -- to develop the 64bit capability. Once complete, it was presented fait accompli for wholesale merge into the mingw.org baseline. Danny said, IIRC, please keep it separate for now, and break the changes up into smaller, easily reviewed patches so that each may be reviewed -- and determined to follow mingw.org's licensing policy with appropriate documentation of provenance -- individually. The next thing that happened, was mingw64.sourceforge. Perhaps it was merely meant as a temporary, this time public, holding area before Kai started trying to do as Danny asked. Perhaps progress in that directly was stymied by Danny's disappearance. Perhaps Kai believed then that it would be impossible to completely document all the changes as desired by Danny, and simply gave up and had no choice to but to start his fork. I don't know. What I DO know is that few, if any, patches (to mingw-runtime or w32api) were ever broken up into small reviewable pieces, documented as coming from public sources, and pushed in our direction. And the most recent time somebody -- Chris Sutcliff -- attempted to resolve the issue from this side of the big ditch between the two camps, one NightStrike kiboshed it with -- yet again -- accusing all of us of being great big meanies. Again, please stop doing that. Punching me in the nose and insulting me is not calculated to encourage me to be nicer to you, as much as I would like to be -- under non-insulting non-punching situations. If, after this point, you KEEP insulting me in every attempt at conversation -- even if you actually believe I am a despicable human being -- I will have to wonder WHY you would continue to do so? Would you, in that case, be TRYING to perpetuate the divide between our two projects for some non-public reason? What could that reason be? -- Chuck |
From: Charles W. <cwi...@us...> - 2010-06-26 15:33:34
|
On 6/26/2010 1:06 AM, Conan Kudo (ニール・ゴンパ) wrote: > Many countries in Europe have made it illegal to make anything "Public > Domain" and use anything under "Public Domain" because "Public Domain" > disclaims ALL rights, including moral ones. You may have a point here...but have you really heard of anyone refusing to use MinGW.org's offerings SPECIFICALLY because of the public domain issue, as opposed to just one minor issue among many that may prompt a different choice of win32 gcc compiler? If so, I wonder if it would be possible to convert the mingw-runtime and w32api files to the Creative Commons CC0 license, which was designed specifically as an equivalent for public domain, especially in those jurisdictions where ACTUAL public domain is problematic: http://creativecommons.org/about/cc0 Does any body know what it would take to convert all these files to some new -- ANY new -- license? Do we need to contact all previous contributors and get their permission (and if so, why? they specifically relinquished all rights to place the product in the public domain). But if something IS in the public domain, how can we (now) assert copyright over the collection, even if only to apply a new license to the result that is substantially similar to PD? (And, as a side note, if WE can't do that -- and I'm not saying we can't; in fact, I'm hoping we CAN -- but, again, if WE can't do that, then how did mingw64.org assert copyright, and apply a different license, to code derived from our collection? It seems they could apply copyright to their changes, but not the original core -- if any still remains unmodified...but IANAL) -- Chuck |
From: Alexander S. <ash...@gm...> - 2010-06-26 16:18:42
|
On Sat, 26 Jun 2010 11:33:10 -0400 Charles Wilson <cwi...@us...> wrote: > If so, I wonder if it would be possible to convert the mingw-runtime and > w32api files to the Creative Commons CC0 license, which was designed > specifically as an equivalent for public domain, especially in those > jurisdictions where ACTUAL public domain is problematic: > > http://creativecommons.org/about/cc0 AFAIK, CC0 is not meant to be used with software (it seems to apply to data). The most free (while remaining legal) license I'm aware of is Unlicense: http://unlicense.org/ I would certainly love to see mingw licensed under Unlicense - it seems to be that this way it will have less legal ambiguity (compared to copyrightless files). I guess re-licensing public domain code is OK - it's public domain, after all. Then again, IANAL. Thanks, Alexander |
From: Charles W. <cwi...@us...> - 2010-06-26 17:09:34
|
On 6/26/2010 12:17 PM, Alexander Shaduri wrote: > On Sat, 26 Jun 2010 11:33:10 -0400 > Charles Wilson <xx...@xx...> wrote: ^^^^^^^^^^^^^ please don't feed the spammers >> If so, I wonder if it would be possible to convert the mingw-runtime and >> w32api files to the Creative Commons CC0 license, which was designed >> specifically as an equivalent for public domain, especially in those >> jurisdictions where ACTUAL public domain is problematic: >> >> http://creativecommons.org/about/cc0 > > AFAIK, CC0 is not meant to be used with software (it seems to apply > to data). http://wiki.creativecommons.org/CC0_FAQ > CC0 may be used for any type of content protected by copyright, such > as journal articles, educational materials, books, music, and art, as > well as databases and data. They don't specifically mention software, but it is a "type of content protected by copyright". OTOH, according to http://wiki.creativecommons.org/Frequently_Asked_Questions "How does a Creative Commons license operate?" > Software programs are also protected by copyright but, as explained > below, we do not recommend that you apply a Creative Commons license > to software code. and "Can I use a Creative Commons license for software?" > We do not recommend it. The CC0 doesn't contain the MIT/X-ish disclaimer * This code is distributed in the hope that it will be useful but * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY * DISCLAIMED. This includes but is not limited to warranties of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So that might be a problem, too. > The most free (while remaining legal) license I'm aware of is Unlicense: > http://unlicense.org/ > > I would certainly love to see mingw licensed under Unlicense - it seems > to be that this way it will have less legal ambiguity (compared to copyrightless > files). Well, the Unlicense has the same "problem" that the current public domain declaration does: "This is free and unencumbered software released into the public domain" How this is an "alternative" to the (apparently problematic, in certain jurisdictions) concept of public domain, is not really clear to me. If mingw WERE to go thru the effort of (a) determining HOW we can change the license of non-copyrighted code -- since licensing is based on copyright, and (b) actually do it -- it would be nice to avoid the issues that prompted the change, rather than repeating them. The issue, as I understand it, is that in some jurisdictions certain "moral rights" cannot be waived. Thus, IN those jurisdictions, you can't actually put things into the "public domain" in the true, legal, sense of the term. This could scare off users who are subject to those jurisdictions from using stuff the original authors *attempt* to put into the public domain, because those users can't really be sure WHAT the legal status of the so-called "public domain" software IS. > I guess re-licensing public domain code is OK - it's public domain, after all. IANAL, either -- but licensing is a perquisite of a copyright holder. By asserting no copyright, and explicitly putting stuff in the public domain, you're essentially saying NOBODY has the authority to assert a license. Including yourself. Now, you could create a new work, bring in lots of public domain content, and license the new work however you like. (Legally. I think. But IANAL. Morally...it'd be better to give credit if the bulk of the new work was someone else's public domain contribution). So...MAYBE...we could set a new license for each file, after making a ***substantive*** change to that file. Technically, the new version is a new adaptation -- with lots of old, imported "public domain" content. But the new bits are under the new license, so...the rest of the file, as a "new adaptation", would be under the new license too. See http://wiki.creativecommons.org/Frequently_Asked_Questions -- especially: "May I apply a Creative Commons license to a work that is in the public domain?" where the answer is generally "no" except for the last sentence: "...you may apply a Creative Commons license to an adaptation of a public domain work if you hold copyright to the adaptation." But even if it's possible, I dunno that we really want to do it. I merely raised it as a possibility we might consider, if this public domain issue really IS a problem in actual use. Two final notes: 1) However, looking closer at mingw64, it is NOT true that everything they distribute is other-than-pd. Here's _mingw.h: /** * This file has no copyright assigned and is placed in the Public Domain. * This file is part of the w64 mingw-runtime package. * No warranty is given; refer to the file DISCLAIMER.PD within this package. */ Here's DISCLAIMER.PD http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/DISCLAIMER.PD?revision=1748&view=markup /** * DISCLAIMER * This file has no copyright assigned and is placed in the Public Domain. * This file is a part of the w64 mingw-runtime package. * * The w64 mingw-runtime package and its code is distributed in the hope that it * will be useful but WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESSED OR * IMPLIED ARE HEREBY DISCLAIMED. This includes but is not limited to * warranties of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. */ So, I fail to see that Conan Kudo's argument can possibly be correct, since BOTH mingw.org and mingw64 products are public domain -- at least, the "w32api" bits of them. The mingw(64)-runtime portions... Well, that's a different story. See http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt?revision=2592&view=markup I've gotta run, or I'd track down the parallel information for mingw(32)-runtime... 2) Apparently the mingw64 guys ARE trying to keep track, at least, of WHICH of their headers do have provenance acceptable to mingw.org: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-doc/headers-ref/header_doc.txt?revision=2281&view=markup So, determining which ones do not YET have "proper" documentation is a simple exercise in set mathematics. -- Chuck |
From: Kai T. <kti...@go...> - 2010-06-26 17:41:32
|
2010/6/26 Charles Wilson <cwi...@us...>: > So, I fail to see that Conan Kudo's argument can possibly be correct, > since BOTH mingw.org and mingw64 products are public domain -- at least, > the "w32api" bits of them. The mingw(64)-runtime portions... Please see http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/COPYING?revision=1748&view=markup for the mentioned COPYING file, which is our license file. What you are referring to is the DISCLAIMER for PD (as we have a separate for ZPL). > Well, that's a different story. See > > http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt?revision=2592&view=markup > > I've gotta run, or I'd track down the parallel information for > mingw(32)-runtime... Well, I assume that those files are addressing mostly the same third-party licenses for both ventures. By the way, this kind of license collection seems to be missing in tree of mingw.org, but well, this is a different story. > > 2) Apparently the mingw64 guys ARE trying to keep track, at least, of > WHICH of their headers do have provenance acceptable to mingw.org: > http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-doc/headers-ref/header_doc.txt?revision=2281&view=markup > > So, determining which ones do not YET have "proper" documentation is a > simple exercise in set mathematics. Well, here I need to let you down. Those files were generate at times we believed a merge would be possible, but we stopped here to continue on this list, as it had shown to us a vain work. We let this file in our repository just for historical reasons. Regards, Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
From: Charles W. <cwi...@us...> - 2010-06-26 18:17:01
|
On 6/26/2010 1:41 PM, Kai Tietz wrote: > 2010/6/26 Charles Wilson <cwi...@pu...>: >> So, I fail to see that Conan Kudo's argument can possibly be correct, >> since BOTH mingw.org and mingw64 products are public domain -- at least, >> the "w32api" bits of them. The mingw(64)-runtime portions... > > Please see http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/COPYING?revision=1748&view=markup > for the mentioned COPYING file, which is our license file. What you > are referring to is the DISCLAIMER for PD (as we have a separate for > ZPL). Thanks, Kai. >> Well, that's a different story. See >> >> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/COPYING.MinGW-w64-runtime/COPYING.MinGW-w64-runtime.txt?revision=2592&view=markup >> >> I've gotta run, or I'd track down the parallel information for >> mingw(32)-runtime... > > Well, I assume that those files are addressing mostly the same > third-party licenses for both ventures. By the way, this kind of > license collection seems to be missing in tree of mingw.org, but well, > this is a different story. Hmm. You're right. We should probably do that audit and add similar information to our tree. Thanks for the heads up. >> 2) Apparently the mingw64 guys ARE trying to keep track, at least, of >> WHICH of their headers do have provenance acceptable to mingw.org: >> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-doc/headers-ref/header_doc.txt?revision=2281&view=markup >> >> So, determining which ones do not YET have "proper" documentation is a >> simple exercise in set mathematics. > > Well, here I need to let you down. Those files were generate at times > we believed a merge would be possible, but we stopped here to continue > on this list, So you're saying the information in that file has not been kept up to date, and may no longer be accurate? Perhaps because files listed IN that document have since been modified with information taken from other-than-open-documentation-like-MSDN? That's too bad, but thanks for the warning. > as it had shown to us a vain work. Well, I'm not sure about that. Chris Sutcliff volunteered to spearhead an new effort in this direction some time ago. Has anything come of that on your side? OTOH, there are two additional routes to "success": 1) my (weak?) argument that if mingw64's rationale concerning API headers is good enough for Fedora, it ought to be good enough for mingw.org despite our longstanding contrary opinion. 2) Tor's advice to see if we can't get MS, thru CoApp, to modify the actual distribution rules of at least SOME of the Windows SDK headers. A long shot, but the US did make it out of the first round of the World Cup...so ANYTHING is possible. -- Chuck |
From: Earnie <ea...@us...> - 2010-06-29 16:17:08
|
Alexander Shaduri wrote: > > The most free (while remaining legal) license I'm aware of is Unlicense: > http://unlicense.org/ > Except for the clarifying lines, how is this different from Public Domain? In fact the license begins: "This is free and unencumbered software released into the public domain." -- Earnie -- http://www.for-my-kids.com |
From: Alexander S. <ash...@gm...> - 2010-06-29 19:19:10
|
On Tue, 29 Jun 2010 12:16:54 -0400 Earnie wrote: > Alexander Shaduri wrote: > > > > The most free (while remaining legal) license I'm aware of is Unlicense: > > http://unlicense.org/ > > > > Except for the clarifying lines, how is this different from Public > Domain? In fact the license begins: > > "This is free and unencumbered software released into the public domain." The difference is that, as far as I understand, in jurisdictions where Public Domain is not recognized, this license provides a fallback. Someone mentioned already that the unrecognized parts of the license get dropped in such cases. This means that you still have the "Anyone is free ..." part and the all-caps warranty disclaimer (I've read that it _must_ be all caps and worded that way). Plus, anything is better than files without copyright headers. Alexander |
From: Earnie <ea...@us...> - 2010-06-29 20:26:51
|
Alexander Shaduri wrote: > Plus, anything is better than files without copyright headers. > If there are those, then it is a bug and needs to be tracked in the bug/patch tracker. -- Earnie -- http://www.for-my-kids.com |
From: Earnie <ea...@us...> - 2010-06-29 15:53:51
|
Charles Wilson wrote: > > Does any body know what it would take to convert all these files to some > new -- ANY new -- license? Do we need to contact all previous > contributors and get their permission (and if so, why? they specifically > relinquished all rights to place the product in the public domain). But > if something IS in the public domain, how can we (now) assert copyright > over the collection, even if only to apply a new license to the result > that is substantially similar to PD? > If we need legal advise I would think Redhat would be willing to provide it since Cygwin has a vested interest in MinGW. But to apply a new license would simply mean that we increase the major version of the library. We could simply add a sentence similar to what Kai had added that gives permissions to use a license that would be in good standing for the governing body of use that waives the rights to intellectual property and is at the same time copacetic with the GPL where the PD license isn't a viable option. -- Earnie -- http://www.for-my-kids.com |
From: Earnie <ea...@us...> - 2010-06-29 15:38:21
|
Conan Kudo (ニール・ゴンパ) wrote: > Many countries in Europe have made it illegal to make anything "Public > Domain" and use anything under "Public Domain" because "Public Domain" > disclaims ALL rights, including moral ones. I don't see how "moral" rights are included with intellectual property which is what a "Public Domain" license gives rights to. A public domain license means that the intellectual property has no ownership and you have the right to do with the intellectual property anything you desire. -- Earnie -- http://www.for-my-kids.com |
From: Greg C. <gch...@sb...> - 2010-06-29 16:16:24
|
On 2010-06-29 15:38Z, Earnie wrote: > Conan Kudo (ニール・ゴンパ) wrote: >> Many countries in Europe have made it illegal to make anything "Public >> Domain" and use anything under "Public Domain" because "Public Domain" >> disclaims ALL rights, including moral ones. > > I don't see how "moral" rights are included with intellectual property > which is what a "Public Domain" license gives rights to. A public > domain license means that the intellectual property has no ownership and > you have the right to do with the intellectual property anything you desire. The law of many countries considers certain rights of authorship to be inalienable, so that an author cannot transfer or abandon those rights. http://en.wikipedia.org/wiki/Moral_rights_(copyright_law) |
From: Tor L. <tm...@ik...> - 2010-06-26 07:57:19
|
Note that we now have a person on this list who is known to actually work for Microsoft, and who works on promoting Open Source, and clearly approves of gcc being an alternative compiler on Windows for cases where MSVC for some reason doesn't fit. I am talking about Garrett Serack, the CoApp maintainer. Presumably he is doing his work on CoApp with the full knowledge and approval of his superiors, at least a few steps up the chain. So perhaps we should just ask him whether he could try to persuade Microsoft to release the headers for at least the C libraries and the core Win32 API (of course, the more APIs, the better) under a more permissive license that would permit their redistribution, slightly edited as necessary to be palatable to gcc. Or even to just accept gcc-specific ifdefs into their headers and allow them to be redistributed unmodified. That would at least get rid of one cause for the mingw.org / mingw-w64 schisma. Although, especially that second way (getting gcc ifdefs upstream into MS headers, redistributing allowed only unmodified) would probably mak them unacceptable to for instance Debian. But there could always be packages that would download the headers from Microsoft to each machine directly, instead of distributing with a distro, just like many distros to for some MS fonts, for instance. Another thing, and now we definitely come into "I am not a lawyer" territory: Conan Kudo says some countries in Europe makes it "illegal" to make anything "Public Domain". I think that is exaggerating. In my opinion saying that something is "illegal" is equivalent to saying it is explicitly prohibited by law, and perhaps in fact punishable. I guess in the "public domain" concept simply is undefined and meaningless in these countries. Presumably in the legal tradition of such countries an author of a work can never lose the moral rights to the work, even if the author would want to. Presumably, even in this tradition, if an author donates a work to the public domain in another country where such a concept has a meaning, it would be accepted as implicitly publishing it under very generous license, though, while retaining the moral rights to it. Which is more or less equally good in my opinion, no? --tml |
From: Garrett S. <gar...@mi...> - 2010-07-12 18:04:31
|
Sorry for the late reply... I joined the mailing list, and then the next day I went out of town for two weeks (China & Canada). >> Presumably he is doing his work on CoApp with the full knowledge and >> approval of his superiors, at least a few steps up the chain. Indeed... I have support of my superiors all the way up to our Corporate VP for Windows Server, whom I got signoff for CoApp directly. >> ... ask him whether he could try to persuade Microsoft to release the >> headers for at least the C libraries and the core Win32 API ... I could begin to find out what it would take... I suspect this is a long road to walk down... I will start poking folks this week. Off the top of my head, I do have a couple of thoughts in this regard: - Does anyone know if other C/C++ compilers (like Watcom, Borland, etc) ever redistributed the SDK headers? If they licensed them for redistribution, the easiest path may be getting the same type of license they used--assuming of course that we could get it zero-fee. - Since the SDK is free to download... you might look at it from another direction: have the installer download the SDK ISO file, and extract the files that you need (or some other automation that gets you what you want). Garrett Serack | Open Source Software Developer | Microsoft Corporation -----Original Message----- From: Tor Lillqvist [mailto:tm...@ik...] Sent: Saturday, June 26, 2010 12:57 AM To: MinGW Users List Subject: Re: [Mingw-users] gcc forks on Windows (was re: repository for Open Source Windows) Note that we now have a person on this list who is known to actually work for Microsoft, and who works on promoting Open Source, and clearly approves of gcc being an alternative compiler on Windows for cases where MSVC for some reason doesn't fit. I am talking about Garrett Serack, the CoApp maintainer. Presumably he is doing his work on CoApp with the full knowledge and approval of his superiors, at least a few steps up the chain. So perhaps we should just ask him whether he could try to persuade Microsoft to release the headers for at least the C libraries and the core Win32 API (of course, the more APIs, the better) under a more permissive license that would permit their redistribution, slightly edited as necessary to be palatable to gcc. Or even to just accept gcc-specific ifdefs into their headers and allow them to be redistributed unmodified. That would at least get rid of one cause for the mingw.org / mingw-w64 schisma. Although, especially that second way (getting gcc ifdefs upstream into MS headers, redistributing allowed only unmodified) would probably mak them unacceptable to for instance Debian. But there could always be packages that would download the headers from Microsoft to each machine directly, instead of distributing with a distro, just like many distros to for some MS fonts, for instance. Another thing, and now we definitely come into "I am not a lawyer" territory: Conan Kudo says some countries in Europe makes it "illegal" to make anything "Public Domain". I think that is exaggerating. In my opinion saying that something is "illegal" is equivalent to saying it is explicitly prohibited by law, and perhaps in fact punishable. I guess in the "public domain" concept simply is undefined and meaningless in these countries. Presumably in the legal tradition of such countries an author of a work can never lose the moral rights to the work, even if the author would want to. Presumably, even in this tradition, if an author donates a work to the public domain in another country where such a concept has a meaning, it would be accepted as implicitly publishing it under very generous license, though, while retaining the moral rights to it. Which is more or less equally good in my opinion, no? --tml ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ MinGW-users mailing list Min...@li... This list observes the Etiquette found at http://www.mingw.org/Mailing_Lists. We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. _______________________________________________ You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-07-12 18:18:22
|
On Mon, Jul 12, 2010 at 1:04 PM, Garrett Serack <gar...@mi...>wrote: > Sorry for the late reply... I joined the mailing list, and then the next > day I went out of town for two weeks (China & Canada). > > >> Presumably he is doing his work on CoApp with the full knowledge and > >> approval of his superiors, at least a few steps up the chain. > > Indeed... I have support of my superiors all the way up to our Corporate VP > for Windows Server, whom I got signoff for CoApp directly. > > Impressive. I knew CoApp was supported pretty well by Microsoft, I didn't know it was that well. > >> ... ask him whether he could try to persuade Microsoft to release the > >> headers for at least the C libraries and the core Win32 API ... > > I could begin to find out what it would take... I suspect this is a long > road to walk down... I will start poking folks this week. > > Great! > Off the top of my head, I do have a couple of thoughts in this regard: > > - Does anyone know if other C/C++ compilers (like Watcom, Borland, etc) > ever redistributed the SDK headers? If they licensed them for > redistribution, the easiest path may be getting the same type of license > they used--assuming of course that we could get it zero-fee. > > I think Borland did, but I think they stripped those out of the "free" BCC 5.5 compiler. Watcom stripped their Win32 headers out of their packages when the compiler went open source. They originally used MinGW's SDK for OpenWatcom, but then they completely rewrote it last year to clean up and add support for more APIs from Vista and Windows 7. That SDK is unfortunately under the same license as the compiler, so it is not GPL-compatible. > - Since the SDK is free to download... you might look at it from another > direction: have the installer download the SDK ISO file, and extract the > files that you need (or some other automation that gets you what you want). > > That is a very ugly and wasteful process, because it would also download bits that may (and probably are) not useful for MinGW. Plus, I don't think MinGW uses an NSIS based installer anymore. Or at least, they don't update it anymore... > > Garrett Serack | Open Source Software Developer | Microsoft Corporation > > -----Original Message----- > From: Tor Lillqvist [mailto:tm...@ik...] > Sent: Saturday, June 26, 2010 12:57 AM > To: MinGW Users List > Subject: Re: [Mingw-users] gcc forks on Windows (was re: repository for > Open Source Windows) > > Note that we now have a person on this list who is known to actually work > for Microsoft, and who works on promoting Open Source, and clearly approves > of gcc being an alternative compiler on Windows for cases where MSVC for > some reason doesn't fit. I am talking about Garrett Serack, the CoApp > maintainer. > > Presumably he is doing his work on CoApp with the full knowledge and > approval of his superiors, at least a few steps up the chain. > > So perhaps we should just ask him whether he could try to persuade > Microsoft to release the headers for at least the C libraries and the core > Win32 API (of course, the more APIs, the better) under a more permissive > license that would permit their redistribution, slightly edited as necessary > to be palatable to gcc. Or even to just accept gcc-specific ifdefs into > their headers and allow them to be redistributed unmodified. > > That would at least get rid of one cause for the mingw.org / mingw-w64 > schisma. Although, especially that second way (getting gcc ifdefs upstream > into MS headers, redistributing allowed only unmodified) would probably mak > them unacceptable to for instance Debian. But there could always be packages > that would download the headers from Microsoft to each machine directly, > instead of distributing with a distro, just like many distros to for some MS > fonts, for instance. > > Another thing, and now we definitely come into "I am not a lawyer" > territory: Conan Kudo says some countries in Europe makes it "illegal" > to make anything "Public Domain". I think that is exaggerating. In my > opinion saying that something is "illegal" is equivalent to saying it is > explicitly prohibited by law, and perhaps in fact punishable. I guess in the > "public domain" concept simply is undefined and meaningless in these > countries. Presumably in the legal tradition of such countries an author of > a work can never lose the moral rights to the work, even if the author would > want to. > > Presumably, even in this tradition, if an author donates a work to the > public domain in another country where such a concept has a meaning, it > would be accepted as implicitly publishing it under very generous license, > though, while retaining the moral rights to it. Which is more or less > equally good in my opinion, no? > > --tml > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint What will you do first with EVO, > the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |