Comments (21)
I have used the Artistic License -
http://opensource.org/licenses/Artistic-2.0 - for a number of years for my
JavaFBP work. Do you think this is appropriate for JSFBP (and the other
"classical" implementations on Github)?
I see some people have used the MIT License - do you know what the
difference is? There is also the GNU License - same question...
Thanks,
Paul
On Thu, Feb 5, 2015 at 10:37 AM, ComFreek [email protected] wrote:
I have just created a package.json
https://docs.npmjs.com/files/package.json for this project. (It
includes the fibers dependency, so that the installation will become as
simple as git clone ... and npm install in the cloned directory.)Every package.json should include a license field. What's the license for
the code in this repo?—
Reply to this email directly or view it on GitHub
#3.
from jsfbp.
In a nutshell: http://choosealicense.com/licenses/
MIT/BSD is so popular nowadays because it allows use in commercial products without source disclosure requirement (compared to GPL). Apache is a good choice for a permissive license as well. While Artistic license (which I used too some 12 years ago) is a bit exotic nowadays.
from jsfbp.
Artistic License
I have never used the Artistic license before, so all the information I currently have is from the German Wikipedia (which states all enforced rules and usage rights contrary to the Enlish version of the article).
The Artistic license permits you the distribution if at least one of the following conditions is met:
- A standard version of the package in conjunction with a description on how to obtain that package will be distributed.
- The source code with all done modifications will be distributed as well.
- All standard and non-standard (i.e. the modified ones) executables will be distributed. In addition, the modifications must be documented, e.g. by means of man pages.
original source: http://de.wikipedia.org/wiki/Artistic_License
I found an interesting comment at Programmers.StackExchange:
(1) The Artistic License was written for the Perl programming language in order to avoid fragmentation (e.g. a fork that wouldn't be able to execute all standard Perl programs). As a result there are no (serious) forks of the interpreter, but loads of distributions that offer precompiled versions. You want it the other way. [...]
source: http://programmers.stackexchange.com/questions/222820/license-for-free-source-redistribution-but-no-distribution-of-modified-execut#comment443296_222820, user: amon from Programmers.SE, license: CC BY-SA 3.0
GPL
GPL is AFAIK rather unpopular for products whose authors don't want to exclude commercial companies from using it without releasing their proprietary software products.
@trustmaster I didn't know that useful site. Thanks for sharing!
from jsfbp.
I notice a reference to binaries, which I assume JS doesn't have... Is there a way to make JSFBP a "black box" vis a vis any commercial products that decide to use it?
from jsfbp.
Binares from JS could be produced (embed V8, Node and the code in an executable), but why should they? Do you want to restrict commercial use?
PS: On the mailing list I heard that JSFBP could per definition only be executed on the client side. Is that true? I have not read your book, so I may be missing some parts of FBP.
from jsfbp.
No, the idea is to restrict users from tinkering with the infrastructure, unless they do a formal fork (if that's the right term). This is standard with other languages that do have binaries.
I didn't see the mailing list item, but I think that's backwards - IIUC node.js only runs on the server side, so that applies to JSFBP also. Of course you can also run it in a stand-alone bat file.
HTH
from jsfbp.
@jpaulm could you explain what you mean by "tinkering the infrastructure"?
from jsfbp.
I guess it's an extension of the "black box" concept of FBP. There are obviously different classes of user, but hopefully the majority will be (or should be) people who just use the JSFBP scheduler and our prewritten components. If they can easily make changes to these and still call the result JSFBP, then we can't support them, and we have lost any control of JSFBP that we may have had.
I guess if they play by the Github rules, that's OK - I'm just worried about unsophisticated users making uncontrolled change to their own copies of the code. Maybe an old-fashioned view...?!
from jsfbp.
If I understood it correctly, all worries are about people making changes to JSFBP in a way that is not welcomed by the authors of JSFBP and then getting in trouble because of their changes and demanding support from JSFBP authors. This is pretty covered by NO WARRANTY clause which is present in most software licenses in the world, including proprietary ones and the 3 open source licenses in question of this thread.
But if you'd like to restrict people from making changes in their JSFBP forks that are not officially (in a written form) approved by the authors of JSFBP, that's a different thing. If you want to restrict such deviating forks from using the trademark of JSFBP (r) (tm), then you should choose between Apache and Artistic license. If you want to restrict people from making such forks entirely, then this is not going to be open source.
from jsfbp.
If you want to restrict such deviating forks from using the trademark of JSFBP (r) (tm), then you should choose between Apache and Artistic license.
— trustmaster
http://choosealicense.com/licenses/ states for the Apache license with regard to trademarks:
While this may be implicitly true of all licenses, this license explicitly states that you may NOT use the names, logos, or trademarks of contributors.
— http://choosealicense.com/licenses/
But are there really people claiming support for their own forks? In addition, I must say that I've never seen people intentionally and abusively taking advantage of the original name in their open source forks.
from jsfbp.
from jsfbp.
I agree we don't want to restrict people from making their own forks, and calling it anything they like (except JSFBP)! I agree the NO WARRANTY clause covers us prretty well.
I originally chose Artistic because it says the following (I can't remember seeing this in other licenses):
You may aggregate the Package (either the Standard Version or Modified Version) with other packages and Distribute the resulting aggregation provided that you do not charge a licensing fee for the Package. Distributor Fees are permitted, and licensing fees for other components in the aggregation are permitted.
from jsfbp.
That's in fact a nice "restriction". I can't imagine a Scenario where chariging license fees for an open source product would not be malicious.
Then again, I have never seen the Artistic License in use (for any reasonably up-to-date software), so that would be a reason for others to shy away from forking, even thought it (v2 at least) is an approved OSS license: http://opensource.org/licenses/Artistic-2.0
(BTW, a malicious company can declare a licensing fee as a distributor fee to overcome the license restriction, can't it? However, do malicious companies even read licenses at all?
from jsfbp.
Based on that, let's go with whatever license you guys think will work best!
Thanks,
Paul
On Feb 6, 2015 3:31 PM, "ComFreek" [email protected] wrote:
That's in fact a nice "restriction". I can't imagine a Scenario where
chariging license fees for an open source product would not be malicious.
Then again, I have never seen the Artistic License in use (for any
reasonably up-to-date software), so that would be a reason for others to
shy away from forking, even thought it (v2 at least) is an approved OSS
license: http://opensource.org/licenses/Artistic-2.0(BTW, a malicious company can declare a licensing fee as a distributor fee
to overcome the license restriction, can't it? However, do malicious
companies even read licenses? [image:😄 ])—
Reply to this email directly or view it on GitHub
#3 (comment).
from jsfbp.
I propose MIT, it allows for private companies to use the library in their
system without having to release the source, it's similar to the Artistic
License but much more popular. Still, we are not lawyers, but most
developers prefer the MIT license. Forks can't use the same name but that's
just a copyright issue, it shouldn't matter.
The important thing here is that the meat of the open source aspect of the
project is the community creating and sharing compatible components.
2015-02-06 18:26 GMT-03:00 jpaulm [email protected]:
Based on that, let's go with whatever license you guys think will work
best!Thanks,
Paul
On Feb 6, 2015 3:31 PM, "ComFreek" [email protected] wrote:
That's in fact a nice "restriction". I can't imagine a Scenario where
chariging license fees for an open source product would not be malicious.
Then again, I have never seen the Artistic License in use (for any
reasonably up-to-date software), so that would be a reason for others to
shy away from forking, even thought it (v2 at least) is an approved OSS
license: http://opensource.org/licenses/Artistic-2.0(BTW, a malicious company can declare a licensing fee as a distributor
fee
to overcome the license restriction, can't it? However, do malicious
companies even read licenses? [image:😄 ])—
Reply to this email directly or view it on GitHub
#3 (comment).—
Reply to this email directly or view it on GitHub
#3 (comment).
from jsfbp.
The MIT license seems to mean that a commercially successful product can be based on Open Source software, with absolutely no remuneration going to the developers of said software! I know we should be doing it for the sheer joy of it... but still! Maybe any other arrangement is unenforceable, but it does seem a shame! Maybe we should try going as http://en.wikipedia.org/wiki/Donationware !
from jsfbp.
The MIT license seems to mean that a commercially successful product can be based on Open Source software, with absolutely no remuneration going to the developers of said software!
Yes, but basically you don't expect any reward from dishonest people and honest people won't hesitate rewarding you if they succeed. This is proven to work by many open source projects, like Node.js itself for instance.
I agree with Alfredo and would recommend following the best practices of the open source world by choosing either MIT or Apache. The more limitations are imposed on a project, the less likely it is that people (and companies, which is important) keep contributing to it over time.
from jsfbp.
Either one is fine by me. I note Apache grants patent rights - does this make a difference?
from jsfbp.
Apache v2 is not compatible with GPLd code, whereas MIT is. It'd be a shame
to have license problems with components.
But it's up to you @jpaulm.
2015-02-07 11:49 GMT-03:00 jpaulm [email protected]:
Either one is fine by me. I note Apache grants patent rights - does this
make a difference?—
Reply to this email directly or view it on GitHub
#3 (comment).
from jsfbp.
I'm fine with MIT. Thanks to you both for all the research!
Regards,
Paul
On Sat, Feb 7, 2015 at 10:41 AM, alfa256 [email protected] wrote:
Apache v2 is not compatible with GPLd code, whereas MIT is. It'd be a shame
to have license problems with components.
But it's up to you @jpaulm.2015-02-07 11:49 GMT-03:00 jpaulm [email protected]:
Either one is fine by me. I note Apache grants patent rights - does this
make a difference?—
Reply to this email directly or view it on GitHub
#3 (comment).—
Reply to this email directly or view it on GitHub
#3 (comment).
from jsfbp.
I'm late to the game, but +1 for a permissive license like MIT or Apache. For something as foundational as a FBP runtime I think you want it as widely used as possible.
from jsfbp.
Related Issues (20)
- Travis broken in Oct. 25 this year - commit 44bd142 HOT 6
- Dependency Dashboard
- Not keen on 2nd parameter of defProc function in Network.js HOT 4
- Add to npm HOT 7
- collate test fails
- Composite components
- Following README on Win 7 doesn't work HOT 10
- Set up Travis testing HOT 1
- Add support for .fbp files HOT 1
- Expose IP types on the Process object HOT 1
- Empty IIPs are treated incorrectly
- Strange behaviour when an IIP and OutPort connect to the same InPort HOT 2
- Switch to associative arrays where appropriate
- Add automatic ports HOT 5
- Add external ports
- Need to reinstate send suspend logic HOT 30
- Set up Renovate HOT 1
- Publish new NPM version 3.0.0 HOT 4
- Can't install fibers HOT 1
- Action Required: Fix Renovate Configuration
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jsfbp.