Menu
▾
▴
mingw-users
|
From: LM <lm...@ya...> - 2010-06-25 17:21:29
|
Charles Wilson wrote: > I like the > first bit and the > last bit; I just wish the middle bit would re-use our > packaging -- and > distro. > > The Wascana gcc is TDM's 4.4.1 distro, instead of our 4.5.0 > version. It is getting to be a nuisance. Of late, I keep running into projects that use "mingw", but aren't using a version from www.mingw.org. They're using some other version, fork or distribution instead. I was just checking into using Strawberry Perl as a replacement for Activestate Perl. When I asked on their mailing list about using the latest version of mingw instead of an older version, was told they use someone else's distribution of mingw so they have both 32 bit and 64 bit support. Now, I'm considering whether I should have stuck with Activestate Perl, whether to look into the version in the DTK that will work with msys (but I really want a version that's not tied to the msys environment) or whether it's even worth the time and effort to check into building it myself from scratch. > 'course, a working mingw-get and widespread acceptance of > same would be > a pre-requisite. <g> Looking forward to that. Wish I could be of more use in testing and debugging, but my Internet connection is very slow and somewhat iffy. Maybe I can be of more help on the documentation end of things. Sincerely, Laura |
|
From: Kai T. <kti...@go...> - 2010-06-26 16:24:29
|
Hi Chuck, 2010/6/26 Charles Wilson <cwi...@us...>: > (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) To anwser this reasonable question, I'll enter this thread. Of course we can't change license in general for sources, which are provided under PD, where authors don't agree. As we have advices by lawyers (thanks to the comany I am working for, which grants us juristic advice) we did the following approach. For jurisdictions - as in French and Germany - where the legal term PD doesn't exist, we added the sentence "With exception of certain parts that are prominently marked as being in the Public Domain, BSD, or LGPL this Software is provided under the Zope Public License (ZPL) Version 2.1." to our license COPYING file. This leads to the fact, that for countries, which don't have the legal term PD, the source-code gets covered by the ZPL license. We choose the ZPL license as it is a FSF compatible license and it provides to us - as project mingw-w64 - a weak copy-left, which is of some advantage to get patches back into mainline. 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:09:31
|
On 6/26/2010 12:24 PM, Kai Tietz wrote: > 2010/6/26 Charles Wilson >> (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) > > To anwser this reasonable question, I'll enter this thread. Of course > we can't change license in general for sources, which are provided > under PD, where authors don't agree. As we have advices by lawyers > (thanks to the comany I am working for, which grants us juristic > advice) we did the following approach. For jurisdictions - as in > French and Germany - where the legal term PD doesn't exist, we added > the sentence "With exception of certain parts that are prominently > marked as being in the Public Domain, BSD, or LGPL this Software is > provided under the Zope Public License (ZPL) Version 2.1." to our > license COPYING file. This leads to the fact, that for countries, > which don't have the legal term PD, the source-code gets covered by > the ZPL license. We choose the ZPL license as it is a FSF compatible > license and it provides to us - as project mingw-w64 - a weak > copy-left, which is of some advantage to get patches back into > mainline. Thanks, Kai. As I noted in another message, many of the individual w32api-ish files in mingw64 still carry a PD notice, just as they do in mingw.org. So, I guess the real difference that Conan Kudo was highlighting was this over-arching distribution-wide notice that "hey, if your legal jurisdiction does't recognize 'public domain', then assume any file marked that way is actually ZPL kinda by default". So...Conan Kudo was kinda right, but kinda wrong: in those jurisdictions that DO recognize PD, the code marked PD *is* PD. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Not trying be argumentative -- after all, IANAL -- but I'm still not sure how exactly that works (in non-PD jurisdictions). They don't recognize PD, so the original authors could never give up their 'moral rights' to the code. Which means the mingw64 team can't assert their own ownership over (unmodified portions of) that code. Which means the mingw64 team can't set ANY license terms on them -- in those jurisdictions, because of the pre-existing and (not allowed to be waived) 'moral rights' held by the original authors. Of course, neither can the mingw.org people -- because only the original authors could do so in those jurisdictions. Anybody know how to contact Colin Peters, Jan-Jaap van der Heijden, Mumit Khan, and Anders Norlander? Unless, of course, mingw64 is simply relying on the fact that all proprietary rights CAN be waived, even in non-PD jurisdiction, (and have been waived, assuming those non-PD jurisdictions recognize mingw.org's original PD declaration at least enough to allow THAT much). Therefore any new collection or new adaptation can be placed under a new license, thanks to the added or modified content of each and every file that mingw64 has created (at the very least, the comments in every file have been modified). Using that fig leaf (EVEN in non-PD jurisdictions, mingw64 is author of the modified version, even if it includes a lot of stuff for which all proprietary, non-moral rights, have been waived), mingw64 can assert ownership of the new version, and assert any license it wants. PD in PD jurisdictions, ZPL in non-PD ones. Which sorta goes back to my question about one way "we" at mingw.org could change the licensing *as each file is modified*. IF we wanted to do so. Perhaps we could take a similar tack as mingw64, and assert PD-in-PD-juris, ZPL-otherwise. ZPL may be weak copy-left (VERY weak); it appears to me to be more BSDish, except for the "modified files must declare themselves so" clause. But IANAL, and unlike mingw64, unfortunately mingw.org does not have the benefit of legal counsel, AFAIK. But if you guys can (legally) do it, then we certainly can, too. But there is ONE thing I know about the law: it doesn't matter much what the law actually says on paper; law is not software that is run thru a compiler to generate legal outcomes. Judges and courtrooms are not Turing Machines. The only thing that matters is what case law rulings apply, when specific legal actions are taken under the law in specific legal jurisdictions -- and that's what you pay lawyers, as opposed to armchair analysts, to know. BEFORE you get yourself involved in one of those "legal actions". Us non-lawyers might wish it were otherwise...but it isn't, and the legal guild wants to keep it that way. Since 99% of politicians are members of that guild...that's the way it will stay. -- Chuck |
|
From: Stephen L. <sld...@so...> - 2010-06-27 08:12:35
|
Kai, Maybe your lawyers have already cleared this; just wanted to point out something I am confused about. Kai Tietz wrote: > "With exception of certain parts that are prominently > marked as being in the Public Domain, BSD, or LGPL this Software is > provided under the Zope Public License (ZPL) Version 2.1." to our > license COPYING file. It sounds to me though the above statement breaks "this Software" down to 4 components: A. parts that are prominently marked as being in the Public Domain B. parts that are prominently marked as being BSD C. parts that are prominently marked as being LGPL D. the rest i.e. parts that are provided under the ZPL Version 2.1 > This leads to the fact, that for countries, > which don't have the legal term PD, the source-code gets covered by > the ZPL license. I don't see how for those countries (A) magically becomes (D). Whether PD is a valid term there or not (A) is "marked as PD" nonetheless, and therefore not included in the "exception" IMHO. This seems to make (A) unlicensed in those countries, but IANAL... |
|
From: Kai T. <kti...@go...> - 2010-06-27 09:15:52
|
2010/6/27 Stephen Lee <sld...@so...>:
> Kai,
>
> Maybe your lawyers have already cleared this; just wanted to point out
> something I am confused about.
>
> Kai Tietz wrote:
>> "With exception of certain parts that are prominently
>> marked as being in the Public Domain, BSD, or LGPL this Software is
>> provided under the Zope Public License (ZPL) Version 2.1." to our
>> license COPYING file.
>
> It sounds to me though the above statement breaks "this Software"
> down to 4 components:
>
> A. parts that are prominently marked as being in the Public Domain
> B. parts that are prominently marked as being BSD
> C. parts that are prominently marked as being LGPL
> D. the rest i.e. parts that are provided under the ZPL Version 2.1
>
>> This leads to the fact, that for countries,
>> which don't have the legal term PD, the source-code gets covered by
>> the ZPL license.
>
> I don't see how for those countries (A) magically becomes
> (D). Whether PD is a valid term there or not (A) is "marked as PD"
> nonetheless, and therefore not included in the "exception" IMHO.
>
> This seems to make (A) unlicensed in those countries, but IANAL...
Well, our lawyers had described it to me as following. The issue here
is, that if the license form A isn't existing in local law, then this
clause get simply dropped and being replaced under the next mentioned
copyright (for mingw-w64 ZPL is default). So this means for such
countries the PD (as it is to existing that a license form (if present
and mentioned) is choosen, which fits original author intention. By
the statement that ZPL is the default license-form, any license -
which doesn't exists - get replaced by the default one. This is like a
typical severability clause.
But well, INAL too, so if you want to get it answered in more detail,
you need possibly to ask one.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
|
|
From: Jax <cyb...@gm...> - 2010-07-13 23:33:07
|
KILL ALL THE FUCKING NIGGERS AND JEWS
SIEG HEIL HEIL HITLER!
_
/ /\
/ / /
/ / / _
/_/ / / /\
\ \ \ / / \
\ \ \/ / /\ \
_ \ \ \/ /\ \ \
/_/\ \_\ / \ \ \
\ \ \ / / \ \_\/
\ \ \/ / /\ \
\ \ \/ /\ \ \
\ \ / \ \ \
\_\/ / / /
/ / /
/_/ /
\_\/
burn all white traitors alive kill their children too.
On Fri, Jun 25, 2010 at 7:21 PM, LM <lm...@ya...> wrote:
> Charles Wilson wrote:
>> I like the
>> first bit and the
>> last bit; I just wish the middle bit would re-use our
>> packaging -- and
>> distro.
>>
>> The Wascana gcc is TDM's 4.4.1 distro, instead of our 4.5.0
>> version.
>
> It is getting to be a nuisance. Of late, I keep running into projects that use "mingw", but aren't using a version from www.mingw.org. They're using some other version, fork or distribution instead. I was just checking into using Strawberry Perl as a replacement for Activestate Perl. When I asked on their mailing list about using the latest version of mingw instead of an older version, was told they use someone else's distribution of mingw so they have both 32 bit and 64 bit support. Now, I'm considering whether I should have stuck with Activestate Perl, whether to look into the version in the DTK that will work with msys (but I really want a version that's not tied to the msys environment) or whether it's even worth the time and effort to check into building it myself from scratch.
>
>> 'course, a working mingw-get and widespread acceptance of
>> same would be
>> a pre-requisite. <g>
>
> Looking forward to that. Wish I could be of more use in testing and debugging, but my Internet connection is very slow and somewhat iffy. Maybe I can be of more help on the documentation end of things.
>
> Sincerely,
> Laura
>
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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: Maurício G. <ors...@gm...> - 2010-07-13 23:58:05
|
Regarding the "public-domain" thing... In countries with Moral Rights, the author has ALWAYS Moral Rights, and cannot waive them or sell them, or do whatever he wants with them... It is not much a issue actually, the moral rights don't screw-up with software making. On Tue, Jul 13, 2010 at 8:32 PM, Jax <cyb...@gm...> wrote: > KILL ALL THE FUCKING NIGGERS AND JEWS > > SIEG HEIL HEIL HITLER! > > _ > / /\ > / / / > / / / _ > /_/ / / /\ > \ \ \ / / \ > \ \ \/ / /\ \ > _ \ \ \/ /\ \ \ > /_/\ \_\ / \ \ \ > \ \ \ / / \ \_\/ > \ \ \/ / /\ \ > \ \ \/ /\ \ \ > \ \ / \ \ \ > \_\/ / / / > / / / > /_/ / > \_\/ > > burn all white traitors alive kill their children too. > > > On Fri, Jun 25, 2010 at 7:21 PM, LM <lm...@ya...> wrote: > > Charles Wilson wrote: > >> I like the > >> first bit and the > >> last bit; I just wish the middle bit would re-use our > >> packaging -- and > >> distro. > >> > >> The Wascana gcc is TDM's 4.4.1 distro, instead of our 4.5.0 > >> version. > > > > It is getting to be a nuisance. Of late, I keep running into projects > that use "mingw", but aren't using a version from www.mingw.org. They're > using some other version, fork or distribution instead. I was just checking > into using Strawberry Perl as a replacement for Activestate Perl. When I > asked on their mailing list about using the latest version of mingw instead > of an older version, was told they use someone else's distribution of mingw > so they have both 32 bit and 64 bit support. Now, I'm considering whether I > should have stuck with Activestate Perl, whether to look into the version in > the DTK that will work with msys (but I really want a version that's not > tied to the msys environment) or whether it's even worth the time and effort > to check into building it myself from scratch. > > > >> 'course, a working mingw-get and widespread acceptance of > >> same would be > >> a pre-requisite. <g> > > > > Looking forward to that. Wish I could be of more use in testing and > debugging, but my Internet connection is very slow and somewhat iffy. Maybe > I can be of more help on the documentation end of things. > > > > Sincerely, > > Laura > > > > > > > > > > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > 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 > |
|
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-25 18:45:31
|
On Fri, Jun 25, 2010 at 12:21 PM, LM <lm...@ya...> wrote: > Charles Wilson wrote: > > I like the > > first bit and the > > last bit; I just wish the middle bit would re-use our > > packaging -- and > > distro. > > > > The Wascana gcc is TDM's 4.4.1 distro, instead of our 4.5.0 > > version. > > It is getting to be a nuisance. Of late, I keep running into projects that > use "mingw", but aren't using a version from www.mingw.org. They're using > some other version, fork or distribution instead. I was just checking into > using Strawberry Perl as a replacement for Activestate Perl. When I asked > on their mailing list about using the latest version of mingw instead of an > older version, was told they use someone else's distribution of mingw so > they have both 32 bit and 64 bit support. Now, I'm considering whether I > should have stuck with Activestate Perl, whether to look into the version in > the DTK that will work with msys (but I really want a version that's not > tied to the msys environment) or whether it's even worth the time and effort > to check into building it myself from scratch. > > > 'course, a working mingw-get and widespread acceptance of > > same would be > > a pre-requisite. <g> > > Looking forward to that. Wish I could be of more use in testing and > debugging, but my Internet connection is very slow and somewhat iffy. Maybe > I can be of more help on the documentation end of things. > > Sincerely, > Laura > > > > 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. |
|
From: Earnie <ea...@us...> - 2010-06-25 19:05:38
|
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. > Are you volunteering to be the creator of such a work? Really, that is all it would take, someone willing to do the initial work and maintain it. -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-06-25 19:41:32
|
Earnie wrote: > Are you volunteering to be the creator of such a work? Really, that is > all it would take, someone willing to do the initial work and maintain it. Would it make sense to approach the maintainers of such a project - like mingw-w64 and ask them if they would like to be involved in getting that functionality to work in mingw? Also, when choosing another package like TDM, the problem is in the installation. As far as I have seen, mingw-get works pretty well. However, this is not very clear. As it is, the site provides manual install and an installation procedure that has a bolded caption that it only provides gcc 3. It is easy to get confused and when you are, a fully automated installer like TDM's is an easy way out of the state of confusion. I think this is a problem that leads to projects using another distribution of mingw. greetings, Jasper |
|
From: Earnie <ea...@us...> - 2010-06-25 20:21:00
|
Jasper Horn wrote: > Earnie wrote: >> Are you volunteering to be the creator of such a work? Really, that is >> all it would take, someone willing to do the initial work and maintain it. > > Would it make sense to approach the maintainers of such a project - > like mingw-w64 and ask them if they would like to be involved in > getting that functionality to work in mingw? http://search.gmane.org/?query=64bit&group=gmane.comp.gnu.mingw.devel -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-06-26 00:32:55
|
Earnie wrote: > http://search.gmane.org/?query=64bit&group=gmane.comp.gnu.mingw.devel I'm sorry, but I can't make any sense of that link in this context... Jasper |
|
From: John K. <xix...@gm...> - 2010-06-26 01:21:03
|
On Fri, Jun 25, 2010 at 7:32 PM, Jasper Horn <jas...@gm...> wrote: > Earnie wrote: >> http://search.gmane.org/?query=64bit&group=gmane.comp.gnu.mingw.devel > > I'm sorry, but I can't make any sense of that link in this context... > This one will start you at the to of the relevant thread: http://news.gmane.org/find-root.php?message_id=%3c2bf229d30907181538v59442a13ke80e7261b4b1f39d%40mail.gmail.com%3e --John Klehm |
|
From: Jasper H. <jas...@gm...> - 2010-06-29 02:06:45
|
John Klehm wrote: > This one will start you at the to of the relevant thread: > http://news.gmane.org/find-root.php?message_id=%3c2bf229d30907181538v59442a13ke80e7261b4b1f39d%40mail.gmail.com%3e Thanks for pointing me at the relevant link! I am glad that I was able to bring this discussion back to the foreground again, as it seems that maintaining these two projects separately is a waste of (human) resources. Additionally, it seems that as time has passed this discussion is now more about practical problems and less about the bad blood between the two projects. So let me summarize the current obstacles on the road to working together or even merging projects (at least the ones mentioned in this discussion): - mingw.org requires proper (PD) sources of where a win32 api call was found - meaning that Microsoft's own header files are excluded - while mingw64 has no such requirement, meaning that Microsoft's own header files can be used as a source - mingw.org has everything released in the public domain, while mingw64 has different licenses for different parts of mingw - including a clause that covers PD works in countries that have no (voluntary) public domain - mingw.org and mingw64 have radically different mailing list guidelines (including the guidelines for the project maintainers) Most of these gaps seem bridgeable to me, and while there needs to be considerable work in order to bridge them, I think the advantages of only a single team clearly outweigh the work that needs to be done here. I have a question about the mingw64 licensing, that I believe has been asked but not answered. There is a clause that turns public domain works into ZPL licensed works in countries where they can't be PD. Wouldn't this be relicensing this software, for which you need to have the author's permission to do so? Of course you would have such permission from authors that provided PD code for the mingw64 project after that clause was invented (perhaps this should be clearly stated for authors, so they release it as such by intension not "accidentally"), but how about code that was not expressively released into the public domain with this clause in effect? I'm willing to help on resolving these issues, but my input would most probably not be a code contribution, as I simply do not have the necessary skills for that. So if there's anything else I can do, please let me know. Jasper Horn |
|
From: Erwin W. <wat...@xs...> - 2010-06-29 08:00:43
|
Op 29-06-10 04:06, Jasper Horn schreef: > I have a question about the mingw64 licensing, that I believe has been > asked but not answered. There is a clause that turns public domain > works into ZPL licensed works in countries where they can't be PD. > Wouldn't this be relicensing this software, for which you need to have > the author's permission to do so? > Of course you would have such permission from authors that provided PD > code for the mingw64 project after that clause was invented (perhaps > this should be clearly stated for authors, so they release it as such > by intension not "accidentally"), but how about code that was not > expressively released into the public domain with this clause in > effect? > Isn't that a property of Public Domain. You can do with it what you want and even re-license it into a closed commercial license. No need to ask the author. Erwin |
|
From: Earnie <ea...@us...> - 2010-06-29 15:32:12
|
Erwin Waterlander wrote: > Isn't that a property of Public Domain. You can do with it what you want > and even re-license it into a closed commercial license. No need to ask > the author. Yes. That is the definition of Public Domain. The author has relinquished all rights to the intellectual property for the source and has granted use of the source for any purpose, including the claim of ownership in a closed commercial license. -- Earnie -- http://www.for-my-kids.com |
|
From: Kai T. <kti...@go...> - 2010-06-29 08:21:58
|
Hi Jasper, 2010/6/29 Jasper Horn <jas...@gm...>: > I am glad that I was able to bring this discussion back to the > foreground again, as it seems that maintaining these two projects > separately is a waste of (human) resources. Additionally, it seems > that as time has passed this discussion is now more about practical > problems and less about the bad blood between the two projects. Well, things calm down a bit and indeed did mingw-w64 begun to contribute some vital features to mingw.org. I am hoping this kind of co-operation will grow. If the two ventures will merge one day, I can't predict, but well, this will time show. > So let me summarize the current obstacles on the road to working > together or even merging projects (at least the ones mentioned in this > discussion): > > - mingw.org requires proper (PD) sources of where a win32 api call was > found - meaning that Microsoft's own header files are excluded - while > mingw64 has no such requirement, meaning that Microsoft's own header > files can be used as a source To clarify this point. We don't allow patches copied directly from MS own headers. We simply are reviewing msdn provided information (via RFC's, internet articles, etc) to verify that provided information is correct. Sadly we had to notice that msdn information is sometimes wrong ... Indeed, we allow (and use) for verification only third-party (non mingw-w64-member) information coming from users, which aren't contributing to our project in source. Additionally we begun to co-operate with some other projects to ease maintance and best quality of platform headers. > - mingw.org has everything released in the public domain, while > mingw64 has different licenses for different parts of mingw - > including a clause that covers PD works in countries that have no > (voluntary) public domain > > - mingw.org and mingw64 have radically different mailing list > guidelines (including the guidelines for the project maintainers) > > Most of these gaps seem bridgeable to me, and while there needs to be > considerable work in order to bridge them, I think the advantages of > only a single team clearly outweigh the work that needs to be done > here. > > I have a question about the mingw64 licensing, that I believe has been > asked but not answered. There is a clause that turns public domain > works into ZPL licensed works in countries where they can't be PD. > Wouldn't this be relicensing this software, for which you need to have > the author's permission to do so? Well, the source code we used (and be sure w32api is merged into our header and our headers aren't based on it) from mingw.org was already derived by us. So at least the derived work can be relicensed by us as wished. But in fact PD allows explicit the relicensing, so this is a real non-issue - as our lawyers already had pointed out to us. We try to keep PD license generally for headers. For source code we are using the copyright choosen by initial author - even if those files sometime are already mainly rewritten-, as this sounds to us as just fair. > Of course you would have such permission from authors that provided PD > code for the mingw64 project after that clause was invented (perhaps > this should be clearly stated for authors, so they release it as such > by intension not "accidentally"), but how about code that was not > expressively released into the public domain with this clause in > effect? We provided for this our license files and explicit encourage people to enter themselves to our AUTHORS file. > I'm willing to help on resolving these issues, but my input would most > probably not be a code contribution, as I simply do not have the > necessary skills for that. So if there's anything else I can do, > please let me know. > > Jasper Horn Kai -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | (")_(") him gain world domination |
|
From: Jasper H. <jas...@gm...> - 2010-06-29 09:40:57
|
Kai Tietz wrote: > But in fact PD allows explicit the relicensing, so this is a > real non-issue - as our lawyers already had pointed out to us. I thought this would be an issue because the countries in question do not have a PD, so you wouldn't be able to relicense it based on that either. However IANAL and if it's been pointed out by lawyers, than it's probably a non-issue. Thanks for the clarification, Kai. There is another obstacle that hasn't been mentioned in this discussion, but which I just realized: - 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) Jasper Horn |
|
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-29 11:20:34
|
On Tue, Jun 29, 2010 at 4:39 AM, Jasper Horn <jas...@gm...> wrote: > Kai Tietz wrote: > > But in fact PD allows explicit the relicensing, so this is a > > real non-issue - as our lawyers already had pointed out to us. > > I thought this would be an issue because the countries in question do > not have a PD, so you wouldn't be able to relicense it based on that > either. However IANAL and if it's been pointed out by lawyers, than > it's probably a non-issue. > > Thanks for the clarification, Kai. > > There is another obstacle that hasn't been mentioned in this > discussion, but which I just realized: > > - 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) > > Jasper Horn > > It might be possible to package the subversion client for MSYS, if we package the required dependencies too. Those dependencies, last I checked, are: libapr and libapr-util, sqlite, and zlib. The optional dependencies are: libserf, openssl, berkleydb, and libsasl. There are, of course, the optional dependencies to support language bindings like Perl, Python, etc. We already have Perl, openssl, and zlib. So the most important ones would be libapr & libapr-util, and sqlite. I think SF uses Berkleydb for the backend, so bdb would be needed too. Since svn protocol is used on SourceForge, libserf is not needed. Obviously to commit to the SVN server over svn protocol, you need to be able to authenticate. That drags in libsasl. So, apparently the only thing we could possibly drop from porting would be language bindings.... |
|
From: Earnie <ea...@us...> - 2010-06-29 16:10:09
|
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. -- Earnie -- http://www.for-my-kids.com |
|
From: Erwin W. <wat...@xs...> - 2010-06-29 18:42:19
|
Op 29-06-10 18:09, Earnie schreef: > 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. > > Anything is better than CVS. Keith once mentioned that most of the current MinGW CVS archive is obsolete stuff. A big problem with CVS is that you can't change directories once they are checked in. All newer VCSes, like SVN, can remove and move directories. That makes it easier to keep your database clean. The step from CVS to SVN is small from a user perspective. When you are familiar with CVS, SVN is easy to learn. Mingw64 already uses SVN. There is a good windows native version, so you can save the trouble of porting. SVN treats all files as binary, there are no problems with text files with unix line endings. I would say that SVN is a pragmatic good choice to get the combined Mingw/Mingw64 development going. When the number of developers grows very large, you have to thing of something else. Erwin |
|
From: Earnie <ea...@us...> - 2010-06-29 19:29:26
|
Erwin Waterlander wrote: > Anything is better than CVS. That depends on ones perspective and thinking. > I would say that > SVN is a pragmatic good choice to get the combined Mingw/Mingw64 > development going. When the number of developers grows very large, you > have to thing of something else. I doubt that SVN is a good choice. Cygwin (IOW Red Hat) controls that VCS and they still use CVS for sourceware.org and they will not be changing because some MinGW users have a hankering to. Better would be to use the git conversion scripts, then you can use your favorite CVS, SVN or GIT commands. -- Earnie -- http://www.for-my-kids.com |
|
From: Jasper H. <jas...@gm...> - 2010-06-30 00:52:54
|
Earnie wrote: > 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. >From this post: http://thread.gmane.org/gmane.comp.gnu.mingw.user/33348 I figured that MinGW only wants to use a VCS that they provide a client for themselves. I guess I was mistaken in that conclusion. > 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. It was clear to me that there was no willingness to move to another VCS without a good reason to do so. However, I brought it up again in this context because I believe there is a good reason to do so here. Using the same VCS on mingw.org and mingw64 would make cooperation easier (at least, that's what it appears like to me) and is very much a requirement if a merge is to happen. There are three ways to achieve using the same VCS: - mingw64 switching to CVS - mingw.org switching to SVN - both switching to something else entirely I believe the first option can be discarded without any further explanation. Some time later Earnie wrote: > Cygwin (IOW Red Hat) controls that > VCS and they still use CVS for sourceware.org and they will not be > changing because some MinGW users have a hankering to. I don't quite get what you are saying there, but if I can read your message as "There is a good reason we need to support CVS commands, and we cannot change that reason", no more explanation will be necessary. > Better would be > to use the git conversion scripts, then you can use your favorite CVS, > SVN or GIT commands. 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. Jasper Horn |
|
From: Earnie <ea...@us...> - 2010-06-30 12:32:09
|
Jasper Horn wrote: > Some time later Earnie wrote: >> Cygwin (IOW Red Hat) controls that >> VCS and they still use CVS for sourceware.org and they will not be >> changing because some MinGW users have a hankering to. > > I don't quite get what you are saying there, but if I can read your > message as "There is a good reason we need to support CVS commands, > and we cannot change that reason", no more explanation will be > necessary. > http://www.mingw.org/wiki/Official_CVS_Repository >> Better would be >> to use the git conversion scripts, then you can use your favorite CVS, >> SVN or GIT commands. > > 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. -- Earnie -- http://www.for-my-kids.com |
|
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-30 12:51:13
|
On Wed, Jun 30, 2010 at 7:11 AM, Earnie <ea...@us...>wrote: > Jasper Horn wrote: > > Some time later Earnie wrote: > >> Cygwin (IOW Red Hat) controls that > >> VCS and they still use CVS for sourceware.org and they will not be > >> changing because some MinGW users have a hankering to. > > > > I don't quite get what you are saying there, but if I can read your > > message as "There is a good reason we need to support CVS commands, > > and we cannot change that reason", no more explanation will be > > necessary. > > > > http://www.mingw.org/wiki/Official_CVS_Repository > > >> Better would be > >> to use the git conversion scripts, then you can use your favorite CVS, > >> SVN or GIT commands. > > > > 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. > > -- > Earnie > -- http://www.for-my-kids.com > > 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? |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X