I have found that in r328060 someone restricted distribution of the package without maintainer update. As maintainer and package porter i am strictly against this. I am against disabling package build of the exfat. I am very tired to return to this discussion 100th time (yeah) and i personally think that someone have nothing to do. Few points from the past discussions on the net: a) other systems, including well-known like Debian, OpenSUSE and Gentoo are distributing binary packages and i never heard about any problems with it. b) I never heard any copyright problems or requests from MS to remove this binary packages. I don't see any points to be "proactive" and do anything before getting any requests from the patent holder. Because using this logic we should remove libav, FAT32 kernel implementation and tonn of other staff potentially hurts some other patents. c) there are at least few other, non-fuse, implementation publicly available. I also never heard about requests to remove them. From what i see now that someone disabled distribution of the package w/o maintainer aprrover. Why do we need maintainers them? Please revert it back or remove me from the port maintainers, thank you.
And license change is a full mess. Please do something with it, this should NEVER be done this way. https://svnweb.freebsd.org/ports/head/sysutils/exfat-utils/Makefile?r1=327772&r2=328060
same about http://www.freshports.org/sysutils/fusefs-exfat
(In reply to samm from comment #0) > I have found that in r328060 someone restricted distribution of the package > without maintainer update. As maintainer and package porter i am strictly > against this. Your feelings do not overrule portmgr _AND_ core: We should not distribute exFAT related packages due to licensing issues. Reviewed by: tabthorpe Approved by: portmgr (bapt), core > From what i see now that someone disabled distribution of the package w/o > maintainer aprrover. Why do we need maintainers them? Please revert it back > or remove me from the port maintainers, thank you. I am very happy to remove you as the maintainer. If you are serious about this, just confirm and it shall be done.
Assign to portmgr to let them handle this.
> > From what i see now that someone disabled distribution of the package w/o > > maintainer aprrover. Why do we need maintainers them? Please revert it back > > or remove me from the port maintainers, thank you. > > > I am very happy to remove you as the maintainer. > > If you are serious about this, just confirm and it shall be done. If you are not going to respect maintainers - yes, please. Also from all other freebsd ports I am maintaing. Why do you need maintainers if such weird and wrong changes are done without them? Lets do everything w/o it. P.S. i am porter of the exfat (as well as many other tools) to the FreeBSD. Such actions are not only non-polite but also very stupid. Could you please reply why license was changed from GPLv2 before removing me? Thank you. P.P.S. I am donating to freebsd project for years and really can't understand this logic. But okay, if you feel that its a good thing to do such crazy commits without notifying maintainer - go on and reset maintairship of the all my ports, thank you.
Also it would be great to know who personally approved this instead of "core". And how he can change third-party project license without letting author or maintainer aware of this, thank you.
So if a maintainer requests that all the legal restrictions are lifted from his ports, everyone should just blindly do it to afford him due respect? There are limits to maintainers can request, and denying requests that violate rules and even laws is not a sign of disrespect. And if such violations are going on, nobody needs to ask your permission to stop violating. You're the only one talking in non-polite terms btw. So go ahead and list all the ports you want to release.
This license change is just stupid. Author never used microsoft license and always was using GPLv2. This change make no sense at all. We never had any claim from microsoft or any other companies to do such change. Why don't you change FreeBSD license to microsoft this way? P.S. you can find all my ports, isn't it?
And John, could you please also tell why Debian do not have any issues when distributing this package for all supported platforms, as well as using author-defined GPLv2 instead of this crappy MS-License from nowhere?
(In reply to samm from comment #8) > This license change is just stupid. Author never used microsoft license and > always was using GPLv2. This change make no sense at all. We never had any > claim from microsoft or any other companies to do such change. Why don't you > change FreeBSD license to microsoft this way? > > And John, could you please also tell why Debian do not have any issues when > distributing this package for all supported platforms, as well as using > author-defined GPLv2 instead of this crappy MS-License from nowhere? I have nothing to do with any of this. I wasn't part of the any of the discussions, I don't know how the conclusions were made. I do know that I will not revert a commit that multiple portmgr and src committers and core were involved with. > P.S. you can find all my ports, isn't it? I asked you for 2 reasons. 1) So there's a documentation trail that you explicitly wanted it to be released 2) You're asking somebody to do work for you, so its reasonable that you try to make it easy on them and avoid undue decision making.
"I have nothing to do with any of this. I wasn't part of the any of the discussions, I don't know how the conclusions were made. I do know that I will not revert a commit that multiple portmgr and src committers and core were involved with." So i am asking who was involved in this and why this decision was done. Or its too much for the project contributor, maintainer and freebsd supporter?
1) Portmgr has been assigned to the PR several replies ago (by tijl@) they will tell you 2) You've got at least 3 names on the commit itself. Why don't you ask one of them directly, e.g. gavin? http://www.freshports.org/commit.php?category=sysutils&port=exfat-utils&files=yes&message_id=201309232136.r8NLaUu9084173@svn.freebsd.org
Just in case: 1) Official license of the project is GPLv2, not MS,see [1] 2) Project is registered on Sep 14, 2009 and never had any requests for removal from MS or other parties. 3) There are official binary debian [2], SUSE [3], ArchLinux [4] packages, as well as packages for many other operating systems. I am not aware of any claims agains them. [1] https://code.google.com/p/exfat/ [2] https://packages.debian.org/stable/exfat-fuse [3] http://software.opensuse.org/package/fuse-exfat [4] https://www.archlinux.org/packages/?q=exfat
(In reply to John Marino from comment #12) > 1) Portmgr has been assigned to the PR several replies ago (by tijl@) they > will tell you Ok, thanks. > > 2) You've got at least 3 names on the commit itself. Why don't you ask one > of them directly, e.g. gavin? > http://www.freshports.org/commit.php?category=sysutils&port=exfat- > utils&files=yes&message_id=201309232136.r8NLaUu9084173@svn.freebsd.org I already sent mail to the gavin@freebsd.org but do not have reply yet. From the same time nobody notified me about this change.
I digged in the mail archives and found that portmgr was informed on Jan 22 by core (gavin) of a possible patent violation. You were cc'd on all the mails and you also replied to a few of them. The decision to mark the port as restricted was taken to ensure that we do not create and ship any binary packages for the port. FreeBSD as a project and most of the FreeBSD.org infrastructure including package servers are located in the US so whatever you think of the US patent situation we have to follow US law in such cases. I cannot speak for any Linux distro but their situation might be different. Core and portmgr position in such cases is to avoid potential harm to the project. If you feel this decision has been wrong then we need some good arguments and or formal papers on this subject before we can reenable it. We could for example talk to the Debian maintainer and ask them if they have something to say about it. It might also help to see if other companies or projects were already contacted by Microsoft about it or if they have some official statement about it.
Please try o avoid the personal statements and stuff about giving back maintainership. I think this situation was communicated okay - you were contacted on Jan 22 and stayed in the loop while portmgr had to take a decision and yes your position was not followed. Portmgr and core have a veto right in such cases and there were some serious concerns that we might violate us patents and license terms. If this is wrong and we can come to a new conclusion this would be just fine for the project and especially the users. So I think if we want to make some progress on this matter please let's focus on the actual issues and concerns that were raised. Talking about maintainer reset, other ports or other people does not help at all. With my portmgr@ hat on.
(In reply to Bernhard Froehlich from comment #15) > I digged in the mail archives and found that portmgr was informed on Jan 22 > by core (gavin) of a possible patent violation. You were cc'd on all the > mails and you also replied to a few of them. > Thank you for reply and feedback. I been asked about restriction of the distribution and never about project license change. Of course license change is not possible without author approval and is a wrong step. > The decision to mark the port as restricted was taken to ensure that we do > not create and ship any binary packages for the port. FreeBSD as a project > and most of the FreeBSD.org infrastructure including package servers are > located in the US so whatever you think of the US patent situation we have > to follow US law in such cases. I cannot speak for any Linux distro but > their situation might be different. Core and portmgr position in such cases > is to avoid potential harm to the project. It is at least undertandable. From other side - we should remove a lot of packages which potentially violating someone patents in this case, including VLC, LibAV and many others. > > If you feel this decision has been wrong then we need some good arguments > and or formal papers on this subject before we can reenable it. 1) I think that at least license needs to be reverted back ASAP. It is not legal to change project license without code copyright holder (author) decision. And this is clear mistake, because project never been distributed under any of MS license and was using GPLv2 from the first commit. 2) About distribution i am open to discuss this. From other point i see that project itself never had and claims from the MS and living on google code for years. Also independed kernel-level GPLv2 implementation is hosted on github and also nobody from MS asked github to remove it. About patenting issues - there were a lot of rumors that FAT32 is also covered by some MS patents but we have it the FreeBSD kernel for years. > example talk to the Debian maintainer and ask them if they have something to > say about it. It might also help to see if other companies or projects were > already contacted by Microsoft about it or if they have some official > statement about it. I will send mail to the debian maintainer and ask if he had any contacts from MS or other concerns about this port.
This statement was found on the exfat mailinglist archives and seems to be copied from their wiki: "Microsoft has not released the official exFAT file system specification, and a restrictive license from Microsoft is required in order to make and distribute exFAT implementations. Microsoft also asserts patents on exFAT which make it impossible to re-implement its functionality in a compatible way without violating a large percentage of them.[11] This renders the implementation, distribution, and use of exFAT as a part of free or open-source operating systems or of commercial software, for which the vendors could not obtain a license from Microsoft, not only technically difficult, but legally impossible in countries that recognize United States software patents" Binary packages would fall into "distribution" section for sure. The author seems to be from Russia and so he does not need to care about US patents and reverse engineering is allowed in Russia too. There is also a thread about licenses in the mail archives: "The code (trunk) was recently relicensed from GPLv3+ to GPLv2+ (I've got permission from all contributors). All release versions (including 1.0.1) are under GPLv3+."
> > Binary packages would fall into "distribution" section for sure. The author > seems to be from Russia and so he does not need to care about US patents and > reverse engineering is allowed in Russia too. > > There is also a thread about licenses in the mail archives: > > "The code (trunk) was recently relicensed from GPLv3+ to GPLv2+ (I've > got permission from all contributors). All release versions (including > 1.0.1) are under GPLv3+." Is it sounds reasonable to restrict distribution and revert license to the GPLv2?
BTW, MS also claiming that FAT implementation is covered by patents and require license from them :) http://www.microsoft.com/about/legal/en/us/IntellectualProperty/IPLicensing/Programs/FATFileSystem.aspx
When we originally needed to restrict the ports, the LICENSE framework was relatively new. As I am not a ports committer, and didn't know full details about how it works, I took advice from several ports people about the best way to achieve what we needed to do - the committed changes are the sum of that. The change of listed license from GPLv2 to something else is purely due to the way the Ports license framework works - if you use one of the standard license types (e.g. "GPLv2") you are not able to specify any other restrictions over and above what that automatically provides. See the comments in bsd.licenses.mk for more information - "Case 1" wouldn't allow what was necessary to be done, so "Case 2" had to be followed. FWIW, the maintainer was involved with the original discussion, and was against the restrictions being applied. He was not involved with the creation of the patch eventually committed.
FWIW, FreeBSD as a project has made great progress in making packages usable, and would like to see as many people using packages as possible in the future. Restricting a port such that a package is not created is a decision nobody takes lightly - every port that has to be restricted reduces the utility of packages as a whole. We will never do this unless it is felt that this is absolutely necessary. Unfortunately for the ExFAT packages, it was felt to be necessary.
(In reply to Gavin Atkinson from comment #22) > FWIW, FreeBSD as a project has made great progress in making packages > usable, and would like to see as many people using packages as possible in > the future. Restricting a port such that a package is not created is a > decision nobody takes lightly - every port that has to be restricted reduces > the utility of packages as a whole. We will never do this unless it is felt > that this is absolutely necessary. Unfortunately for the ExFAT packages, it > was felt to be necessary. Thank you for reply. I have a few questions: 1) Is it still limitation of the License framework in the ports? Actually if it is then something needs to be fixed here, because: a) Code License and distribution models should not be mixed. E.g. GPL or BSD code can use something covered by patents (probably our case). b) It is looking weird, because it is labeling someone code with license it never had. 2) Could you please let me know why it was done against exFAT and was not done against in-kernel FAT implementation which is also covered by MS licensing program (see TOM-TOM case [1]). Thank you for reply. [1] http://en.wikipedia.org/wiki/Microsoft_Corp._v._TomTom_Inc.
My feeling is that this port should be GPLv2+ and RESTRICTED and NO_CDROM at least this was how we handled it in the past and it has allowed us to add a notice about the patent situation but we could not decide what exactly was allowed and what wasn't because it was only text. Nowadays with the new license framework it is much more fine grained and we can do clever things but it is all about licenses and not patents. In this case now we would need GPLv2 license with the usual restrictions and in addition to that a possibility to protect US based users of the patent situation.
> My feeling is that this port should be GPLv2+ and RESTRICTED and NO_CDROM From my point of view, this would be most correct. Faking code license, while the problem has actually nothing to do with licenses (but patents instead) feels wrong.
If the license is set as GPLv2, I believe we end up also hosting a copy of the distfile, which we must not do. Whatever the outcome, we want to ensure we never distribute either the package or the distfile from any FreeBSD.org infrastructure.
From bsd.port.mk: # RESTRICTED - Prevent the distribution of distfiles and packages to # the FTP sites or on CDROM (e.g. forbidden by license # considerations).
(In reply to Tijl Coosemans from comment #27) > From bsd.port.mk: > > # RESTRICTED - Prevent the distribution of distfiles and packages to > # the FTP sites or on CDROM (e.g. forbidden by license > # considerations). RESTRICTED is supposed to be the *old* way of doing things, the new way being the LICENSE framework.
How about adding GPLv2 to LICENSE and setting LICENSE_COMB=multi?
It's quite strange to use license framework for expressing patent problems.
(In reply to Tijl Coosemans from comment #29) > How about adding GPLv2 to LICENSE and setting LICENSE_COMB=multi? I've been wondering about that, yes.
(In reply to Dmitry Marakasov from comment #30) > It's quite strange to use license framework for expressing patent problems. It doesn't have to be strictly about copyright licenses. It works for any type of license.
It is sad that i never had explanation why this package should be restricted. 1) FAT32/FAT implementation is also covered by MS patents but exists in kernel for years. There are known legal issues (TOM TOM case) with it, but its not removed or restricted. 2) About source on freebsd mirror servers - it seems to be a paranoia, because source is living on US based Google Code services, also mirrored on US based github servers and there are no problems with that. 3) License of the code is only GPLv2. Restricting binary by setting fake license is not a good idea IMHO.
(In reply to samm from comment #33) > It is sad that i never had explanation why this package should be restricted. This might be confused by language, but from what I have read, you've been given numerous explanations going back months. To tell somebody that all of their previous responses went in one ear and out the other only serves to annoy them. I was translate this to: "I have not heard an explanation that I accept as valid, which saddens me".
(In reply to John Marino from comment #34) > (In reply to samm from comment #33) > > It is sad that i never had explanation why this package should be restricted. > > This might be confused by language, but from what I have read, you've been > given numerous explanations going back months. To tell somebody that all of > their previous responses went in one ear and out the other only serves to > annoy them. > > I was translate this to: "I have not heard an explanation that I accept as > valid, which saddens me". John, if you have nothing to add don't waste your and mine time, thanks a lot. For all other - no, there were no reply to the questions I asked, unfortunately. And i don't see how fat related issues are different from exfat related issues, especially if microsoft states that licensing is required for both filesystems.
(In reply to samm from comment #35) > John, if you have nothing to add don't waste your and mine time, thanks a > lot. Alright Samm, I'll stop wasting my time and yours -- consider it a standing promise on all PRs, current and future. I'm punching off now.