License about jsfbp

[jpaulm]

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.

[trustmaster]

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.

[ComFreek]

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:

1. A standard version of the package in conjunction with a description on how to obtain that package will be distributed.
2. The source code with all done modifications will be distributed as well.
3. 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!

[jpaulm]

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?

[ComFreek]

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.

[jpaulm]

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

[trustmaster]

@jpaulm could you explain what you mean by "tinkering the infrastructure"?

[jpaulm]

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...?!

[trustmaster]

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.

[ComFreek]

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.

[trustmaster]

@ComFreek 👍

[jpaulm]

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.

[ComFreek]

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? 😄)

[jpaulm]

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).

[alfa256]

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).

[jpaulm]

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 !

[trustmaster]

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.

[jpaulm]

Either one is fine by me. I note Apache grants patent rights - does this make a difference?

[alfa256]

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).

[jpaulm]

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).

[tlrobinson]

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.