Hyper-V ICS 1.0 (w/Synthethic Network Driver) for pfSense 2.1 & 2.1.1
-
Sorry i should correct my mistake "freeware" with "Freeculture" (share-alike) license.
http://creativecommons.org/freeworks
As you can see: http://creativecommons.org/licenses/by-sa/4.0/legalcode
is: Attribution-ShareAlike 4.0 InternationalUnless you consider all that not opensource (even tho it actually forces everyone using the code to keep it opensource) i am really not sure what your definition of opensource will be.
===================================================================================================================
Why is the Share-Alike license a free culture license?
ShareAlike doesn’t place any restrictions on the type of use–its only difference from the BY license is that it requires works that build upon it to be released freely. (Usually, under the same license, but there may be other compatible licenses in the future.)This is different from the NC and ND licenses, which restrict some types of uses entirely, regardless of whether those users would contribute their work back to the commons.
that i have breached your agreement is kinda odd considering we haven't actually done anything but you keep seeming to miss that.
Apparently giving a example of a license we like to see (preventing closed source) didn't sit well with you.
That my English isn't perfect, granted it's my 3rd language so mistakes will be made. we can talk in my native language if you prefer?.
That i am deceptive.. what gave you the idea on that? my entire life i been called too direct.
You can even see that in earlier conversations where i gave the site we are planning to open AND that we expect you to check it out on any flaws.I have also said countless of times we will make sure the licensing aspect will be correct following legal laws, and gave you an example of the license we are looking into.
Instead of talking like a decent human being you just keep attacking me, and now also my company.
You really wonder why your own contributors are looking for a path far away from you?As far as how i run my company: my company has been ran for 9 years with success, we deliver 24/7 Support with a no-cure no pay guarantee, 300+ satisfied and returning customers all in the IT and Hosting business.
Reasons why our customers like us: Because we are honest and fair. (reflected in all their feed backs).
I can't imagine a situation where we have deceived you, we have talked with you for weeks, on a simple subject.
That you where planning to receive/ view and use our code was obvious from the start it's also the reason why you haven't seen it without a agreement in place.in native language "wat je zegt ben je zelf", translation: what you say is what you are your self.
bit like: when you point a finger to someone there's 3 pointing back at you.It's actually my dev that was already convinced there was no way to reason with you and we should fork it after the second email.
I however thought there was a way to reason with you, turns out my dev was right and we just wasted weeks for nothing while people still don't have a good firewall they can virtualize..As far as your references to the PFSense license: you might actually want to check your site, as a detailed license isn't to be found.
BSD license and GPL license do allow people to dual-license as they please. (meaning our codes can be under our license and yours can stay under yours)
It also does not fall under "Re-license PFSense" it falls under our codes are under a different license.
Much like the projects PFSense is using fall under different licenses then the PFSense license.Most funny part: you do actually allow that part following your site, if people use codes made by others they have to provide you with the type of license their distributed under.
Common practice to simply include their license under their code and your license under your code if there's a difference.
Only thing you have to make sure is that their license is inline with the type of license you distribute under.With the share-alike license it's compatible however restricts other forks from making it closed source IF they keep our code.
A little advice for you:
Stop pushing everyone away with your attitude, people are generally here to improve the project without bad intentions.
It appears you think everyone has bad intentions and you react as such.
it might be true in 1 out of 100 cases, but the other 99 where here with good intentions and you chased them away by treating them as a criminal.and in the end.. people will treat you how you treat them.
-
Sorry i should correct my mistake "freeware" with "Freeculture" (share-alike) license.
http://creativecommons.org/freeworks
As you can see: http://creativecommons.org/licenses/by-sa/4.0/legalcode
is: Attribution-ShareAlike 4.0 InternationalUnless you consider all that not opensource (even tho it actually forces everyone using the code to keep it opensource) i am really not sure what your definition of opensource will be.
Rather than get into what I consider Open Source to be, or what you consider it to be, I quoted the Open Source Definition.
http://opensource.org/osdthat i have breached your agreement is kinda odd considering we haven't actually done anything but you keep seeming to miss that.
This reads a lot like, "I've not molested your child yet."
In any case, you readily state that Key4ce hasn't signed the CLA or License, state that only you can bind the company, that Angelo has signed them, (or has otherwise acquired access to the pfsense-tools repo), and that you are prepared to distribute. You've provided notice that the CLA and License agreement are not in-force, so I've provided notice that you don't have a license.
Apparently giving a example of a license we like to see (preventing closed source) didn't sit well with you.
Not at all. The pfSense license agreement also prevents closed source. What didn't sit well with me is that you are:
a) relicensing pfSense (which is not allowed, and will cause a revocation of the license.
b) calling what you're doing "open source", when it fits neither the definition of Open Source or Free Software.That my English isn't perfect, granted it's my 3rd language so mistakes will be made. we can talk in my native language if you prefer?.
As you prefer.
That i am deceptive.. what gave you the idea on that? my entire life i been called too direct.
Funny thing. The same is true of me. Yet you castigate me for being direct. Seems to be another funny thing.
I have also said countless of times we will make sure the licensing aspect will be correct following legal laws, and gave you an example of the license we are looking into.
What is a "legal law"? How does one "follow a legal law"? Also, there is a difference between what one says one will do, and what one does.
Instead of talking like a decent human being you just keep attacking me, and now also my company.
You really wonder why your own contributors are looking for a path far away from you?Here you make an assertion without providing evidence.
I can't imagine a situation where we have deceived you, we have talked with you for weeks, on a simple subject.
That you where planning to receive/ view and use our code was obvious from the start it's also the reason why you haven't seen it without a agreement in place.I notice your attempt to turn this around. As they say in the US, "Nice Try. (Try again.)" I always said that we needed an agreement in-place before I received and reviewed your code, and that I was unwilling to accept it until the CLA and License agreement were in-place. Once I said that,
you put up a front that you were never going to sign it. Since you state that you will never sign it, you don't have a license. Q.E.D.It's actually my dev that was already convinced there was no way to reason with you and we should fork it after the second email.
I've always said that forks are allowed. Forking requires that you sign the CLA and License agreement, and then follow the terms in the license agreement (attribution, can't call it pfSense, acknowledge that our marks are valid and agree to not challenge them, etc.) Despite all the suspicion here, there is no 'trap'. It's not a method to end up with ownership of your code. It's simply a way for us to defend our marks against people who want to "clone" pfSense and it does the same thing you requested, it puts a condition of acknowledgement of the origin in the bargain.
The thing that people seem to object to is that any code given back has to be given to us with a license to any patents that you have that you (claim) cover the contributed code, and a license to the code to do with as we deem. This was put in to protect the project and community (and yes, ESF too.) I'm not going to detail the backstory here, but there is one.
The 'side-effect' that people seem to find distasteful is a jaundiced read of the language (completely allowed) where we end up being able to use said code in a proprietary product.
Here is the thing about that: When I came into BSD Perimeter (which 'became' ESF), there were 22 private forks of pfSense that BSD Perimeter was being paid to maintain. I've eliminated all 22 of them. Every. Single. Last. One. There was much protest about it, too. People whined that they were losing their private-lable product. My response: "Just run pfSense." ESF doesn't have any proprietary software (there are some fallow repositories, but these are not actively maintained.)
I would much rather that the Key4ce technology was in pfSense than not in pfSense. I'm just unwilling to sacrifice the rest of the codebase to a set of terms that are not Open Source.
So you can accuse me of laying in wait to rip-off your code, but it's not true. It's simply not true.
You (or others) can accuse me of trying to turn pfSense into Vyatta, but it's not true.
You (or others) can say that your license is "open source", but in your case, the Creative Commons license doesn't even claim what you say it does.I guess I could be deceptive and just agree to your license, and then comply with said license, rather than your interpretation of it. Then what?
I however thought there was a way to reason with you, turns out my dev was right and we just wasted weeks for nothing while people still don't have a good firewall they can virtualize..
Many people use pfSense in a virtual environment today with success.
As far as your references to the PFSense license: you might actually want to check your site, as a detailed license isn't to be found.
I've provided links in this thread and elsewhere.
BSD license and GPL license do allow people to dual-license as they please. (meaning our codes can be under our license and yours can stay under yours)
If you are the original author, (or are otherwise the copyright holder, via assignment or otherwise) then yes, you can "dual license". But you can't "dual license" code that belongs to someone else. That would mean you are re-licensing it.
It also does not fall under "Re-license PFSense" it falls under our codes are under a different license.
This is true. Your code can be licensed in any way you see fit. Granted.
But if said license is not acceptable to the project, then it can't be used upstream.
Much like the projects PFSense is using fall under different licenses then the PFSense license.
I don't understand what you mean here.
-
I tried to edit this above 6 times and it wouldn't take. Following the paragraph about "When I came into BSD Perimeter" and "22 forks".
I suppose one could see this as my objecting to forks. Not the case here, as this is about ESF supporting pfSense, not forks of pfSense.
"All the wood behind one arrowhead." and similar sayings. All we do is pfSense. We provide pfSense, we maintain it, we sell services around it, and provide support for it, but we don't sell pfSense. I'm trying to see the pfSense user base and community grow, and keeping pfSense open source aids in that effort. -
@gonzopancho:
This is true. Your code can be licensed in any way you see fit. Granted.
But if said license is not acceptable to the project, then it can't be used upstream.
I am just talking about my code, and we do not release "my" code under anything else then opensource.
check ur mailbox, check everything up here and you will see: thats the sole purpose of my resentment of your license.You don't have to like my license, it's exactly the reason why we moved forward with a fork (Plan B).
We have always been clear about the fork aspect if you do not meet what we seek, and thats not to mess pfsense up, or to get things closed source.
quite on the opposite: we DEMAND opensource and to keep it that way.WE do NOT relicense PFSense, and we never planned to violate your terms, even now we are still trying to figure out a way to implement 2 of your demands in the license that contridict, and for example in short advertisements –> there will be no way to include your mandatory requirement to the advertisement.
in return we are seeking legal boundry's to your demands, as when you prohibit advertisements it gets in the way with default legal law regarding your license addatives.
That being said: i still seek a way to comply to your terms without compromising basic laws.
I have never meant to violate your licenses, and never said anything otherwise.
You on the otherhand suspended us for no reason even though you still try to justify it, truth be told you given me more then enough reason to never allow you in our source due to your intentions described publicly here. however lets just state i will be the better man on this, as my intentions never changed: a Opensource firewall that is virtualized.As far as PFsense goes:
Your actually the one in the way of PFSense growth, you turned your own contributors against you.
In short.. if your for PFsense then your for contributions, growth, etc.
as you show with us, and people before us –> you actually have no problem taking it all down, diminishing its existence just because you see it as a threat.
If you just asked them a simple question like "lets publish this in our official repo" --> you would already have a basic hyper-v functionality.Just your attitude in the original posts already nearly made us fork it from the start, i was hoping there was some reasoning with you but ended up in a waste of time.
You can ask anyone around us: did we want this under PFSense: yes we 100% did, we never wanted to fork it, even now we don't really want to but feel forced to.
In our eyes forks has no point, its actually the main cause why Linux and Unix is SO far behind on everything and failed to succeed.
safe to say: what we are doing is the last thing we wanted, yet we felt like there was no other choice available, we stick to what we believe in, and that includes distributing our codes made for free –> stay for free. -
I have a long rebuttal to Marco's comments here, but the forum software doesn't seem to want to allow me to post.
I've sent he and Angelo the rebuttal via email, it's conclusion reads as below.
I could spend a couple more hours trying to figure out what the formatting issue is with my post, but I think the end of it states my issue. I can't sign up to Marco / Key4ce eliminating section 3 of the license agreement, because it leaves pfSense, the community and ESF open to an infringement suit.
On the chance that Marco didn't understand what Section 3 is about, and that he is instead concerned with what I interpret his comments to mean (explained below), I've offered the other dilemma here: pfSense can't be Open Source with the restrictions he seeks.
Suffice it to say that I'm not seeking a fork here, but if Marco demands that pfSense no longer be Open Source, then I will not accept his terms.
In our eyes forks has no point, its actually the main cause why Linux and Unix is SO far behind on everything and failed to succeed.
safe to say: what we are doing is the last thing we wanted, yet we felt like there was no other choice available, we stick to what we believe in, and that includes distributing our codes made for free –> stay for free.We're talking past each other now. Let's get back to the subject-at-hand.
Let's assume, for now, that your objection to the Section 3 is really about the "sale" of pfSense, rather than not wanting to grant us a license to any patent you own that would enable you (or a successor party in interest to those patent rights) to claim patent infringement on pfSense via your changes to it.
Let's also assume, for now, that your definition of "sale" is really "collect money in-exchange for a license to pfSense", or even "sell the company that holds these agreements, and the Copyright to pfSense, to a different party, who might "close source" the tree, or at least the parts you contributed to it.
I don't know if I'm right in these, so, if I'm not, then please, explain the scenario(s) that you're concerned about.
Then, please show me any code that has been contributed to a major Open Source project that has the restriction you state.
Linux? Nope.
FreeBSD? Nope.
OpenBSD? NetBSD? Nope, Nope.
FreeNAS? Nope.Please. Provide me with an example.
I don't think you'll find one. All of these are Free and Open Source software. The GPL won't allow the restriction you state, so all of Linux (and glibc, gcc, etc) won't provide an example.
None of the other projects I've named would allow it either, because they're all proud of being "more open than linux" (read: "the GPL is viral/evil/…") They all encourage commercial forks of their project. They are proud of the commercial forks of their project.
I could provide many other examples.
The MPL has been approved as both a free software license by the Free Software Foundation, and an open-source software license by the Open Source Initiative. So nothing covered by the MPL has your restriction. By extension, nothing covered in this list: https://www.gnu.org/licenses/ or this list: http://opensource.org/licenses/ allows your restriction, either.
This covers most of what people deem "Open Source" and/or "Free Software", Marco.
-
We are going back and forth.
Lets keep it simple: We like the "share alike" license, and we publish OUR code under it.
we are 100% allowed to do so.
we are 100% keeping your license in tact.
even better: we actually had to add your license to quite a few places you forgot to place it your self.
all to 100% comply to your terms.You on the other hand revoked Angelo's license, for breaching your agreement, this is still not reasonable or explainable when all we did was talk and comply to your agreements.
but hey, whatever you feel like doing, we are past that.
I'm also kinda past this whole talk, as it's pointless and quite meaningless.
not to mention i am sure bored the previous posters out of their mind.Please let me know if you find anyway we do not uphold your agreements.
but asfar as we can tell: we comply to all of them and to basic legal law it self.When you get access to our code i do expect the same of you, so we don't have to continue talking and wasting eachothers time.
I wish you and PFSense good luck.
Regards,
Marco -
If you all are done now, how about sharing those drivers so the rest of us can use pfSense on Hyper-V?
-
Well,
As said we now launched our own fork which first beta is available at https://virtualpf.com
Stable will be released at 30 November.However PFSense won't be able to integrate our code into their branch without publishing it in the share-alike license (preventing closed source).
Regards,
Marco -
Would you consider providing a tutorial to help users like myself build Hyper-V support from public source that isn't being fought over?
To be clear, are pfSense forums are blocking the links on the op-post or have you guys removed them?
Your competing build may make a lot of sense in a number of ways, but it's far from ideal for those of us who have used pfSense for years (and have purchased support even) and from the little bit I've read so far, it sounds like you are refusing use of code that is otherwise open-source which would put you in more of a position as a barrier than a solution provider to someone like myself. That's wouldn't encourage me to try your alternate solution, even if it opened up the Hyper-V option.
I want to make sure I understand who is creating barriers here because that will vastly impact my opinion and the choices I make. Finger-pointing doesn't change that either, responsibility (ability to respond) supersedes "fault". That means that where it counts, both your organization AND pfsense can be equally responsible where I'm concerned, but if that's not the case, I would want to know that as well.
-
Well in short: We normally publish under GPL
but as this has a BSD license base it's not possible.
Next in line is Creative Commons share-alike license.quick overview:
http://creativecommons.org/licenses/by-sa/4.0/it pretty much mandates that all and any codes based up on our codes has to stay opensource (share-alike).
as in the end, what we create for free should stay for free.As far as finger pointing goes: We both just want/require different things when it comes to source-codes. so no real party to blame to other then both have different requirements and wishes.
There's no quick howto guide on how to make PFSense fully work with Virtualized environments.
PFSense 2.2 beta will have some basic drivers in it as it's based up on FreeBSD 10 which has it build in
however alot of components like CARP (clustering / loadbalancing) won't work on Hyper-v. (it's why we spend well over 8 months on development on getting it to work 100%).Regards,
Marco -
You can't relicense the pfSense base.
To be perfectly clear, you can choose whatever license you like for your code.
but you can't relicense the pfSense base, which you appear to have done here.
-
And in our experience, pfSense works fine on Hyper-V.
The Key4ce folks are allowed (of course) to make other claims.
Let the market decide.
-
Jim, you can hold your accusations for your self.
We can't re-license the base which is exactly why we can't apply GPL but CAN apply Share-alike.
Unlike GPL, Share-alike can be applied for just a part of the code (OUR CODE) in an entire base you provide (the fork).
which is why we opted for share-alike rather then the more common GPL.
But please note whenever you use OUR code anywhere else the ENTIRE code has to stay opensource (share-alike).As you can see from the license, codes, and even download sections no pfsense licenses, copyrights, etc have been violated.
We are still working on scrubbing the PFSense name from the builder etc (not the copyrights but the name it self) so we can publish the builders without a CLA in place without it affecting PFSense.so the builder/tools can only be used with VirtualPF, and won't affect your CLA agreements before people get access to PFSense tools for PFSense it self.
As i told you countless of times: we ARE compliant to license agreements, we ARE NOT planning to voilate anything even though you keep trying to tell everyone that we got bad intentions and don't comply.
As far as CARP not working.. even FREEBSD mailing list tells you it won't:
http://lists.freebsd.org/pipermail/freebsd-net/2014-March/038053.htmlIt won't on Hyper-v. (stays in init)
It will when you extensively re-develop the protocol like we did and make it compliant with any virtual environment.You might also want to know you need to adjust other codes to use 10+ Gbit speeds in Freebsd.
Even though you got the drivers in place it will by default not allow you to use that much speed (it's capped to less then 1 Gbit).Regards,
Marco -
Jim, you can hold your accusations for your self.
Since I am the dude that deals with this for pfSense, that's not going to happen.
We can't re-license the base which is exactly why we can't apply GPL but CAN apply Share-alike.
Nope. And I'm sure you know better. You can choose whatever license you like for your changes, but the code is licensed as a whole (via the license agreement, that you "signed".) That license agreement prohibits you from relicensing the code.
Unlike GPL, Share-alike can be applied for just a part of the code (OUR CODE) in an entire base you provide (the fork).
Yes, you can apply whatever license you like to YOUR CODE.
You can't relicense what you got FROM US.
which is why we opted for share-alike rather then the more common GPL.
But please note whenever you use OUR code anywhere else the ENTIRE code has to stay opensource (share-alike).Yes, YOUR LICENSE applies to YOUR CODE. Not pfSense.
As you can see from the license, codes, and even download sections no pfsense licenses, copyrights, etc have been violated.
We are still working on scrubbing the PFSense name from the builder etc (not the copyrights but the name it self) so we can publish the builders without a CLA in place without it affecting PFSense.Unfortunately, your statement is not true.
For example, where is the required attribution on this page?: https://virtualpf.com
And… I knew you were after freeing the builder code. Unfortunately, you'll now have to follow the train, or live with your fork.
C'est la vie, such is open source. You chose to fork.
so the builder/tools can only be used with VirtualPF, and won't affect your CLA agreements before people get access to PFSense tools for PFSense it self.
As i told you countless of times: we ARE compliant to license agreements, we ARE NOT planning to voilate anything even though you keep trying to tell everyone that we got bad intentions and don't comply.
As far as CARP not working.. even FREEBSD mailing list tells you it won't:
http://lists.freebsd.org/pipermail/freebsd-net/2014-March/038053.htmlMany people are having good luck. https://forum.pfsense.org/index.php?topic=75549.0
You might also want to know you need to adjust other codes to use 10+ Gbit speeds in Freebsd.
Even though you got the drivers in place it will by default not allow you to use that much speed (it's capped to less then 1 Gbit).I've allowed many times, in many places that work is underway on 10Gbps.
As for your release.. (let's stop talking about licensing, because it's obvious you don't care, and instead talk technology):
The only functional differences I see in your release (after quickly running through a test install) is things your team broke - they screwed up interfaces in general (assignments screwy, DHCP interfaces don't pull IPs the way they should), the ISO doesn't reboot post-install (spews "vm_fault pager read error" over and over and over until you reset the machine).
Your new theme on the web interface is broken in a variety of ways. You try to load some sort of VMware tools, but do so in a broken manner that causes VMware Workstation to complain.
You claim, "We have modified CARP extensively to work on any virtual platform" - as if it didn't already. (It does!)
The GUI-side is the same, if you modified the OS you might have broken something. I've not had time to even look for
the source code (where is it?) much less check out what you've done.From what we can tell, your release is effectively 2.2, except on an older 10-STABLE from before we moved to 10.1, with a lot more stuff that doesn't work.
pfSense 2.2 will be based on FreeBSD 10.1-RELEASE, and there is a lot of work that came after your 14 March posting above.
https://virtual-ops.de/?p=600
https://wiki.freebsd.org/HyperV
http://azure.microsoft.com/blog/2014/05/22/running-freebsd-in-azure/But hey, it's Open Source!
-
Jim, again we only licensed our code, your code stays in tact and so does your license.
The code as a whole is then known as dual licensed and it is shown very clearly (altho the legal page is still in the making to clear it out further).
Thats why where in some sections where we changed you will find your License.txt and our License-VirtualPF.txt.Bit odd you can claim we don't care about licensing when we spend so much time argueing about it tho.
also not something i care to do again. we checked it over with multiple legal shavy people who all said what we did is actually over doing what is required.Which makes me wonder 1 or 2 things:
- Your either not fully aware of legal laws and limitations of your own legal aspects
- Your very aware but pretend not to know and scare people out of it and/or to see what it is they exactly know.
That i don't have to put credits on every website page: that is correct. you can ask your lawyers and they will tell you that claim is not possible under international laws. (and is also not written in your Legal section.. please read your own legal section careful.)
We did however keep it in the license page within the software and everyone can see it in full view before download.
We did not release any git code yet as it's still fully compatible with PFSense (including the builder).
I doubt you want agreements and CLA's to get crossed.However we expect that part to be 100% available for public within about 3 weeks (after we fully integrated freebsd 10.1 stable)
The agreement Angelo signed does not limit the use or fork of any code so we still comply to that too.
As far a tech:
Ours already works and tested with over 40 Gbit's speeds.The gui is indeed not finished, if you check the roadmap –> it was only made in 5 days and got quite alot left to redo (it's why we only made a Beta release their not intended on being perfect but atleast function wise you can test)
The Ejecting CD on what Virtual Environment is it tested? (version)
as we confirmed it working on vmware esxi, and vmware desktop (both latest versions).That our release is effectively 2.2 is total BS and you know it.
CARP was just one, supporting 10 Gbit+, supporting AND automatically installing any virtual platform driver automatically based up on platform detection would be another. gui improvements is one, and translations to Chinese, Dutch, German are on their way.Much more features have been added and will be carefully detailed before November 30th
It's just the first release, it won't truly define our selfs just yet. that will come with stable 2.
That you think CARP is fully working: sorry we already confirmed this: it wasn't, even this week we found some new bugs with it.
But ofcourse feel free to believe it is, I personally think our testing grounds are a bit more advanced then yours (as below 1 Gbit speeds won't be accepted by any of our customers, not even our own environment can go below 20 Gbit else we pinch our customers off lol).Regards,
Marco -
@gonzopancho:
You claim, "We have modified CARP extensively to work on any virtual platform" - as if it didn't already. (It does!)
Sorry, but thats not true, you can't use CARP with Hyper-V with current 2.2 (stucks in init as key4ce said)
-
@gonzopancho:
And in our experience, pfSense works fine on Hyper-V.
The Key4ce folks are allowed (of course) to make other claims.
Let the market decide.
Everywhere I've found a solution, it is to use legacy nics with a disclaimer that it should not be used in production. Is there another solution or is that advice wrong?
Afterthought: …or is this a reference to 2.2? I'm out of the loop and didn't realize it was available yet since I've only been looking at RELEASE. I realize it is considered BETA, but would anyone with the project be willing to call it stable enough for more basic use in production (NAT, Firewall, IPSEC)?
Thanks in advance
-
Jim, again we only licensed our code, your code stays in tact and so does your license.
The code as a whole is then known as dual licensed and it is shown very clearly (altho the legal page is still in the making to clear it out further).
Thats why where in some sections where we changed you will find your License.txt and our License-VirtualPF.txt.Bit odd you can claim we don't care about licensing when we spend so much time argueing about it tho.
also not something i care to do again. we checked it over with multiple legal shavy people who all said what we did is actually over doing what is required.Which makes me wonder 1 or 2 things:
- Your either not fully aware of legal laws and limitations of your own legal aspects
- Your very aware but pretend not to know and scare people out of it and/or to see what it is they exactly know.
That i don't have to put credits on every website page: that is correct. you can ask your lawyers and they will tell you that claim is not possible under international laws. (and is also not written in your Legal section.. please read your own legal section careful.)
We did however keep it in the license page within the software and everyone can see it in full view before download.
We did not release any git code yet as it's still fully compatible with PFSense (including the builder).
I doubt you want agreements and CLA's to get crossed.However we expect that part to be 100% available for public within about 3 weeks (after we fully integrated freebsd 10.1 stable)
The agreement Angelo signed does not limit the use or fork of any code so we still comply to that too.
As far a tech:
Ours already works and tested with over 40 Gbit's speeds.The gui is indeed not finished, if you check the roadmap –> it was only made in 5 days and got quite alot left to redo (it's why we only made a Beta release their not intended on being perfect but atleast function wise you can test)
The Ejecting CD on what Virtual Environment is it tested? (version)
as we confirmed it working on vmware esxi, and vmware desktop (both latest versions).That our release is effectively 2.2 is total BS and you know it.
CARP was just one, supporting 10 Gbit+, supporting AND automatically installing any virtual platform driver automatically based up on platform detection would be another. gui improvements is one, and translations to Chinese, Dutch, German are on their way.Much more features have been added and will be carefully detailed before November 30th
It's just the first release, it won't truly define our selfs just yet. that will come with stable 2.
That you think CARP is fully working: sorry we already confirmed this: it wasn't, even this week we found some new bugs with it.
But ofcourse feel free to believe it is, I personally think our testing grounds are a bit more advanced then yours (as below 1 Gbit speeds won't be accepted by any of our customers, not even our own environment can go below 20 Gbit else we pinch our customers off lol).Regards,
MarcoFor someone who wouldn't have a project without everything provided in the pfSense base, you come across very rude, unappreciative and ungrateful. You sound like you're using open-source ideals as a defense, rather than being a good player in the scene. If the claims made by other on the PFSENSE forums aren't true, what do you gain by arguing; especially when they're providing evidence?
Generally, only guilty parties or those in harm of penalty feel the need to continuously justify themselves because the truth speaks for itself.
Furthermore, you're enforcing what I said earlier; "I" am the type of customer you're going to be pursuing if you are actually trying to build a business, and you're doing everything in your power to ensure that I don't go anywhere near testing, let alone production use of your build. If your build is so different and superior, why not do it from scratch and stay away from these forums so that you can have more control, less licensing issues and more respect for the finished product. Of course, I'm just "a customer" so what does my opinion matter? :)
I will step out of the drama on that note and continue my search for how to run pfSense, stable, on Hyper-V.
-
@gonzopancho:
You claim, "We have modified CARP extensively to work on any virtual platform" - as if it didn't already. (It does!)
Sorry, but thats not true, you can't use CARP with Hyper-V with current 2.2 (stucks in init as key4ce said)
We're not done with CARP in 2.2.
-
I don't recommend even trying 2.1 on Hyper-V. That path leads to madness.
2.2 is in pretty good shape. There are 10 (count them, 10) outstanding bugs in the way of cutting a release candidate.
one of them concerns CARP.
try it out! (It's a VM environment, what do you have to lose?)
Jim