You keep repeating this as if this is not common knowledge. I get it, I think most bothering to read this far understand the distinction.
By this logic, simply forking the GPL GNU repository would open one up to liability. Forks are used for any number of things, be it personal use or branched development efforts. Not really your place to police them, the published license dictates usage and allows redistribution in original form. A situation where common usage of the license via repository fork opens individuals up to legal liability doesnāt exist, itās a complete reach. I can fork a repo with a button click.
Are you stating that the expectation is that any fork removes any instance of the term VESC to be free of potential liability?
@agentdev Third party distribution is no issue if the TM is stripped although Benjamin does not believe in forks that have zero or minor changes: https://vesc-project.com/Ethos
Distribution with the TM incorporated is an issue.
Vedder does not want old versions of VESC-Tool published. He has his reasons. I asked him many times if it is worth running an archive.
I can fork a repo with a button click.
Are you stating that the expectation is that any fork removes any instance of the term VESC to be free of potential liability?
What you can do and what regulations allow TM owners to do are two different matters. I did a little research on that and as far as I could see, there are cases where TM owners made use of their rights.
Statements like this are incompatible with law/license.
Personally, Iād love to see what Mr Vedder actually had to say on the matter of a simple GNU GPL v3 repo fork becoming a liability and/or requiring censorship of the term VESC.
I find it strange you continue to project āpersonal wishes & beliefsā onto a matter of OS licensure/trademark conflict. What has already been published via public license is already out there as such, and what he chooses to do in the future is his decision and irrelevant to the conversation at hand.
Just wait until CI build bots/services show up and start automated forking/building. Oof. You guys are in for a wild ride if youāve not been paying attention to modern OS development trajectory.
I find it strange you continue to project āpersonal wishes & beliefsā onto a matter of OS licensure/trademark conflict
Iām not projecting anything! You can do your own research and see how things are handled in different jurisdictions. A simple search brings up quite a lot of information and cases. WordPress, Rad Hat, Mozilla, etc.
When you apply personal statements about beliefs, wishes, wants, and other subjective opinions towards clearly defined licensure, it comes across as you projecting your own desires of what you wish the GPL to be. But the license doesnāt work like that.
Iāve read the VESC ethos. It has a lot of these subjective statements of desire, which are fine as a general guideline for contribution but nowhere in there does it say anything about forking requiring removal of the word VESC.
In fact, a large part of what it talks about is wanting the project to be open & inviting.
My goal here is to clarify and get clear answers on these questions. If the simple act of forking a repo is going to be an issue, there needs to be clearly defined contribution guidelines about that topic.
FWIW: 139 public forks of the vesc_tool project and I think I saw a 2-3 with name changes.
Andrew, pressing a button and creating a Git repository is one thing and maybe is a gray area.
Iām pretty sure Vedder is not interested in such things. If you look on the internet, you will find some cases of TM leverage in source code.
Publishing a fork under the same brand is definitely not a gray area and not OK.
Hosting a compiled, branded software without the consent of the author, is definitely not a gray area and not OK.
These are the same exact actions on GitHub, by default.
I donāt mean this in a patronizing way- but do you use GitHub for code development?
I dont want to make any assumptions here, but perhaps you are not understanding how GitHub/Forks work. One button click, from their website interface even. Itās encouraged, and part of normal workflow.
I hope you can see that a developer repository that doesnāt link to a real, publicly promoted project fork differs from a fork that distributes a compiled software to attract a mass of users.
The real issue that arises from this thread: Vedder can choose where to publish his compiled, executable VESC branded software and he can choose what version to publish. You canāt simply take a branded software release and host it without the consent of the author/TM owner. In this case you need to re-brand.
Actually, the only difference is the audience/following of the fork (so, subjective). Theyāre is zero difference otherwise. A fork is a fork. GPL doesnāt cover intent.
A fork action on GitHub, by default, forks it publicly and applies it as a separate forked repository hosted on your profile.
The other flipside to this coin is that it could also be viewed as removal of attribution should you scrub every mention of VESC from the source code. Would also require replacing logos.
If this is the intent you should have clearly defined expectations in your contribution/attribution guideline.
Iād genuinely love to get Vedderās opinion on this minus Frankās business needs being addressed. Everything we hear about this stuff is through Frank and I know that that sours a lot of us. BRING US BV
I would suggest you fork Firefox, make some changes to the code and publish executables under the Firefox brand, using their logos. Letās see what happens.
Firefox is published under a different/proprietary license, and itās ambiguous as itās published much differently than VESC, as individual portions primarily and not named āFirefox browserā as a monolithic software piece. Even in cases like Ubuntu there are distributions over torrents, for every release.
I can fork the VESC Tool to my personal GitHub account (that I also use professionally at times), and the setup a CI BuildBot (free tools integrated into GitHub) to continually merge in new updates, compile the code, and push releases to a ācompiled branchā.
It could create a new release for each subsequent release, without any further interaction once deployed. From my perspective this would be helpful as the mainline VESC tool repo doesnāt currently implement release features.
This could all be for personal use, but if suddenly a group of users starts using the automated fork, does the liability somehow suddenly increase? The situation from my perspective hasnāt changed, and as a developer it makes sense for me to have all release versions available to test against. I canāt tell people to not use my fork, so why would it cause me to become liable?
I fear you donāt have clear answers or full understanding of the interactions at play here. It would be beneficial for you, Trampa, and the community, to clarify.
Iām sure courts will draw a line somewhere and that will have to do with targeting, fair use of TM or Nominative use. TMs serve the purpose that a user can clearly identify a certain source.
The intent of trademarks in open source software is to protect the brand/associated business. Many software vendors open source their software but build a reputation and brand awareness which helps them to sell services or hardware.
I obviously cannot use the VESC or Ubuntu logos in my products or software, but they CAN be distributed. If that was not Vedderās intent, then the project needs to change licensing moving forward.
Any repository on this forum is a collection of buildsā¦ not a new product or service. The trademark is being respected and this does not violate the rules that Vedder described.
I completely agree that it was important for Vedder to trademark VESC. I do not believe that he intended to inconvenience and bully the community.
Frank - iāve read this thread a few times and iām struggling to understand what action you are specifically requesting and why. i contributed to the Wiki post and have a strong genuine desire to contribute to the community inside the bounds of the law.
I have demonstrated numerous times that iām not the brightest tool in the sandbox, so if you could help me understand what your ideal reasonable next step with the wiki post i would greatly appreciate the time.
